（from：http://www.51testing.com/?94273/action_viewspace_itemid_9903.html）
Bug reportMILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">的核心是對錯誤的描述，而優秀的bug report對反映測試小組真實的和可理解的工作質量同測試本身一樣都是非常重要的。那么什么樣的缺陷報告才是優秀的缺陷報告呢？這里我引用一位測試界的大師總結的十大特性，并加上自己對于目前很多缺陷報告存在的問題的分析。希望可以給相關的測試工程師編寫缺陷報告時進行參考：
組織Structure：測試人員應該采用深思熟慮的，小心謹慎的方法執行測試，并且做詳盡的記錄。這樣可以促使他們對測試下的系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題的地方。（目前存在的主要問題：在編寫報告時邏輯不夠清晰，開發人員拿著缺陷報告還需要通過打電話跟測試人員交流才能重現問題，甚至需要讓測試人員當著開發人員來重現。往往一個問題需要交流上好幾次才能解決。）
重現Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現。如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反復嘗試3次。（目前存在的主要問題：很多時候測試人員因為時間不足（或者這個只是借口）根本就不按照測試用例來執行（測試用例這個時候只是一件例行的輸出件），所以發現問題的過程有時很隨機，以致在填寫缺陷報告時也沒有一個規格化的順序，可重現性比較差。）
隔離Isolate：在嘗試編寫bug report之前，必須試著隔離錯誤。可以采用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的癥狀。這些信息可以為開發人員著手調試提供思路（目前存在的主要問題：由于有些問題在很大程度處決于周邊的操作，比如多個測試人員同時使用同一套測試環境時，不可避免的存在相互影響，這個時候如果需要確保問題能得到合理的理解，需要測試人員把周邊環境描述清楚，而實際上這點往往更容易被人忽視）。
歸納Generalize：在測試人員發現了一個已隔離的，可重現的問題后，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？（目前存在的主要問題：很多人并不是不清楚某個問題可能在其他地方也可能出現，只是有時為了在統計Bug數量時有一個令人滿意的數量，而故意把本來是一個或者一類問題的問題拆分成多個。）
對比Compare：如果測試人員以前曾經驗證過現在出錯的測試用例，那么他就應該檢查以前的測試結果以檢查相同的條件是否通過以前的測試。如果是的話，那么這個問題就象是一個回歸的錯誤。注意由于同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結果。（目前存在的主要問題：很多測試人員對于回歸測試的理解僅僅停留在上個版本的用例在回歸版本的重復執行，而對于用例的大的預制條件考慮得不夠充分。）
總結Summarize：在bug report的第一行寫上錯誤的總結是非常關鍵的。測試人員要花些時間思考已發現的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設置錯誤修復的優先級別。（目前存在的主要問題：在寫缺陷報告標題時，很多人只是簡單描述下現象，都把現象作為標題，而原因并沒有在標題上也提示出來，他總是認為開發人員或者客戶不管怎么都會看完整個缺陷報告。）
精簡Condense：在bug report的初稿完成后，測試人員應該反復閱讀它，集中剔除那些沒有關系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關系的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。（目前存在的主要問題：事實上報告要做到在精簡和翔實之間找到一個平衡點，很多時候測試人員一般會認為越詳細的報告越有助于開發人員去重現問題。）
消除歧義Disambiguate：測試人員在精簡空話的同時或其之后隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該盡量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。（目前存在的主要問題：測試人員在對一些不能必然重現的問題時，一般都會說這種情況在某些可能的情況下會發生。對自己不確定的問題很喜歡加上“可能發生”，“正常情況下會重現”等）
中立Neutralize：如文中所述，作為壞消息的傳遞人，和善地提交消息是一個挑戰。如同所有的錯誤總結一樣，獨立的bug report在措辭方面應該保持公正。攻擊開發人員，指責潛在的錯誤，企圖詼諧或使用挖苦將引起開發人員的憎惡，并且使注意力從“提高產品質量”這個大的目標上轉移開了。謹慎的測試人員只用Bug report來描述事實。（目前存在的主要問題：測試人員有時在對于連預測試都沒有通過的遺留到正式測試時的問題會感到氣氛，認為開發人員怎么一點都不負責，因此報告中會情不自禁的加上自己的感情色彩。）
檢查Review：一旦測試人員感覺bug report是他能夠編寫的最好版本，他應該將報告再給一個或多個同行進行檢查。他的同事們也應該給出一些建議，為了澄清問題不斷地提問，如果適當的話，甚至可以挑戰“錯誤成災”的結論。在允許的時間里，測試小組應該盡可能提交最好的bug report。（目前存在的主要問題：業界的測試人員很少會把自己的缺陷報告供其他人去評審和檢查，除了測試組長可能會簡單審核下問題以外。）
總結：缺陷報告是體現測試工程師價值和水平的東西，希望這十條建議對大家能有一定的幫助，同時大家也可以思考下，在填寫缺陷報告的過程中，您是否也出現過同樣的問題。
