如何寫好測試報告

　　最近讀Cem Kaner，James Bach，Bret Pettichord合著的《軟件測試經驗與教訓》受益頗多，因此根據文中的部份內容總結出來與大家共享，希望能達到知識交流與共享的目的。如果感興趣，也可以閱讀原書。

　　測試報告是產品部與技術部進行溝通的主要手段，測試報告的好壞直接影響BUG的修改速度和程序員的心情。如果下苦功夫研究并寫好報告，則所有閱讀這些報告的人都會受益。因此我整理并撰寫此文，希望對于能修直產品部與技術部的橋梁有所幫助。

　　一、 缺陷報告的原則

　　1、 有些錯誤永遠也不會改正。測試員的責任不是保證所有錯誤都得到改正，而是準確報告問題，使程序員能夠理解問題的影響。而深入研究并寫出好的報告，常常對錯誤改正的可能性產生巨大的影響。

　　2、 及時報告缺陷。不要等到第二天或是下周才報告程序錯誤，不要等到忘記了一些關鍵細節才報告。拖延的時間越長，程序錯誤被解決的可能性就越小。

　　3、 每個程序錯誤都需要單獨報告。不要努力把不同的程序錯誤合并到同一份報告，來減輕項目經理或程序員對重復錯誤報告的不斷抱怨。如果多個程序錯誤寫到一份報告中，有些錯誤就可能得不到修改。

　　4、 小缺陷也值得報告。小錯誤會使客戶感到困惑，并降低客戶對產品其他部份的信心。被認為是很小的缺陷可能包括拼寫錯誤、小的屏幕格式問題，鼠標遺跡、小的計算錯誤，圖形比例不準、在線幫助錯誤、不適當的灰掉了的菜單選項、不起作用的快捷鍵、不正確的錯誤信息，以及其它程序員認為不值得花精力去修改的缺陷。

　　5、 努力使錯誤報告有更高的價值。由于有很多人都要閱讀并依賴錯誤報告，因此要下功夫豐富每個錯誤報告的信息。提高報告的可理解性。如：A、清楚列出錯誤報告的前置條件與實現的每一個步驟，避免前后語言混亂，它應該只需要描述現象，不要在產生錯誤的步驟中試圖給出程序員的解決辦法。這樣會使錯誤報告看來冗長而難于理解。如果有好的解決辦法或建議可以附在錯誤報告描述之后。B、要始終保持中立語氣。C、不要開玩笑，否則有可能造成誤解。

　　6、 永遠都要報告不可重現的錯誤，這樣的錯誤可能是時間炸彈。不可重現的錯誤可能會是公司能夠支付的最昂貴的缺陷。有時錯誤無法重現?？吹匠绦蝈e誤一次，但不知道如何使其再次出現。如果產品交付客戶還出現這種情況，會影響客戶對產品的信心，如果技術支持人員需要很長時間評估客戶的數據或環境，客戶則會更加厭煩。如果測試員清晰地報告錯誤征兆，程序員通過研究測試員怎么得到特定消息，或當測試員查看對話框或點擊特定控件時可能會出現的情況。從而能夠跟蹤代碼，相信程序員能夠改正報告中“不可重現”缺陷中的20%。但在報告此類BUG時，一定要明確說明自己不能重現這個程序錯誤。

　　二、 缺陷報告的注意事項

　　1、 引用別人的錯誤報告要小心。如果沒有得到錯誤報告的提交者的允許，可以補充評論，但不能編輯別人的材料。對于其他測試員的錯誤報告即使很糟糕也不要擅自修改。任何時候需要在錯誤報告中做補充，都要注明自己的姓名和日期。

　　2、 看似極端的缺陷可能是潛在的安全漏洞。如在一個在預期接受一個1~99的字段中，輸入65536個9會導致程序崩潰。會有人真的這么干嗎?是的，有人當然要這樣做。有人會認為“如果有人愚蠢到這樣做，程序崩潰會教訓他“而忽略該錯誤，但實際上白癡不是惟一濫用程序的人。任何會產生嚴重后果的問題都應該解決，不管其多么“不可能”發生，當熟練的攻擊者利用程序中的缺陷得手后，會寫下這個消息并廣為傳播，使得其所有生手都可以使用腳本。

　　3、 立即對程序錯誤延遲決定上訴，如果決定據理力爭，就一定要贏。如果測試員對某個BUG的處理有意見，確實需要上訴，不要依賴自己最初錯誤報告中的語言和信息，報告是不可更改的，但是測試員需要列舉更有效的例子，測試員需要與其他產品項目相關人員溝通，補充做一些后續測試，尋找該程序錯誤可能存在的更嚴重的錯誤。程序員所做的每個上訴都必須是有說服力的。即使不能贏得所有上訴(當然不可能贏得所有上訴)也應該得到自己的所有上訴理應獲勝的好名聲。

　　至此，上面羅列的條款都與我們實際工作有著密切的關聯，希望能借助此篇文章，讓你能有興趣讀完本書的全部內容,相信一定能讓你獲益匪淺。

原文轉自：http://www.uml.org.cn/Test/200512212.htm