BUG描述規范BUG描述規范一、目的清晰簡單描述好缺陷，編寫有效的缺陷實例，幫助開發人員有效的進行缺陷定位，重現錯誤，從而去有效的定位錯誤，修改錯誤。二、目標u 減少開發人員的二次缺陷率u 提高開發人員修改缺陷的速度u 提高測試質量部門的信用度u 增加開發與測試的協作u 有效提高產品的質量三、范圍本文檔適合于系統產品部門所有的人員四、缺陷的要素u 描寫格式：填寫缺陷的時候，若為軟件的模塊名稱、頁面元素和按鈕、關鍵步驟、附件則應由對應的“ “ 進行描寫，描述中出現的缺陷錯誤需用引號+粗體+紅顏色進行標記；u 描寫步驟：缺陷描述的時候要分層次，首先是描述缺陷發生的位置和條件，其次描述缺陷發現的步驟，再描述缺陷發生的結果，給出缺陷修改建議，最后必須附上結果的附件或快照；u 描述方法：填寫缺陷的時候，盡量采用書面語，不能采用口語、歧義性語言，激動的語言（毀謗性）；缺陷的狀態改變，需注釋對應的用戶名、時間、原因，才能改變狀態；u 附件和快照標準格式： 附件根據需要對缺陷的過程和結果進行標注和文字說明，說明過程需用紅色箭頭對缺陷過程進行描述和說明；u 缺陷主題描述：簡單清晰的描述在什么樣的位置，什么樣的條件下，發生什么樣的結果，不能完全復制詳細描述中的語言； u 缺陷描述標準格式： 缺陷描述規范：缺陷主題： 缺陷位置+缺陷結果（在什么樣的位置，什么樣的條件下，發生什么樣的結果）參數設置： 定位好缺陷類型，項目優先級，程序優先級，缺陷狀態等TD必填字段詳細描述：1） 缺陷發生在哪里：標準格式：在XXX模塊YYY子模塊下；2） 缺陷發生的步驟/條件：通過對什么樣的操作，進行了什么樣步驟；3） 缺陷發生的結果：出現了ZZZ的錯誤現象，見附件 NNN；4） 針對問題的建議：根據判斷，給出缺陷解決的建議，建議對此缺陷進行怎樣的修改或者對應的處理方式，針對建議需要給出解決的方法和過程；5） 缺陷必須要有附件或快照（其中必須對其按照標準格式進行標注和文字說明）五、缺陷描述的案例案列一：缺陷主題： 集成管理模塊的項目注冊管理頁面， 查看項目立項信息時，出現“未能加載類型“ProjectGeneralView”錯誤參數設置： 定位好缺陷來源，檢測版本，所屬模塊，嚴重程度、優先級詳細描述：1）在集成管理 項目注冊管理頁面下；2）選擇已發布TAB頁； 3）在GRID列表中，選擇任意一條項目立項信息，點擊查看按鈕；4）系統頁面彈出：按鈕報錯信息“未能加載類型“ProjectGeneralView“，見附件1.JPG、2.JPG； 1.jpg2.jpg六、測試屬性定義u 測試優先級高：在所有的測試項中排在首位、最核心也是最能影響整體的被測對象或功能中：主要的涉及到細節化的被測對象或功能低：不影響系統運行和整體架構的被測對象或功能u BUG嚴重級高：引起系統崩潰或無法正常運行和安裝中：需求說明書中要求的功能未實現或不符，或流程數據錯誤低：顯示差錯、風格差異或建議u BUG優先級高：非常緊急且無法繼續測