2.3? 測試工作量估算

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

在傳統(tǒng)開發(fā)模式中，測試工作量估算是測試計(jì)劃的基礎(chǔ)工作之一，但在敏捷開發(fā)中，雖然也強(qiáng)烈建議有一個(gè)測試計(jì)劃，但其測試計(jì)劃簡明扼要，主要是列出測試目標(biāo)、測試邊界、測試點(diǎn)、主要的測試風(fēng)險(xiǎn)和注意事項(xiàng)等。其測試任務(wù)在迭代計(jì)劃（如Scrum的Sprint Planning）會(huì)議中和開發(fā)任務(wù)一并考慮，可以采用Scrum估算撲克牌的方式來完成估算，這樣測試工作量估算主要依賴個(gè)人經(jīng)驗(yàn)、團(tuán)隊(duì)溝通等完成。即使是采用這種方式，對下面內(nèi)容了解之后，有一個(gè)科學(xué)估算的基礎(chǔ)，在敏捷開發(fā)中依舊會(huì)發(fā)揮作用。

2.3.1? 工作量的估計(jì)

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

在一般情況下，一個(gè)項(xiàng)目要進(jìn)行2～3次回歸測試。所以，假定一輪（Round）功能測試需要100個(gè)人日（man-day），則完成一個(gè)項(xiàng)目所有的功能測試肯定就不止100個(gè)人日，往往需要200～300多個(gè)人日。可以采用以下公式計(jì)算：

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

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

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

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

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

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

工作量的估計(jì)是比較復(fù)雜的，針對不同的應(yīng)用領(lǐng)域、程序設(shè)計(jì)技術(shù)、編程語言等，其估算方法是不同的。其估算可能要基于一些假定或定義。

（1）效率假設(shè)，即測試隊(duì)伍的工作效率。對于功能測試，這主要依賴于應(yīng)用的復(fù)雜度、窗口的個(gè)數(shù)、每個(gè)窗口中的動(dòng)作數(shù)目。對于容量測試，主要依賴于建立測試所需數(shù)據(jù)的工作量大小。

（2）測試假設(shè)，目的是驗(yàn)證一個(gè)測試需求所需測試的動(dòng)作數(shù)目，包括估計(jì)的每個(gè)測試用例所用的時(shí)間。

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

（4）復(fù)雜度假定，應(yīng)用的復(fù)雜度指標(biāo)和需求變化的影響程度決定了測試需求的維數(shù)。測試需求的維數(shù)越多，工作量就越大。

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

2.3.2? 工作分解結(jié)構(gòu)表方法

要做好測試工作量的估算，需要對測試任務(wù)進(jìn)行細(xì)化，對每項(xiàng)測試任務(wù)進(jìn)行分解，然后根據(jù)分解后的子任務(wù)進(jìn)行估算。通常來說，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮動(dòng)幅度，來確定實(shí)際所需的測試工作量。比較專業(yè)的方法是工作分解結(jié)構(gòu)表（WBS），它按以下3個(gè)步驟來完成。

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

（2）對每個(gè)任務(wù)進(jìn)一步細(xì)分，可進(jìn)行多層次的細(xì)分，直到不能細(xì)分為止。如針對測試計(jì)劃，首先可細(xì)分為：

?? 確定測試目標(biāo)；

?? 確定測試范圍；

?? 確定測試資源和進(jìn)度；

?? 測試計(jì)劃寫作；

?? 測試計(jì)劃評審。

“確定測試范圍”還可再細(xì)分為功能性測試范圍和非功能性測試范圍的分析。“測試計(jì)劃評審”可以再分為測試組內(nèi)評審、項(xiàng)目組評審、公司質(zhì)量保證小組評審和最終批準(zhǔn)。

（3）列出需要完成的所有任務(wù)之后，根據(jù)任務(wù)的層次給任務(wù)進(jìn)行編號，就形成了完整的工作分解結(jié)構(gòu)表（如表2-5所示）。

WBS除了用表格的方式表達(dá)之外，還可以采用結(jié)構(gòu)圖的方式，那樣會(huì)更直觀、方便，如圖2-5所示。

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

2.3.3? 工作量估計(jì)的實(shí)例

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

?? 根據(jù)測試團(tuán)隊(duì)和項(xiàng)目的具體情況來算，如2.3.3節(jié)中的幾個(gè)假定：效率假設(shè)、測試假設(shè)和應(yīng)用的維數(shù)等。

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

?? 回歸測試頻率和重復(fù)次數(shù)。

?? 自動(dòng)化測試的水平。

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

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

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

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

?? 70%的測試用例可以進(jìn)行自動(dòng)化測試，30%為手工測試。即自動(dòng)化測試用例數(shù)為252例，手工測試用例數(shù)為108例。

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

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

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

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

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

?? 自動(dòng)化測試的運(yùn)行都在晚上進(jìn)行，工程師需要時(shí)間分析測試結(jié)果、修改腳本適應(yīng)新的變化、做缺陷報(bào)告等，估計(jì)要5個(gè)人日。

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

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

2.4? 測試資源需求

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

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

1．人力資源需求

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

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

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

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

（4）在測試后期，資深的測試人員可以抽出部分時(shí)間去做新項(xiàng)目的準(zhǔn)備工作。

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

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

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

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

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

2.5? 測試?yán)锍瘫瓦M(jìn)度安排

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

里程碑一般是項(xiàng)目中完成階段性工作的標(biāo)志，即用一個(gè)結(jié)論性的標(biāo)志來描述一個(gè)過程性任務(wù)明確的起止點(diǎn)，進(jìn)度安排就是確定里程碑的起止點(diǎn)。一個(gè)里程碑標(biāo)志著上一個(gè)階段結(jié)束、下一個(gè)階段開始，也就是定義當(dāng)前階段完成的標(biāo)準(zhǔn)（Entry Criteria）和下一個(gè)新階段啟動(dòng)的條件或前提（Entry Criteria）。里程碑具有很強(qiáng)的時(shí)序性，還具有下列特征。

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

?? 不同類型的項(xiàng)目，里程碑可能不同。

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

2.5.1? 傳統(tǒng)測試

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

（1）M1：需求分析和設(shè)計(jì)的審查。

（2）M2：測試計(jì)劃和設(shè)計(jì)。

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

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

（5）M5：代碼凍結(jié)。

（6）M6：測試結(jié)束。

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

2.5.2? 敏捷測試

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

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

（1）測試任務(wù)定義；

（2）測試計(jì)劃制定和評審?fù)ㄟ^；

（3）測試需求或測試點(diǎn)（或測試場景）列表明確和評審?fù)ㄟ^；

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

總結(jié)

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

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