1. 缺陷的定義

• 軟體未實現產品說明書中要求的功能；
• 軟體未實現產品說明書中未明確提及但應該實現的目標；
• 軟體實現了產品說明書中未提到的功能；
• 軟體出現了產品說明書中指明不應該出現的功能。
• 軟體難以理解、不易使用、執行緩慢或者—從測試員的角度看—終端使用者會認為不好

2. 缺陷的屬性

3. 缺陷型別

缺陷型別是根據缺陷的自然屬性劃分的缺陷種類

功能（Function）、介面（UI）、文件（Documentation）、軟體包（Package）、效能（Performance）、介面（Interface）

注意：需求分析、設計階段，文件型別的缺陷多；

整合測試階段，一般介面型別的缺陷多一點；

系統測試階段，功能、介面型別的缺陷多一些；

驗收測試階段，更多的關注效能缺陷；

實施過程，可能會遇到一些軟體包的缺陷。

4. 缺陷嚴重程度

缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。

5. 缺陷優先順序

缺陷的修復優先順序：缺陷的優先順序指缺陷必須被修復的緊急程度。

缺陷的嚴重程度和優先順序有什麼聯絡？

1. 沒有任何的直接聯絡

嚴重性(Severity)顧名思義就是軟體缺陷對軟體質量的破壞程度，即此軟體缺陷的存在將對軟體的功能和效能產生怎樣的影響。

在軟體測試中，軟體缺陷的嚴重性的判斷應該從軟體終端使用者的觀點做出判斷，即判斷缺陷的嚴重性要為使用者考慮，考慮缺陷對使用者使用造成的惡劣後果的嚴重性。

優先順序是表示處理和修正軟體缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。

確定軟體缺陷優先順序，更多的是站在軟體開發工程師的角度考慮問題，因為缺陷的修正順序是個複雜的過程，有些不是純粹技術問題，而且開發人員更熟悉軟體程式碼，能夠比測試工程師更清楚修正缺陷的難度和風險。

2. 缺陷的嚴重性和優先順序是含義不同但相互聯絡密切的兩個概念。它們都從不同的側面描述了軟體缺陷對軟體質量和終端使用者的影響程度和處理方式。

一般地，嚴重性程度高的軟體缺陷具有較高的優先順序。嚴重性高說明缺陷對軟體造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟體不太盡善盡美，可以稍後處理。

但是，嚴重性和優先順序並不總是一一對應。有時候嚴重性高的軟體缺陷，優先順序不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先順序。

6. 缺陷狀態

缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。

7. 缺陷起源

缺陷起源指缺陷引起的故障或事件被第一次被檢測到的階段

8. 缺陷根源

缺陷根源指發生錯誤的根本因素

9. 缺陷的生命週期

——每個公司、每一個工具對bug生命週期的定義都是不一致的，下面僅是一個常見的例子：

測試人員應該跟蹤一個Bug的整個生命週期，從Open到Closed的所有狀態。

10. 缺陷的生命週期

• 發現缺陷：由測試人員。開發也能知道自己哪裡寫錯了，但是不會廣而告之。
• 提交缺陷：由測試人員。開發更不可能提交bug。
• 確認缺陷：一般由測試主管、或者質量保證（QA）、由產品經理進行確認。
• 分配缺陷：經確認後，有效的缺陷會指派給相關人員進行處理。一般由誰確認的缺陷，就由誰分配。分配的物件可能是開發、也可能是UI、也可能是產品經理。
• 修復缺陷：主要由開發修復，也有可能是產品經理修復問題，也有可能是UI修復問題。
• 驗證缺陷：測試去驗證缺陷有沒有修復成功。
• 關閉缺陷：只能是測試人員進行。否則出了問題，測試人員一律不背鍋。

面試提問：針對你工作中發現的一個bug，說說這個bug的處理過程。（缺陷的生命週期中，每一個環節由誰做什麼）

10. 缺陷的識別

• 通過測試用例中的預期結果進行識別
• 通過需求規格說明書進行識別
• 通過使用者手冊及其他文件進行識別
• 通過同行業相類似成熟的商業軟體來識別
• 通過和開發人員的溝通進行識別
• 通過和有經驗的測試人員溝通進行識別
• 參照同行業隱式需求進行識別

缺陷的識別

依據

需求文件、設計文件、產品原型、測試用例，都是客觀的依據。

同行業的類似成熟軟體，和開發人員溝通，跟有經驗的測試人員溝通，同行業隱形需求，都是帶有主觀色彩的依據。

測試人員在識別缺陷的時候，要很靈活的對待。

11. 報告模板

1.編寫目的和預期讀者

1. 缺陷報告編寫目的

• 易於搜尋軟體測試報告的缺陷
• 報告的軟體缺陷進行了必要的隔離，報告的缺陷資訊更具體、準確
• 軟體開發人員希望獲得缺陷的本質特徵和復現步驟
• 市場和技術支援等部門希望獲得缺陷型別分佈以及對市場和使用者的影響程度

2. 預期讀者

• 開發人員、質量管理人員、市場人員、運維人員·······

2. 報告編寫準則

• Correct（準確）：每個組成部分的描述準確，不會引起誤解
• Clear（清晰）：每個組成部分的描述清晰，易於理解
• Concise（簡潔）：只包含必不可少的資訊，不包括任何多餘的內容
• Complete（完整）：包含復現該缺陷的完整步驟和其他本質資訊
• Consistent（一致）：按照一致的格式書寫全部缺陷報告

3. 缺陷描述準則

• 單一準確
• 可以再現
• 完整統一
• 短小簡練
• 特定條件
• 補充完善
• 不做評價

4. 缺陷管理方式和模版

注意：

缺陷報告模板

• 缺陷編號：Bug_專案名稱 _功能名稱 _0001。
• 所屬模組：一級模組/二級模組/三級模組。例如：上課所用的直播軟體，如果想要檢視簽到歷史記錄，需要進入直播介面——互動應用——簽到——簽到歷史記錄。
• 優先順序：缺陷的修復緊急程度。P1>P2>P3>P4。
• 嚴重程度：S1>S2>S3>S4。
• 缺陷概述：用一句話描述缺陷的基本情況。
• 缺陷的描述：缺陷的復現步驟、預期結果和實際結果列出來。
• 提交人：是誰就寫誰的名
• 備註：一般寫產生該缺陷的特殊情況。將bug的截圖作為備註資訊。

缺陷報告的編寫目的

1. 展現缺陷的詳細資訊

2. 展現缺陷的影響程度和方式

由於缺陷報告的讀者很多：開發、質量管理、市場人員、運維人員，所以缺陷報告要寫的很直白、清晰、明瞭。

報告編寫的準則：準確、清晰、一致、簡潔、完整。

缺陷描述的規則：

可以再現。針對絕大多數的缺陷都是如此。但是有一些小部分的缺陷是難以做到（類似閃退、崩潰這種不可再現缺陷，無需做的。針對一些可以重複出現的閃退缺陷，也要進行步驟的詳細描述）

不做評價。不對缺陷的出現的嚴重程度和缺陷表現出來的效果進行主觀臆斷。

缺陷報告本身要保證沒有任何表述性的錯誤。

測試需求和測試用例、缺陷報告的關係？

測試的基本流程：獲取測試需求——編寫測試計劃——制定測試方案——設計和開發測試用例——執行測試——提交缺陷——測試分析和評審——測試總結——準備下一版本的測試。

獲取測試需求是測試工作的重點，也是第一步。通過需求的分析，瞭解和掌握測試的方向和內容。例如：

1. 分析出系統的模組和組織結構

2. 分析出軟體的基本功能和執行流程。（業務分析）包括可能會有哪些人或者哪些角色要用。

3. 識別出軟體的重要功能和次要功能。獲取測試需求的過程中，測試人員就要有相應的分析成果。一般用Xmind這樣的思維導圖工具進行分析，或者使用需求跟蹤矩陣來完成測試需求的獲取和分析。

設定測試中需求的正、反向，和優先順序。

當有了測試需求之後，就開始針對每一個需求點進行測試用例的設計。也就是，每一個需求點，都要被測試。

因此測試的過程中，衡量需求的覆蓋程度，就非常的重要。使用： 需求的覆蓋程度=被測試用例覆蓋的需求數/需求點總數 進行計算和說明。

如果需求覆蓋度<100%,那一定說明了測試的覆蓋度不夠。

測試中，最能體現測試人員工作量的指標就是缺陷的數量和用例的數量。

1. 設計的測試用例總量 TC。

2. 自信的測試用例數量 EC。

3. 為執行的測試用例數量 WC。

4. 執行通過的測試用例總量 SC。

5. 執行失敗的測試用例總量 FC。

6. 提交的缺陷的總量 BC（Bug Counts）。

以上幾個資料，他們要符合如下的數量關係。
  
    1. TC大於等於EC。
  
    2. TC=EC+WC。
  
    3. EC=SC+FC。
  
    4. BC大於等於FC。提交的bug數量，多於執行未通過的用例數。一條用例的預期結果數量是固定（甚至是唯一的）。說明了，測試過程中發現的缺陷，除一部分是用例執行失敗帶來的，還有一部分應該是測試人員自身經驗和直覺（其他知識）帶來的。
  
    5. 通過 SC/EC 可以表現出系統的質量是否合格。
  
    6. 通過 EC/TC 可以表現出系統的需求是否得到滿足。