1.為什么要寫缺陷報告

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

　　2.填寫缺陷報告時應(yīng)注意的幾個地方

　　2.1標(biāo)題

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

　　2.2描述

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

　　2.3重現(xiàn)的步驟

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

　　步驟應(yīng)盡量詳細(xì)，例如，我們要描述通過excel保存一個表格，那么有兩種方式，一是說得細(xì)點(diǎn)兒，即“從[表格]菜單里單擊[保存]，另一種就是說得簡單點(diǎn)，即“保存表格”，但請記住，并非所有人都知道如何從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)成習(xí)慣不管有用沒用的圖都往上貼，或者是只貼圖而缺少文字描述。附圖能夠使開發(fā)人員結(jié)合你的描述快速地重現(xiàn)Bug是最理想的：所附圖片的尺寸和占用空間不要太大，盡量用jpg或gif格式，而不要用bmp格式。在圖中出問題的地方標(biāo)注一下，更利于開發(fā)人員快速定位。

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

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

　　2.7日志

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