1.為什么要寫缺陷報告

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

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

　　2.1標題

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

　　2.2描述

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

　　2.3重現(xiàn)的步驟

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

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

　　2.4測試數(shù)據(jù)

　　開發(fā)人員重現(xiàn)Bug時可能不會訪問測試環(huán)境，有些Bug可能只能用一定的測試數(shù)據(jù)才能重現(xiàn)，所以盡量把測試數(shù)據(jù)附在缺陷報告上。

　　2.5屏幕截圖

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

　　2.6嚴重程度/優(yōu)先級

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

　　2.7日志

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