1、缺陷編號defect id
提交缺陷的順序
注意：在實際項目中一般采用缺陷管理工具可以生成編號，整個項目組統一編號
2、缺陷標題summary
簡明扼要的描述一下該bug
3、缺陷的發現者detected by
一般就是自己
4、發現缺陷的日期detected on date
一般就是當天
5、缺陷所屬的模塊subject
在測試程序的哪個功能模塊時發現的bug
開發經理會根據bug所在的模塊找到由誰解決該bug
6、發現缺陷版本detected in release
在測試程序的哪個版本時發現的bug
7、指派給誰處理assigned to
測試人員指派給開發經理開發經理會根據該bug所在的模塊再次指派給具體的開發人員進行解決bug
8、缺陷的狀態status
缺陷此時所處的情況或處理的階段
- 測試人員發現bug提交缺陷報告給開發經理把缺陷的狀態寫成New——新提交
- 開發經理驗證此bug如果是把缺陷狀態改為Open——開發組承認的bug，並指派給開發人員進行bug修復，如果不是則把缺陷狀態改為rejected——拒絕的bug
- 開發人員看到指派給自己的bug進行bug修復，修改完后把缺陷的狀態改為Fixed——解決的bug、待返測的bug
- 測試人員對修復的bug進行返測，如果返測成功把缺陷的狀態改為Closed——關閉的bug、歸檔的bug、返測成功的bug；如果返測失敗把缺陷的狀態改為Reopen——重新打開的bug
此過程稱為缺陷的處理流程或者缺陷報告處理流程、缺陷的跟蹤管理過程、缺陷的生命周期：
New-Open-Fixed-Closed
9、缺陷的嚴重程度severity
表明該bug有多糟糕或者對軟件影響的大小
- urgent——致命的、造成系統死機、崩潰的bug
- VeryHigh——非常嚴重的bug
- High——嚴重的bug
- Medium——中等程度的bug
- Low——小的bug
說明：在實際工作中每個單詞代表的具體情況會有所不同。為了避免爭議應該在相關文檔中把每個級別的具體情形列舉出來供
測試人員和開發人員參考，如Bug Level Definition.xls
10、缺陷的優先級priority
希望程序員什么時間內或在程序的哪個版本中解決該bug
- Urgent——立即修改否則影響測試/開發進度
- VeryHigh——本版本修改
- High——下版本修改
- Medium——發布之前修改
- Low——允許在發布中存在的bug
優先級制定時主要考慮因素
- 1嚴重程度—— 一般嚴重程度越高優先級越高
- 2影響范圍—— 一般影響范圍越廣優先級越高
- 3參考開發組的當前任務壓力——開發任務越輕優先級越高
- 4解決bug的成本——成本越低優先級越高
11、缺陷描述
把發現缺陷的過程、步驟、使用的數據等記錄下來使程序員通過該描述能夠再現該bug
注意：
1、優先級和嚴重程度不是嚴格正比關系
2、嚴重程度確定好后一般就不再更改而優先級確定好后可能經常修改一般會向后推延
3、不是所有的bug在產品發布之前都能被修復，對於發布之前不修復的bug要通過缺陷討論明確解決bug
的成本、時間以及該bug如果不解決給用戶造成的影響、損失
4、不可重再現的bug也叫做隨機bug也要報告，但要說明該bug不可重現，如果可能可以對bug做截圖