##php
###html
外包項目測試工做量評估指南
一、目的
編寫本指導書的目的旨在爲我公司進行測試外包服務工做進行指導，幫助項目經理和相關人員編寫測試方案、評估工做量、制定測試計劃和測試策略等，以儘可能減少項目工做量評估上的風險。算法
二、適用範圍和對象
本指南的使用範圍是對於測試外包服務項目前期作總體的測試方案時，須要對工做量進行評估的項目經理、測試專家參考的文檔。安全
三、工做量評估原則
一個特定項目須要的工做量依賴於不少變量。包括：組織文化或者組織的「測試程度度」、被測試項目的軟件複雜度、須要測試的範圍、執行測試的個體的技能水平以及承擔測試工做的測試組織的類型。不過，就算給出影響工做量的變量也不能真正反映出實際付出的工做量，由於每一個項目都是不一樣的。架構
對於測試項目評估，在評估工做量時，從下面幾點進行把握：性能
一、工做量評估是創建在商務溝通的基礎之上的，客戶比咱們更瞭解系統；單元測試
二、工做量評估採用的任何方法都只是一個估計，因此風險因素是要考慮的；測試
三、工做量評估必須通過領導、專家組組成的小組的評審。字體
四、外包測試項目
根據外包測試項目主要有兩種方式，一種是on-site，稱爲離岸外包，另外一種是off-site是在公司內部作。不論是以那種方式，都須要對工做量進行全面的評估，而對於人力外包的項目則不須要工做量評估。因爲IT系統項目實施是智力型密級行業，到目前爲止，尚未一套科學有效、準確的評估方法，尤爲是對於咱們還不熟悉的行業，因此咱們根據蒐集到的資料以及咱們的項目經驗，整理出本文的幾種方法，做爲參考。url
五、幾種方法的對比
六、開發比例法
這個方法的基本前提是測試工做量依賴於開發週期/開發工做量。無論開發團隊依據何種方式評估研發的工做量，咱們測試團隊能夠根據研發團隊的研發週期，肯定大體的測試工做量。
經過下面的方式得到開發週期/開發工做量：
A. 經過商務溝通或技術溝通得到研發的進度表或研發週期；
B. 得到客戶計劃的整個項目的時間；
C. 根據研發工做量經過參考下面的表格估計工做量。
在評估須要的工做量以及相應的人員配置時，也要參考一下研發人員和測試人員的比例，若是測試團隊在項目需求階段就進入，則經過3：二、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的博客
字體：大 中 小 | 上一篇 | 下一篇 |我要投稿 | 推薦標籤：
七、項目經驗類比法
根據公司之前所作的類似項目，主要在項目性質，領域，規模上考慮，所積累的經驗或歷史數據來估算工做量。項目經驗類比法估計結果的精確度取決於對歷史項目咱們所收集數據的完整性和準確度。所以，項目經驗類比法的前提條件之一是組織創建起較好的項目後評價與分析機制，對歷史項目的數據分析是可信賴的。
主要從下面幾個方面借鑑原項目狀況：
一、項目所屬的行業。不一樣的行業，在類比時要考慮差別性。有無行業經驗是須要考慮的。該考慮要體如今工做量中，可是不能體現方案中。
二、項目的架構、規模、包括研發、測試工做量、代碼行數等。這些數據對於評估可參考性比較強，注意項目實施中這些數據的收集。逐漸提升測試中的數據統計，提升咱們測試能力的成熟度。
三、用戶需求的數量。這個經過對比用戶需求，大體估計系統特色、功能複雜程度，有無新技術應用等，這些數據可用於對比。
四、開展的測試活動。注意在原項目所進行的測試活動，與當前項目所進行的測試活動，再借鑑上面開發時間百分比法。
五、當時有無項目經驗。原項目是不是新開拓的領域，則當時付出的工做量確定會多一些，當前項目與原項目爲同一個行業領域，則會減小一些工做量。
六、參與人員的狀況。當前可參加到項目組人員狀況與原項目人員狀況進行對比。測試工程師以及業務分析師的項目經驗是須要考慮的因素之一。
七、客戶的狀況，例如對系統質量要求、重視的程度。客戶若是對質量很重視，實施質量管理規範，則可能對研發團隊要求也高，這樣系統交付質量可能會高一些；
八、項目系統使用對象。項目使用對象是須要考慮的，例如使用者對計算機的熟悉程度。系統是客戶內部使用，仍是面對Internet用戶，這樣對系統的安全性要求程度不一樣。
九、研發公司的狀況。研發公司是否爲知名公司，其研發能力的成熟度會高一些，對項目質量要求也可能高一些。該公司在行業中的作系統的名譽、口碑如何，也能夠參考。
評估流程可參考以下：
一、在公司知識庫中搜索類似項目，得到類似項目的信息；
二、把當前項目與類似項目進行對比，找出差別性，可參考上面對比數據；
三、對差別性進行分析，找出當前項目的特色；
四、對當前項目進行評估，沒有的測試階段評估方法可參考其餘的評估方法；
五、最後統計出總的工做量，請相關的領導、項目經理、測試專家參與討論，肯定下最後的工做量。
八、WBS法
WBS（work breakdown structure）估算法。將項目或產品分解爲具體的工做，而後分別對各個工做進行時間估算，最終求和統計得出項目或產品的測試工做量。
在工做拆分的原則應該是儘可能把工做拆分爲能夠用小時或人/日度量、能夠安排給一個測試工程師完成、且能夠有交付物的工做。
在評估時，能夠參考一下研發規模。例如代碼行數（LOC）、等價的代碼行數、功能點。
在評估中根據咱們須要進行的測試活動，把每一個測試活動進行拆分，同時把測試需求、測試用例、測試用例執行、輪次、缺陷修復等都進行拆分，評估每一個活動須要的工做量。
這種評估的輸入是須要客戶的需求規格說明書的，且須要該文檔描述用戶需求比較詳盡、全面，才能比較準確的評估所須要的工做量。對需求規格說明書中的功能需求和非功能需求進行分解，能夠經過一條或多條測試需求來描述。
單元測試結果審覈評估流程：
一、若是有系統詳細設計說明書，則依據詳細說明書中劃分的模塊，來計算劃分的單元模塊數量；若是沒有該文檔，是否可經過其餘文檔估算單元模塊的數量；
二、肯定單元測試審覈中每一個活動的工做量，例如，文檔審覈、測試用例審覈，測試結果審查、缺陷報告審查、若是須要單元抽測，則須要單獨計算工做量。
表2：單元測試結果審覈評估表
產品集成測試評估流程：
一、把整個系統分解成子系統，肯定每一個子系統的接口數量。對於如何肯定接口，主要根據子系統是否與其餘子系統存在輸入/輸出數據而肯定。
二、對每兩個子系統之間有接口的子系統進行評估，須要構造多少測試用例覆蓋接口，也要考慮接口之間的測試方案，如何構造測試數據，如何知足集成測試環境等。
三、須要考慮整個集成測試的所用的工做量，能夠參考上面集成測試大約佔整個測試的工做量的比例。
表3：集成測試工做量評估表
系統功能測試評估流程：
一、把整個系統中的各子系統分解成功能點，在各功能點上肯定操做數量，肯定功能點的口徑，例如把下一個訂單作一筆交易，作一次交易歷史數據的查詢做爲一個功能點，即功能點應該是系統中獨立的可以實現某個具體功能的一系列操做。在具體功能點中時，須要考慮功能點對應的操做數量，例如交易類型、查詢中的升序、降序，都視做一個操做。把功能點和操做數量累計出來，造成一個功能點的需求數。
二、統計出全部的需求點後爲整個系統中的功能需求總數。再考慮測試中具體的方案的工做量，是否考慮自動化測試、是否須要構造大量基礎數據等。
三、須要考慮整個系統功能測試所用的工做量，能夠參考上面系統測試大約佔整個測試的工做量的比例。
表4：系統功能測試評估表
系統性能測試評估流程：
一、把整個系統中的性能需求點整理出來，注意咱們性能測試包括的範圍是功能測試以外的全部測試活動；
二、評估每一個性能點須要的工時，造成整個系統性能測試的總工時。
表5：系統性能測試評估表
UAT測試評估流程：
一、在商務溝通階段，儘可能得到客戶對UAT的指望，由客戶來實施，仍是咱們協助來實施UAT測試；
二、根據客戶但願咱們測試團隊所作的工做，肯定大體的工做量。通常應該是咱們協助進行UAT測試，大概須要幾位測試工程師進行支持便可。根據客戶指望的UAT時間，來肯定咱們測試團隊所付出的工做量。
九、Delphi法
Delphi法是最流行的專家評估技術，在沒有歷史項目數據的狀況下，這種方式能夠減輕估算的誤差。Delphi法鼓勵參加者就問題相互討論。這個技術，要求有多種相關經驗人的參與，互相說服對方。
Delphi法的評估步驟是：
一、項目協調人向各測試專家和項目經理介紹項目規格和估計表格；
二、項目協調人召集小組會，各測試專家和項目經理討論與規模相關的因素；
三、各測試專家匿名填寫迭表明格；
四、項目協調人整理出一個估計總結，以迭表明的形式返回測試專家；
五、項目協調人召集小組會，討論較大的估計差別；
六、測試專家複查估計總結並在迭表明上提交另外一個匿名估計；
七、重複4-6， 直到達到一個最低和最高估計的基本一致。