使用缺陷數據來測量績效是誘人的。測試人員是找缺陷的，因此您期望好的測試人員找到很 多缺陷。許多管理人員通過收集和跟蹤缺陷數據來進行績效管理。然而， 缺陷數量報告僅能 對個人業績提供非常有限的參考。尤其是同事人之間的比較時， 缺陷數據具有太多的可變量， 比如下面的幾方面：? ?所測試功能的復雜性? ?開發人員編程能力? ?規格完整性? ?缺陷預防與缺陷發現? ?報告的及時性 此外，如果有人打算利用缺陷數量數作為一個業績考核標準，該人必須理解該標準的參數和 考慮到諸如如下的問題： ?報告的缺陷具有什么嚴重性和優先度, ?分布如何？? ?功能缺陷與簡單的用戶界面缺陷一樣算數量嗎？ ??花費時間（一天或幾天）追蹤一 個關鍵問題（如數據丟失，內存泄漏）并使之得到解決，這能說明沒有達到預期或 業績表現差嗎？如果是，什么是團隊合作的政策，即協助開發人員排解疑難問題？? ?缺陷質量是一個因素嗎？如果是的話，在團隊里，這些具體因素是如何決定缺陷 的？團隊平均值是什么？平均數是目標嗎？哪些具體的因素是超過預期的目標？? ?每一次評比，最低的缺陷數量是什么？什么樣的缺陷數量是測試人員超過期望的數 量？? 發現了大量的缺陷可能表明測試人員做的很好，或者它可能意味著開發人員編寫的代碼很 差。反之，如果一個測試人員找到很少的缺陷，這可能是一個跡象:表明他做得不理想，也 可能意味著他正在測試高質量的代碼，具有較低的缺陷密度。所以關鍵是怎樣解讀數據，這 也意味著可能需要額外的個案調查。例如，如果一個測試人員沒有報告很多缺陷，看一下功 能區以確定是什么原因造成缺陷數量低。如果其他用戶（客戶、開發，Beta測試用戶）在該 功能區找到缺陷，該測試人員的低缺陷數可能會有問題。如果是測試運行次數 （用測試用例 或代碼覆蓋信息為度量） ，低缺陷數量也是值得調查的。當然，如果進一步的調查后，您確 定功能區的測試不錯，沒有多少缺陷，這當然就不該怪測試人員了。 一個缺陷度量的故事 當我剛開始在微軟工作時， 對找缺陷數量有特定的要求。我的經理告訴我， 團隊里的每一個 測試人員每星期應找到 10 個缺陷。這似乎像一個合理的要求，所以我努力去工作，并開始 尋找缺陷。 像大多數微軟的員工，我一直想做得更多一點， 所以我每星期找出 12 或 13 個缺 陷。 幸運的是，我所測試的領域總是在變化，對我來說，完成配額從來沒有問題。事實上，有幾 個星期，我發現 20 個或更多的缺陷！當發生這種情況，我卻很擔心，我已發現太多的缺陷， 下周我將無法完成我的配額。所以，我每周只報 13 個缺陷左右，這樣來“節省‖缺陷，以防 下一周我的缺陷枯竭。 這是另一類典型的例子，它表明你衡量的是什么。我的經理每星期要 10 個缺陷，我給了他 所想要的，卻不管我是否能發現更多的缺陷。我一再看到有人企圖利用缺陷度量來衡量個人 業績，但這些度量很少有效。 ——摘自《微軟測試之道》第9章

?

轉載于:https://www.cnblogs.com/songzhenhua/p/9312819.html

總結

以上是生活随笔為你收集整理的不能使用缺陷数据作为绩效度量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。