軟件測試作為軟件生命周期中不可或缺的重要環節，正在受到越來越多的重視。然而，在實際項目測試工作中卻存在一個突出的問題，就是測試工作量的統計問題。如何統計更科學、更準確，本文作者在實際工作中進行了摸索和嘗試。
雖然，目前測試工作越來越受到企業的重視，已形成規模，參與測試工作的人越來越多，投入也越來越大。但與之不協調的是沒有一個配套的、較為合理的工作量統計方法。原有的測試工作量計算方法，一般是把測試人員進入項目的時間與進入項目的人員數量相乘，得到項目測試的工作量。該計算方法由于計算方便，容易操作，深受眾多項目的推崇。
但是，隨著測試在項目的重要性的加深，測試工作分工日益細化，測試資源強調有效重用，測試團隊協作越來越強，使用這種方法已經不能滿足測試工作量計算的需要了：上級領導不了解整個測試團隊資源的使用情況；測試團隊負責人難于對項目測試任務實際執行過程產生的工作量、成本進行跟蹤；項目組在考核績效時，遺漏了部分測試人員的工作量。
所以，在項目測試領域急需一種新的工作量統計方法。筆者將這方面的一些實踐進行了總結，供讀者朋友參考。
其基本思路如下：首先就任務類型的設置要達成一致；其次從每日的工作量收集開始，將測試任務按照一定的類別進行分類；然后將工作量數據按照不同的需求進行統計，得出不同的統計表；最后對這些統計表的數據進行分析，得出相應的結論。
設置任務類型
設置任務類型，是每日工作量數據錄入的前提。任務類型需要在整個測試團隊內達成一致，這樣大家有了相同的標準，得出的數據才具有統計的意義。本文以某公司的項目測試為例進行介紹，其任務類型如表1所示。
這里提到的測試任務類型，在實踐中會根據項目實際需要進行調整。例如，新增“測試工具學習”任務類型等。
另外，在表1所示的任務類型中，有一項比較靈活的任務類型——溝通。有的團隊認為溝通都是有目的、有目標的，是一個為完成具體測試任務所進行的中間活動，所以他們把溝通作為具體測試任務的一部分。也就是說，對于這樣的團隊，他們沒有“溝通”這個任務類型。有的團隊則認為將溝通的內容很難劃清界限，為避免測試人員填寫工作量時發生混淆，所以，將“溝通”作為獨立的任務類型。筆者認為這屬于任務類型定義問題，測試團隊可以根據已經存在的約定俗成進行設置，只要在整個團隊內達成一致就可以的。
表1 測試任務類型分類
記錄工作量基礎數據
這項工作由團隊成員根據當天的工作任務完成情況進行記錄。它是后續工作量統計的基礎，所以要保證這項基礎數據收集的準確性，切不可應付了事，最好能在當天下班前填寫好當天工作量分配情況。
堅持記錄時間需要很強的自我約束能力，所以每天填寫工作量記錄需要一定的堅持力。在填寫工作量記錄時，需要為每個任務選擇相應的任務類型，填寫工作任務持續時間。工作任務持續時間最好不超過4個小時，這是為了避免填寫的任務過粗，不利于發現工作過程中的問題。
及時記錄、數據準確，是這個環節工作的原則。本例中某公司使用的工作量記錄表格如表2所示。
統計人力占用情況
這項工作主要統計測試團隊所有成員在各個項目中的投入情況，或者說是項目對測試人員的人力占用情況，每周統計一次。通過對人力占用情況進行統計，測試團隊負責人可以得到一份人力占用表。這份人力占用表的主要用途的有三個：
● 供測試團隊負責人和上級領導使用，方便他們了解測試團隊對項目的支持情況及項目占用測試資源的情況。
● 讓上級領導間接了解測試團隊的人員飽和度。如果測試團隊負責人要申請新增測試資源時，將整個團隊的歷史人力占用表作為數據證據提供給上級領導，可以增強申請的說服力。
● 提供給項目經理參考。避免項目經理在進行項目人員績效考核時，遺漏了部分測試人員的工作量。
這項人力占用情況統計工作，筆者建議使用者在每周末進行。統計結束后，測試團隊負責人將統計結果作為測試團隊工作匯報的一部分提交上級領導。本例中，某公司在某一周測試團隊人力占用情況如表2所示。
表2 工作量記錄表格
在本文的例子里，測試團隊在項目1一共投入了B、C、D三個人，B、C成員是100%資源投入。因為項目后續工作安排未知，而B、C成員又屬于項目1核心測試人員，因此這兩名成員的退出時間未知。另外一個測試成員D因為不屬于項目1的核心測試成員，所以他參與2個項目。同時因為項目2規模較小，所以成員D在項目2中投入20%的資源，在項目1中投入80%的資源。考慮到公司在2005年3月將要啟動一個新項目，所以，經過和項目1的項目經理協商后達成一致，計劃成員D在2005年2月退出該項目，這樣他在2005年3月將投入新啟動的項目。
通過及時更新、跟蹤這張表的數據，可以對團隊內測試人員的工作情況心中有數，并可根據公司業務發展、部門建設、人員發展需要，合理安排團隊成員的工作。
表3 測試團隊人力占用表
統計項目測試工作量投入情況
這項統計工作是在每日工作量統計的基礎上整理得到的。每周測試團隊成員提交工作匯報時，會將本周的工作量數據整理后一起提交。測試團隊負責人定期（每周或半個月）對團隊成員提交的數據進行匯總，并整理到項目工作量投入表中。這就解決了在實際測試執行過程中，測試人員無法對測試工作量進行跟蹤的問題。
筆者曾經碰到一個項目，該項目的測試計劃只安排了1.5人日的工作量，但是實際上該項目在測試計劃上總共投入了9人日的工作量。經過分析，筆者發現是兩個原因導致這個問題的發生：一是測試人員在填寫每日工作量記錄時，部分任務的“任務類型”選錯了；二是該項目測試組長在估算測試工作量時，沒有考慮到實際測試執行過程中也需要進行測試計劃工作，如每次測試執行的計劃、實際工作過程中的計劃更新工作等。通過這次分析后，該項目的測試工作量沒有再發生這么大的偏差了（偏差率＝（計劃值－實際值）/計劃值×100%）。所以說，測試工作量的統計、分析可以幫助使用者發現一些問題，并改進使用者的工作。某公司某一項目的測試團隊工作量投入情況如表4所示。
表4 某項目測試工作量統計表
通過這張統計表格，可以很清楚地了解某個人的工作量投入情況，及具體測試任務使用的工作量情況。
匯總項目測試數據
在項目關閉時，測試團隊負責人把整個項目測試過程中產生的數據以及項目基礎數據進行匯總。測試過程中產生的數據包括：測試工作量、測試投入成本，它的數據來源于表四；項目基礎數據包括：項目規模、項目總成本、項目總工作量，這些數據是向項目經理獲取的。這里提到的測試成本，是把每個測試人員的人力成本系數和工作量數據相乘得到的。所有相關人可以通過這張統計表了解項目組中測試占開發總工作量的比例，以及項目組用在測試上的開銷情況。這項工作是測試團隊資產沉淀的很重要的一項工作。主要用途是：從項目角度對項目測試整體情況進行分析；把測試團隊所承接測試的項目進行縱向對比，總結共性，發現問題。
例如，可以對這些項目的測試數據進行分析，得出測試工作量估算公式。再如，筆者曾經通過數據的對比，發現測試文檔編寫工作量占整個測試工作量的比例較大。通過進一步分析，發現測試用例的維護占用了測試設計很大一部分的工作量，從而應考慮在團隊內改進測試用例管理方法。某公司兩個項目的測試數據如表5所示。
表5 某測試團隊測試項目資產庫——測試數據
參考項目背景，筆者對幾個項目的測試數據進行分析后，得到了項目測試總人力成本的估算公式：測試總人力成本＝20%×項目總人力成本。
另外，通過把幾個項目的各項測試類型所花費的工作量進行對比分析后，筆者得出各項測試任務的工作量相對于測試總工作量的分配比例。對于后續的項目，項目測試組長可以參考這個分配比例進行測試工作量的估算。
當然，上面介紹的估算公式和工作量比例，只是適用于筆者所在的測試團隊。不同測試團隊、項目組、公司組織情況都不一樣，這里介紹這個例子，目的只是說明測試工作量統計的一個用途。
表6 某測試團隊各項測試任務的工作量比例
總結
測試工作量的統計，是整個測試團隊管理的基礎。測試團隊的管理、決策、策劃等需要數據的支持，即用數據說話，所以，數據的收集、統計是很重要的。有了這些數據之后，我們就可以將它應用到績效考核和項目成本核算上。
在本文中，筆者主要介紹的是測試團隊的工作量統計，但實際上這些方法不僅適用于測試團隊，也適用于個人、項目團隊或者整個公司組織。實施時只需要調整“任務類型”等與測試有關的屬性，并做一定的擴展即可。
本文使用的表格，都是在Excel中建立和維護的。在團隊規模不是很大時，或者處于試用初期時，使用很方便、實施成本也低。但是如果團隊規模較大，團隊成員比較多，數據量較大的話，這種手工方式就顯得有些力不從心了。讀者可以自行開發一個工作量管理系統，使用數據庫的方式來記錄、分析這些數據。在使用初期可先實現每日工作量數據的錄入，以及針對個人、項目、任務類型等屬性的統計分析功能即可。