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

1 測試計劃的定義

IEEE 829-1983 測試計劃的定義及目的

? 一個敘述了預定的測試活動的范圍、途徑、資源及進度安排的文檔。它確認了測試項、被測特征、測試任務、人員安排以及任何偶發事件的風險。

? 軟件測試計劃是指導測試過程的綱領性文檔。計劃可以統一認識，可以規劃過程。

? 測試計劃包含了產品概述、測試區域/測試范圍(測試項)、 測試目標(被測特征)、測試優先級、測試配置/測試資源、測試周期、進度安排(測試任務、人員安排)、 測試策略、測試方法/途徑、測試交流、風險分析、測試標準、需交付文檔等內容。

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

3 測試計劃的編寫原則

? 為了做好軟件測試計劃，需要注意以下幾個方面

1、明確測試的目標，增強測試計劃的實用性。

2、堅持“5W”規則，明確內容與過程。

? What(做什么)

? Why(為什么做)

? When(何時做)

? Where(在哪里)

? How(如何做)

3、采用評審和更新機制，保證測試計劃滿足實踐需求

測試計劃創建完畢后必須提交給由項目經理、開發經理、測試經理、市場經理等組成的評審委員會審閱。

4、測試計劃中不要包含詳細的測試技術指標、測試步驟和測試用例。

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系。

4 測試計劃的主要工作

? 確定測試資源

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

? 風險分析

? 制定測試策略

? 編寫計劃書

二、 確定測試資源

1 測試資源的分類

2 測試資源的規劃

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

? 在初期，測試組長首先要介入進去，參與需求評審、確定測試需求和測試范圍、制定測試策略和測試計劃等。

? 在測試前期，需要一些比較資深的測試設計人員、測試腳本或測試工具開發人員參與或負責軟件測試需求的制定和分解、設計測試用例、開發測試腳本等工作。

? 在測試中期，主要是測試的執行，測試人員的數量取決于測試自動化實現的程度。如果測試自動化程度高，人力的投入則不需要明顯的增加：如果測試自動化程度低，對執行測試的人員要求就比較多了。

? 在測試后期，資深的測試人員可以抽出部分時間去做新項目的準備工作。

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

1 測試工作量估計

1.1 怎么確定測試工作量

? 測試的工作量是根據測試范圍、測試任務和開發階段來確定的。

? 團隊工作效率越低，測試工作量越大。

? 測試的質量要求越高，測試的工作量越大。

? 不同的開發階段的測試工作量的差異也較大。新產品第一個版本的測試的工作量要大一些，若后續版本功能增加加多，則后續版本測試量變大。

? 編程質量越低，測試的工作量越大。

? 程序復雜度越高，測試的工作量越大。

? 之前測試的缺陷多且分布很廣，測試工作量大。

? 風險越多，等級越高，測試工作量越大。

? 自動化程度越低，測試工作量越高。但是在很多情況下，測試自動化并不能大幅度降低工作量，因為測試腳本開發的工作量很大。

1.2 任務細分

工作分解結構表方法

? 列出本項目需要完成的各項任務。

? 對每個任務進一步細分，可進行多層次細分，直到不能細分為止。

? 根據任務的層次給任務進行編號。

案例

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 里程碑的特點

? 里程碑具有很強的時序性，可以有層次(分為父里程碑、子里程碑等)。

? 不同類型的項目，里程碑可能不同。

? 不同規模項目的里程碑，其數量的多少不一樣，里程碑可以合并或分解。

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

? 測試計劃簽發、測試用例簽發、自動測試腳本完成、功能測試完成、性能測試完成

等。

2.4 進度安排

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

? 案例

四、 測試風險分析與管理

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

1 風險識別

? 建立風險項目檢查表，將測試范圍、測試過程中的風險識別出來，按風險內容進行

逐項檢查、逐個確認，確定哪些是可避免的風險，哪些是不可避免的，對可避免的

風險要盡量采取措施去避免。

案例

2 風險評估

從成本、進度及性能三個方面對風險進行評估，通過評估可以確定這些風險的特點或可

能帶來的危害，根據風險發生的概率和帶來的影響確定風險的優先級。

3 風險控制

? 制定風險管理計劃和風險應急處理方案，來降低風險和消除風險。

? 對風險的處理還要制定一些應急的、有效的處理方案。

? 做計劃時，估算資源、時間、預算等要留有余地，不要用到 100%。

? 制定文檔標準，并建立一種機制，保證文檔及時產生。對所有工作多進行互相審查，

及時發現問題。

案例

五、 制定測試策略

1 什么是測試策略

? 描述當前測試項目的目標和所采用的測試方法；

? 描述在規定的時間內哪些測試內容要完成，軟件產品的特性或質量在哪些方面得到

確認；

? 描述測試不同階段(單元測試、集成測試、系統測試)的測試對象、范圍和方法；

? 描述每個階段內所要進行的測試類型(功能測試、性能測試、壓力測試等)。

2 案例

? 分階段的測試策略

? 嚴格執行代碼復查，保證在早期就發現問題，而非在代碼發布之后。

? 利用單元測試和集成測試，盡早地發現更多的問題，并準備好自動化測試的

BVT (Build Verification Test，軟件包驗證測試)。

? BVT 是開發人員檢入自己的代碼，項目組編譯生成當天的版本后進行的

測試，主要目的是驗證最新的軟件版本在功能上是否完整，主要的軟件特

性是否正確實現。冒煙測試通過后，就可以進行更大規模的測試了。

? BVT 優點是時間短，缺點是覆蓋率很低。BVT 測試也稱“冒煙測試”。

? 不能忽略安全性測試、可用性測試、配置測試和數據完整性測試。

? 在功能性測試、安全性測試、配置測試中可進行一些探索性測試。

? 制定更為詳細的 UAT(用戶驗收測試)測試計劃，將其與測試腳本和培訓材

料一起提供給用戶，以幫助用戶快速提高并完成任務。

六、 編寫測試計劃書

? 測試計劃是一個過程，不僅僅是“測試計劃書”這樣一個文檔，測試計劃會隨著情

況變化不斷進行調整，以便于優化資源和進度安排，減少風險，提高測試效率，并

及時修改“測試計劃書”。

? 測試計劃書的內容也可以按集成測試、系統測試、驗收測試等階段去組織。

? 為每一個階段制定一個計劃書，還可以為每個測試任務，目的(安全性測試、性能

測試、可靠性測試等)制定特別的計劃書。

? 對于一些重要的項目，會形成一系列的計劃書，如測試范圍，風險分析報告、測試

標準工作計劃、資源和培訓計劃、風險管理計劃、測試實施計劃、質量保證計劃等。

總結

以上是生活随笔為你收集整理的软件测试中的测试进度安排怎么写,测试开发之测试计划的全部內容，希望文章能夠幫你解決所遇到的問題。

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