編寫文檔的質量體現的公式是：評審中發現的問題個數/編寫文檔的頁數�？墒窃跍y試的評審工作做得不是很完善的前提下，問題個數的統計是很難量化的，我也試著采用其他辦法，例如測試人員編寫的文檔是經過我審核的，那么我發現的問題就以bug的形式管理起來，這樣在考核的時候就有數據即可以參考，但是這樣的過程一是沒有過程監督不是很規范，問題的紀錄不全面，有時候圖方便就直接跟負責這個文檔的測試人員說哪里需要改進，沒有進行問題紀錄；二是個人的精力有限，有時候忙起來就草草看了一下，這樣對其他仔細看過的文檔的數據就沒有可比性；另外關于文檔頁數這個指標個人認為也不是很準確，很多文檔都不是頁數與時間成正比的，根項目復雜程度和類似項目有沒有做過有很大關系，所以與此關聯的編寫文檔效率的指標也沒有應用。
測試用例的編寫效率的公式是：測試用例個數/編寫測試用例的有效時間。這里編寫的測試用例個數有的測試用例是從通用用例里直接導過來的，這和其他重新編寫的分開在統計上就很麻煩，另外根據個人分配的項目模塊的復雜程度測試用例的編寫效率也有不同體現。雖然這個指標已經在實際統計中應用，但是也有相應的測試人員提出過疑義。
無效bug率的公式為：無效bug數/發現bug總數。目前我一般是一個月統計一次相關考核指標，但是目前的缺陷跟蹤工作做得不好，有很多bug在開發那邊不能及時響應，這就造成了我統計的時候發現的bug總數有大半開發人員還沒來得及看，那么無效bug數當然也就不準確了。
還有bug的嚴重程度的劃分，因為有的bug級別高并不等于很難發現，所以這就造成了有些測試人員刻意的去追求那種很容易發現但是bug級別又很高的bug，這就有點偏離考核本身的目的。
以上絮叨這么多的根本原因還是我們的開發過程和測試過程均不是很完善，但我還是把已經統計的一些指標拿出來看一下，結果不能體現出全部，也沒有拿它與績效掛鉤，但是有時候從結果還是能分析出一些東西來的~~~~
2006年11月（10.27～12.1）發現bug工作情況 服務器嚴重程度姓名1 姓名2 姓名3 合計 71 1 0 6 0 1 0 6 13 80 6 1 6 71 2 2 51 2 22 4 38 111 80 49 20 34 71 3 3 102 1 19 1 53 174 80 99 18 52 71 4 0 20 1 14 0 22 56 80 20 13 22 71 5 0 0 0 0 0 0 0 80 0 0 0 總計 179 56 119 354 工時 68 13 39 120 姓名1 姓名2 姓名3 平均值 效率 2.63 4.31 3.05 2.95 質量 0.51 0.76 0.57 0.61 分數 5.1 5.9 5.7 5.6 效率=∑缺陷數（個）/ ∑執行系統測試的有效時間（小時）
質量=1級*0.3+2級*0.2+3級*0.2+4級*0.1+5級*0 / ∑執行系統測試的有效時間（小時）
2006年11月（10.27～12.1）設計、執行用例工作情況 任務類別姓名1 姓名2 姓名3 平均值 設計個數 0 85 115 100.00 設計工時 0 30.5 32.5 31.5 bug數 0 51 72 61.5 設計效率 0.00 2.79 3.54 3.16 設計質量 0.00 0.60 0.63 0.61 設計分數 0.00 2.86 3.09 2.98 執行個數 87 0 99 93 執行工時 31 0 35 33 bug數 56 0 111 83.5 執行效率 2.81 0.00 2.83 2.82 執行質量 0.64 0.00 1.12 0.88 執行分數 2.99 0.00 3.95 3.47 分數 2.95 2.86 3.52 3.11 設計效率=∑測試用例數（個）/ ∑編寫測試用例有效時間（小時）
執行效率=∑測試用例數（個）/ ∑執行系統測試的有效時間（小時）
設計質量=∑缺陷數（系統測試）（個）/ ∑設計測試用例數（個）
執行質量=∑缺陷數（系統測試）（個）/ ∑執行測試用例數（個）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
