一、什么是缺陷

不滿足用戶確定需求、影響軟件功能實現的問題、故障
缺陷就是人們通常所說的bug。

ex.一下哪一種選項不屬于軟件缺陷___。
A.軟件沒有實現產品規格說明所要求的功能
B.軟件中出現了產品規格說明不應該出現的功能
C.軟件實現了產品規格說明沒有提到的功能
D.軟件實現了產品規格說明書所要求的功能但因受性能限制而未考慮可移植性問題

答案：D

二、缺陷的識別

缺陷的產生原因

• 人員（用戶、設計、開發、測試、技術支持等）之間的溝通交流不夠，交流上有誤解或者根本不進行交流
• 文檔不完善甚至沒有文檔（尤其是國內中小軟件企業）
• 需求不斷電變化
• 參與人員技術能力上的局限
• 程序設計本身有誤
• 軟件復雜度大，缺陷很難避免（例如Windows、Word）
• 工期短，任務重，時間壓力大
• 軟件開發工具與系統軟硬件的支持有局限

判斷缺陷的依據

• 通過參考文檔來確認缺陷
• 需求規格說明書
• 概要設計、詳細設計
• 用戶手冊
• ...
• 通過了解軟件行業標準、行業背景（或參考同類典型軟件）來發現缺陷
• 通過溝通來確認和識別缺陷（問開發人員、問需求人員、問用戶... ...）

三、再現與優化缺陷

再現（又叫重現）與優化缺陷的必要性
優化缺陷并不是指優化缺陷本身，而是優化缺陷的再現步驟

為什么要再現與優化缺陷？
關于軟件中“隨機”出現的缺陷如何處理？

再現與優化缺陷的方法

• 深入熟悉需求，從需求本身出發
• 熟悉程序設計、從設計開發著手
• 熟悉常用測試方法、手段、典型套路
• 同一個缺陷用不同測試過程（含步驟、數據）多次驗證，分析缺陷的現象與成因，找出規律和最簡實現過程
• 查找依賴關系和競爭條件
• 不斷積累處理缺陷的經驗

四、怎樣有效記錄缺陷

保證重現缺陷

判斷一個缺陷報告撰寫好壞的簡單方法：讓非缺陷報告撰寫者（技術人員）依據缺陷報告重現缺陷，如果能簡單、迅速的重現缺陷，表明缺陷報告較好

分析故障——使用最少步驟重現缺陷

減少開發人員重復缺陷的時間
使開發人員更準確的定位缺陷

包含所有重現缺陷的必要步驟

測試人員假定常用的操作步驟開發人員不一定熟悉，省略了必要的步驟長處造成開發人員無法重現缺陷。

其他注意事項

方便閱讀

舉例：
概述：使用“記事本”僅保存“聯通”二字后再打開該文件，出現亂碼。
描述步驟：
1.點擊“開始” → “程序” → “附件” → “記事本” 打開記事本軟件；
2.僅輸入“聯通”二字，點擊“文件” → 保存；
3.在打開的“另存為”對話框中保存文件后退出（文件名、保存位置任意）；
4.打開保存的文件，出現亂碼，不是“聯通”二字。

注意自己的語氣

舉例：
概述：“記事本”中“另存為”對話框中默認文件后綴寫成了“.txk”。
描述步驟：
1.點擊“開始” → “程序” → “附件” → “記事本” 打開記事本軟件；
2.僅輸入“聯通”二字，點擊“文件” → 保存；
3.在打開的“另存為”對話框中，默認文件文件后綴應該是“.txt”，你們開發人員是不是用腳后跟考慮問題的，居然寫成了“.txk”；

六、缺陷報告

缺陷報告是描述軟件缺陷現象和重現步驟地集合。
軟件缺陷報告Sottware Bug Report(SBR)或軟件問題報告Software Problem Report(SPR)

缺陷報告的作用

1.缺陷報告是軟件測試人員的工作成果之一，體現軟件測試的價值
2.缺陷報告可以把軟件存在的缺陷準確描述出來，便于開發人員修正
3.缺陷報告可以反映項目/產品當前的質量狀態，便于項目整體進度和質量控制
4.軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力

缺陷報告的“5C”原則

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

缺陷報告的內容

缺陷的標題
缺陷的的基本信息：
1.測試的軟件和硬件環境
2.測試的軟件版本
3.缺陷的類型
4.缺陷的嚴重程度
5.缺陷的處理優先級
復現缺陷的操作步驟
缺陷的實際結果描述
期望的正確結果描述
注釋文字和截取的缺陷圖像

缺陷的二八定理

在分析、設計、實現階段的復審和測試工作能夠發現和避免80%的缺陷，而系統測試又能找出其余缺陷中的80%，最后的4%的缺陷可能只有在用戶大范圍、長時間使用后才會暴露出來。

七、記錄缺陷與缺陷報告

• 使用較少的、必要的操作步驟確保缺陷能夠重現
• 記錄缺陷時要使用專業術語、注意書寫格式
• 缺陷要言簡意賅、盡量一個缺陷一個報告
• 對于實在不可重現的缺陷也需要報告，并且盡快報告
• 不能夸大缺陷的數量和缺陷的級別
• 及時記錄缺陷

八、缺陷的分類

按照嚴重程度分類、缺陷的優先級、缺陷的類型以及功能模塊等進行分類

按嚴重程度

致命錯誤：如數據丟失、死機、系統崩潰
嚴重錯誤：如功能未完成，功能完成不正確
一般錯誤：如功能不完善，界面問題等
建議（輕微）：測試人員認為怎么處理更好一些的問題

按照修改優先級

立即修改
在本版本修改
在產品發發布前修改
在發布版本中可以存在的問題

按照缺陷類型

功能、壓力/負載、界面、兼容、易用、安裝/卸載、安全

按照功能模塊

功能模塊1
功能模塊2
功能模塊3
功能模塊4
......

缺陷報告的處理流程?