前言
缺陷報告是描述軟件缺陷現象和重現步驟地集合。
軟件缺陷報告Software Bug Report或軟件問題報告Software Problem Report
作用：缺陷報告是軟件測試人員的工作成果之一，體現軟件測試的價值缺陷報告可以把軟件存在的缺陷準確的描述出來，當測試人員發現一個缺陷，需要填寫一份“缺陷報告”來記錄這個缺陷，並通過這個缺陷報告告知開發人員所發生的問題–缺陷報告是測試人員和開發人員交流溝通的重要工具。便於開發人員修正缺陷報告可以反映項目產品當前的質量狀態，便於項目整體進度和質量控制軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力。
一、缺陷報告的要點
1.標題
描述：簡潔、準確、完整、反映缺陷本質
2.重現步驟
3.嚴重程度
4.優先級
5.截圖
6.編號
7.指派人
二、“5C”原則
1.內容準確（Correct）：每個組成部分的描述準確，不會引起誤解
2.步驟簡潔（Concise）：只包含必不可少的信息，不包括任何多餘的內容
3.內容清晰（Clear）：每個組成部分的描述清晰，易於理解
4.結構完整（Complete）：包含復現該缺陷的完整步驟和其他本質信息
5.風格一致（Consistent）：按照一致的格式書寫全部缺陷報告
三、二八定理
在分析、設計、實現階段的複審和測試工作能夠發現和避免80%的缺陷，而系統測試又能找出 其餘缺陷中的80%，最後的4%的缺陷可能只有在用戶大範圍、長時間使用後纔會暴露出來。
四、缺陷報告的組成：
1、缺陷編號（Defect ID）：提交缺陷的順序
2、缺陷的標題（summary）：簡明扼要的描述缺陷
3、缺陷的發現者（Defected By）：測試人員
4、缺陷發現的日期（date）：一般爲當天
5、缺陷所屬的模塊（subject）：在測試那個功能模塊時發現的bug
6、發現缺陷的版本（Defected in release）：開發的軟件的版本
7、指派給誰處理（Assigned to）：測試人員指派給開發經理，開發經理根據缺陷所在的模塊，需要再次指派具體的開發人員
8、缺陷的狀態（status）：缺陷此時所處的處理階段或處理情況
a.測試人員發現缺陷，提交缺陷報告，把缺陷的狀態置爲new（新）
b.開發經理驗證提交的bug，如果是bug，把狀態改爲open（打開的bug，開發組承認的bug），指派給具體的開發人員解決；如果不是bug，把狀態改爲rejected（拒絕的bug）
c.開發人員看到指派給自己解決的bug，進行缺陷修復，修改完後，把缺陷狀態fixed（已經修復的bug，可以返測的bug）
d.測試人員對修復的bug進行反測，若返測成功，將狀態改爲closed（關閉的缺陷，歸檔的bug）；如果返測不成功，把狀態改爲reopen（重新打開的bug）
五、缺陷報告的深度理解
1、缺陷的嚴重程度和優先級是不是成正比關係？
界面問題的嚴重程度一般比較低，擔優先級可能很高————立即修復
某些重大的功能問題可能暫時解決不了，但不影響其他功能的使用，這時優先級可能定義的比較低————在發佈之前修復
2、缺陷的嚴重程度和優先級確定好後，還能修改嗎？
嚴重成度不允許改，優先級可能修復。
測試人員確定一個缺陷“立即修復”，但開發組認爲這個缺陷不好解決，而這個缺陷又不影響其他功能，這時可能要求在“下一個版本修改”或“發佈之前修改”
3、是不是所有一發現的缺陷都會被修復？
有些缺陷修復的成本太高或者由於進度壓力可能在發佈前得不到修復，這樣的缺陷一定要經過項目組的討論，權衡成本和風險，要確保不會對用戶在成重大的影響及法律糾紛。後面再通過升級軟件或者打補丁的方式修復缺陷或彌補漏洞
六、缺陷報告的作用
1、記錄bug
2、對bug進行分類（模塊、bug狀態、嚴重程度、版本）
3、跟蹤bug
4、對bug進行分析、統計
今天的分享就到這裏了，希望能夠給大家帶來幫助。未來的你一定會感激今天奮鬥的自己！