軟件測試--缺陷報告

缺陷報告是描述軟件缺陷現象和重現步驟地集合。軟件缺陷報告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

自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。