選擇和使用測試方法和工具
- 按照測試需求用途（或測試技巧）選擇
- 在軟件開發生命周期和軟件測試流程中適當地選擇
- 按照測試人員實際技能選擇
- 選擇可提供的和可執行的
測試方法
| 類別及技巧 | 目標 | 使用方法 | 舉例 | 適合場景 |
|---|---|---|---|---|
| 壓力測試 | 模擬出實際用戶環境 | 產生測試數據;測試組模擬用戶處理被創建的數據 | 確定是否分配了足夠的磁盤空間;通訊的容量是否足夠;測試系統過載的情況 | 關於容量的信息不確定 |
| 性能測試 | 確定系統達到了希望達到的性能水平 | 使用軟件和硬件的監視器;使用模擬的監控模型，對關心的性能指標進行監控;創建一個小程序; | 計算通信的時間;單位時間處理的信息量; | 程序開發的早期 |
| 恢復測試 | 當在進行安裝或組裝操作過程中，文件丟失時或發生意外后系統有能力重新進行操作 | 程序的安裝，運行方式，工具的使用和關鍵技術經過足夠的評估;系統開發完畢后，介紹一下發生失敗后的處理過程 | 人為的使一個系統在安裝或者組裝過程中產生錯誤 | 當操作的連續性是個重點的時候 |
| 操作測試 | 確定操作文檔已經完整 | 作為計算機正常操作的一部分來執行測試 | 操作的介紹被文檔化，操作者被培訓 | 預先將程序進行產品化。操作性是系統的一個重要指標 |
| 復合性測試（與過程的復合性） | 校驗程序的開發是否依照已定義的標准，流程和操作方式進行的。 | 將文檔/程序同標准相比較,比較有效的方法是檢查過程 | 代碼互查（一行一行） | 依賴於管理的需要 |
| 安全性測試 | 安全性的缺陷很難被發現;大多數的情況下組織能夠防止一般性的破壞者。 | 對安全性的需求進行評審;分析與安全性有關的處理流程;轉包給專業的人員; | 定義了被保護的資源，權限進行了控制，日志文件和審查追蹤是可用的。 | 當被保護的資源對於組織具有重要的價值 |
| 需求測試 | 用戶的需求可以被實現 | 創建測試用例和功能檢查列表 | 建立測試矩陣去證實系統需求均被文檔化 | 每一個應用程序都要進行需求測試 |
| 回歸測試 | 程序修改后，確保功能的正確性 | 重新測試應用程序中沒有改變的部分 | 重新執行以前的測試用例 | 當新的程序有可能影響老的功能 |
| 錯誤處理測試 | 所有可能的錯誤條件均經過了驗證 | 一組有經驗的人員預測在那里會出現問題 | 建立一個錯誤處理的列表 | 貫穿整個開發生命周期 |
| 支持手冊測試 | 檢驗操作過程被完整地文檔化了 | 對過程有足夠的介紹;可以協助用戶正常使用 | 系統在一定的條件下產生一個提示，用戶被告知如何采取必要的操作。 | 最佳時機是在安裝測試的時候，但是應該在開發全過程中。 |
| 系統兼容測試 | 檢驗當使用適當的參數和數據時，需要的信息可以在兩個系統中正確的交換 | 文件和數據被用來在多系統之間傳遞。 | 典型的由一個系統到另一個系統的數據交換程序。 | 兩個應用程序之間的參數有可能發生變化 |
| 控制性測試 | 驗證數據交換時有足夠的審計追蹤能力 | 關鍵數據或者有價值的數據 | 從負面來看程序，是否確保了會出錯的條件都被保護了。 | 系統測試的一部分 |
| 並行測試 | 新版本和老版本同時運行，用以確保新版本的程序運行正確。 | 需要對兩個系統輸入相同的數據來運行 | 運行新舊兩個工資支付系統 | 不確定新系統的的運行情況 |
測試工具
| 階段 | 測試工具 | 備注 |
|---|---|---|
| 需求 | 檢查表、實況調查與驗證、流程圖、需求模型、錯誤推測、風險列表、打分表、走查（講解開發思路）、...... | |
| 設計 | 因果圖、檢查表、實況調查與驗證、正確性數據、評審、錯誤推測、執行規范、流程圖、設計模型、風險列表、打分表、測試用例、走查（講解開發思路）、...... | |
| 編碼 | 邊界值分析、因果圖、檢查表、實況調查與驗證、編譯分析、基礎復雜度、控制流分析、覆蓋測試對照表、數據流分析、錯誤推測、流程圖、映射圖、代碼互查、完成特征、測試用例、跟蹤、走查（講解開發思路）、...... | |
| 測試 | 確認測試標准、邊界值分析、檢查表、實況調查與驗證、基礎復雜度、控制流分析、覆蓋測試對照表、數據字典、功能性測試、災難性測試、錯誤推測、全面測試、測試儀器、並行模擬、代碼互查、系統日志、測試用例的產生及執行、程序及工具、容量測試、...... | |
| 安裝 | 確認測試標准、檢查表、實況調查與驗證、錯誤推測、全面測試、測試儀器、並行操作、代碼互查、系統日志、程序及工具、...... | |
| 維護 | 檢查表、代碼比較、實況調查與驗證、災難性測試、錯誤推測、測試儀器、綜合測試工具、代碼互查、系統控制審計評審、系統日志、測試用例的產生及執行、跟蹤、程序及工具、...... |
UT - IT - ST
| 測試過程 | 單元測試（UT） | 接口測試（IT） | 系統測試（ST） |
|---|---|---|---|
| 定義 | 是對軟件基本組成單元（軟件設計的最小單位）進行正確性檢測，如函數或一個類的方法。 | 通常所說的接口聯調，是單元測試的邏輯擴展。在單元測試的基礎上，將所有模塊按照HLD要求組裝成為子系統或系統，驗證模塊間的接口是否正確的。 | 將已經集成好的軟件系統，作為整個基於計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。 |
| 測試依據 | 源程序本身，包括代碼和注釋；詳細設計(LLD，Low Level Design) | 單元測試的模塊；概要設計(HLD，High Level Design) | 軟件需求規格說明（SRS，Software Requirement Specification） |
| 測試目的 | 與LLD是否符合 | 與HLD是否符合 | 與SRS是否符合 |
| 測試方法 | 屬於白盒測試范疇 | 屬於灰盒測試范疇 | 屬於黑盒測試范疇 |
| 考察范圍 | 主要測試單元內部的數據結構、邏輯控制、異常處理等 | 主要測試模塊之間的接口和接口數據傳遞關系，以及模塊組合后的整體功能 | 主要測試整個系統相對於需求的符合度 |
| 評估基准 | 邏輯覆蓋率 | 接口覆蓋率 | 測試用例對需求規格的覆蓋率 |
| 評估基准的方法 | TDD，測試驅動開發 | 每個接口被覆蓋的程度；每個接口的等價類、邊界值被覆蓋的程度 | 等價類兩兩組合；邊界值分析；業務流程法；狀態遷移法；錯誤猜測法；輸出域覆蓋 |
| 被測對象 | 一個或一組函數 | 子系統、模塊間接口 | 完整的軟件系統及系統交互的軟硬件平台 |
| 測試時機 | 編碼之后，代碼已經通過編譯之后 | 在單元測試之后 | 集成測試之后 |
| 測試人員 | 開發人員或白盒測試工程師 | 函數間/模塊內集成是開發人員；模塊間集成是白盒測試員;子系統間集成是黑盒測試員； | 黑盒測試工程師 |
| 測試通過標准 | 單元測試用例的執行率為100%，通過率為95%；語句的覆蓋率達100%；分支的覆蓋率達85% | 各個單元模塊結合到一起能夠協同配合，正常運行；測試用例的執行率為100%，通過率為95% | 系統功能、性能等滿足需求規格說明書中的要求；測試用例的執行率為100%，通過率為95% |
| 測試策略 | 控制流測試、數據流測試、排錯測試、分域測試等 | 大爆炸、自頂向下測試、自底向上測試、三明治 | 功能測試、性能測試、隨機測試等 |