測試工作量估算是整個測試過程中不可忽視的環節，關乎項目整體的交付計划及時間工期安排。預估的越准確，對項目整體節奏的把握更有利。
我們首先要強調，估算估算，本身就帶有預測性質，其准確程度是要受到多方面因素制約的，尤其是信息的充分性。
越是大型的復雜項目，對於估算的要求就越高；反之，小規模“短頻快”的項目則對於估算要求不那么高。
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步，直至整體模塊估算完成。
結語
需要指出的是，雖然更為准確的測試工作量估算是理想的效果，但是由於測試工作對於其他部門產出的依賴，往往在實際工作中，影響到計划的測試進度安排的變量非常多而且難以預期。
估算結果是隨着工作迭代，一步步精確的一個過程。
測試管理人員需要密切關注測試真實進度，實際工作量與預估工作量之間的偏離，並及時調整估算結果，同時也總結估算偏離的原因，為自己和項目的后續估算工作累積經驗。