使用缺陷資料來測量績效是誘人的。測試人員是找缺陷的，因此您期望好的測試人員找到很
多缺陷。許多管理人員通過收集和跟蹤缺陷資料來進行績效管理。然而， 缺陷數量報告僅能
對個人業績提供非常有限的參考。尤其是同事人之間的比較時， 缺陷資料具有太多的可變數，
比如下面的幾方面：
•所測試功能的複雜性
•開發人員程式設計能力
•規格完整性
•缺陷預防與缺陷發現
•報告的及時性
此外，如果有人打算利用缺陷數量數作為乙個業績考核標準，該人必須理解該標準的引數和
考慮到諸如如下的問題：
•報告的缺陷具有什麼嚴重性和優先度, 分布如何？
•功能缺陷與簡單的使用者介面缺陷一樣算數量嗎？ •花費時間（一天或幾天）追蹤一
個關鍵問題（如資料丟失，記憶體洩漏）並使之得到解決，這能說明沒有達到預期或
業績表現差嗎？如果是，什麼是團隊合作的政策，即協助開發人員排解疑難問題？
•缺陷質量是乙個因素嗎？如果是的話，在團隊裡，這些具體因素是如何決定缺陷
的？團隊平均值是什麼？平均數是目標嗎？哪些具體的因素是超過預期的目標？
•每一次評比，最低的缺陷數量是什麼？什麼樣的缺陷數量是測試人員超過期望的數
量？ 發現了大量的缺陷可能表明測試人員做的很好，或者它可能意味著開發人員編寫的**很
差。反之，如果乙個測試人員找到很少的缺陷，這可能是乙個跡象:表明他做得不理想，也
可能意味著他正在測試高質量的**，具有較低的缺陷密度。所以關鍵是怎樣解讀資料，這
也意味著可能需要額外的個案調查。例如，如果乙個測試人員沒有報告很多缺陷，看一下功
能區以確定是什麼原因造成缺陷數量低。如果其他使用者（客戶、開發，beta測試使用者）在該
功能區找到缺陷，該測試人員的低缺陷數可能會有問題。如果是測試執行次數 （用測試用例
或**覆蓋資訊為度量） ，低缺陷數量也是值得調查的。當然，如果進一步的調查後，您確
定功能區的測試不錯，沒有多少缺陷，這當然就不該怪測試人員了。
乙個缺陷度量的故事
當我剛開始在微軟工作時， 對找缺陷數量有特定的要求。我的經理告訴我， 團隊裡的每乙個
測試人員每星期應找到 10 個缺陷。這似乎像乙個合理的要求，所以我努力去工作，並開始
尋找缺陷。 像大多數微軟的員工，我一直想做得更多一點， 所以我每星期找出 12 或 13 個缺
陷。幸運的是，我所測試的領域總是在變化，對我來說，完成配額從來沒有問題。事實上，有幾
個星期，我發現 20 個或更多的缺陷！當發生這種情況，我卻很擔心，我已發現太多的缺陷，
下週我將無法完成我的配額。所以，我每週只報 13 個缺陷左右，這樣來「節省‖缺陷，以防
下一周我的缺陷枯竭。
這是另一類典型的例子，它表明你衡量的是什麼。我的經理每星期要 10 個缺陷，我給了他
所想要的，卻不管我是否能發現更多的缺陷。我一再看到有人企圖利用缺陷度量來衡量個人
業績，但這些度量很少有效。
——摘自《微軟測試之道》第9章
HashMap不能使用基本資料型別作為key
抄自 在hashmap中，為什麼不能使用基本資料型別作為key？其實和hashmap底層的儲存原理有關，hashmap儲存資料的特點是 無序 無索引 不能儲存重複元素。儲存元素採用的是hash表儲存資料，每儲存乙個物件的時候，都會呼叫其hashcode 方法，算出其hash值，如果相同，則認為是相同...
HashMap不能使用基本資料型別作為key
hashmap儲存元素採用的是hash表儲存資料，每儲存乙個物件的時候，都會呼叫其hashcode 方法，算出其hash值，如果相同，則認為是相同的資料，直接不儲存，如果hash值不同，則再呼叫其equals方法進行比較，如果返回true，則認為是相同的物件，不儲存，如果返回false，則認為是不同...
pdfcrop不能使用
最近，用到了pdfcrop，用來去除pdf中空白的邊。但是使用pdfcrop margins 0 pdf 後，給出了錯誤 error pdfcrop cannot call ghostscript 但是我已經安裝了ctex，裡面已經包含ghostscript，所以就不知道什麼錯誤。在網上針對這個問題...