如何編寫更佳的bug report[2]

　　如何編寫更佳的bug report[2]   軟件測試

　　測試數據

　　盡力編寫普通的bug report，開發人員可能沒有權限訪問你的測試數據。如果bug是和一組特定的測試數據相關，在你的bug report上附帶上它。

　　截屏

　　截屏是bug report中一個十分必要的部分。一個圖片勝過一千句話。但是不要把在每個bug report里附帶沒有必要的截屏變成一個習慣。理想的來說，你的bug report應該是足夠有效的使開發人員重現問題。截屏應該只是驗證的一種方法。

　　◆　如果你要在bug report里附帶截屏，要確保那些圖片不是太大的，使用jpg或gif的格式，而不是bmp格式

　　◆　在截屏上寫上注釋以指出問題所在。這將幫助開發人員一眼就可以馬上定位問題。

　　嚴重程序/優先級別

　　◆　在設置bug report的嚴重程序之前應該全面的分析缺陷的影響程序。如果你認為你的bug具有很高的優先級應該被修復，在bug report中證明這點。應該在bug report的描述部分指出這個理由。

　　◆　如果bug是來自上個內部小版本或版本回歸的結果，那么發出警報。象這種bug的嚴重程序可能是低的，但是優先級別應該是高。

　　日志

　　在bug report里附上日志或日志的摘錄片斷。這將幫助開發人員輕松地分析且調試系統。多數情況下，如果不附上日志而且在開發人員那邊又很難重現問題的話，他們將會把bug report打回給你并要求附帶日志文件。

　　如果日志文件不太大的話，舉個例子，大約20到25行，你就可以把它貼在bug report里。但是如果它比較大的話，把它做為附件貼在bug report里，否則你的bug report會看上去象個日志。

　　其他信息

　　◆　如果你的bug是隨機出現的，只需在你的bug report中說一下就可以了。但是不要忘記歸檔它。你總是能夠在你發現它們之后的任何時間里增加準確的步驟。這也將在其他人提交這個問題時解救你，特別是當那個問題比較嚴重時。

　　◆　在bug report中寫下錯誤信息，特別是當錯誤信息有編號的時候。例如，來自數據庫中的錯誤信息。

　　◆　在bug report中寫下版本編號和內部小版本編號

　　◆　寫下問題可以被重現的平臺。準確的說明問題不可重現的平臺。同樣也要理解問題在特定平臺上不可重現和沒有在某個平臺上測試之間的分別。這個可能會造成混淆。

　　◆　如果你遇到幾個問題卻有一樣的結果，只需寫一個bug report。問題的修復可能只是一個。同樣，如果你在不同的地方遇到相似的問題，且要求同一種修復方法,但是在不同的地方，那么就要為每一個問題書寫單獨的bug report。每個bug report對應一個修復。

　　◆　如果可以重現bug的測試環境是開發人員可以訪問的，寫下訪問這種設置的詳情。這將幫助他們節約安裝環境的時間以重現你提交的bug。

　　◆　你決不能堅持關于bug的任何信息。在bug被修復之前由于低效的提交bug而引起的開發人員和測試人員之間不必要的交互只是浪費時間。

原文轉自：http://www.anti-gravitydesign.com