我們是否經??吹?a href='http://www.anti-gravitydesign.com/ceshi/ruanjianceshikaifajishu/' target='_blank'>開發人員針對我們歸檔的bug report要求提供更多的信息?我們是否經常需要在bug report歸檔后花更多的時間去研究那個問題?我們是否經常從開發人員那里聽到在他們那邊難以重現bug并且需要即刻提供“可重現的步驟”?廣義上來說,我們與其花更多的時間在這些問題上還不如投資更多的時間來測試系統。問題出在bug report的質量上。這里介紹一些如何改進并達到完美bug report的建議。
Bug report的目的
當我們發現一個缺陷時,我們需要把它告訴給開發人員。Bug report就是這種溝通的媒介物。Bug report的主要目的是讓開發人員親眼看到這個錯誤。如果你不能和他一起以在他面前制造出那個失敗,那么就需要給他們足夠多的指引以便他們能夠自己制造出那個失敗。Bug report就是解釋在期望結果和實際結果之間的差距并且詳細的說明如何重現那個場景。
在發現缺陷之后
◆ 只有當你確信你已經發現一個bug的時候開始起草bug report,不要在測試結束或每天結束之后。那樣,你可能會遺忘掉一些東西。更糟的情況是,我們可能會忘掉那個bug。
◆ 花一些時間去診斷你正在報告的缺陷。想想可能存在的原因??赡艿阶詈竽銜l現更多的缺陷。在你的bug report中說說你的發現。開發人員將不僅僅對你使他們的工作變得輕松而感到高興。
◆ 在開始讀你的bug report之前抽出一些時間來。你可能會感覺到象重新編寫報告一樣。
摘要
Bug report的摘要是你bug report給讀者的第一印象。你提交的bug的命運很大程度依賴于你的bug report能否吸引讀者。原則就是每個bug應該有一個簡單有趣的摘要。它可能會聽上去象編寫一個優秀的勾起注意的廣告活動。但是隨后,沒有什么意外。一個好的摘要應該不超過50到60個字符。而且一個好的摘要不應該承載任何對bug主觀的表達。
語言
◆ 不要在bug report中夸大缺陷。同樣,也不要太輕描淡寫了。
◆ 不管bug是多么的令人討厭,別忘了是bug令人討厭,而不是開發人員。永遠不要冒犯開發人員的努力。使用委婉些的說法。“混亂的UI”可以被溫和些改為“不正確的UI”。這樣開發人員的努力將會得到尊重。
◆ 保持簡單誠實。你不是在寫散文或文章,因此使用簡單的語言
◆ 在編寫bug report的時候記住你的目標讀者。他們可能是開發人員,其他的測試人員,經理,或者在一些情況下,甚至是客戶。Bug report應該可以被所有的人理解。
可重現的步驟
◆ “可重現的步驟”的流程應該是合乎邏輯的。
◆ 清楚的列出前提條件
◆ 寫下平常的步驟。例如,如果一個步驟要求用戶創建文件并且為它命名,不要要求用戶命名為“Mihir’s file”。最好命名為好像“Test File”一樣的文件名。
◆ “可重現的步驟”應該詳盡。例如,如果你想用戶在Microsoft Word里保存一個文件,你可以要求用戶到File菜單并且點擊Save子菜單項。你也可以只說“保存文件”。但是記住,并不是所有的人都知道如何在Microsoft Word中保存文件。因此最后遵守第一種方法。
◆ 在一個干凈的系統里測試你的“可重現的步驟”。你可能會發現有些步驟被遺漏或是毫無關系的。
測試數據
盡力編寫普通的bug report,開發人員可能沒有權限訪問你的測試數據。如果bug是和一組特定的測試數據相關,在你的bug report上附帶上它。
截屏
截屏是bug report中一個十分必要的部分。一個圖片勝過一千句話。但是不要把在每個bug report里附帶沒有必要的截屏變成一個習慣。理想的來說,你的bug report應該是足夠有效的使開發人員重現問題。截屏應該只是驗證的一種方法。
◆ 如果你要在bug report里附帶截屏,要確保那些圖片不是太大的,使用jpg或gif的格式,而不是bmp格式
◆ 在截屏上寫上注釋以指出問題所在。這將幫助開發人員一眼就可以馬上定位問題。
嚴重程序/優先級別
◆ 在設置bug report的嚴重程序之前應該全面的分析缺陷的影響程序。如果你認為你的bug具有很高的優先級應該被修復,在bug report中證明這點。應該在bug report的描述部分指出這個理由。
◆ 如果bug是來自上個內部小版本或版本回歸的結果,那么發出警報。象這種bug的嚴重程序可能是低的,但是優先級別應該是高。
原文轉自:http://www.uml.org.cn/Test/200612143.htm