雖然，目前測試工作越來越受到企業的重視，已形成規模，參與測試工作的人越來越多，投入也越來越大。但與之不協調的是沒有一個配套的、較為合理的工作量統計方法。原有的測試工作量計算方法，一般是把測試人員進入項目的時間與進入項目的人員數量相乘，得到項目測試的工作量。該計算方法由于計算友善，容易操作，深閱聽人多項目的推崇。
但是，随着測試在項目的重要性的加深，測試工作分工日益細化，測試資源強調有效重用，測試團隊協作越來越強，使用這種方法已經不能滿足測試工作量計算的需要了：上級上司不了解整個測試團隊資源的使用情況；測試團隊負責人難于對項目測試任務實際執行過程産生的工作量、成本進行跟蹤；項目組在考核績效時，遺漏了部分測試人員的工作量。
是以，在項目測試領域急需一種新的工作量統計方法。筆者将這方面的一些實踐進行了總結，供讀者朋友參考。
其基本思路如下：首先就任務類型的設定要達成一緻；其次從每日的工作量收集開始，将測試任務按照一定的類别進行分類；然後将工作量資料按照不同的需求進行統計，得出不同的統計表；最後對這些統計表的資料進行分析，得出相應的結論。
設定任務類型
設定任務類型，是每日工作量資料錄入的前提。任務類型需要在整個測試團隊内達成一緻，這樣大家有了相同的标準，得出的資料才具有統計的意義。本文以某公司的項目測試為例進行介紹，其任務類型如表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中建立和維護的。在團隊規模不是很大時，或者處于試用初期時，使用很友善、實施成本也低。但是如果團隊規模較大，團隊成員比較多，資料量較大的話，這種手工方式就顯得有些力不從心了。讀者可以自行開發一個工作量管理系統，使用資料庫的方式來記錄、分析這些資料。在使用初期可先實作每日工作量資料的錄入，以及針對個人、項目、任務類型等屬性的統計分析功能即可。
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/