一、 測試計劃的定義與原則

1. 測試計劃的定義

• IEEE 829-1983 測試計劃的定義及目的
  • 一個敘述了預定的測試活動的范圍、途徑、資源及進度安排的文檔。它確認了 測試項、被測特征、測試任務、人員安排以及任何偶發(fā)事件的風險。
  • 軟件測試計劃是指導測試過程的綱領性文檔。計劃可以統(tǒng)一認識，可以規(guī)劃過 程。
  • 測試計劃包含了產(chǎn)品概述、測試區(qū)域/測試范圍（測試項）、 測試目標（被測 特征）、測試優(yōu)先級、測試配置/測試資源<硬件、軟件、人力、技術等>、測 試周期、進度安排（測試任務、人員安排）、 測試策略、測試方法/途徑、測 試交流、風險分析、測試標準、需交付文檔等內容。

2. 測試計劃進入與退出準則、責任人

3. 測試計劃的編寫原則

• 為了做好軟件測試計劃，需要注意以下幾個方面
  • 1、明確測試的目標，增強測試計劃的實用性。
  • 2、堅持“5W”規(guī)則，明確內容與過程。
    • What（做什么）
    • Why（為什么做）
    • When（何時做）
    • Where（在哪里）
    • How（如何做）
  • 3、采用評審和更新機制，保證測試計劃滿足實踐需求
    • 測試計劃創(chuàng)建完畢后必須提交給由項目經(jīng)理、開發(fā)經(jīng)理、測試經(jīng)理、市場 經(jīng)理等組成的評審委員會審閱。
  • 4、測試計劃中不要包含詳細的測試技術指標、測試步驟和測試用例。
    • 測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系。

4. 測試計劃的主要工作

• 確定測試資源
• 工作量估算、里程碑和進度安排
• 風險分析
• 制定測試策略
• 編寫計劃書

二、確定測試資源

1. 測試資源的分類

2. 測試資源的規(guī)劃

軟件測試項目所需的人員和要求在各個階段是不同的。

• 在初期，測試組長首先要介入進去，參與需求評審、確定測試需求和測試范圍、 制定測試策略和測試計劃等。
• 在測試前期，需要一些比較資深的測試設計人員、測試腳本或測試工具開發(fā)人 員參與或負責軟件測試需求的制定和分解、設計測試用例、開發(fā)測試腳本等工 作。
• 在測試中期，主要是測試的執(zhí)行，測試人員的數(shù)量取決于測試自動化實現(xiàn)的程 度。如果測試自動化程度高，人力的投入則不需要明顯的增加：如果測試自動 化程度低，對執(zhí)行測試的人員要求就比較多了。
• 在測試后期，資深的測試人員可以抽出部分時間去做新項目的準備工作。

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

1. 測試工作量估計

1.1 怎么確定測試工作量

測試的工作量是根據(jù)測試范圍、測試任務和開發(fā)階段來確定的。

• 團隊工作效率越低，測試工作量越大。
• 測試的質量要求越高，測試的工作量越大。
• 不同的開發(fā)階段的測試工作量的差異也較大。新產(chǎn)品第一個版本的測試的工作 量要大一些，若后續(xù)版本功能增加加多，則后續(xù)版本測試量變大。
• 編程質量越低，測試的工作量越大。
• 程序復雜度越高，測試的工作量越大。
• 之前測試的缺陷多且分布很廣，測試工作量大。
• 風險越多，等級越高，測試工作量越大。
• 自動化程度越低，測試工作量越高。但是在很多情況下，測試自動化并不能大 幅度降低工作量，因為測試腳本開發(fā)的工作量很大。

1.2 任務細分

工作分解結構表方法

• 列出本項目需要完成的各項任務。
• 對每個任務進一步細分，可進行多層次細分，直到不能細分為止。
• 根據(jù)任務的層次給任務進行編號。

案例

1.3 測試工作量估算

案例

• 考慮回歸測試（如 2-3 輪）
  • W= Wo+WoRl+WoR2+Wo*R3
    • W 為總工作量，Wo 為一輪測試的工作量。
    • 在代碼質量相對較低的情況下，假定 Rl、R2、R3 的值分別為 80%、 60%、40%，若一輪功能測試的工作量是 100 個人日，則總的測試工 作量為 280 個人日。
    • 如果代碼質量高，一般只需要進行兩輪的回歸測試，Rl、R2 值也降 為 60%、30%，則總的測試工作量為 190 個人日，工作量減少了 32% 以上。

2. 測試里程碑和進度安排

2.1 里程碑

• 一般一個里程碑標志著上一個階段結束、下一個階段開始，也就是定義當前階段完
  成的標準（Entry Criteria）和下一個新階段啟動的條件或前提（Entry Criteria）。

2.2 里程碑的特點

• 里程碑具有很強的時序性，可以有層次（分為父里程碑、子里程碑等）。
• 不同類型的項目，里程碑可能不同。
• 不同規(guī)模項目的里程碑，其數(shù)量的多少不一樣，里程碑可以合并或分解。

2.3 軟件測試中常見的里程碑

測試計劃簽發(fā)、測試用例簽發(fā)、自動測試腳本完成、功能測試完成、性能測試完成 等。

2.4 進度安排

進度安排就是確定里程碑的起止點。
案例

四、 測試風險分析與管理

對軟件測試中的風險進行管理，基本內容有：風險識別、風險評估和風險控制。

1. 風險識別

• 建立風險項目檢查表，將測試范圍、測試過程中的風險識別出來，按風險內容進行 逐項檢查、逐個確認，確定哪些是可避免的風險，哪些是不可避免的，對可避免的 風險要盡量采取措施去避免。

案例

2. 風險評估

從成本、進度及性能三個方面對風險進行評估，通過評估可以確定這些風險的特點或可 能帶來的危害，根據(jù)風險發(fā)生的概率和帶來的影響確定風險的優(yōu)先級。

3. 風險控制

• 制定風險管理計劃和風險應急處理方案，來降低風險和消除風險。
• 對風險的處理還要制定一些應急的、有效的處理方案。
• 做計劃時，估算資源、時間、預算等要留有余地，不要用到 100%。
• 制定文檔標準，并建立一種機制，保證文檔及時產(chǎn)生。對所有工作多進行互相審查， 及時發(fā)現(xiàn)問題。
• 案例
  

五、 制定測試策略

1. 什么是測試策略

• 描述當前測試項目的目標和所采用的測試方法；
• 描述在規(guī)定的時間內哪些測試內容要完成，軟件產(chǎn)品的特性或質量在哪些方面得到 確認；
• 描述測試不同階段（單元測試、集成測試、系統(tǒng)測試）的測試對象、范圍和方法；
• 描述每個階段內所要進行的測試類型（功能測試、性能測試、壓力測試等）。

2. 案例

分階段的測試策略

• 嚴格執(zhí)行代碼復查，保證在早期就發(fā)現(xiàn)問題，而非在代碼發(fā)布之后。
• 利用單元測試和集成測試，盡早地發(fā)現(xiàn)更多的問題，并準備好自動化測試的 BVT （Build Verification Test，軟件包驗證測試）。
  • BVT 是開發(fā)人員檢入自己的代碼，項目組編譯生成當天的版本后進行的 測試，主要目的是驗證最新的軟件版本在功能上是否完整，主要的軟件特 性是否正確實現(xiàn)。冒煙測試通過后，就可以進行更大規(guī)模的測試了。
  • BVT 優(yōu)點是時間短，缺點是覆蓋率很低。BVT 測試也稱“冒煙測試”。
• 不能忽略安全性測試、可用性測試、配置測試和數(shù)據(jù)完整性測試。
• 在功能性測試、安全性測試、配置測試中可進行一些探索性測試。
• 制定更為詳細的 UAT（用戶驗收測試）測試計劃，將其與測試腳本和培訓材 料一起提供給用戶，以幫助用戶快速提高并完成任務。

六、編寫測試計劃書

• 測試計劃是一個過程，不僅僅是“測試計劃書”這樣一個文檔，測試計劃會隨著情 況變化不斷進行調整，以便于優(yōu)化資源和進度安排，減少風險，提高測試效率，并 及時修改“測試計劃書”。
• 測試計劃書的內容也可以按集成測試、系統(tǒng)測試、驗收測試等階段去組織。
• 為每一個階段制定一個計劃書，還可以為每個測試任務，目的（安全性測試、性能 測試、可靠性測試等）制定特別的計劃書。
• 對于一些重要的項目，會形成一系列的計劃書，如測試范圍，風險分析報告、測試 標準工作計劃、資源和培訓計劃、風險管理計劃、測試實施計劃、質量保證計劃等。

總結

以上是生活随笔為你收集整理的测试计划的全部內容，希望文章能夠幫你解決所遇到的問題。

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