我們是否經(jīng)常看到開發(fā)人員針對我們歸檔的bug report要求提供更多的信息？我們是否經(jīng)常需要在bug report歸檔后花更多的時間去研究那個問題？我們是否經(jīng)常從開發(fā)人員那里聽到在他們那邊難以重現(xiàn)bug并且需要即刻提供“可重現(xiàn)的步驟”？廣義上來說，我們與其花更多的時間在這些問題上還不如投資更多的時間來測試系統(tǒng)。問題出在bug report的質(zhì)量上。這里介紹一些如何改進并達到完美bug report的建議。

?

Bug report的目的

當我們發(fā)現(xiàn)一個缺陷時，我們需要把它告訴給開發(fā)人員。Bug report就是這種溝通的媒介物。Bug report的主要目的是讓開發(fā)人員親眼看到這個錯誤。如果你不能和他一起以在他面前制造出那個失敗，那么就需要給他們足夠多的指引以便他們能夠自己制造出那個失敗。Bug report就是解釋在期望結(jié)果和實際結(jié)果之間的差距并且詳細的說明如何重現(xiàn)那個場景。

?

在發(fā)現(xiàn)缺陷之后

·???????? 只有當你確信你已經(jīng)發(fā)現(xiàn)一個bug的時候開始起草bug report，不要在測試結(jié)束或每天結(jié)束之后。那樣，你可能會遺忘掉一些東西。更糟的情況是，我們可能會忘掉那個bug。

·???????? 花一些時間去診斷你正在報告的缺陷。想想可能存在的原因。可能到最后你會發(fā)現(xiàn)更多的缺陷。在你的bug report中說說你的發(fā)現(xiàn)。開發(fā)人員將不僅僅對你使他們的工作變得輕松而感到高興。

·???????? 在開始讀你的bug report之前抽出一些時間來。你可能會感覺到象重新編寫報告一樣。

?

摘要

Bug report的摘要是你bug report給讀者的第一印象。你提交的bug的命運很大程度依賴于你的bug report能否吸引讀者。原則就是每個bug應(yīng)該有一個簡單有趣的摘要。它可能會聽上去象編寫一個優(yōu)秀的勾起注意的廣告活動。但是隨后，沒有什么意外。一個好的摘要應(yīng)該不超過50到60個字符。而且一個好的摘要不應(yīng)該承載任何對bug主觀的表達。

?

語言

·???????? 不要在bug report中夸大缺陷。同樣，也不要太輕描淡寫了。

·???????? 不管bug是多么的令人討厭，別忘了是bug令人討厭，而不是開發(fā)人員。永遠不要冒犯開發(fā)人員的努力。使用委婉些的說法。“混亂的UI”可以被溫和些改為“不正確的UI”。這樣開發(fā)人員的努力將會得到尊重。

·???????? 保持簡單誠實。你不是在寫散文或文章，因此使用簡單的語言

·???????? 在編寫bug report的時候記住你的目標讀者。他們可能是開發(fā)人員，其他的測試人員，經(jīng)理，或者在一些情況下，甚至是客戶。Bug report應(yīng)該可以被所有的人理解。

?

可重現(xiàn)的步驟

·???????? “可重現(xiàn)的步驟”的流程應(yīng)該是合乎邏輯的。

·???????? 清楚的列出前提條件

·???????? 寫下平常的步驟。例如，如果一個步驟要求用戶創(chuàng)建文件并且為它命名，不要要求用戶命名為“Mihir’s file”。最好命名為好像“Test File”一樣的文件名。

·???????? “可重現(xiàn)的步驟”應(yīng)該詳盡。例如，如果你想用戶在Microsoft Word里保存一個文件，你可以要求用戶到File菜單并且點擊Save子菜單項。你也可以只說“保存文件”。但是記住，并不是所有的人都知道如何在Microsoft Word中保存文件。因此最后遵守第一種方法。

·???????? 在一個干凈的系統(tǒng)里測試你的“可重現(xiàn)的步驟”。你可能會發(fā)現(xiàn)有些步驟被遺漏或是毫無關(guān)系的。

?

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

盡力編寫普通的bug report，開發(fā)人員可能沒有權(quán)限訪問你的測試數(shù)據(jù)。如果bug是和一組特定的測試數(shù)據(jù)相關(guān)，在你的bug report上附帶上它。

?

截屏

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

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

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

?

嚴重程序/優(yōu)先級別

·???????? 在設(shè)置bug report的嚴重程序之前應(yīng)該全面的分析缺陷的影響程序。如果你認為你的bug具有很高的優(yōu)先級應(yīng)該被修復(fù)，在bug report中證明這點。應(yīng)該在bug report的描述部分指出這個理由。

·???????? 如果bug是來自上個內(nèi)部小版本或版本回歸的結(jié)果，那么發(fā)出警報。象這種bug的嚴重程序可能是低的，但是優(yōu)先級別應(yīng)該是高。

?

日志

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

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

?

其他信息

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

·???????? 在bug report中寫下錯誤信息，特別是當錯誤信息有編號的時候。例如，來自數(shù)據(jù)庫中的錯誤信息。

·???????? 在bug report中寫下版本編號和內(nèi)部小版本編號

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

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

·???????? 如果可以重現(xiàn)bug的測試環(huán)境是開發(fā)人員可以訪問的，寫下訪問這種設(shè)置的詳情。這將幫助他們節(jié)約安裝環(huán)境的時間以重現(xiàn)你提交的bug。

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