我的理解，效率不等于速度，效率=速度+質量+進度。
經過上次和大家的討論，我歸納我們的測試效率和以下幾點有關：
對業務組測試人員效率的度量因素如下：
1. Bug總數，包含數量，等級，其他因素不變的前提下，肯定是bug數越多這位測試人員的效率越高，在統計bug數的時候，可以根據bug等級×相應的基數來計算bug總數。比如，bug數=V級×1.5+IV級×1.3+III級+II級×0.7+I級×0.5。
2. 有效Bug所占的比例，即使我們報上去很多bug，但有效的卻不多，也不能說明我們效率高，反而，無效的bug會浪費開發和測試相關人員很多時間處理，降低了我們的效率。
3. 發布后的線上故障，現階段測試相關的故障主要都是因為測試遺漏，有遺漏就說明我們的測試還是效率不高，可以改進。
4. Bug發現的時間點，bug曲線的收斂性，理想的效率高的模式應該是前多后少，慢慢收斂的，如果前期bug非常少，后期卻發現大量bug，那我們的前期效率就有問題。
5. TC評審或review時考察TC的數量，速度，質量，顆粒度，對功能點的覆蓋，是否有遺漏等等，參加評審人員提出的修改建議，給出打分，評價測試人員TC準備的效率，同時，提出較多修改意見的評審人員的效率也是比較高的。
6. TC評審通過，執行完之后，需要考察執行的速度和質量準確率，同樣的用例，有人2天就執行完了，有人卻要3天，說明速度不佳;一個case，測試的時候OK，后期卻發現其實應該是NG，說明執行不認真，或者理解有問題，這些都是低下的效率，尤其是為了趕進度填寫假的結果，嚴重違背我們誠信的基本價值觀。
7. 測試人員造成的二次預發布，將對很多人和整體造成影響，也要計入測試人員的效率中。
對技術組(性能自動化和環境)測試人員效率的度量因素如下：
1. 自動化測試的引入和使用是否合理，不是每個項目都適合做自動化的，自動化并不能保證效率的提高，用5個小時開發的自動化腳本來替代3個小時的手工測試并不合算，自動化測試需要評審，按照項目的大小不同，必要的情況下才引入自動化測試;
2. 自動化測試，特別是性能測試結束之后，我們要分析部分測試結果，測試結果的分析水平，也可以作為衡量測試效率的一個指標。
對測試項目負責人的效率的度量因素如下：
1. 測試是否提早介入項目，例如FRD階段就介入，越早介入，越有利于測試，使測試人員更加熟悉整個項目，使問題早暴露，提高整體效率。
2. 開發提交測試的時候，標準是否合理，把關是否嚴格，如果開發的質量不行，堅決要退回，不然會影響我們測試的效率和進度。
3. 測試計劃階段，評價測試計劃的合理性，包括任務細化，細化的程度是否合理，任務順序，資源安排，任務分配合理，風險預估等等
4. 項目結束后，評價項目進行階段中負責人的跟進情況，特殊情況處理，風險觸發之后的處理，資源協調，信息收集，共享，溝通，配合等等
需要做到以上，我們必須用量化的方法得到很多數據才能度量我們的測試效率，我期望的效果是測試部門內部成員的工作業績數據化，例如，每天給每個測試工程師分配的任務非常具體，測試負責人隨時關注他們的進展情況，完成的百分比，并不斷督促他們，每天報告總體狀態和緊急情況。并且，把每個人每天或每周的工作成果(發現bug的數量和工作的質量，效率)數據化，通過郵件的形式發給組內的成員，讓大家有個比較。大家都有自尊心，看到自己落后，后面就主動加油趕工，形成一種良好的測試氛圍。每周周例會的時候，對表現突出的給予表揚，對每次都比較差的下屬，單獨談心，問問具體原因，改進他們的效率，多給他們一些幫助，這樣有利于你們的小組的整體進步。
測試效率作為新的KPI，將在09年慢慢落實，上面很多的數據現在還沒有具體量化，我們會通過技術委員會或者架構組SQA幫我們取得相關量化的數據，慢慢充實改進我們的測試效率度量方法，大家先看一下上面的內容，可能有遺漏，如果有更好的想法或建議，請隨時盡早提出給我。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
