● 缺陷的定義
→ 軟件沒有達到產品說明書表明的功能
→ 軟件出現了產品說明書中不一致的表現
→ 軟件功能超出產品說明書的范圍
→ 軟件沒有達到用戶期望的目標(雖然產品說明書中沒有要求)
→ 測試員或用戶認為軟件的易用性差
● 不是所有缺陷都會修改
→ 市場的壓力使得產品最終發行有時間限制
→ 測試員錯誤理解或者不正確操作引出的缺陷(FAQ)
→ 錯誤的修改影響的模塊較多，帶來的風險較大（遺留）
→ 修改性價比太低(FAQ，遺留）
→ 缺陷報告中提出的問題很難重現
1、缺陷報告管理系統
● 是測試流程在工具上的固化
● 通過權限控制來實現流程監控
● 記錄了缺陷識別到關閉過程中的所有數
● 記錄了版本變更的信息
● 是開發和測試之間溝通的信息平臺
● 實時的數據和信息的更新
● 度量和統計分析，為改進產品提供依據
方正測試缺陷跟蹤與管理系統
● 采用Lotus Notes作為bug管理平臺
● 完全電子化的信息傳遞
● 統一管理和備份
具備數據統計和查詢功能
能夠進行個性化二次開發
1.1 系統測試缺陷處理流程
缺陷報告
● Bug報告準則
→ 如何重現錯誤-使用最少步驟重現
→ 現象描述沒有歧義
→ 盡量簡單-一個bug一個報告
→ 可以提出對錯誤的解決建議
● 開發人員拒絕修改的bug
→ 程序員無法重現或者現象難以捕捉
→ 沒有明確的報告以說明重現bug的步驟
→ 程序員無法讀懂的bug報告
→ 用戶很少使用或者不符合用戶使用習慣的操作出錯
→ 由不受信任的測試人員提出
1.2 集成測試缺陷處理流程
● 缺陷分析的關注點：
1、對軟件問題的功能域分布進行分析，找出系統的薄弱環節
→ 要詳細采集每個功能模塊或系統構件的bug數據，并按功能、錯誤類型、嚴重程度等分類
→ 比較實際發現的軟件bug是否與預期的問題分布相吻合
→ 二八定理：80%的軟件問題總是發生在大約20%的功能模塊（系統構件）中。
2、對bug的注入階段的分布進行分析，并與歷史數據相比較。應按不同的開發階段詳細采集bug的數據
→ 要求軟件各開發階段的缺陷密度小于本單位過去的平均值
→ 而且要求需求分析、設計和代碼復查階段的缺陷排除率之和大于或等于規定值（例如75%）。（同行評審）
3、應對軟件缺陷類型進行分析，以便針對各自的特點，先修復嚴重缺陷。
→ 可參考PSP中缺陷類型標準（如下表），其中缺陷類型是按照問題的復雜度來排列的，類型10到40是比較簡單的編碼缺陷，類型50到100是比較復雜的設計缺陷。
4、應動態采集每個測試周期中發現的bug數，并有效地控制缺陷的修復率。
5、應密切觀察bug的狀態，并及時跟蹤其狀態的變化，以檢查測試和開發人員的工作情況
6、應該采集bug不同方式的修復數據，以便檢驗軟件產品是否滿足交付規則
→ 分析修改代碼、改變設計、封掉功能遺留以及下一版本解決的bug數約占缺陷總數的比例。
→ 在有嚴密和有效的質量保證體系條件的監控下，常常會引起有較高比例的延期解決的缺陷數，這是因為許多細微的或枝節性的問題被測試出來，經過評價證明不會造成大的質量影響，但可為產品進一步升級提供有價值的參考。
● 測試人員的績效評價
→ 評價標準：
1、bug數量：
同一個項目組內，提交bug數量的多少是衡量測試人員工作效率的一方面；另一個衡量指標是每人日提交的bug數。
2、bug嚴重程度：
Bug的嚴重程度是衡量bug的質量的一個重要因素，好的bug應該是極端嚴重的，對系統造成極大危害的。
3、bug價值：
Bug的雙方面評判，對于bug的價值開發人員在另外一個角度上進行評判
以上三個因素的加權平均才能更有效的評價測試人員的績效！
缺陷統計分析工具介紹
●測試結果分析和評價
缺陷密度:
→ 基本的缺陷測量是以每千行代碼的缺陷數(Defects/KLOC)來測量的。稱為缺陷密度(Dd)，其測量單位是defects／KLOC。可按照以下步驟來計算一個程序的缺陷密度：
→ 累計開發過程中每個階段發現的缺陷總數(D)。
→ 統計程序中新開發的和修改的代碼; height:28px;">