3、Bug的規范

　　a）簡要的說：bug的標題摘要需要具備的描述方式應該清晰，明了。

　　i. 在什么情況下

　　ii. 進行什么操作

　　iii. 產生什么現象

　　b）如何讓你的bug情景化

　　i. 在發現缺陷之后，只有當你確信你已經發現一個bug的時候開始起草bug report，不要在測試結束或每天結束之后。那樣，你可能會遺忘掉一些東西。更糟的情況是，我們可能會忘掉那個bug

　　ii. 花一些時間去診斷你正在報告的缺陷。想想可能存在的原因并嘗試定位問題，可能到后你會發現更多的缺陷。在你的bug report中說說你的分析。有助于提高開發的認可度和測試人員的專業程度

　　c）Bug的元素信息

　　i. 摘要：見a說明，一個好的摘要應該不超過50到60個字符。而且一個好的摘要不應該承載任何對bug主觀的表達。

　　ii. 在編寫bug report的時候記住你的目標讀者。他們可能是開發人員，其他的測試人員，經理，或者在一些情況下，甚至是客戶。Bug report應該可以被所有的人理解

　　iii. 清楚的列出前提條件

　　iv. 有清晰的可重現的步驟，可重現步驟應該詳盡

　　v. 備注說明：有頁面或者特殊情況下，或者可重新幾率不高的問題，盡量保證有截圖和相關說明信息。也可在備注中進行問題分析和bug定位的缺陷引導

　　vi. 簡化和剔除步驟：在一個干凈的系統里測試你的“可重現的步驟”。你可能會發現有些步驟被遺漏或是毫無關系的，這樣可以剔除部分不必要的說明步驟，也能避免步驟過多對于問題定位的干擾。

　　vii. 預期結果和實際結果，清晰描述現象即可

　　viii. 附件：截圖和一些配置文件，需要進行附件的添加，方便開發進行定位缺陷和分析問題點

　　d）Bug的級別劃分

　　i. Bug的嚴重性級別劃分一般分為4類：嚴重、主要、次要、輕微

　　ii. 對應級別的對應問題的劃分，可以見QC中對應級別功能的劃分

　　iii. Bug的優先級別劃分

　　（1）緊急（Urgent）缺陷必須被立即解決

　　（2）高級別（High）缺陷需要盡快處理

　　（3）正常（Medium）缺陷需要正常排隊等待修復或列入軟件發布清單

　　（4）不緊急（Low）缺陷可以在方便時被糾正，解決的優先級別不高