軟體測試--缺陷報告

缺陷報告是描述軟體缺陷現象和重現步驟地集合。軟體缺陷報告 Software Bug Report（SBR）或軟體問題報告 Software Problem Report（SPR）

作用：缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值缺陷報告可以把軟體存在的缺陷準確的描述出來，當測試人員發現一個缺陷，需要填寫一份 “缺陷報告” 來記錄這個缺陷，並透過這個缺陷報告告知開發人員所發生的問題–缺陷報告是測試人員和開發人員交流溝通的重要工具。便於開發人員修正缺陷報告可以反映專案產品當前的質量狀態，便於專案整體進度和質量控制軟體測試缺陷報告是軟體測試的輸出成果之一，可以衡量測試人員的工作能力。

一、缺陷報告的要點

1）標題

2）描述：簡潔、準確、完整、反映缺陷本質

3）重現步驟

4）嚴重程度

5）優先順序

6）截圖

7）編號

8）指派人

二、“5C” 原則

內容準確（Correct）：每個組成部分的描述準確，不會引起誤解

步驟簡潔（Concise）：只包含必不可少的資訊，不包括任何多餘的內容

內容清晰（Clear）：每個組成部分的描述清晰，易於理解

結構完整（Complete）：包含復現該缺陷的完整步驟和其他本質資訊

風格一致（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）：缺陷此時所處的處理階段或處理情況

（1）測試人員發現缺陷，提交缺陷報告，把缺陷的狀態置為 new（新）

（2）開發經理驗證提交的 bug，如果是 bug，把狀態改為 open（開啟的 bug，開發組承認的 bug），指派給具體的開發人員解決；如果不是 bug，把狀態改為 rejected（拒絕的 bug）

（3）開發人員看到指派給自己解決的 bug，進行缺陷修復，修改完後，把缺陷狀態 fixed（已經修復的 bug，可以返測的 bug）

（4）測試人員對修復的 bug 進行反測，若返測成功，將狀態改為 closed（關閉的缺陷，歸檔的 bug）；如果返測不成功，把狀態改為 reopen（重新開啟的 bug）

五、缺陷報告的深度理解

1、缺陷的嚴重程度和優先順序是不是成正比關係？

介面問題的嚴重程度一般比較低，擔優先順序可能很高————立即修復

某些重大的功能問題可能暫時解決不了，但不影響其他功能的使用，這時優先順序可能定義的比較低————在釋出之前修復

2、缺陷的嚴重程度和優先順序確定好後，還能修改嗎？

嚴重成度不允許改，優先順序可能修復。

測試人員確定一個缺陷 “立即修復”，但開發組認為這個缺陷不好解決，而這個缺陷又不影響其他功能，這時可能要求在 “下一個版本修改” 或 “釋出之前修改”

3、是不是所有一發現的缺陷都會被修復？

有些缺陷修復的成本太高或者由於進度壓力可能在釋出前得不到修復，這樣的缺陷一定要經過專案組的討論，權衡成本和風險，要確保不會對使用者在成重大的影響及法律糾紛。後面再透過升級軟體或者打補丁的方式修復缺陷或彌補漏洞

六、缺陷報告的作用

1、記錄 bug

2、對 bug 進行分類（模組、bug 狀態、嚴重程度、版本）

3、跟蹤 bug

4、對 bug 進行分析、統計

介面測試工具可以使用國產的介面測試和介面文件生成工具：apipost