##
###
外包項目測試工作量評估指南
1、目的
編寫本指導書的目的旨在為我公司進行測試外包服務工作進行指導，幫助項目經理和相關人員編寫測試方案、評估工作量、制定測試計划和測試策略等，以盡量減小項目工作量評估上的風險。
2、適用范圍和對象
本指南的使用范圍是對於測試外包服務項目前期做整體的測試方案時，需要對工作量進行評估的項目經理、測試專家參考的文檔。
3、工作量評估原則
一個特定項目需要的工作量依賴於很多變量。包括：組織文化或者組織的“測試程度度”、被測試項目的軟件復雜度、需要測試的范圍、執行測試的個體的技能水平以及承擔測試工作的測試組織的類型。不過，就算給出影響工作量的變量也不能真正反映出實際付出的工作量，因為每個項目都是不同的。
對於測試項目評估，在評估工作量時，從下面幾點進行把握：
1、工作量評估是建立在商務溝通的基礎之上的，客戶比我們更了解系統；
2、工作量評估采用的任何方法都只是一個估計，所以風險因素是要考慮的；
3、工作量評估必須經過領導、專家組組成的小組的評審。
4、外包測試項目
根據外包測試項目主要有兩種方式，一種是on-site，稱為離岸外包，另一種是off-site是在公司內部做。不管是以那種方式，都需要對工作量進行全面的評估，而對於人力外包的項目則不需要工作量評估。由於IT系統項目實施是智力型密級行業，到目前為止，還沒有一套科學有效、准確的評估方法，尤其是對於我們還不熟悉的行業，所以我們根據搜集到的資料以及我們的項目經驗，整理出本文的幾種方法，作為參考。
5、幾種方法的對比
6、開發比例法
這個方法的基本前提是測試工作量依賴於開發周期/開發工作量。不管開發團隊依據何種方式評估研發的工作量，我們測試團隊可以根據研發團隊的研發周期，確定大致的測試工作量。
通過下面的方式獲得開發周期/開發工作量：
A. 通過商務溝通或技術溝通獲得研發的進度表或研發周期；
B. 獲得客戶計划的整個項目的時間；
C. 根據研發工作量通過參考下面的表格估計工作量。
在評估需要的工作量以及相應的人員配置時，也要參考一下研發人員和測試人員的比例，如果測試團隊在項目需求階段就進入，則通過3：2、3：1等這樣的比例估計需要投入的測試人員，這個比例沒有一定的約束，主要根據系統對錯誤的容忍度，例如，醫療設備系統或飛機控制系統不能容忍錯誤，而銀行涉及到重大財產安全則應該也不能容忍大的錯誤存在。評估時，這也是需要考慮的一個方面。
表1：測試各階段比例估算
| 單元測試結果審核 |
集成測試 |
系統功能測試 |
系統性能測試 |
系統驗收測試 |
所占百分比合計 |
| 2%~5% |
8%~11% |
18%~24% |
8%~15% |
3%~5% |
39%~60% |
|
|
9%~12% |
18%~24% |
8%~15% |
3%~5% |
38%~56% |
|
|
|
22%~28% |
8%~15% |
3%~5% |
33%~48% |
|
|
|
|
14%~20% |
12%~20% |
26%~40% |
|
|
|
|
|
15%~24% |
15%~24% |
|
|
|
|
15%~21% |
|
15%~21% |
注：灰色背景表示不進行測試測試。
如果公司沒有被評估項目所屬的行業的項目經驗，則應該在所占百分比基礎上增加5%~10%的風險工作量。
上面表格中前三行我們所做的系統驗收測試活動為輔助驗收測試活動，即有輔助客戶完成驗收測試。而后面只有兩行則驗收測試則可以作為一個獨立的測試，客戶參與人員很少，所以需要更多的工作量，可以根據客戶的實際情況進行相應調整。
外包項目測試工作量評估指南
發表於：2008-2-20 17:36 作者：manok 來源：manok的博客
字體：大 中 小 | 上一篇 | 下一篇 |我要投稿 | 推薦標簽：
7、項目經驗類比法
根據公司以前所做的相似項目，主要在項目性質，領域，規模上考慮，所積累的經驗或歷史數據來估算工作量。項目經驗類比法估計結果的精確度取決於對歷史項目我們所收集數據的完整性和准確度。因此，項目經驗類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數據分析是可信賴的。
主要從下面幾個方面借鑒原項目情況：
1、項目所屬的行業。不同的行業，在類比時要考慮差異性。有無行業經驗是需要考慮的。該考慮要體現在工作量中，但是不能體現方案中。
2、項目的架構、規模、包括研發、測試工作量、代碼行數等。這些數據對於評估可參考性比較強，注意項目實施中這些數據的收集。逐漸提高測試中的數據統計，提高我們測試能力的成熟度。
3、用戶需求的數量。這個通過對比用戶需求，大致估計系統特點、功能復雜程度，有無新技術應用等，這些數據可用於對比。
4、開展的測試活動。注意在原項目所進行的測試活動，與當前項目所進行的測試活動，再借鑒上面開發時間百分比法。
5、當時有無項目經驗。原項目是否是新開拓的領域，則當時付出的工作量肯定會多一些，當前項目與原項目為同一個行業領域，則會減少一些工作量。
6、參與人員的情況。當前可參加到項目組人員情況與原項目人員情況進行對比。測試工程師以及業務分析師的項目經驗是需要考慮的因素之一。
7、客戶的情況，例如對系統質量要求、重視的程度。客戶如果對質量很重視，實施質量管理規范，則可能對研發團隊要求也高，這樣系統交付質量可能會高一些；
8、項目系統使用對象。項目使用對象是需要考慮的，例如使用者對計算機的熟悉程度。系統是客戶內部使用，還是面對Internet用戶，這樣對系統的安全性要求程度不同。
9、研發公司的情況。研發公司是否為知名公司，其研發能力的成熟度會高一些，對項目質量要求也可能高一些。該公司在行業中的做系統的名譽、口碑如何，也可以參考。
評估流程可參考如下：
1、在公司知識庫中搜索相似項目，獲得相似項目的信息；
2、把當前項目與相似項目進行對比，找出差異性，可參考上面對比數據；
3、對差異性進行分析，找出當前項目的特點；
4、對當前項目進行評估，沒有的測試階段評估方法可參考其他的評估方法；
5、最后統計出總的工作量，請相關的領導、項目經理、測試專家參與討論，確定下最后的工作量。
8、WBS法
WBS（work breakdown structure）估算法。將項目或產品分解為具體的工作，然后分別對各個工作進行時間估算，最終求和統計得出項目或產品的測試工作量。
在工作拆分的原則應該是盡量把工作拆分為可以用小時或人/日度量、可以安排給一個測試工程師完成、且可以有交付物的工作。
在評估時，可以參考一下研發規模。例如代碼行數（LOC）、等價的代碼行數、功能點。
在評估中根據我們需要進行的測試活動，把每個測試活動進行拆分，同時把測試需求、測試用例、測試用例執行、輪次、缺陷修復等都進行拆分，評估每個活動需要的工作量。
這種評估的輸入是需要客戶的需求規格說明書的，且需要該文檔描述用戶需求比較詳盡、全面，才能比較准確的評估所需要的工作量。對需求規格說明書中的功能需求和非功能需求進行分解，可以通過一條或多條測試需求來描述。
單元測試結果審核評估流程：
1、如果有系統詳細設計說明書，則依據詳細說明書中划分的模塊，來計算划分的單元模塊數量；如果沒有該文檔，是否可通過其他文檔估算單元模塊的數量；
2、確定單元測試審核中每個活動的工作量，例如，文檔審核、測試用例審核，測試結果審查、缺陷報告審查、如果需要單元抽測，則需要單獨計算工作量。
表2：單元測試結果審核評估表
產品集成測試評估流程：
1、把整個系統分解成子系統，確定每個子系統的接口數量。對於如何確定接口，主要根據子系統是否與其他子系統存在輸入/輸出數據而確定。
2、對每兩個子系統之間有接口的子系統進行評估，需要構造多少測試用例覆蓋接口，也要考慮接口之間的測試方案，如何構造測試數據，如何滿足集成測試環境等。
3、需要考慮整個集成測試的所用的工作量，可以參考上面集成測試大約占整個測試的工作量的比例。
表3：集成測試工作量評估表
系統功能測試評估流程：
1、把整個系統中的各子系統分解成功能點，在各功能點上確定操作數量，確定功能點的口徑，例如把下一個訂單做一筆交易，做一次交易歷史數據的查詢作為一個功能點，即功能點應該是系統中獨立的能夠實現某個具體功能的一系列操作。在具體功能點中時，需要考慮功能點對應的操作數量，例如交易類型、查詢中的升序、降序，都視作一個操作。把功能點和操作數量累計出來，形成一個功能點的需求數。
2、統計出所有的需求點后為整個系統中的功能需求總數。再考慮測試中具體的方案的工作量，是否考慮自動化測試、是否需要構造大量基礎數據等。
3、需要考慮整個系統功能測試所用的工作量，可以參考上面系統測試大約占整個測試的工作量的比例。
表4：系統功能測試評估表
系統性能測試評估流程：
1、把整個系統中的性能需求點整理出來，注意我們性能測試包括的范圍是功能測試之外的所有測試活動；
2、評估每個性能點需要的工時，形成整個系統性能測試的總工時。
表5：系統性能測試評估表
UAT測試評估流程：
1、在商務溝通階段，盡量獲得客戶對UAT的期望，由客戶來實施，還是我們協助來實施UAT測試；
2、根據客戶希望我們測試團隊所做的工作，確定大致的工作量。一般應該是我們協助進行UAT測試，大概需要幾位測試工程師進行支持即可。根據客戶期望的UAT時間，來確定我們測試團隊所付出的工作量。
9、Delphi法
Delphi法是最流行的專家評估技術，在沒有歷史項目數據的情況下，這種方式可以減輕估算的偏差。Delphi法鼓勵參加者就問題相互討論。這個技術，要求有多種相關經驗人的參與，互相說服對方。
Delphi法的評估步驟是：
1、項目協調人向各測試專家和項目經理介紹項目規格和估計表格；
2、項目協調人召集小組會，各測試專家和項目經理討論與規模相關的因素；
3、各測試專家匿名填寫迭代表格；
4、項目協調人整理出一個估計總結，以迭代表的形式返回測試專家；
5、項目協調人召集小組會，討論較大的估計差異；
6、測試專家復查估計總結並在迭代表上提交另一個匿名估計；
7、重復4-6， 直到達到一個最低和最高估計的基本一致。