1.為什么要寫缺陷報告

　　當我們發現Bug后，需要通知開發人員，缺陷報告是一種溝通的介質，它的主要目的是讓開發人員能夠親眼看到這個Bug是什么，如果不提供足夠詳細的說明來幫助開發人員重現Bug，那么他們就沒法確定問題的根源。缺陷報告是一種用來說明期望結果和實際結果之間的差異以及描述bug如何重現的文檔。發現Bug,最好是一發現并確認了bug就立即填寫缺陷報告，而不要等到當天測試結束再和其他bug一起填，因為那時就有可能遺漏一些要點，甚至是遺漏某個bug。花點時間分析一下造成Bug的根本原因是什么，你可能會因此發現更多的Bug，最好能把你的任何有用的證據都寫到缺陷報告上。缺陷報告提交之前自己再讀一遍，可能會有錯別字或者什么寫錯的地方需要重寫。

　　2.填寫缺陷報告時應注意的幾個地方

　　2.1標題

　　缺陷報告的“標題”部分是一個缺陷報告帶給讀者的最初印象，它在瀏覽大量Bug時起著非常重要的作用，每個缺陷報告都應該有一個能夠突出重點的“標題”，就好像做廣告一樣。好的標題應該控制在措辭，要據實反應情況，不要夸大或縮小Bug的影響。有時候會發現一些令人不可思議的低級Bug，但還是要盡量使用較為委婉的詞語來表述，免得傷害開發人員的自尊心。

　　2.2描述

　　描述越簡單直接越好，要考慮到目標讀者，他們可能是開發人員、測試人員、管理人員或者其他人，所以要讓目標讀者都能看得懂Bug描述。

　　2.3重現的步驟

　　每一步以及所有步驟組合起來應該是符合邏輯的。清晰地列出所需的前置條件。

　　步驟應盡量詳細，例如，我們要描述通過excel保存一個表格，那么有兩種方式，一是說得細點兒，即“從[表格]菜單里單擊[保存]，另一種就是說得簡單點，即“保存表格”，但請記住，并非所有人都知道如何從excel保存表格，或者說所有人都會使用同樣的方式保存表格，所以描述的時候最好還是采用第一種方式。寫完之后自己用新的測試數據或者在新的系統上按照步驟親自執行一遍，或許能夠發現缺陷報告里有一些是遺漏的或多余的步驟。

　　2.4測試數據

　　開發人員重現Bug時可能不會訪問測試環境，有些Bug可能只能用一定的測試數據才能重現，所以盡量把測試數據附在缺陷報告上。

　　2.5屏幕截圖

　　屏幕截圖是缺陷報告里非常重要的組成部分，有時一張圖能勝過千言萬語，但也不能養成習慣不管有用沒用的圖都往上貼，或者是只貼圖而缺少文字描述。附圖能夠使開發人員結合你的描述快速地重現Bug是最理想的：所附圖片的尺寸和占用空間不要太大，盡量用jpg或gif格式，而不要用bmp格式。在圖中出問題的地方標注一下，更利于開發人員快速定位。

　　2.6嚴重程度/優先級

　　設置Bug的嚴重程度之前，應該全面地分析Bug的影響，如果我們認為這個Bug的優先級很高，那么應該在缺陷報告里說明優先級高的原因。

　　2.7日志

　　如果可以的話一定要把程序報錯的日志附上，這會讓開發人員比較容易進行分析和調試。很多不能重現的Bug都是因為缺少日志，開發人員就會返回去找測試人員要日志信息。如果日志文件不大的話，比如十幾行，那么可以直接把日志信息粘到缺陷報告里，如果日志很大的話，那么最好單獨粘到一個文件里，然后當作缺陷報告的附件就可以了。