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

?

轉(zhuǎn)載于:https://www.cnblogs.com/songzhenhua/p/9312819.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。