軟件測試人員如何概述缺陷? 測試基礎 一. 缺陷報告（defect report） ，現在小編就來說說關于軟件測試人員如何概述缺陷?下面内容希望能幫助到你，我們來一起看看吧!

軟件測試人員如何概述缺陷

測試基礎

一. 缺陷報告（defect report）

1.1 測試工程師主要工作職責

1.測試負責人（測試經理，測試組長），編寫測試計劃

2.測試工程師

1）熟悉需求，編寫各功能模塊測試用例

2）執行測試用例，發現缺陷，提交缺陷報告

3）返測（複測），驗證缺陷是否得到修改

4）編寫測試總結報告

1.2 什麼是缺陷報告？

當測試人員發現一個缺陷時，需要填寫一份“缺陷報告”來記錄這個缺陷，并通過缺陷報告告知開發人員所發現的問題-------缺陷報告是測試人員和開發人員交流溝通的工具

1.3 缺陷報告的重要組成

測試人員在測試過程中，發現缺陷，将缺陷提交給開發組，為了提高缺陷的質量和效率，幾乎所有的軟件項目組，都是項目管理工具（測試管理工具，bug管理工具），

例如：禅道， HP Quality Center（QC,） Jire，Bugzilla

因為不同公司使用的項目管理工具不同，造成缺陷報告的模闆不完全同，大同小異。

1.缺陷編号（Defect ID）

記錄缺陷發現的順序，如果使用項目管理工具，自動生成。

2.缺陷發現者（Defected by）

測試人員自己

3.缺陷标題（Summary）

簡明，扼要的描述缺陷

4.缺陷日期（Defected on date）

注意：不要寫成data（數據）

發現缺陷的時間，在項目管理工具中，時間自動填寫

5.指派給誰處理（Assigned To）

說明：測試人員發現缺陷，提交給開發組（開發經理），

開發經理将缺陷指派開發人員處理

6.缺陷所屬模塊（Subject）

在哪裡發現的缺陷

7.缺陷版本（Detected in release/version/build）

在軟件測試過程中，會生成很多臨時版本（11.21）

擴展：

回歸測試：在當前版本中，對上一個版本中，測試過的功

能再測試一遍

回歸測試中有很多重複的操作，為了提高測試效率，采用

自動化測試（條件允許）。

8.缺陷的狀态（status）

發現缺陷所處的狀态

狀态：

以項目管理工具QC為例：

new-----新發現的缺陷

open---确認的缺陷（被承認的bug）

fixed---修改過的缺陷（待返測的缺陷）

closed---關閉的缺陷

rejected---被拒絕的缺陷(沒有被開發組承認)

reopen---再次激活（打開）的缺陷

以禅道為例：

激活狀态-----新的 缺陷

已修改缺陷----修改後的缺陷

關閉------ 關閉的缺陷

擴展：

常見面試題：缺陷的處理流程？（缺陷的生命周期/缺陷的一生）

步驟1：測試人員填寫缺陷報告，提交缺陷，此時的

狀态：new

步驟2：開發經理确認（驗證）缺陷

情況1：如果是缺陷，将缺陷的狀态變為：open， 将此缺陷指派給相應的開發人員修改.

情況2：不是缺陷,将缺陷的狀态變為：rejected

說明：被拒絕的缺陷是可以再次激活的，需要測試組長和測試經理和需求人員讨論得出結果。

步驟3：開發人員修改缺陷，修改完成後，開發人員将缺陷的狀态變為：fixed

步驟4：測試人員返測（複測）

情況1：如果測試通過，将缺陷的狀态變為：closed

情況2：如果測試不通過，将缺陷的狀态變為：reopen，指派給開發人員再次修改

缺陷狀态的變化：

【1】new> >open> >fixed> >closed

【2】new> >open> >fixed> >reopen> >fixed> >closed

９．缺陷的嚴重程度（severity）

測試的軟件有多糟糕，影響有多嚴重

嚴重程度：

Urgent---緻命的問題（死機）

Very High----非常嚴重缺陷

High----嚴重缺陷

Medium-----中級缺陷

Low-----小缺陷（小問題 ）

10.缺陷的優先級（priority）

缺陷在什麼時間或者什麼版本解決

優先級：

Urgent----立即解決

Very High---版本内解決

High----------下一個版本解決

Medium-----在軟件發布之前解決

Low-----------可以存在軟件中（需要測試人員，開發人員讨論，确定沒有問題）

說明：一般軟件在更新或者打補丁時，解決以前沒有解決的bug

擴展：

關于優先級和嚴重程度

1）關于優先級定義影響的因素

【1】 缺陷的嚴重程度-----一般缺陷的嚴重程度越高，優先級越高

【2】開發人員任務壓力-----壓力越小，優先級越高

【3】缺陷的影響範圍-------影響範圍越廣，優先級越高

【4】解決成本-----------------成本越低，優先級越高

2）優先級和嚴重程度是否成正比關系

不成正比關系

例如：軟件界面存在問題，嚴重程度比較低，優先級較高

3）優先級和嚴重程度确定後，是否可以修改？

嚴重程度一般不修改，優先級可以修改

11缺陷描述(Description)

将發現缺陷的步驟（操作）和數據記錄下來，讓開發人員可以重現缺陷

說明：一般提交缺陷時，都會附帶“證迹”（截圖、視頻）

總結：

缺陷報告的組成？

【1】缺陷編号

【2】缺陷标題（summary）

【3】缺陷發現者

【4】缺陷日期

【5】指派給誰處理

【6】缺陷所屬模塊

【7】缺陷版本

【8】缺陷狀态(Status)

【9】缺陷的嚴重程度

【10】缺陷的優先級

【11】缺陷的描述（Description）

2缺陷報告的作用

1.記錄bug

2.對bug進行分類（日期，提交者，版本，狀态，嚴重程度，

優先級）

3.對bug進行跟蹤管理（new->open->fixed->closed）

4.對bug進行分析統計

3.如何判斷bug

1.根據測試用例的預期結果判斷（實際結果與預期結果不一緻，就是bug）

2.看需求（與需求不一緻的bug）

3.與相關人員讨論（用戶，需求，開發，産品）

4.參考bug的5點定義

注意：

1.不可重現（不可複現，随機bug）的bug也要報告，但要說明該bug不可重現，如果有可能，說明一下出現的頻率（按照時間，後者操作10次出現幾次）

4.bug的處理流程（bug的生命周期）

new->open->fixed->closed

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!