測試管理-測試工做量估算實踐

測試工做量估算是整個測試過程當中不可忽視的環節，關乎項目總體的交付計劃及時間工期安排。預估的越準確，對項目總體節奏的把握更有利。

咱們首先要強調，估算估算，自己就帶有預測性質，其準確程度是要受到多方面因素制約的，尤爲是信息的充分性。

越是大型的複雜項目，對於估算的要求就越高；反之，小規模「短頻快」的項目則對於估算要求不那麼高。

1. 估算辦法

如何得出對於測試時間的準確估算，能夠從三種思路去保證：

• 參照以往項目的經驗
• 依靠專家經驗進行估算
• 使用專業的估算算法

項目中常見的估算形式有自上而下式的，也有自下而上式的。

自上而下式：

• 先總體，再拆解
• 先宏觀，再細節
• 管理人員主導，基層人員落實

自下而上式：

• 先拆解，再整合
• 先細節，再總體
• 基層人員估算，管理人員覈算

自上而下和自下而上式的估算方法都有其適合的應用場景，這取決於項目的特性，組織的風格等。

例如，對於一個嚴格約定了交付時間的定製性開發項目而言，其項目的總體時間框架是固定的，開發和測試工做時間都須要在相應的時間框架內進行工做量的細化和編排；而對於一個典型的Scrum式敏捷項目而言，工做項時間的估算一般都來自於工做人員本身我的的估算，而後再由項目統籌彙總。

一個典型的估算思路以下圖所示：

2. 常見的估算方式

類比估算

根據之前相似項目的實際工做量，憑經驗來推測當前項目的工做量。

例如，系統迭代週期內，曾經新增一個功能模塊，實際開發和測試工做量是15人天。參照歷史經驗，當咱們再次新增相似規模的功能模塊時，咱們推測當前的任務工做量也爲15天。

爲了準確的使用類比方法，要求組織內部簡歷比較完善的經驗庫，同時也要求參與估算人員有較豐富的同類項目經驗。

類比估算的方法並不適合用於大型複雜和變更可能性高的項目。

用開發時間的百分比估算

這種估算方法在一些項目裏是比較常見的，其成立前提在於，測試工做量依賴於軟件的規模，而軟件的規模又決定了開發編碼的工做量。

這個方法的基本前提是測試工做量依賴於開發時間/開發工做量。首先，開發工做量使用例如LOC或FP方法被估算出來，而後根據項目以往測試花費時間的經驗總結，按必定比例得出測試時間/工做量。

好比預留開發時間的50%給測試工做，是一種常見的作法。

這種方法的風險也比較大，而且不適用於複雜狀況。

WBS估算法

WBS全稱（work breakdown structure），即工做內容分解。嚴格來講他不是一種估算方法，而是項目管理方法，而且能夠應用在大多數場景。其理念在於將複雜的工做內容分解成足夠的顆粒度，對這些細粒度的內容逐一估算，繼而累加得出總體結果。

WBS是一種典型的自底向上的方法。

咱們使用WBS法對測試任務進行細化，對每項測試任務進行分解，而後根據分解後的子任務進行估算。

一般來講，分解的粒度越小，估算精度越高。能夠再加上10%～15%的浮動幅度，來肯定實際所需的測試工做量。

Delphi估算法

典型的專家判斷法，是由許多專家運用結構化的方法來作出主觀判斷。

簡單來講就是背對背評估、誤差不超過必定數值（好比10%）有效。德爾菲估算法通常進行4~6輪，使你們的意見逐漸趨於一致。

專家的選擇方面，在測試領域內一般沒有嚴格要求，任務的相關人員通常都作爲專家參與Delphi估算。

PERT估算法

又稱三點估算法，是指估算三種可能的工期，而後加權平均，得出活動的平均工期和標準誤差。

PERT對各個項目活動的完成時間按三種不一樣狀況估計：一個產品的指望工期，一個最低可能估計，一個最高可能估計。

用這三個估計用來獲得一個產品指望工期和標準誤差的Pert 統計估計。Pert 估計可獲得工期的指望值E，和標準誤差SD。

T(E)指望值=

SD標準誤差=

軟件規模估算法

對於軟件規模，業界有兩種普遍應用的估算方式：

• 代碼行估算LOC（Line Of Code）
• 功能點估算FPA（Functional Point Analysis）

軟件規模估算更多的是用於預估軟件開發工做量，但測試工做量依賴於軟件的規模，所以經過規模與測試工做量之間的對應關係推算測試工做量，是具備可行性的。

這種方法對於項目成員缺少相關經驗，或者系統功能、結構比較複雜的狀況下有必定的使用價值。

而相較於代碼行估算，功能點（換言之能夠對應到測試點）估算對於測試工做而言具備更高的相關性。

軟件規模估算可能會用到一些科學的算法，例如對於MVC模型比較有效的MarkII方法，其計算公式爲：

功能點＝輸入DET×0.58＋實體類型×1.66＋輸出DET×0.26

注意以上的估算方法都有其應用價值，並且頁並不是割裂的存在。在實際項目種應用時，每每會多種方法結合使用。

3.估算實踐

下面咱們經過一個案例來分析各類估算方法結合使用的實例。

以以下項目爲例：

X&X COTS Commercial

• 該項目爲一個COTS產品的定製性二次開發項目
• 項目週期計劃爲4個月
• 採用持續集成，高速迭代的研發方式

3.1.工做量框架肯定

首先在項目立項階段，項目工期已被肯定爲4個月。在這樣的背景下，項目經理與架構師進行了軟件規模總體估算，並得出了所需開發人員人數爲7人。
測試經理經過百分比類比預估，憑藉本身的經驗，以開發人員人數爲基礎，提出了3人測試的人員需求。

3.2.測試任務拆解

立項階段結束後，商務分析人員/產品人員開始逐步肯定系統需求，架構師給出系統架構概要。測試經理經過手頭能夠肯定和預計存在任務狀況，開始作WBS任務分解。
經過將測試計劃、分析、設計、實施、執行、評估、報告等工做進行逐一分解，獲得以下任務列表：

3.3.估算會議

在人員基本到位後，項目經理召集項目全員，啓動項目工做量估算會議。

會議上，基於WBS拆解的任務項，逐項任務展開Delphi專家估算。

專家的挑選並不採用嚴格的形式，而是由項目經理主持選定單項任務的執行人、合力者和審批者參與估算。估算最小精度被肯定爲0.25人/天。

每一項任務進行具體估算時，估算人員進行實名投票（舉牌），管理人員統籌投票結果的偏離度，若是單個估算人員的估算誤差超出平均（好比20%），則須要闡述本身的理由。

闡述完畢後，從新開始投票，重複上述過程，直到全部人員的投票值收斂於必定誤差值以內，用其平均值作爲最終估算值。

3.4.MarkII功能點估算應用

在Delphi估算的過程當中，出現了專家廣泛認爲對於某功能模塊經驗不足，沒法準確估算的狀況。所以採用功能點估算法推算相應工做量，步驟以下：

①　選取一個已知（已估）工做量大小的模塊，拆解其功能點。（如用戶管理模塊的用戶註冊功能點）已知功能點對應測試任務爲1.5/人天。

②　按照MarkII方法，拆解該功能點的輸入、輸出與關聯實體。如：

用戶註冊事務

• 輸入DET 「用戶名稱」、「用戶密碼」、「用戶條款」等約15項

• 輸出DET 「註冊成功」、「密碼不符合規範」、「用戶已註冊」等10項

• 關聯實體 用戶記錄，地址簿記錄，地址詳情記錄，支付卡記錄等5項

根據公式計算得出：15×0.58+5×1.66+10×0.26=19.6。

這裏得出的數字是一個指數，推論的具體含義能夠這麼理解：一個大小爲19.6的事務（功能點），對應所需測試活動工做量爲1.5人/天。

③　拆解待估算模塊功能點，進而一樣對於功能點使用Mark II估算：

訂單建立事務

• 輸入DET 「收貨地址」、「支付方式」、「配送方式」等約20項

• 輸出DET 「下單成功」、「支付失敗」、「庫存不足」等20項

• 關聯實體 訂單記錄，庫存記錄，支付記錄，物流記錄等5項

計算得出其規模指數爲：20×0.58+5×1.66+20×0.26=25.1。
結合上一步的結論，大小爲25.1的事務，對應所需測試工做量推算爲：
25.1×（2.5/19.6）= 1.92（人/天）≈ 2（人/天）

④　對於其餘待測功能點重複第3步，直至總體模塊估算完成。

結語

須要指出的是，雖然更爲準確的測試工做量估算是理想的效果，可是因爲測試工做對於其餘部門產出的依賴，每每在實際工做中，影響到計劃的測試進度安排的變量很是多並且難以預期。

估算結果是隨着工做迭代，一步步精確的一個過程。

測試管理人員須要密切關注測試真實進度，實際工做量與預估工做量之間的偏離，並及時調整估算結果，同時也總結估算偏離的緣由，爲本身和項目的後續估算工做累積經驗。