全程軟件測試之測試需求分析與計劃（2）

2.3測試工作量估算

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

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

2.3.1工作量的估計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2工作分解結構表方法

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

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

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

?確定測試目標；

?確定測試范圍；

?確定測試資源和進度；

?測試計劃寫作；

?測試計劃評審。

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

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

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

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

2.3.3工作量估計的實例

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

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

?測試平臺、環(huán)境的不同組合，包括操作系統(tǒng)、瀏覽器、通信協(xié)議、防火墻、代理服務器等的組合。

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

?自動化測試的水平。

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4測試資源需求

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

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

1．人力資源需求

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

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

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

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

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

2．測試環(huán)境資源

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

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

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

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

2.5測試里程碑和進度安排

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

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

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

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

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

2.5.1傳統(tǒng)測試

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

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

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

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

（4）M4：測試執(zhí)行。

（5）M5：代碼凍結。

（6）M6：測試結束。

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

2.5.2敏捷測試

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

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

（1）測試任務定義；

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

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

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