介紹
缺陷報告是測試過程中可以提交的最重要的東西。它的重要性絲毫不亞於測試計劃，並
且比其他的在測試過程中的產出文件對產品的質量的影響更大。所以很有必要學習如何寫出
有效的缺陷報告。有效的缺陷報告將能夠：
減少開發部門的二次缺陷率
提高開發修改缺陷的速度
提高測試部門的信用度
增強測試和開發部門的協作
為什麼測試人員從開發那裡得到的反饋比從其他部門得到的更多？一定程度上這個答
案就是缺陷報告，依照一些簡單的規則可以使整個過程更加順暢。但是我們的目標並不是寫
一個非常完美的缺陷報告，而是能夠傳達正確的資訊，讓工作得以完成並且能夠簡化流程的
有效的缺陷報告。
這篇文章主要講述缺陷報告的兩個方面：1）描述的註釋；2）摘要。首先我們先來看
註釋。
缺陷註釋
下面是確保你下一篇缺陷報告是有效的幾個關鍵點：
Condense－精簡，清晰而簡短
Accurate－準確，這到底是不是一個 bug？還是使用者操作錯誤，或者是理解錯
了，等等？
Neutralize－用中性的語言描述事實，不帶偏見，不用幽默或者情緒化的語言。
Precise－精確，這到底是什麼問題？
Isolate－定位，這到底是個什麼樣的問題？儘量縮小這個問題的範圍。
Generalize－還有沒有其他的某些地方存在這樣的問題？
Re-Create－如何引發和重現這個 bug？（環境，步驟，前提條件）
Impact－影響，這個缺陷對客戶有何影響？對測試有什麼影響？
Debug－怎麼做才可以讓開發更容易來修改這個 bug？（跟蹤，截圖，日誌，
直接訪問等等）
Evidence－證據，如何證明確實存在這個 bug？寫有效的缺陷報告並不需要很好的文字功底，只要確認你正確回答了上面的問題，關鍵
就是確認你覆蓋了所有的你的缺陷報告的檢視者關注的要點就好了。
有效缺陷註釋的要點
精簡
清晰而簡短。首先，去掉不必要的詞；其次，不要新增無關的資訊。包含相應的資訊是
最重要的，但是確保這些資訊都是有用的。不管什麼原因，對於那些沒有描述清楚如何重現
或者難以理解的問題，你都應該提供更多的資訊。寫過多的不必要的資訊也是問題的一種。
準確
確信你正在提交的確實是一個 bug，如果你因為安裝問題或者理解錯誤，操作錯誤錯報
了 bug 的話，你將會很快失去你的信譽。所以在提交一個 bug 前，一定要考慮：
是否會因為安裝的某個原因導致這個問題？例如，是否安裝了正確的版本而且各種
先決條件也已經滿足？是否你登陸，安全設定，命令或者操作的順序有錯誤？
是否存在清除不乾淨，或者結果不完整，或者因為上次測試的某些更改導致？
會不會是網路或者環境的問題？
你是不是真的理解了你的期望的結果？
通常會有很多的情況會影響到我們的測試結果，確信你知道這些影響並且在你報 Bug
的時候考慮過這些影響。這也是區分一個測試人員是新手還是有經驗的一個方面。如果你不
能確定你發現的確實是一個 bug 的話，跟有經驗的測試人員或者開發商量遠比直接提交 bug
要明智。
但是同時請大家記住這樣一句話：“報了可能是錯的，但是不報就是犯罪”（有點象中國
的“寧可錯殺一千，不可放過一個”），不要因為怕報錯而害怕報 bug，你要做的只是勁力來
確保你報的是有效的就好了，而且如果你後來發現曾經報的一個問題是錯報的話，確信你從中得到了教訓和經驗。
中性的語言
客觀的說這個問題，測試人員在報 Bug 時，不要使用幽默的或者其他帶有感情色彩的
語句。在你看來好笑的問題，，對於那些迫於 schedule 的壓力，日夜加班的做出這些東西開
發人員來說就不見得可笑了。用帶有感情色彩的語句，把 bug 報的聲情並茂除了造成 team
內部的溝通屏障和協作困難外，對修改 bug 沒有任何好處。甚至如果開發人員曾經懷疑你並
且打回一個你報的 bug，而現在你找到證據證明你是對的的話，也不要這麼做，你要做的就
是報出這個問題，並且加上對開發人員有幫助的資訊，長此以往，有助於增加你的信譽度。
在提交 bug 之前，仔細閱讀你的 bug 的描述，刪除或者修改哪些可能讓別人產生歧義的句子。
精確
看你的 bug 報告的人可能不需要知道這是什麼樣的問題，所以測試人員有必要正確的描
述出自己所希望的情況，其中一些描述是操作步驟和結果，例如：“我按了回車鍵，然後現
象 A 出現，接著按了後退鍵，現象 B 出現，接著輸入命令‘XYZ’，現象 C 出現”，看到這
樣的說明，很難讓別人明白你到底想說明什麼問題，三個現象中哪一個是錯誤的。無論如何，
當 Bug 的描述很長時，一定要在開頭對這個 bug 做概要的描述。不要認為你在 bug 報告中
寫的那些抽象的話別人能夠理解，也不要認為看了你的描述，別人會跟你有一樣的結論。你
的目的不是寫一份很難讓別人理解的高深的文章，而是一份不被別人誤解的描述。想做到這
個只有清晰準確並且客觀的描述你發現的問題，而不是簡單說明發生了什麼。
定位
對於測試人員應該把問題定位到什麼程度，每個公司或者每個部門都有不同的規定和期
望值。不管這些要求有什麼不同，對於一個測試人員來說必須做一些有效的事情來定位發現
的問題。在試圖隔離一個問題的時候，需要考慮下面的幾點：
嘗試著找到最短，最簡單的步驟來重現這個問題，這通常需要花很長的時間。
問問自己會不會是外部的什麼特殊的原因引起的這個問題？例如，系統掛起或
延時，會不會是因為網路的問題？如果你在做點對點的測試，你是否能夠說出
是哪一個元件出現了錯誤？有沒有什麼辦法來縮小判斷出錯元件的範圍？
如果你在測試一個存在多種輸入條件的專案，可以嘗試不斷的改變輸入值，然
後檢視結果，直到你找到是哪個值導致的錯誤。
在問題描述中，在儘可能的範圍內，精確描述你所使用的測試輸入值。例如，如果你在
測試中發現列印一份指令碼的時候會出錯，那你應該首先想到是不是列印所有的這種型別的腳
本都會出錯。
測試人員定位 bug 的能力，一定程度上是自己做為一個 tester 的附加價值的體現。有效
的 bug 定位能夠節省同一小組的所有的人的時間，同時也節省了你回測 bug 的時間。
歸納
一般情況下，開發人員只會“精確的”按照你的報告來修改 bug，而不會因為測試人員
沒有進行歸納而把相應的其他的相關 bug 都改好。例如，我報了這樣一個 bug，就是我的文
字處理程式的儲存功能有問題，當儲存一個名為“我的檔案”的檔案時文字處理程式會當掉。
但是這樣的情況同時發生在儲存一個檔案長度為 0 的檔案，或者試圖儲存在一個遠端的磁
盤，一個只讀磁碟時都會產生這個情況。如果能這樣寫的話會節省開發很多的時間，並且能
很大的提高系統的質量。
當你發現一個問題時，採用合理的步驟來確定這個問題是通常會發生還是偶然一次出現
或者是在特殊條件才出現。
重現
有些 bug 很容易就重現，有些就很難，如果你能重現一個 bug，你應該準確的解釋必需
的條件。你應該列出所有的步驟，包括精確的組合，檔名以及你碰到或者重現這個問題的
操作順序。如果你能構確認這個問題在任何檔案，任何的操作順序等條件下都會發生，那也
最好能夠給出一個明確的示例用來幫助開發來重現。
如果你經過測試卻發現不能再重現一個問題，那就儘可能多的提供有效的資訊給你的開
發人員。在開發沒有重現或者開發沒有給你反饋之前，不要清除你的測試資料，或者至少你
要備份這些資料。在你沒有驗證這個問題如何重現之前不要確信一個問題是可以重現，如果
你無法重現或者沒有做驗證是否可以重現，一定要標註在 bug 的報告中。
影響
如果在客戶的環境中出現一個 bug 的影響是什麼？很多 bug 是很明顯的。例如：進入系
統時，敲擊回車鍵，系統會 down 掉。還有的問題不是這麼明顯的，你可能在某一個視窗發
現一個排版錯誤或者拼寫錯誤，對於測試人員來說可能會覺得是很小的問題，甚至是微不足
道的問題，但是對於使用者來說，這是他接觸你的產品的第一件事，而且如果這個單詞事比較
敏感的話，就很不妙了，在這種情況下，即使我們認為這是很小的問題，也必須在給客戶實
施前修改好。如果你覺得這個問題不會給客戶帶來重大的影響，那就可以釋出出去了。
除錯
開發人員會如何除錯這個問題？有沒有跟蹤、截圖、日誌等對捕獲這個 bug 有幫助的
資訊包含在你的 bug 報告中？檔案的位置和訪問許可權設定的如何？
證據
有什麼可以證明這個 bug 確實存在？你是發已經提供了期望結果和實際結果？有沒有
文件來支援你的期望結果？既然你提交了 bug，也就意味著你認為這是一個 bug 了，那就提
供你可以提供並且可以說服其他人認可這確實是一個 bug 的資訊吧！這些資訊可能包括操作
指導，文件，必備條件等等，還有可能是客戶以前反饋過來的零碎的資訊，或者是競爭對手
的軟體中的一些標準，又或者來源於以往版本中的結果。並且不要認為每個人看到一件事情
後的反應都跟你一樣，也不要期望別人能跟你得出一樣的結論，並且不要認為在過去三個禮
拜以後你還能認為這是一個bug。
考慮一個所有支援你認為這是bug的原因並且歸入你的bug
報告中。如果你意識到別人可能認為它不是 bug 的話，你也必須這樣做。強化記憶
你不需要每次報 bug 的時候都來檢視一下上面的關注點，你需要強化記憶，然後在你
每一次報 bug 的時候可以信手拈來。這是提高軟體質量消費成本最小並且最有效的辦法，即
使有可能這只是自己認為的。通常一份寫的不好的 bug 報告不是因為我們不能寫好，而是因
為我們沒有考慮和回答正確的問題，這就是強化記憶的作用。
不知道你有沒有發現一個有趣的問題，就是在前面提到的那些單詞的首字母合起來就
是“CAN PIG RIDE？”這個足夠短並且比較容易記住。如果你花了 20－30 分鐘的時間來
看這 10 個單詞以及他們的含義，估計在你的腦子裡會留下一定的印象，如果你覺得 10 個單
詞實在很難記住，那我們可以壓縮一下，單單記住 PIG 就好了，如果在這三點（Precise，Isolate，
Generalize）上你做的足夠好了，在大多數的情況下，在你做 bug 報告時會大有幫助。
模板
一個好的 bug 模板有助於我們在報 bug 的時候確認我們提供了正確的適當的資訊並且
回答了正確的問題。有一些 bug 追蹤工具在發現 bug 的時候會自動生成 bug 模板。不過儘管
如此，你還是很有必要用“複製”和“貼上”來把資訊放入你的 bug 報告中，下面是一個
bug 的模板：
Bug 的標題
Bug 的標題在很多情況下是一個有力的和專案組成員之間的溝通工具，在很多情形下，
能夠做決定的人都不會去仔細的看 bug 的描述，而只是檢視 bug 的標題，然後就下結論。通
常的產品經理，team leader 還有其他的經理們也都是隻會關注到 bug 的標題。
Bug 的標題必須簡短而且要求描述和傳達出準確的資訊。因為有長度的限制，這個概
要的描述一般都比較短，使用一些不會引起歧義的簡寫比好的語法和句子更好。因為許多使
用者習慣於用關鍵詞來搜尋，所以在 bug 的標題中使用一些精練的關鍵詞事很有必要的，象
掛起，異常中止，拼寫錯誤等都是比較有效的和有力的搜尋關鍵字。如果長度允許，在 bug
的標題中有必要加上諸如環境，影響等 5 個 W（why，when，who，where，what）的問題。
有一些 bug 跟蹤的工具會自動把 bug 的第一行的 bug 描述做為 bug 的標題，永遠不要
使用這樣的預設標題，要儘可能的特殊和精確。例如：下面的標題就沒有提供足夠多的資訊。
標題：在儲存和恢復資料成員時出錯。
一個比較好的標題可能是這樣：在 WINNT 環境下，XYZ 的儲存和恢復資料失敗，數
據丟失。
通常在 bug 的標題中你不會得到任何你想得到的資訊，下面是一個寫 bug 標題應該注
意的幾點：
簡單，明確的說明問題（不能只是說出現問題）
建議（如果長度允許的話）：
使用有意義的單詞
描述環境和影響z 回答5W1H的問題
使用簡寫
相對於描述清楚而言，語法不是很重要
不要使用測試工具提供的預設的標題
總結
測試人員為了尋找和發現軟體中的問題會花費大量的時間，一旦發現了，就要想方設
法如何用最小的代價來促使這個問題得到解決。確保 bug 報告中包括了必要的適當的資訊比
高超的寫作技巧更重要。
不是所有的人都會完整的檢視 bug 的報告，很多拍板的人通常只依靠 bug 的標題來幫
助他們做決定，所以用精確的語言來描述你的 bug 標題很有必要。
你的 bug 報告寫的越好，在實際中為了修改這個 bug 花費的時間相對來說就會越少。
你的信譽度和產品中的貢獻度也會得到很好的提升，因為你的 bug 報告夠好並且可以信賴，
其他測試人員的工作也會得到相應的提升。
