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

我們首先要強調，估算估算，本身就帶有預測性質，其準確程度是要受到多方面因素制約的，尤其是資訊的充分性。

越是大型的複雜專案，對於估算的要求就越高；反之，小規模“短頻快”的專案則對於估算要求不那麼高。

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步，直至整體模組估算完成。

結語

需要指出的是，雖然更為準確的測試工作量估算是理想的效果，但是由於測試工作對於其他部門產出的依賴，往往在實際工作中，影響到計劃的測試進度安排的變數非常多而且難以預期。

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

測試管理人員需要密切關注測試真實進度，實際工作量與預估工作量之間的偏離，並及時調整估算結果，同時也總結估算偏離的原因，為自己和專案的後續估算工作累積經驗