2.3? 測試工作量估算

在確定了測試需求、明確了測試范圍之后，就需要明確測試任務，估算測試工作量。基于質量需求和測試的工作量、測試環境、產品發布的設想時間等要求，就可以確定測試進度和所需的測試資源，或者基于現有的測試資源來決定測試的日程表。

在傳統開發模式中，測試工作量估算是測試計劃的基礎工作之一，但在敏捷開發中，雖然也強烈建議有一個測試計劃，但其測試計劃簡明扼要，主要是列出測試目標、測試邊界、測試點、主要的測試風險和注意事項等。其測試任務在迭代計劃（如Scrum的Sprint Planning）會議中和開發任務一并考慮，可以采用Scrum估算撲克牌的方式來完成估算，這樣測試工作量估算主要依賴個人經驗、團隊溝通等完成。即使是采用這種方式，對下面內容了解之后，有一個科學估算的基礎，在敏捷開發中依舊會發揮作用。

2.3.1? 工作量的估計

測試的工作量是根據測試范圍、測試任務和開發階段來確定的。測試范圍和測試任務是測試工 作量估算的主要依據。如何確定測試范圍已在上一節做了充分的討論，可以根據產品需求規格說明來決定。測試任務是由質量需求、測試目標來決定的，質量要求越 高，越要進行更深、更充分的測試，回歸測試的次數和頻率也要加大，自然，測試的工作量要增大。處在不同的開發階段，測試工作量的差異也挺大。新產品第一個 版本的開發過程，相對于以后的版本來說，測試的工作量要大一些。但也不是絕對的，例如，第一個版本的功能較少，在第2、3個版本中，增加了較多的新功能，雖然新加的功能沒有第一個版本的功能多，但是在第2、3個版本的測試中，不僅要完成新功能的測試，還要完成第一個版本的功能回歸測試，以確保原有的功能正常。

在一般情況下，一個項目要進行2～3次回歸測試。所以，假定一輪（Round）功能測試需要100個人日（man-day），則完成一個項目所有的功能測試肯定就不止100個人日，往往需要200～300多個人日?？梢圆捎靡韵鹿接嬎?#xff1a;

W ＝ Wo + Wo ? R1 + Wo ? R2 + Wo ? R3

?? W為總工作量，Wo為一輪測試的工作量。

?? R1，R2，R3為每輪的遞減系數。受不同的代碼質量、開發流程和測試周期等影響，R1、R2、R3的值是不同的。對于每一個公司來說，可以通過歷史積累的數據獲得經驗值。

測試的工作量，還受自動化測試程度、編程質量、開發模式等多種因素影響。在這些影響的因素中，編程質量是主要的。編程質量越低，測試的重復次數（回歸測試）就越多?；貧w測試的范圍，在這3次中可能各不相同，這取決于測試結果，即測試缺陷的分布情況。缺陷多且分布很廣的話，所有的測試用例都要被再執行一遍。缺陷少且分布比較集中，可以選擇部分或少數的測試用例作為回歸測試所要執行的范圍。

在代碼質量相對較低的情況下，假定R1、R2、R3的值分別為80%、60%、40%，若一輪功能測試的工作量是100個人日，則總的測試工作量為280個人日。如果代碼質量高，一般只需要進行兩輪的回歸測試，R1、R2值也降為60%、30%，則總的測試工作量為190個人日，工作量減少了32%以上。

自動化程度越高，測試工作量就越低。由計算機運行的自動化腳本效率很高，能使執行實際測 試的工作量大大降低。但是在很多情況下，測試自動化并不能大幅度降低工作量，因為測試腳本開發的工作量很大。也就是說，將總體的測試工作量前移了，從測試 執行階段移到測試腳本設計和開發的階段，總體工作量沒有明顯降低。同時，由于自動化腳本可以重復使用，而且機器可以沒日沒夜地運行，回歸測試就可以頻繁進 行，如每天可以執行一次，這樣任何回歸缺陷都可以即時發現，提高軟件產品的質量。

工作量的估計是比較復雜的，針對不同的應用領域、程序設計技術、編程語言等，其估算方法是不同的。其估算可能要基于一些假定或定義。

（1）效率假設，即測試隊伍的工作效率。對于功能測試，這主要依賴于應用的復雜度、窗口的個數、每個窗口中的動作數目。對于容量測試，主要依賴于建立測試所需數據的工作量大小。

（2）測試假設，目的是驗證一個測試需求所需測試的動作數目，包括估計的每個測試用例所用的時間。

（3）階段假定，指所處測試周期不同階段（測試設計、腳本開發、測試執行等）的劃分，包括時間的長短。

（4）復雜度假定，應用的復雜度指標和需求變化的影響程度決定了測試需求的維數。測試需求的維數越多，工作量就越大。

（5）風險假定。一般考慮各種因素影響下所存在的風險，將這些風險帶來的工作量設定為估算工作量之外的10%～20%。

2.3.2? 工作分解結構表方法

要做好測試工作量的估算，需要對測試任務進行細化，對每項測試任務進行分解，然后根據分解后的子任務進行估算。通常來說，分解的粒度越小，估算精度越高?？梢栽偌由?/span>10%～15%的浮動幅度，來確定實際所需的測試工作量。比較專業的方法是工作分解結構表（WBS），它按以下3個步驟來完成。

（1）列出本項目需要完成的各項任務，如測試計劃、需求和設計評審、測試設計、腳本開發、測試執行等。

（2）對每個任務進一步細分，可進行多層次的細分，直到不能細分為止。如針對測試計劃，首先可細分為：

?? 確定測試目標；

?? 確定測試范圍；

?? 確定測試資源和進度；

?? 測試計劃寫作；

?? 測試計劃評審。

“確定測試范圍”還可再細分為功能性測試范圍和非功能性測試范圍的分析?！?/span>測試計劃評審”可以再分為測試組內評審、項目組評審、公司質量保證小組評審和最終批準。

（3）列出需要完成的所有任務之后，根據任務的層次給任務進行編號，就形成了完整的工作分解結構表（如表2-5所示）。

WBS除了用表格的方式表達之外，還可以采用結構圖的方式，那樣會更直觀、方便，如圖2-5所示。

當WBS完成之后，就擁有了制定日程安排、資源分配和預算編制的基礎信息，這樣不僅可獲得總體的測試工作量，還包括各個階段或各個任務的工作量，有利于資源分配和日程安排。所以，WBS方法不僅適合工作量的估算，還適合日程安排、資源分配等計劃工作。

2.3.3? 工作量估計的實例

結合Google日歷的功能點可以看出，測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各階段的時間安排。根據Google日歷的功能計算，測試用例數為6×60 = 360例（以平均每個大模塊60個用例來算）。除了測試用例數，還要考慮以下因素。

?? 根據測試團隊和項目的具體情況來算，如2.3.3節中的幾個假定：效率假設、測試假設和應用的維數等。

?? 測試平臺、環境的不同組合，包括操作系統、瀏覽器、通信協議、防火墻、代理服務器等的組合。

?? 回歸測試頻率和重復次數。

?? 自動化測試的水平。

?? 其他特定的因素，增加10%～20%的余量。

在Google日歷的測試中，做如下假定和分析。

?? 所有人員為中級軟件測試工程師的水平。

?? 每個測試用例設計時間為20分鐘，包括評審、輸入到用例管理數據庫中等所用的時間。所以測試用例設計的時間為120小時，即15個人日。

?? 70%的測試用例可以進行自動化測試，30%為手工測試。即自動化測試用例數為252例，手工測試用例數為108例。

?? 每位工程師每天可開發10個測試用例的測試腳本，包括調試。所以測試腳本開發的工作量為26個人日。

?? 要進行兩次的回歸測試，R1、R2值為70%、40%，則單平臺下手工運行的測試用例數為108×(1＋70%＋40%) ＝ 227例。

?? 對操作系統沒有影響，而且不考慮SSL的支持，只考慮瀏覽器IE6.0、IE7.0、Firefox1.5、Firefox2.0和代理服務器的影響。作為交叉組合，共設為4種。

?? 也沒有必要在4種組合上運行所有的測試用例，兩種主要組合運行100%的手工測試用例，另外兩種組合運行50%的手工測試用例，即測試用例數為原來的3倍，所以手工運行的測試用例數為227 × 3 ＝ 681例。

?? 假定每個測試工程師每天可以運行60個測試用例，即每個測試用例的執行要用5分鐘，運行測試用例要用5個小時，另外3個小時用于處理缺陷報告和郵件、與開發人員溝通等。所以手工測試用例執行的時間為12個人日。

?? 自動化測試的運行都在晚上進行，工程師需要時間分析測試結果、修改腳本適應新的變化、做缺陷報告等，估計要5個人日。

這樣就估算出了功能測試的基本工作量，即15＋26+12+5=58個人日。

對系統測試的工作量，可以按照同樣的方法進行，所不同的是系統測試幾乎是由測試工具完成的，工作量主要集中在環境構建、測試數據準備和結果分析等上面。表2-6給出了Google日歷所要的測試工作量。

2.4? 測試資源需求

分析測試范圍之后，所需要的測試資源就比較清楚了。測試的資源需求，包括人力資源和軟、硬件資源。人力資源，側重如何組建測試團隊——項目測試組，而軟、硬件資源，對于不同的項目差異很大。這里只討論一般的操作方法，設計測試環境的建立，將在第7、第9章進行詳細介紹。

如果將測試資源進行較為詳細的分類，可以歸納為如圖2-6所示。

1．人力資源需求

在完成了測試工作量的估算之后，軟件測試項目所需的人員數目就能夠基本確定了。軟件測試項目所需的人員和要求在各個階段是不同的。

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

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

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

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

2．測試環境資源

把建立所有必要的測試環境所需的計算機軟件資源和硬件資源合稱為測試環境資源。硬件提供了一個支持操作系統、應用系統和測試工具等運行的基本平臺，軟件資源包括操作系統、第三方軟件產品、測試工具軟件等，具體如下。

?? 硬件：交換機、路由器、負載均衡器（Load balance）、服務器、客戶端PC、攝像頭、特殊的顯示卡和聲卡、耳機、麥克風等。

?? 支撐的系統軟件：Linux操作系統、Web服務器（如Apache）、中間件（如Tomcat、WebLogic）、數據庫系統軟件MySQL/Oracle等。

?? 測試工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。

2.5? 測試里程碑和進度安排

軟件測試貫穿軟件產品開發的整個生命周期，從產品的需求分析審查到最后的驗收測試，直至軟件發布。從測試實際的前后過程來看，軟件測試的過程是由一系列不同的測試階段組成的，這些階段主要有：需求分析審查、設計審查、單元測試、集成測試（組裝測試）、功能測試、系統測試、驗收測試、回歸測試（維護）等。在軟件測試項目的計劃書中，需要給各個階段制定一個明確的開始和結束時間，這就是通常所說的日程進度表（schedule）。項目進度安排，實際上取決于測試工作量和現有的人力資源。當人力資源充足時，測試周期短；當人力資源較少時，測試周期就會長。

里程碑一般是項目中完成階段性工作的標志，即用一個結論性的標志來描述一個過程性任務明確的起止點，進度安排就是確定里程碑的起止點。一個里程碑標志著上一個階段結束、下一個階段開始，也就是定義當前階段完成的標準（Entry Criteria）和下一個新階段啟動的條件或前提（Entry Criteria）。里程碑具有很強的時序性，還具有下列特征。

?? 里程碑也是有層次的，在一個父里程碑的下一個層次中定義子里程碑。

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

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

2.5.1? 傳統測試

在軟件測試周期中，建議定義下列6個父里程碑。

（1）M1：需求分析和設計的審查。

（2）M2：測試計劃和設計。

（3）M3：代碼（包括單元測試）完成。

（4）M4：測試執行。

（5）M5：代碼凍結。

（6）M6：測試結束。

每個里程碑再劃分為子里程碑，如果項目周期很長，還可以對每個子里程碑進一步劃分為更小的里程碑，以利于更有效的控制，如表2-7所示。

2.5.2? 敏捷測試

在本書一開始的引言中，以Scrum為例，簡要闡述了敏捷測試流程。而在敏捷測試項目中，如何明確測試的里程碑呢？萬變不離其宗，敏捷測試也需要從測試計劃到測試設計、再到執行，只是測試設計和執行的界限不那么分明，測試設計和執行往往交替或并列地開展。在敏捷測試中，甚至可以不需要測試用例，而是針對Use Case 或User Story直 接進行驗證，并進行探索性測試。而節約出來的時間，用于開發相對穩定功能的自動化測試腳本，為后期的回歸測試服務。自動化測試腳本將代替測試用例，成為軟 件組織的財富。原有測試規范還要求進行兩輪回歸測試，在敏捷測試中，只能進行一輪回歸測試。綜合上述考慮，敏捷測試的實際操作流程如圖2-7所示，簡單有效。

在這樣的流程中，大框架也沒有什么不同，而且各項測試件（測試計劃、需求、自動化腳本等）的評審還是需要的，只是沒有明確的評審階段，測試是一個持續的質量反饋過程，階段性不那么突出，但還是可以設定一些控制點，即里程碑：

（1）測試任務定義；

（2）測試計劃制定和評審通過；

（3）測試需求或測試點（或測試場景）列表明確和評審通過；

（4）驗收測試結束。
——————本文節選自《全程軟件測試（第2版）》

總結

以上是生活随笔為你收集整理的全程软件测试之测试需求分析与计划（2）的全部內容，希望文章能夠幫你解決所遇到的問題。

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