1.軟件測試工程師的素質：

良好的溝通和表達能力

具有懷疑與破壞的精神

扎實的軟件測試基礎知識

縝密的業務邏輯分析能力

處在用戶的角度進行換位思考

足夠的耐心、細心、信心、責任心

積極樂觀向上的心態和團隊協作能力

要有嚴謹、敢于承擔責任、穩重的做事風格

善于自我總結、自我督促和不斷學習的能

?

2.軟件的分類：

軟件?=?程序?+?數據?+?文檔。

　　按照功能劃分：

　　　　系統軟件：如操作系統、數據庫管理系統，各種驅動軟件等

　　　　應用軟件：如Office、金山詞霸、QQ等

　　按照技術結構劃分：

　　　　單機版本：如Office，畫圖工具等

　　　　C/S結構軟件：如QQ、MSN等

　　　　B/S結構軟件：如新浪、搜狐、google等

　　按照用戶劃分：

　　　　產品軟件：Office、財務處理軟件、金山毒霸等

　　　　項目軟件：如為企業定制的OA系統等

　　按照開發規模劃分：

　　　　類別??參與人數? ? ?開發時間

　　　　小型??10人以下 ?1-4個月

　　　　中型??10-100人 ?1年以下

　　　　大型??100人以上 ?1年

3.軟件測試的對象：

① 源程序/目標代碼

② 各開發階段的文檔（需求規格說明、概要設計說明、詳細設計說明及其它相關文檔）

4.軟件測試的目的：
軟件測試的目的是盡可能多的發現軟件缺陷。檢查系統是否滿足需求，站在用戶角度思考產品或項目功能實現的正確性。

測試并不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特征。可以幫助項目管理者發現當前所采用的軟件過程的缺陷，以便改進。同時，通過分析也能幫助我們設計出有針對性的檢測方法，改善測試的有效性。

5.軟件測試的原則

0）所有測試的都應以軟件設計需求規格說明書為標準進行。

1）應當把“盡早地不斷地進行軟件測試“作為軟件開發者的座右銘。

2）程序員應避免檢查自己的程序。

3）充分注意測試中的群集現象。

4）嚴格執行測試計劃，排除測試的隨意性。

8）妥善保存測試計劃、測試用例、出錯統計和最終分析報告，為維護提供方便。

5）完全測試是不可能的

6.軟件測試分類

?

單元測試：

單元測試又稱模塊測試，針對軟件設計中的最小單位——程序模塊，進行正確性檢查的測試工作。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。

單元定義:

C中指一個函數，Java中指一個類，在圖形化的軟件中，單元一般指1個窗口，1個菜單。

如何進行單元測試：

單元測試主要用白盒測試，先靜態地檢查代碼是否符合規范，然后動態運行代碼，檢查其實際運行結果，檢查程序的運行結果是否正確是一個最基本的要求，還要關注容錯處理，程序的邊界值處理等。

集成測試：

集成測試又叫組裝測試，通常在單元測試的基礎上，將所有程序模塊進行

有序的、遞增的測試。重點測試不同模塊的接口部分。

系統測試：

指將整個軟件系統看為一個整體進行測試，包括對功能、性能、以及軟件所運行的軟硬件環境進行測試。

驗收測試：

驗收測試指按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的對整個系統的測試與評審，決定是否接收或拒收系統。在系統測試的后期，以用戶測試為主或有測試人員等質量保證人員共同參與的測試。

α測試：指的是指的是由用戶，測試人員、開發人員等共同參與的內部測試。

β測試：指的是內測后的公測，即完全交給最終用戶測試

驗收測試的重要性：驗收簽字,收錢。

靜態測試：

指不實際運行被測軟件，而只是靜態地檢查程序代碼、界面和文檔中可能存在的錯誤的過程。

動態測試：

指實際運行被測程序，輸入相應的測試數據，檢查實際輸出結果與預期結果是否相符。（動態測試方法為結構和正確性測試；動態測試工具Robot、QTP等）

黑盒測試：

指的是把被測的軟件看做一個黑盒子，我們不關心盒子里面的結構是什么樣子的，只關心軟件的輸入數據和輸出

白盒測試：

指的是把盒子打來，去研究里面的源代碼和程序結構。

軟件公司中，往往采用黑盒測試&白盒測試相結合的方式。

（靜態黑盒測試：看文檔，看頁面等

靜態白盒測試：看源代碼等

動態黑盒測試：使用軟件等

動態白盒測試：運行源代碼等）

灰盒測試：

是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。

功能測試：

是黑盒測試的一方面，它檢查實際軟件的功能是否符合用戶的需求。

邏輯功能測試(functiontesting)

界面測試(UItesting)

易用性測試(usability testing)

安裝測試(installationtesting)

兼容性測試(compatibilitytesting)

性能測試：

是軟件測試的高端領域，通常我們所說的高級軟件測試工程師一般就是指性能測試或是白盒測試工程師。

時間性能（事務響應時間等）

空間性能（系統資源消耗）

一般性能測試

可靠性測試

負載測試

壓力測試

回歸測試：

指對軟件的新版本測試時，重復執行上一個版本測試時的用例。

冒煙測試：

是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測試性。

隨機測試：

是指測試中所有的輸入數據都是隨機生成的，其目的是模擬用戶的真實操作，并發現一些邊緣性的錯誤。

7.軟件測試的常用種類：

黑盒測試：把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。

黑盒測試方法包括：等價類劃分、邊界值分析、因果圖分析、錯誤推測法、功能圖分析等。

等價類劃分：

為了保證軟件質量，需要做盡量多的測試。但不可能用所有可能的輸入數據來測試程序，即窮盡測試不可能。因此可以選擇有代表性的數據來測試程序。

等價類是某個輸入域的集合，在這個集合中的每個輸入條件都是等效的。

等價類分為有效等價類和無效等價類。

劃分等價類重要的是：集合的劃分，劃分為互不相交的一組子集，而子集的并集是整個集合。

參考鏈接：https://wenku.baidu.com/view/c491516fa45177232f60a2c4.html

邊界值分析：

邊界值分析法就是對輸入或者輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充。

邊界值分析法與等價類劃分的區別

1.邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

2.邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。

注：

字符的邊界值檢驗：在計算機軟件中，字符也是很重要的表示元素，其中ASCII和Unicode是常見的編碼方式。下表中列出了一些常用字符對應的ASCII碼值。

?

字符	ASCII碼值	字符	ASCII碼值
空 (null)	0	A	65
空格 (space)	32	a	97
斜杠 ( / )	47	Z	90
0	48	z	122
冒號 ( : )	58	單引號 ( ‘ )	96
@	64	?	?

因果圖分析

等價類劃分方法和邊界值分析方法，未考慮輸入條件之間的聯系，相互組合。考慮輸入條件之間的相互組合，可能會產生新的情況。因果圖方法最終生成的就是判定表，適合于檢查程序輸入條件的各種組合情況。

錯誤推測法

基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

錯誤猜測法并非是一項有章可循的工程設計方法，而是很大程度上依賴于測試人員的經驗、能力以及態度。從個人測試經驗角度來看，在考慮使用錯誤猜測法補充測試用例時，可以從如下維度考慮：

A.極限值設計：考慮數值最大、最小、為空、為0等情況。

B.特殊取值設計：

• 年、月、日情況，必須考慮平年、閏年，2月，每月包含28天、29天、31天等情況。同時考慮跨年、跨月等情況。
• 模糊查詢情況，考慮"."、"%"、"？"等特殊字符取值情況。原因是這些字符在SQL中有它指定的含義。
• 其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#...）等。

C.特殊組網考慮：測試場景的考慮必須考慮版本使用局點的組網情況，特別是一些特殊的組網，比如網元主備、容災等。曾經出現過某token使用未考慮同步到備機，導致業務出現故障后切換備機，業務運行失敗的問題。

D.端到端用例考慮：通常測試用例都是以特性為維度進行設計，或者測試人員在用例執行時都是分功能進行測試用例設計和執行，并未進行端到端測試用例設計。而端到端的測試用例更容易發現問題。以充值轉賬功能為例。端到端的用例場景包括：用戶開戶（用戶模型）->用戶轉賬（不同用戶層級間，所有的轉賬接口轉賬） -> 用戶充值（預付費、后付費，所有的充值接口） -> 交易記錄查詢（所有的查詢接口）。當然，如果有必要。這里還需要考慮用戶的類型、交易渠道等。

E.性能角度考慮：測試場景補充設計時必須要考慮性能情況，特別是未針對核心特性進行性能場景驗證的情況。最經常出現的性能問題是報表查詢（功能測試時未考慮交易記錄數），包括充值交易記錄查詢、轉賬記錄查詢等涉及大業務量數據的測試。類似的功能包括報表測試或者核心交易邏輯的測試。業務數據量（交易記錄數）一定需要與現網數據量保持一致。

F.安全角度考慮：是否考慮不同用戶權限功能使用情況、日志中是否有明文顯示用戶隱私信息、用戶登錄是否安全校驗機制（如密碼連續3次輸入錯誤鎖賬戶、驗證碼）、是否允許越權、前后臺校驗是否一致等等。

G.可維護性考慮：新開發特性出現問題時，已知日志信息是否可以快速定位問題故障。如果沒有，需要增加日志信息。

H.用戶體驗：提示信息描述是否合理、搜索出現單條記錄是否默認選中、交互次數是否太多、界面操作是否簡潔、新增菜單風格是否與已知菜單保持一致。

I.功能實現與規格描述是否一致：功能實現是否與規格描述一致。是否存在規格中描述但實際特性缺失或者規格中未描述但存在多于交付特性。無特殊情況，交付功能需與規格內容保持一致。另外一點，產品的某些特性需要在不同模塊中同時滿足。比如新增某充值功能，需要界面模塊和業務模塊兩種接入方式同時支持。

J.輸出域考慮：用例設計需針對輸出域情況進行分類考慮。一個是針對輸出情況設計輸入條件，另外一個是針對輸出內容的使用途徑進行補充用例設計。比如某特性是針對充值功能的話單記錄新增一個字段，也就是話單發生了變化。那么必須要考慮后臺對邏輯對話單的處理是否能夠成功將新增字段的話單入庫到充值歷史記錄表。

K.隱含功能測試考慮：比如客戶要求歷史交易功能查詢，客戶通常僅會要求輸入條件和查詢方式，并會針對隱含功能如交易記錄展示的分頁、跳轉、單頁默認顯示行數等內容。但測試設計時必須針對這些隱含功能進行測試。

L.針對不同開發考慮用例設計：這一條情況比較特殊。版本的缺陷會因人而異，同樣的特性會由于開發能力、開發態度、開發自驗證程度的不同而產生不同的bug。特別注意新員工、自驗證隨意的開發人員，你會發現有很多"驚喜"。但這些"驚喜"沒有在版本發布前發現，就會成為"驚嚇"了

參考鏈接：https://zhuanlan.zhihu.com/p/121831069

白盒測試：是對軟件的過程性細節做細致的檢查。是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。

白盒測試方法包括：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋等。

單元測試：是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟件動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。一個軟件單元的正確性是相對于該單元的規約(詳細設計)而言的。因此，單元測試以被測試單位的規約為基準。

單元測試方法包括：控制流測試、數據流測試、排錯測試、分域測試等。

集成測試：是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。

系統測試：是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等滿足其規約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它被稱為測試的“先知者問題”。因此，系統測試應該按照測試計劃進行，其輸入、輸出和其他動態運行行為應該與軟件規約進行對比。軟件系統測試方法很多，主要有功能測試、性能測試、隨機測試等。

驗收測試：由客戶或最終用戶執行，旨在向軟件的購買者展示該軟件系統滿足其用戶的需求。它的測試數據通常是系統測試的測試數據的子集。所不同的是，驗收測試常常有軟件系統的購買者代表在現場，甚至是在軟件安裝使用的現場。這是軟件在投入使用之前的最后測試。

UAT測試：

UAT，(User Acceptance Test),也就是用戶驗收測試，或用戶可接受測試，系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。 它讓系統用戶決定是否接收系統。 它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。

功能測試：對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。

性能測試：是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。

用戶視角的軟件性能：

• 從用戶角度來說，軟件性能就是軟件對用戶操作的響應時間。

系統管理員視角的軟件性能：

• 系統的響應時間；
• 系統運行時服務器的狀態，如CPU利用情況、內存使用情況等；
• 系統是否能夠實現擴展；
• 系統支持多少用戶訪問；
• 系統性能可能的瓶頸在哪里；
• 系統是否支持7*24小時的業務訪問。

軟件性能指標：

• 并發用戶：一給定時間內，某個時刻與服務器同時進行會話操作的用戶數。
• 響應時間：客戶端發出請求到得到服務器返回結果的整個過程所經歷的時間。
• 吞吐量：單位時間內系統處理的客戶請求的數量；一般來說，吞吐量用請求數/秒或頁面數/秒來衡量；從業務的角度，吞吐量也可以用訪問人數/天或處理的業務數/小時等單位來衡量；從網絡的角度來說，也可以用字節數/天等單位來考察網絡流量。
• 資源利用率：指系統資源的使用程度，比如服務器的CPU利用率、內存利用率、磁盤利用率、網絡帶寬利用率等。

負載測試：

• 定義
  • 數據在超負荷環境下運行，測試軟件系統是否能夠承擔。這種超負荷主要指多并發用戶。
• 方法
  • 人為生成大數據量，并利用工具模擬頻繁并發訪問
• 工具
  • 一般需要使用自動化工具
• 考察指標
  • 響應時間、交易容量、資源使用率等

壓力測試：

• 定義
  • 指系統不斷施加越來越大的負載（并發，循環操作，多用戶，網絡流量）的測試。
• 目標
  • 通過確定一個系統的瓶頸或者不能接收的性能點，來確定系統能提供的最大服務級別的測試。

恢復測試：恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。如果系統恢復是自動的（即恢復由系統自身完成），則應該檢驗以下內容：重新初始化、檢驗點設置機構、數據恢復以及重新啟動是否正確。

可用性測試：

可用性測試是面向用戶的系統測試。讓一群有代表性的用戶嘗試對產品進行典型操作，- - 同時觀察員和開發人員在一旁觀察，聆聽，做記錄。

• 系統中是否存在繁瑣的功能以及指令；
• 安裝過程是否復雜；
• 錯誤信息提示內容是否詳細；
• GUI接口是否標準；
• 登錄是否方便；
• 需要用戶記住內容的多少；
• 幫助文本是否詳細；

兼容性測試：

• 定義
  • 測試軟件在一個特定的硬件、軟件、操作系統、網絡等環境下系統能否正常運行。
• 目的
  • 檢驗被測軟件對其他應用軟件或者其他系統的兼容性。

安全性測試：

• 定義
  • 安全測試檢測系統對非法入侵的防范能力。
• 應用程序級別的安全性測試
• 數據庫安全性測試
• 系統級別的安全性測試

Alpha測試：由用戶在開發者的場所進行，并且在開發者對用戶的“指導”下進行測試。開發者負責記錄發現在錯誤和使用中遇到的問題。總之，Alpha測試是在受控的環境中進行的。

Beta測試：由軟件的最終用戶們在一個或多個客房場所進行。與Alpha測試不同，開發者通常不在Beta測試的現場，因Beta測試是軟件在開發者不能控制的環境中的“真實”應用。用戶Beta測試過程中遇到的一切問題（真實在或想像的），并且定期把這些問題報告給開發者。接收到在Beta測試期間報告的問題之后，開發者對軟件產品進行必要的修改，并準備向全體客戶發布最終的軟件產品。

冒煙測試：可以根據其名稱理解為該種測試耗時短，僅用一袋煙功夫足夠了；其實是對軟件基本的功能進行測試，測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本的功能正常，保證軟件系統能跑的起來，可以進行后續的正式測試工作。

回歸測試：是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤，回歸測試的困難在于不好確定哪些內容應當被重新測試。

隨機測試：主要是根據測試者的經驗對軟件進行功能和性能抽查。它是根據測試說明書執行樣例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。

動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率和健壯性等性能，這種方法由三部分組成：構造測試實例、執行程序、分析程序的輸出結果。所謂軟件的動態測試，就是通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。目前，動態測試也是公司的測試工作的主要方式。

靜態測試：是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態測試結果可用于進一步的查錯，并為測試用例選取提供指導。

UI測試：指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面美工是否好看，文字，圖片組合是否完美，背景是否美觀，操作是否友好等；用戶界面(UI)測試用于核實用戶與軟件之間的交互。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，并符合公司或行業的標準。包括用戶友好性，人性化，易操作性測試。UI測試比較主觀，與測試人員的喜好有關。

自動化測試：利用軟件測試工具自動實現全部或部分測試，它是軟件測試的一個重要組成部分，能完成許多手工測試無法實現或難以實現的測試；正確、合理的實施自動測試，能夠快速、全面的對軟件進行測試，從而提高軟件質量，節省經費，縮短軟件發布周期。

樁測試：

樁的英文是stub；是指一個軟件模塊的框架或特殊目標實現，主要用于開發和測試一個組件，該組件調用或依賴這個模塊。

樁模塊：集成測試前要為被測模塊編制一些模擬其下級模塊功能的“替身”模塊，以代替被測模塊的接口，接受或傳遞被測模塊的數據，這些專供測試用的“假”模塊稱為被測模塊的樁模塊。

測試樁一般是 自頂向下集成時需要使用

驅動測試：

所謂驅動測試（自底向上集成時使用），就是你負責測試模塊/方法是中間的，沒有main（）入口，怎么編譯，怎么啟動呢？就需要寫一個帶main()的方法來調用你的模塊/方法

樁模塊的使命除了使得程序能夠編譯通過之外，還需要模擬返回被代替的模塊的各種可能返回值(什么時候返回什么值需要根據測試用例的情況來決定)。

驅動模塊的使命就是根據測試用例的設計去調用被測試模塊，并且判斷被測試模塊的返回值是否與測試用例的預期結果相符

public class ddd{//Test driverpublic static void main(String[] args) {ddd d = new ddd();d.Add();}//My modulepublic int Add() { int output=this.Stub1() + this.Stub2();System.out.print("My module: return value is "+output+"\n");return output; }//Stub1public int Stub1() { int output=3;System.out.print("Stub 1 : return value is "+output+"\n");return output;}//Stub2public int Stub2() {int output=7;System.out.print("Stub 2 : return value is "+output+"\n");return output;}}

測試用例八大設計方法

測試方法分類：

• 黑盒測試 ：等價類劃分 邊界值分析 因果圖分析 錯誤測試
• 白盒測試：語句覆蓋 判定覆蓋 條件覆蓋 判定/條件覆蓋 多重條件覆蓋

等價類劃分方法

等價類劃分：指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的，并合理地假定；測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據，取得較好的測試結果。

等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

邊界值分析方法

邊界值：是對等價類劃分方法的補充，測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

錯誤推測方法

錯誤推測：基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。例如：在單元測試時曾列出的許多在模塊中常見的錯誤。以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件,但未考慮輸入條件之間的聯系，相互組合等。考慮輸入條件之間的相互組合，可能會產生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。

判定表驅動分析方法

判定表：是分析和表達多邏輯條件下執行不同操作的情況的工具。

正交表設計分析方法

有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

功能圖分析方法

功能圖：由狀態遷移圖和布爾函數組成，狀態遷移圖用狀態和遷移來描述。一個狀態指出數據輸入的位置（或時間），而遷移則指明狀態的改變。同時要依靠判定表或因果圖表示的邏輯功能。

場景模擬分析方法

指根據用戶場景來模擬用戶的操作步驟,這個比較類似因果圖,但是可能執行的深度和可行性更好。

軟件測試基本流程

軟件測試的基本流程（文字描述）

1測試需求分析階段：閱讀需求，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議

2制定測試計劃階段：主要任務就是編寫測試計劃，參考軟件需求規格說明書，項目總體計劃，內容包括測試范圍（來自需求文檔），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規避措施有一個制定。

3測試設計階段：主要是編寫測試用例，會參考需求文檔（原型圖），概要設計，詳細設計等文檔，用例編寫完成之后會進行評審。

4測試執行階段：搭建環境，執行冒煙測試（預測試）-然后進入正式測試，bug管理直到測試結束

5測試評估階段：出測試報告，確認是否可以上線

人工測試技術

從心理學的角度出發思考，下面兩個方面顯著地提高了測試的功效和可靠性

首先，人們普遍認識到錯誤發現得越早，改正錯誤的成本越低，正確改正錯誤

的可能性也越大。

其次，程序員在開始基于計算機的測試時似乎要經歷一個心理上的轉變。從內部產生的壓力似乎會急劇增長，并產生一個趨勢，要“盡可能快地修正這個缺陷”。由于這些壓力的存在．程序員在改正某個由基于計算機測試發現的錯誤時所犯的失誤，要比改正早期發現的問題時所犯的失誤更多一些。

檢查與走查(Inspections And Walkthroughs)

代碼檢查與走查是兩種主要的人工測試方法

代碼檢查與走查都要求人們組成一個小組來閱讀或直觀檢查特定的程序。無論采用哪種方法，參加者都需要完成一些準備工作。準備工作的高潮是在參加者會議上進行的所謂“頭腦風暴會”。“頭腦風暴會”的目標是找出錯誤來，但不必找出改 正錯誤的方法。換句話說，是測試，而不是調試

代碼檢查是以組為單位閱讀代碼，它是一系列規程和錯誤檢查技術的集合。對代碼檢查的大多數討論都集中在規程、所要填寫的表格等。

這個代碼檢查過程通常將注意力集中在發現錯誤上，而不是糾正錯誤。

軟件生命周期

是指從軟件的產生直到報廢的整個周期，包括可行性分析與項目計劃，需求分析，概要設計和詳細設計，編碼，調試，維護七個階段。

軟件測試生命周期

是指從測試項目計劃建立到BUG提交的整個測試過程，包括軟件項目測試計劃，測試需求分析，測試用例設計，測試用例執行，BUG提交五個階段。

也可以是（測試計劃 → 測試設計 → 測試開發 → 測試執行 → 測試評估）。

軟件測試生命周期并行與軟件生命周期，存在于軟件生命周期的各個階段。

軟件測試人員的主要職責

編寫測試計劃

設計測試用例

執行測試，發現缺陷提交測試報告

驗證缺陷是否得到修改

編寫測試總結報告

軟件測試的原則 ：

十項原則

1 測試用例中一個必需部分是對預期輸出或結果進行定義

2 程序員應避免測試自己編寫的程序

3 編寫軟件的組織不應當測試自已編寫的軟件

4 應當徹底檢查每個測試的執行結果

5 測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況

6 檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程是 否“做了其不應該做的”

7 應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

8 計劃測試工作時不應默許假定不會發現錯誤

9 程序某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比

10 軟件測試是一項極富創造性，極具智力的挑戰性的工作

三個重要的測試原則：

? 軟件測試是為發現錯誤而執行程序的過程。

? 一個好的測試用例具有較高的發現某個尚未發現的錯誤的可能性。

? 一個成功的測試用例能夠發現某個尚未發現的錯誤。

優秀的軟件測試人員需要具備的素質和技能

良好的溝通和表達能力

具有懷疑與破壞的精神

扎實的軟件測試基礎知識

縝密的業務邏輯分析能力

處在用戶的角度進行換位思考

足夠的耐心、細心、信心、責任心

積極樂觀向上的心態和團隊協作能力

要有嚴謹、敢于承擔責任、穩重的做事風格

善于自我總結、自我督促和不斷學習的能力

常用測試工具

1、Apache JMeter是一個Apache項目，可用作負載測試工具，用于分析和測量各種服務的性能，重點關注Web應用程序。

做壓力測試的步驟如下:

1. 寫腳本 或者錄制腳本

2. 使用用戶自定義參數

3. 場景設計

4. 使用控制器，來控制 模擬多少用戶。

5. 使用監聽器， 查看測試結果

總結

以上是生活随笔為你收集整理的软件测试面试1--软件测试基础理论（持续更新中...）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。