(翻譯)編寫優(yōu)秀Bug報告的藝術(shù)
? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?----------http://blog.csdn.net/imlogic/
前言

在99年的Quality week上的一次演講中，微軟的一個測試經(jīng)理，Roger Sherman指出了由于“不可重現(xiàn)”導(dǎo)致bug關(guān)閉的主要原因。這是一個非常可惜的情況，因為這樣的bug report浪費了緊張的開發(fā)計劃中的寶貴時間，增加了對產(chǎn)品質(zhì)量完全是無關(guān)緊要的事情，同時導(dǎo)致了在開發(fā)人員和測試之間的挫敗感和差的感覺。有時，bug report是由于短暫的或隨機的事件，測試和開發(fā)之間不一致的工具和配置，或者在測試的環(huán)境下對正確的行為的模糊定義而產(chǎn)生的，但是許多的由于不可重現(xiàn)而被關(guān)閉的測試報告是因為描述不清晰，被誤解，或者只是文字的錯誤。

幸運的是，我學(xué)習(xí)到一些能夠引起管理層注意，更清楚的和開發(fā)人員溝通并得到修復(fù)的編寫優(yōu)秀bug report的訣竅。這些技巧不僅僅提供了是在被修復(fù)的問題的比例方面得到了可靠的回報，而且在同開發(fā)人員和管理層的通過中也得到了回報。在我管理的項目中使用這種方法編寫bug report，8份bug report中大約只有一個沒有被修復(fù)。

這篇文章的思想只有當(dāng)你的報告針對的測試執(zhí)行過程是專業(yè)的質(zhì)量工作才可以發(fā)揮作用。聰明地執(zhí)行完整的測試包是產(chǎn)生可靠的測試狀況信息的基礎(chǔ)的其中一個因素。在許多的測試文獻中廣泛地介紹了多種多樣的關(guān)于如何構(gòu)建這樣的測試包的方法。選擇和你質(zhì)量風(fēng)險管理需求相一致的技術(shù)并且使之適應(yīng)你的具體情況，敏捷地監(jiān)督已計劃的測試的執(zhí)行過程，這樣你就可以擁有可靠的測試執(zhí)行過程。

另外一個關(guān)鍵的因素－bug report，卻沒有得到太多的關(guān)注。這是非常令人遺憾的，因為優(yōu)秀的bug report對反映測試小組真實的和可理解的工作質(zhì)量同測試本身一樣都是非常重要的。試想一下：如果你不能用開發(fā)人員能夠理解的術(shù)語和能夠用于調(diào)試的方法給開發(fā)人員解釋一個錯誤，他怎么能夠修復(fù)問題呢？如果你不能夠在bug report中提出象“保險桿標(biāo)簽”（bumper sticker）一樣的錯誤總結(jié)來引起管理層的注意，你又如何讓他們關(guān)心你們發(fā)現(xiàn)的問題呢？

Bug report的核心是對錯誤的描述。表格1中是一個關(guān)于好和差的錯誤描述的例子。編寫好的bug report是一種好的藝術(shù)形式。采用以下的10條技巧可以幫助你的小組提高編寫bug report的質(zhì)量：

組織Structure：測試人員應(yīng)該采用深思熟慮的，小心謹慎的方法執(zhí)行測試，并且做詳盡的記錄。這樣可以促使他們對測試下的系統(tǒng)有很好的認識。當(dāng)錯誤發(fā)生的時候，一個有組織的測試人員能夠知道最早出現(xiàn)問題的地方。

重現(xiàn)Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現(xiàn)。如果錯誤不可再重現(xiàn)，仍然應(yīng)該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反復(fù)嘗試3次。

隔離Isolate：在嘗試編寫bug report之前，必須試著隔離錯誤。可以采用改變一些變量的方法，如系統(tǒng)的配置，它可能可以改變錯誤的癥狀。這些信息可以為開發(fā)人員著手調(diào)試提供思路。

歸納Generalize：在測試人員發(fā)現(xiàn)了一個已隔離的，可重現(xiàn)的問題后，應(yīng)該對問題進行歸納。同一個問題是否出現(xiàn)在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？

對比Compare：如果測試人員以前曾經(jīng)驗證過現(xiàn)在出錯的測試用例，那么他就應(yīng)該檢查以前的測試結(jié)果以檢查相同的條件是否通過以前的測試。如果是的話，那么這個問題就象是一個回歸的錯誤。注意由于同一測試條件有可能出現(xiàn)在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結(jié)果。

總結(jié)Summarize：在bug report的第一行寫上錯誤的總結(jié)是非常關(guān)鍵的。測試人員要花些時間思考已發(fā)現(xiàn)的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設(shè)置錯誤修復(fù)的優(yōu)先級別。

精簡Condense：在bug report的初稿完成后，測試人員應(yīng)該反復(fù)閱讀它，集中剔除那些沒有關(guān)系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關(guān)系的細節(jié)或者那些在重現(xiàn)錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標(biāo)。

消除歧義Disambiguate：測試人員在精簡空話的同時或其之后隨即應(yīng)該再仔細檢查報告是否有會產(chǎn)生誤解的地方。測試人員應(yīng)該盡量避免使用模糊的，會產(chǎn)生歧義的和主觀的詞語。目標(biāo)是使用能夠表述事實，清楚的，不會產(chǎn)生爭執(zhí)的詞語。

中立Neutralize：如文中所述，作為壞消息的傳遞人，和善地提交消息是一個挑戰(zhàn)。如同所有的錯誤總結(jié)一樣，獨立的bug report在措辭方面應(yīng)該保持公正。攻擊開發(fā)人員，指責(zé)潛在的錯誤，企圖詼諧或使用挖苦將引起開發(fā)人員的憎惡，并且使注意力從“提高產(chǎn)品質(zhì)量”這個大的目標(biāo)上轉(zhuǎn)移開了。謹慎的測試人員只用Bug report來描述事實。

檢查Review：一旦測試人員感覺bug report是他能夠編寫的最好版本，他應(yīng)該將報告再給一個或多個同行進行檢查。他的同事們也應(yīng)該給出一些建議，為了澄清問題不斷地提問，如果適當(dāng)?shù)脑?#xff0c;甚至可以挑戰(zhàn)“錯誤成災(zāi)”的結(jié)論。在允許的時間里，測試小組應(yīng)該盡可能提交最好的bug report。

以上10條技巧可以幫助你和你的小組提交準(zhǔn)確簡潔的，徹底校訂的，精心構(gòu)思的，高質(zhì)量的技術(shù)文檔。測試小組應(yīng)該集中編寫bug report的任務(wù)，測試組長和經(jīng)理應(yīng)該讓測試組成員清楚地認識到編寫優(yōu)秀的bug report是一項首要的工作任務(wù)。衡量優(yōu)秀的bug report的質(zhì)量指標(biāo)應(yīng)該包括如下：
o? ?? ???對管理層來說，是清晰明了的，特別是在概要這一級；
o? ?? ???對于開發(fā)部門是有用的，主要是給出能夠讓開發(fā)人員高效地調(diào)試問題的相關(guān)信息
o? ?? ???可以很快的將bug從“Opened”狀態(tài)轉(zhuǎn)變成“Closed”狀態(tài)，減少為得到更多的信息從開發(fā)人員打回的差的bug report并導(dǎo)致測試人員返工的時間。

改進bug報告的流程是需要花費一些時間的，但是也給予了效果顯著的回報。首先，簡單的流程改進了測試小組和高層、平行管理層之間的溝通，增強小組的信任度，名望和鼓勵管理層給測試投資更多的資源。第二，平穩(wěn)地遞交報告給開發(fā)人員促進了測試和開發(fā)人員之間積極的關(guān)系。第三，更短的bug生命周期是更加有效的，在時間上之前花費在編寫優(yōu)秀bug report上的時間和后期由于返工差的bug report花費的時間相抵消。這些回報幫助開發(fā)流程通過有效的溝通和高效率的流程獲得更好的產(chǎn)品質(zhì)量。

[[i] Last edited by eatmouse on 2005-6-1 at 08:44 [/i]]

===

這里還有一篇，參考下。

你有沒有為了要更多的信息而被返回 bug report 的經(jīng)歷呢？有沒有碰到過你發(fā)現(xiàn)的一個非常嚴重的錯誤被推遲到下一個版本才去修復(fù)的情況呢？ 你提交的每一個 bug report 都是和項目組就正在測試中的軟件質(zhì)量問題的一種書面溝通方式。通常，你用于溝通程序錯誤的能力－不是體現(xiàn)在錯誤本身的內(nèi)在嚴重程度－而是體現(xiàn)在確定這個錯誤是否需要修復(fù)。 如果這是一個可怕的想法，你可能會想， “ 等等！我討厭寫作，我并不擅長寫作。怎么樣才能夠通過編寫 bug report 來決定錯誤的命運呢？ ” 它要吸引大家相信錯誤是為他們說話的－任何一個頭腦正常的人都應(yīng)該主動地查看一個特定的錯誤是足夠可怕的以致要被修復(fù)。不幸的是，事實并不是這樣。 但是好消息是：有效的和軟件開發(fā)人員、項目組溝通的能力不是由你在高校英語課程中的表現(xiàn)所決定的。 這不是關(guān)于用有趣的詞語編寫流暢散文，也不是關(guān)于優(yōu)秀語法和拼寫的方法。它是有關(guān)僅用能夠表達你觀點的詞語明白地表述錯誤的方法。太多地話將會使你的觀點陷入茫然無措中。太少地話又會使他人用自己的假設(shè)去填補隔閡－通常是對軟件有害的部分。如果你不是很確信是什么樣的錯誤，那么不管你的 bug report 寫得怎么好，也沒有人知道那是什么樣的錯誤。 這篇文章主要討論你現(xiàn)在能夠開始著手提高人們傾聽你發(fā)現(xiàn)的錯誤的機會的 4 個方法。 ?? ? ? ? 了解你的聽眾 毋庸置疑，任何寫作課都會告訴你必須了解你是為誰編寫 bug report 。 每份 bug report 至少有兩個聽眾：必須要修復(fù)錯誤的人和決定錯誤命運的人或團體。有時一個人會同時負責(zé)這兩份工作，但是仍然是兩個不同的聽眾，只是一起發(fā)生在同一個人身上罷了。 你的第一個聽眾－那個必須修復(fù)錯誤的人需要清楚，明確的步驟以重現(xiàn)錯誤。信息越多越好。針對這個目的，我們稱這個人為 “ 開發(fā)人員 ” 。開發(fā)人員需要關(guān)于我們操作了什么和我們看見了什么的準(zhǔn)確信息。 你的第二個聽眾－決定錯誤命運的人或團體需要知道如果不修復(fù)此錯誤的后果。這個聽眾需要精練的語句以抓住他們的注意力并且引發(fā)對錯誤的相關(guān)連問題的討論。基于這個目的，我們稱他為 “ 錯誤審核委員會 ” 。在使錯誤得以修復(fù)的過程中你的角色是幫助錯誤審核委員會了解不修復(fù)錯誤的風(fēng)險遠遠超過修復(fù)錯誤可能發(fā)生的風(fēng)險。 你越了解你的開發(fā)人員和錯誤審核委員會如何工作，你就越可以根據(jù)他們的需要裁減你的 bug report 。盡力在私底下設(shè)法了解你的聽眾。如果你能夠出席錯誤審核委員會會議，嘗試這樣做。你將學(xué)習(xí)到許多關(guān)于你的聽眾是如何思考的知識。 ?? ? ? ? 選擇一個好的標(biāo)題 一般把用于描述錯誤的短句稱為錯誤的標(biāo)題或描述。這是 bug report 中最重要的部分。錯誤審核委員會成員經(jīng)常通過它來決定錯誤是否可以推遲修復(fù)。如果標(biāo)題沒有力度，委員會成員可能認為它是不值得花費太多的時間。（畢竟，在接下來的 2 個小時里還有 145 個以上的錯誤要審核。） 以下是一些示例： 好的 ： 超時后在退出時崩潰了 太長的 ： 在數(shù)據(jù)庫不可用后你又保存記錄的更改 , 然后從文件菜單中選擇退出時程序崩潰了 不足夠的信息 ： 程序崩潰了 太模糊 ： 當(dāng)數(shù)據(jù)庫離線時出現(xiàn)問題 標(biāo)題變成了一種給項目組提供檢查和調(diào)查錯誤的方法。和數(shù)據(jù)相比，人們更容易記詞語。人們更愿意記得 “ 在 windows2000 下不能夠安裝 ” 的錯誤，而不是類似 “ ＃ 23423” 錯誤，而且在以后人們還會利用這些關(guān)鍵詞搜索錯誤。 編寫一個好的，簡明的錯誤標(biāo)題是不容易的。和編寫 bug report 的其他部分相比，應(yīng)該多花些時間構(gòu)造理想的錯誤標(biāo)題。要確信標(biāo)題是足夠短以便能夠在顯示錯誤的屏幕上和由缺陷跟蹤系統(tǒng)生成的報表中顯示完全（不會折行）。標(biāo)題不必是完美的語法，而應(yīng)簡短并一針見血。 ?? ? ? ? 書寫清楚，明確的步驟 你提交給開發(fā)人員的步驟應(yīng)該提供如何產(chǎn)生錯誤的信息，這樣錯誤就能夠被發(fā)現(xiàn)并且修復(fù)。它也需要給錯誤審核委員會提供錯誤發(fā)生的環(huán)境。 唯一正確 ： 1 ．運行客戶端 2 ．找出一個記錄 3 ．更改記錄但不存盤 4 ．使數(shù)據(jù)庫服務(wù)器脫機 5 ．嘗試保存記錄 6 ．收到一個超時的錯誤 7 ．退出客戶端 結(jié)果：崩潰 馬虎的（有很大空間讓人產(chǎn)生誤解的 ）： 使數(shù)據(jù)庫服務(wù)器脫機，保存，然后退出，崩潰了。 太多冗余的信息（不能夠指出什么是引發(fā)錯誤的最關(guān)鍵原因） 1 ．運行客戶端 2 ．為輸入新的條目查詢數(shù)據(jù)庫 3 ．打開一個瀏覽器 4 ．在 yahoo.com 上瀏覽新聞 5 ．關(guān)閉瀏覽器 6 ．選擇一個條目 7 ．把種類從 “ 蔬菜 ” 更改到 “ 水果 ” 8 ．使數(shù)據(jù)庫服務(wù)器脫機 9 ．嘗試保存記錄 10 ．收到一個超時的錯誤 11 ．退出客戶端 結(jié)果：崩潰

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的编写优秀Bug报告的艺术 ----转载自CSDN（imlogic的专栏）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。