Bug report的目的
當我們發(fā)現一個(gè)缺陷時(shí)，我們需要把它告訴給開(kāi)發(fā)人員。Bug report就是這種溝通的媒介物。Bug report的主要目的是讓開(kāi)發(fā)人員親眼看到這個(gè)錯誤。如果你不能和他一起以在他面前制造出那個(gè)失敗，那么就需要給他們足夠多的指引以便他們能夠自己制造出那個(gè)失敗。Bug report就是解釋在期望結果和實(shí)際結果之間的差距并且詳細的說(shuō)明如何重現那個(gè)場(chǎng)景。
在發(fā)現缺陷之后
◆ 只有當你確信你已經(jīng)發(fā)現一個(gè)bug的時(shí)候開(kāi)始起草bug report，不要在測試結束或每天結束之后。那樣，你可能會(huì )遺忘掉一些東西。更糟的情況是，我們可能會(huì )忘掉那個(gè) bug。
◆ 花一些時(shí)間去診斷你正在報告的缺陷。想想可能存在的原因�？赡艿阶詈竽銜�(huì )發(fā)現更多的缺陷。在你的 bug report中說(shuō)說(shuō)你的發(fā)現。開(kāi)發(fā)人員將不僅僅對你使他們的工作變得輕松而感到高興。
◆ 在開(kāi)始讀你的bug report之前抽出一些時(shí)間來(lái)。你可能會(huì )感覺(jué)到象重新編寫(xiě)報告一樣。
摘要
Bug report的摘要是你bug report給讀者的第一印象。你提交的bug的命運很大程度依賴(lài)于你的bug report能否吸引讀者。原則就是每個(gè)bug應該有一個(gè)簡(jiǎn)單有趣的摘要。它可能會(huì )聽(tīng)上去象編寫(xiě)一個(gè)優(yōu)秀的勾起注意的廣告活動(dòng)。但是隨后，沒(méi)有什么意外。一個(gè)好的摘要應該不超過(guò)50到60個(gè)字符。而且一個(gè)好的摘要不應該承載任何對bug主觀(guān)的表達。
語(yǔ)言
◆ 不要在bug report中夸大缺陷。同樣，也不要太輕描淡寫(xiě)了。
◆ 不管bug是多么的令人討厭，別忘了是bug令人討厭，而不是開(kāi)發(fā)人員。永遠不要冒犯開(kāi)發(fā)人員的努力。使用委婉些的說(shuō)法�！盎靵y的UI”可以被溫和些改為“不正確的UI”。這樣開(kāi)發(fā)人員的努力將會(huì )得到尊重。
◆ 保持簡(jiǎn)單誠實(shí)。你不是在寫(xiě)散文或文章，因此使用簡(jiǎn)單的語(yǔ)言
◆ 在編寫(xiě)bug report的時(shí)候記住你的目標讀者。他們可能是開(kāi)發(fā)人員，其他的測試人員，經(jīng)理，或者在一些情況下，甚至是客戶(hù)。Bug report應該可以被所有的人理解。
可重現的步驟
◆ “可重現的步驟”的流程應該是合乎邏輯的。
◆ 清楚的列出前提條件
◆ 寫(xiě)下平常的步驟。例如，如果一個(gè)步驟要求用戶(hù)創(chuàng )建文件并且為它命名，不要要求用戶(hù)命名為“Mihir’s file”。最好命名為好像“Test File”一樣的文件名。
◆ “可重現的步驟”應該詳盡。例如，如果你想用戶(hù)在Microsoft Word里保存一個(gè)文件，你可以要求用戶(hù)到File菜單并且點(diǎn)擊Save子菜單項。你也可以只說(shuō)“保存文件”。但是記住，并不是所有的人都知道如何在 Microsoft Word中保存文件。因此最后遵守第一種方法。
◆ 在一個(gè)干凈的系統里測試你的“可重現的步驟”。你可能會(huì )發(fā)現有些步驟被遺漏或是毫無(wú)關(guān)系的。
測試數據
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/