軟件測試中如何編寫一個更好的缺陷報告
我們是否經�？吹介_發人員針對我們歸檔的bug report要求提供更多的信息？我們是否經常需要在bug report歸檔后花更多的時間去研究那個問題？我們是否經常從開發人員那里聽到在他們那邊難以重現bug并且需要即刻提供“可重現的步驟”？廣義上來說，我們與其花更多的時間在這些問題上還不如投資更多的時間來測試系統。問題出在bug report的質量上。這里介紹一些如何改進并達到完美bug report的建議。
Bug report的目的當我們發現一個缺陷時，我們需要把它告訴給開發人員。Bug report就是這種溝通的媒介物。Bug report的主要目的是讓開發人員親眼看到這個錯誤。如果你不能和他一起以在他面前制造出那個失敗，那么就需要給他們足夠多的指引以便他們能夠自己制造出那個失敗。Bug report就是解釋在期望結果和實際結果之間的差距并且詳細的說明如何重現那個場景。
什么是Bug報告，為什么我們要編寫它？
Bug報告描述了所測試系統的失效模式，它也是軟件測試工程的唯一可見產物。通過它與開發人員進行交流，并提高產品質量。
開發人員如果返回很多不可復現的Bug報告，那么我們用來編寫這個Bug報告的時間就算是浪費了，同時也使開發人員和測試人員都感到沮喪，對產品質量的提高也沒有任何的好處。
有多種原因可能產生一個不能復現的Bug報告，Bug不是連續出現的，測試和開發的環境不一致，對于什么是正確的行為有爭論。但是很多不可復現的Bug報告則是由于不恰當的設想和編寫的時候不注意造成的。
以下十條建議可以幫助我們編寫一個好的Bug報告：
1.結構化：仔細的測試
2.復現：再測試一次
3.分離：用不同的環境或步驟來測試
4.概括：在其它相似的地方測試
5.比較：查看其它相似測試的結果
6.總結：把測試同客戶聯系起來
7.簡化：去掉不必要的信息
8.去除歧義：用清楚的字眼來描述
9.中立:公正的描述問題
10.檢查：再查看一遍。
要記住;寫東西就是在創造，兩個關于同一個問題的好的Bug報告在風格和內容上都是不一樣，除了本質。
結構化：
結構化的測試是一個好的Bug報告的基礎：
用有計劃的，仔細的方法來測試，遵照之前寫好的測試用例或者運行自動化測試用例，仔細的做好備注。
當我們所期望和所觀察到的結果不一致的時候就產生了Bug報告，糟糕的測試也會導致糟糕的Bug報告。
好的軟件測試更像是一個實驗室里一個仔細設計的試驗，而不是在閃電中隨意行走或者更糟，畢竟，測試員是個工程師。
復現：
永遠要把檢查失效復現作為編寫測試報告的一部分，一般來說，三次是比較好的。編寫一個能復現這個失效的干脆的步驟。
當報告那些間斷出現或者很難復現的失效時，要注明失效發生的幾率，例如，嘗試了3次，出現1次失效。
試著去找出那些不能復現的的Bug的步驟，事實上，很多時候是我們的步驟不正確或環境原因導致Bug不能復現。
分離：
改變某些參數可能會影響現象：
1.一次改變一個參數
2，這需要對所測試系統的理解和思考
3.可能不會馬上見效
依據問題的嚴重程度來決定你要投入多少努力，同時要避免進入調試狀態
好的分離工作可以顯現出你的勤勉，同時給開發人員的調試活動一個好的開始。
概括：
尋找所測試系統中相關的失效，同樣的失效是否存在于其它的模塊或者其它的位置？同樣的錯誤是否會導致更嚴重的后果？
同時要避免與不相關的問題相混淆，不同的Bug可能也會出現同樣的癥狀。
通過概括可以減少重復的Bug報告，同時幫助更好的理解失效。
比較：
比較相似的測試的結果，有兩層含義：一是在早期版本上運行的同樣的測試，二是在當前版本上，相似的條件下，其它測試的情況。
考慮失效是否是一個回歸問題？是否當前版本中的一個改變導致了在早期版本上不會出現的問題，這通常是在之前的版本上能通過在這版又失效的情況。
但這并不是都可行的，有時候在以前的版本上測試會遭受阻礙，重新安裝又是不切實際的，有時候要測試的功能在之前的版本上并沒有實現。
總結：
給每個報告弄一個標記線（Tag line),記住它的失效模式，同時想想可能給顧客造成什么影響，
比如說：保險杠貼紙（在美國開車，你很可能到處都會看到保險杠貼紙。上面的訊息可能是政治性的，宗教性的，時事導向的，或者是純幽默性的。有些印刷公司可以讓顧客自行設計貼紙上的標語。）
但是它不像看起來那么簡單，測試人員需要時間來想這件事，好的總結可以起到以下的作用：可以得到管理階層的重視，給Bug報告取一個好的名字，同時也有助于設置Bug的優先級別。
簡化：
去掉那些不相干的步驟和文字，寫完之后重新再仔細地讀一遍，去掉那些看起來神秘或者啰嗦的字眼，考慮一下是否還存在無關的動作或者細節？每個人的時間都很有限，去掉那些無關的啰嗦，但是也不要去掉緊要的部分。
去除歧義：
去掉那些含糊的，誤導人和主觀的字眼或者描述，確保報告不會讓人誤解，去除歧義的目標是對于事實有清楚的，無可爭議的陳述來引導開發人員。
中立：
溫和的發表壞消息，在措辭和所包含的言外之意都要公正，避免攻擊開發人員，批評低級錯誤或者任何的幽默或者諷刺，使Bug報告僅限于陳述事實，你可能不會想到以后誰將會閱讀你的Bug報告。
檢查：
每個測試人員都應該提交Bug報告給一個或者更多的同事去檢查。而負責檢查的同時則應該提出一些建議來提高Bug報告的質量，問一些使報告可以更清晰的問題，甚至在適當的時候挑戰Bug成災。
測試組應該在給定的有限的時間里提交盡可能好的Bug報告。
文章來源于領測軟件測試網 http://www.kjueaiud.com/