（一）常規的估算測試工作量的方法
作為一個管理者，你是否被詢問到某個項目要花多少時間，多少人力測試；或是作為一個普通的測試員，你是否被詢問到要花多少時間來完成某個任務或是一次回歸測試？我想大多數在軟件行業的人或多或少都會碰到這樣的關于工作量估計的詢問。那么你是怎么回答的呢？你對你自己的回答有信心嗎？你是否終發現實際上花去的時間和原本估計的時間大相徑庭呢？
不同的人會使用許多不同的方法來估算及安排他們的測試工作量。不同的組織根據項目的類型，項目的內在風險，涉及的技術等而使用不同的方法。但是大多數時候測試工作量是和開發工作量合在一起的，沒有一個單獨的數字。
首先讓我們來看看一些常規的估算測試工作量的方法：
1. Ad-hoc方法
這種方法下的測試工作量不基于任何確定的期限。工作一直繼續直到達到一些由管理或市場人員預先定下的時間表。或者，一直到用完了預算的經費。
這種情況普遍存在于非常不成熟的組織，并且時常有100％的錯誤差數。
2.開發時間的百分比法Percentage of development time
.這個方法的基本前提是測試工作量依賴于開發時間/開發工作量。首先，開發工作量使用例如LOC或FP方法被估算出來，然后使用一些探索性的方法來限制測試的工作量。這種方法變化比較大而且通常基于以前的經驗。
通常預留項目的總花費時間的35％給測試。
5-7%給組件和集成測試
18-20%給系統測試
10%給接收測試（或回歸測試等）
3.類比法（經驗值法或歷史數據法）
根據以前或相似項目（主要在項目性質，領域，規模上有相似）所積累的經驗或歷史數據來估算工作量。類比法估計結果的精確度取決于歷史項目數據的完整性和準確度，因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數據分析是可信賴的。需要收集以下相關的歷史數據：
在設計和實現階段花費的時間
測試工作的規模，例如用戶需求的數量，頁面數，功能點
數據樣式，例如實體，字段的數量
屏幕或字段數量
測試對象的規模，例如KLOC
4.WBS（work breakdown structure）估算法
將項目或產品分解為具體的工作，然后分別對各個工作進行時間估算，終求和得出項目或產品的測試工作量/時間。
5.Delphi 法
Delphi法是流行的專家評估技術，在沒有歷史數據的情況下，這種方式可以減輕估算的偏差。Delphi法鼓勵參加者問題相互討論。這個技術，要求有多種相關經驗人的參與，互相說服對方。
Delphi法的步驟是：
1、協調人向各專家提供項目規格和估計表格；
2、協調人召集小組會各專家討論與規模相關的因素；
3、各專家匿名填寫迭代表格；
4、協調人整理出一個估計總結，以迭代表的形式返回專家；
5、協調人召集小組會，討論較大的估計差異；
6、專家復查估計總結并在迭代表上提交另一個匿名估計；
7、重復4-6， 直到達到一個低和高估計的一致。
6.PERT估計法
PERT對各個項目活動的完成時間按三種不同情況估計：一個產品的期望規模，一個低可能估計，一個高可能估計。用這三個估計用來得到一個產品期望規模和標準偏差的Pert 統計估計。Pert 估計可得到代碼行的期望值E， 和標準偏差SD。
(二) 代碼行分析方法
測試工作量的估計往往和軟件開發的規模是緊密相關的.很多軟件公司往往是在估計了即將要開發的軟件規模后才做測試工作量的估計，然后求和得出項目的終工作量估計.這種方法比較適用于有經驗積累，測試和開發模式穩定的公司或項目，提供了一個比較準確，有參考的數字.但同時由于其完全依賴其前提-開發工作量的估計，顯得比較脆弱，如果開發工作量出現較大偏差，測試工作量也變得毫無用處.在加之代碼行本身存在著許多問題和局限，所以在選擇其做為項目估算方法時需要好好了解它的原理，優缺點進而有選擇性的使用.
