1.定義

Bug（缺陷）：英文單詞，本意是臭蟲、缺陷、損壞等意思。現在人們將在電腦系統或程式中，隱藏著的一些未被發現的缺陷或問題統稱為bug（漏洞）。

2.目的

簡單地說，報告bug的目的是為了開發人員或者其他人員瞭解程式的錯誤。您可以親自示範，也可以給出能導致程式出錯的、詳盡的操作步驟。如果程式出錯了，程式設計師會收集額外的資訊直到找到錯誤的原因；如果程式沒有出錯，那麼他們會請您繼續關注這個問題，收集相關的資訊。

3.報告有效Bug要注意的幾個關鍵字

（1）Condense－精簡，清晰而簡短。

   首先，去掉不必要的詞;

   其次，不要新增無關的資訊。

   包含相應的資訊是最重要的，但是確保這些資訊都是有用的。對於那些沒有描述清楚如何重現或者難以理解的問題，都應該提供更多的資訊。但也要避免寫過多的不必要的資訊。

（2）Accurate－準確，這到底是不是一個bug？ 

確信是一個Bug，避免因為其他原因，導致錯誤的Report Bug，需要考慮：是否會因為安裝的某個原因導致這個問題?例如，是否安裝了正確的版本而且各種先決條件也已經滿足?是否登陸，安全設定，命令或者操作的順序有錯誤?是否存在清除不乾淨，或者結果不完整，或者因為上次測試的某些更改導致?是否是網路或者環境的問題?是否理解了期望的結果?

（3）Neutralize－中性語言，用中性的語言描述事實，不帶偏見，不用幽默或情緒化的語言。

客觀的描述Bug，不要使用幽默的或者其他帶有感情色彩的語句。在提交Bug之前，仔細閱讀Bug的描述，刪除或者修改可能讓人產生歧義的句子。

（4）Precise－精確，這到底是什麼問題？

當Bug的描述很長時，例如：“我按了回車鍵，然後現象A出現，接著按了後退鍵，現象B出現，接著輸入命令‘XYZ’，現象C出現”，看到這樣的說明，很難明白到底想說明什麼問題，三個現象中哪一個是錯誤的。

不要認為你在bug報告中寫的那些抽象的話別人能夠理解，也不要認為看了你的描述，別人會跟你有一樣的結論。你的目的不是寫一份很難讓別人理解的高深的文章，而是一份不被別人誤解的描述。想做到這個只有清晰準確並且客觀的描述你發現的問題，而不是簡單說明發生了什麼。

（5）Isolate－定位，這到底是個什麼樣的問題？

儘量縮小這個問題的範圍。嘗試找到最短，最簡單的步驟來重現這個問題。檢視是否是外部的什麼特殊的原因引起的這個問題?

對於一個存在多種輸入條件的專案，嘗試不斷的改變輸入值，並檢視結果，直到確定哪個值導致的錯誤。 

（6）Generalize－歸納，還有沒有其他的某些地方存在這樣的問題？

Report Bug時，採用合理的步驟來確定這個問題是通常會發生還是偶然一次出現或者是在特殊條件才出現。

（7）Re-Create－重現，如何引發和重現這個bug？（環境，步驟，前提條件）

如果測試時，可以重現Bug，那麼，應該準確的解釋重現Bug所必需的條件。列出所有的步驟，包括精確的組合，檔名以及碰到或者重現這個問題的操作順序。如果確認這個問題在任何檔案，任何的操作順序等條件下都會發生，那也最好能夠給出一個明確的示例用來幫助開發來重現。

如果測試時，不能重現Bug，那就提供儘可能多的有效的資訊。在開發沒有重現或者開發沒有解決之前，不要清除相應的測試資料，或者至少要備份這些資料。

（8）Impact－影響，這個缺陷對客戶有何影響？對測試有什麼影響？

釋出產品時，需要判斷未解決的影響問題。例如，在某一個視窗發現一個排版錯誤或者拼寫錯誤，這類Bug對測試人員來說可能是微不足道的，但對於客戶來說，這是接觸產品的第一件事，所以必須在給客戶實施前修改好。

（9）Debug－除錯，怎麼做才可以讓開發更容易來修改這個bug？

開發人員會如何除錯這個問題？如果需要，在Report時，提供跟蹤、截圖、日誌等對捕獲這個Bug有幫助的資訊。檔案的位置和訪問許可權設定的如何？

（10）Evidence－證據，如何證明確實存在這個bug？

提供Report的是一個Bug的證據資訊，這些資訊可能包括操作指導，文件，必備條件等等，還有可能是客戶以前反饋過來的零碎的資訊，或者是競爭對手的軟體中的一些標準，又或者來源於以往版本中的結果。

4．報告軟體Bug的規範
報告軟體測試錯誤的目的是為了保證修復錯誤的人員可以重複報告的錯誤，從而有利於分析錯誤產生的原因，定位錯誤，然後修正之。因此，報告軟體測試錯誤的基本要求是準、簡潔、完整、規範。需要掌握的報告技術歸納如下：

（1）Bug 的標題

Bug標題應該簡單明朗直接說明什麼地方出現了什麼錯誤。Bug的標題在很多情況下是一個有力的和專案組成員之間的溝通工具，在很多情形下，能夠做決定的人都不會去仔細的看bug的描述，而只是檢視bug的標題，然後就下結論。

Bug的標題必須簡短而且要求描述和傳達出準確的資訊。因為有長度的限制，這個概要的描述一般都比較短，使用一些不會引起歧義的簡寫比好的語法和句子更好。因為許多使用者習慣於用關鍵詞來搜尋，所以在bug的標題中使用一些精練的關鍵詞事很有必要的，象掛起，異常中止，拼寫錯誤等都是比較有效的和有力的搜尋關鍵字。如果長度允許，在bug的標題中有必要加上諸如環境，影響等5個W（why，when，who，where，what）的問題。

（2）描述 (Description)，簡潔、準確，完整，揭示錯誤實質，記錄缺陷或錯誤出現的位置 

描述要準確反映錯誤的本質內容，簡短明瞭。為了便於在軟體錯誤管理資料庫中尋找制定的測試錯誤，包含錯誤發生時的使用者介面（UI）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制元件的名稱。 

（3）明確指明錯誤型別：佈局、翻譯、功能、雙位元組 

根據錯誤的現象，總結判斷錯誤的型別。例如，即佈局錯誤、翻譯錯誤、功能錯誤、雙位元組錯誤，這是最常見的缺陷或錯誤型別，其他形式的缺陷或錯誤也從屬於其中某種形式。 

（4）短行之間使用自動數字序號，使用相同的字型、字號、行間距 

短行之間使用自動數字序號，使用相同的字型、字號、行間距，可以保證各條記錄格式一致，做到規範專業。 

（5）UI要加引號，可以單引號，推薦使用雙引號 

UI加引號，可以容易區分UI與普通文字，便於分辨、定位缺陷或錯誤。

（6）每一個步驟儘量只記錄一個操作保證簡潔、條理井然，容易重複操作步驟。 

（7）確認步驟完整，準確，簡短 

保證快速準確的重複錯誤，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多餘的步驟。 

（8）根據缺陷或錯誤型別，選擇圖象捕捉的方式 

為了直觀的觀察缺陷或錯誤現象，通常需要附加缺陷或錯誤出現的介面，以點陣圖的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或錯誤本質，可以捕捉缺陷或錯誤產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或錯誤位置，通常要求附加中英文對照圖。 

（9）附加必要的特殊文件和個人建議和註解 

如果開啟某個特殊的文件而產生的缺陷或錯誤，則必須附加該文件，從而可以迅速再現缺陷或錯誤。有時，為了使缺陷或錯誤修正者進一步明確缺陷或錯誤的表現，可以附加個人的修改建議或註解。 

（10）檢查拼寫和語法錯誤 

在提交每條缺陷或錯誤之前，檢查拼寫和語法，確保內容正確，正確的描述錯誤。 

（11）儘量使用業界慣用的表達術語和表達方法 

使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。 

（12）通用UI要統一、準確 

錯誤報告的UI要與測試的軟體UI保持一致，便於查詢定位。 

（13）儘量使用短語和短句，避免複雜句型句式 

軟體錯誤管理資料庫的目的是便於定位錯誤，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。 

（14）每條錯誤報告只包括一個錯誤 

每條錯誤報告只包括一個錯誤，可以使錯誤修正者迅速定位一個錯誤，集中精力每次只修正一個錯誤。校驗者每次只校驗一個錯誤是否已經正確修正。 

（15）概率性

在報告Bug時，除了在描述中說明Bug的復現步驟外，還要在Description中，新增該Bug的測試發生率。測試發生率為按照特定步驟執行多次的Bug重現率。測試發生率=ug重現次數/按照特定步驟執行的總次數。

總結：

一份bug報告中需要包括的內容有：標題、測試環境描述、詳細操作步驟、軟體錯誤描述、猜測錯誤原因、提供解決方案（如果可以）。

以上概括了報告測試錯誤的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習高階測試工程師的測試錯誤報告，結合自己以前的測試錯誤報告進行對比和思考，可以不斷提高技巧。