(一)、測試計畫的定義與原則

1. 測試計畫的定義
   • IEEE 829-1983測試計畫的定義及目的
     • 一個敘述了預定的測試活動的範圍、途徑、資源及進度安排的文件。它確認了測試項目、被測特徵、測試任務以及任何偶發事件的風險。
2. 測試計畫的編寫原則
   • 明確的測試目標，增強測試計畫的實用性
   • 5W規則(What、Why、When、Where、How)，明確內容與過程
   • 採用評審和更新機制，保證測試計畫滿足實踐需求
   • 測試計畫中不要包含詳細的測試技術指標、測試步驟和測試案例
     • 測試計畫與詳細的測試規則是戰略與戰術的關係。
3. 測試計畫的主要工作
   • 確定測試資源
   • 工作量估算、里程碑和進度安排
   • 風險分析
   • 制定測試策略
   • 編寫計畫書

(二)、確定測試資源

1. 測試資源的分類

2. 測試資源的規劃
   • 初期：測試組長參與需求評審、確認測試需求和測試範圍、制定測試策略和測試計畫等等
   • 測試前期：資深測試設計人員、測試腳本或測試工具開發人員負責軟體測試需求的制定和分解、設計測試案例、開發測試腳本。
   • 測試中期：測試執行，測試人員的數量取決於自動化程度。
   • 測試後期：資深測試人員可以抽出部分時間進行新專案的準備工作。

(三)、工作量估算、里程碑和進度安排

1. 工作量估算
   1. 怎麼確定測試工作量
      • 測試的工作量依據測試範圍、測試任務和開發階段來判斷
        • 自動化的程度越低，測試的工作量越高，但是在大多數情形下，自動化測試無法大幅度降低工作量，因為測試腳本的開發工作量也會很高。
   2. 任務細分
      • 工作分解結構表(WBS)方法
        • 列出本專案需要完成的各項任務
        • 對每一個任務進一步細分，可進行多層細分，直到不能細分為止。
        • 根據任務的層次給任務進行編號
   3. 測試工作量估算
      • 考慮回歸測試(如2~3輪)
      • W=Wo+Wo×R1+Wo×R2+Wo×R3
      • W為總工作量，Wo為一輪測試的工作量
      • 在程式碼品質較低的情況下，假定R1、R2、R3分別為80%、60%、40%，如果一輪功能測試的工作量為100個人天，則總測試工作量為280個人天
      • 如果程式碼品質較高，一般只需要進行兩輪的回歸測是，R1跟R2也降到60%、30%，總測試工作量為190個人天，工作量減少32%
2. 里程碑和進度安排
   1. 里程碑 - 定義當前階段完成的標準和下一個階段啟動的條件。
   2. 里程碑的特點
      • 具有很強的時序性，可以有層次(父里程碑、子里程碑)
      • 不同類型的專案，里程碑可能不同。
      • 不同規模專案的里程碑，數量不同，里程碑可以合併或分解。
   3. 軟體測試中常用的里程碑 - 測試計畫通過、測試案例通過、自動化測試腳本完成、功能測試完成、性能測試完成等。
   4. 進度安排 - 確定定里程碑的起始點，評估父里程碑與子里程碑需要的時間。

(四)、測試風險分析與管理

1. 風險識別
   • 建立風險項目檢查表，將測試範圍、測試過程中的風險識別出來，按風險的內容進行檢查確認，分辨出哪些是可以避免哪些是無法避免的，對可避免的風險要盡量採取措施避免
2. 風險評估
   • 從成本、進度和性能三個方面對風險進行評估，通過評估可以確定這些風險的特點或可能帶來的危害，根據風險發生的概率和帶來的影響確定風險的優先級。
3. 風險控制
   • 制定風險管理計畫和風險應急處理方案，降低風險和消除風險
     • 列出風險、可能性、潛在的影響、嚴重性、預防/處理措施
   • 估算資源、時間、預算要留有餘地，不要用到100%
   • 制定文件標準並建立一種機制，確保文件即時產生，對所有工作多進行互相審查，及時發現問題。

(五)、制定測試策略

1. 什麼是測試策略
   • 描述當前測試項目的目標和所採用的測試方法
   • 描述時程中哪些測試內容須要完成，軟體產品的特性或品質在哪些方面得到確認
   • 描述不同階段(單元測試、整合測試、系統測試)的測試對象、範圍和方法
   • 描述每個階段內要進行的測試類型(功能測試、性能測試、壓力測試等)
2. 分階段的測試策略
   • 嚴格執行code review，盡可能在早期就發現問題，而非版本發布之後。
   • 利用單元測試和整合測試更早的發現問題，並準備好自動化測試的BVT(Build Verification Test，構建驗證測試)
     • BVT是在所有開發工程師都已經檢入自己的程式碼，專案組編譯生成當天的版本之後進行，主要目的是驗證最新生成的軟體版本在功能上是否完整，主要的軟體特性是否正確。
     • BVT優點是時間短，驗證了軟體的基本功能；缺點是覆蓋率很低。因為執行時間短，不可能把所有的情況都測試到。
     • BVT又稱冒煙測試
   • 不能忽略安全性測試、可用性測試、配置測試和數據完整性測試，在功能性測試、安全性測試、配置測試終可進行一些探索性測試
   • 制定更詳細的UAT(用戶驗收測試)測試計畫，將其與測試腳本、培訓教材一起提供給用戶，以幫助用戶快速完成任務。

(六)、編寫測試計畫書

• 測試計畫是一個過程，不僅僅是「測試計畫書」這樣一份文件。
• 測試計畫書也可以按整合測試、系統測試、驗收測試等階段去組織
• 為每一個階段制定一份計畫書，還可以為每個測試任務、目的(安全性測試、可靠性測試等)制定特別的計畫書
• 對於一些重要的專案，會形成一系列的計畫書，如測試範圍、風險分析報告、測試標準工作計畫、測試實施計畫等。