錯誤：靜態存在於文件說明中的表述或編寫錯誤。
bug：存在**或硬體系統中的錯誤。debug就是尋找錯誤
缺陷：被測物件實際表現與使用者的顯性需求或隱性需求之間的差異，包含了錯誤和bug
(1) 功能實現的錯誤
(2) 功能實現的遺漏
(3) 功能實現的多餘
(4) 功能實現不好
失效：因缺陷激發或者導致的功能的異常，無法使用的現象
需求表述理解，編寫過程中引起的錯誤
系統設計架構引起的錯誤
開發過程中缺乏有效的溝通和監督（team）
開發人員編碼過程產生的錯誤
軟體開發工具本身的錯誤
軟體需求、複雜度越來越高
與使用者需求不符合，即使本身不存在某種意義上的而缺陷
缺陷嚴重度：表示軟體缺陷所造成的危害的惡劣程度，一般分為5級
fatal：致命的缺陷，造成系統或程式的崩潰、宕機、系統懸掛，或造成資料丟失、主要功能喪失等。
critical：嚴重的缺陷，主要指功能或特性沒有實現，主要功能部分喪失，次要功能完全喪失，或致命的錯誤宣告。
major：主要缺陷，雖然不影響系統的執行，但沒有很好的實現功能，沒有達到預期效果。比如提示資訊不準確，或使用者介面差，操作時間長等。
minor：一些小問題，對功能幾乎沒有影響，產品及屬性仍可使用。
suggestion：一些友好的建議
a類：最高優先順序：立即修復，停止進一步測試
b類：次高優先順序：在產品發布之前必須修復
c類：中等優先順序：如果時間允許應該修復
d類：最低優先順序，可能會修復，但是也可以不修復
一般情況下：嚴重程度高的缺陷優先順序高
特殊情況下：不成正比
沒有必然的聯絡，結合實際綜合考慮
缺陷id：用來唯一標識缺陷的字段，不可重複，不能復用
概要描述：描述缺陷的表象或存在的形式，便於開發人員快速推測缺陷的產生原因
發現人:缺陷的發現者，一般測試工程師，專案組其他人員，使用者
發現時間
修復時間
所屬版本：為了統計不同版本的缺陷數量，以及確定測試版本的發布風險
所屬模組：缺陷所在的功能或業務模組，便於後期統計每個功能或業務模組的缺陷分布情況，從而合理利用資源
缺陷狀態
缺陷的嚴重度：
修復的優先順序
詳細描述：對概要描述的補充，步驟，測試資料，操作順序，當時物理環境
下一步處理人
角色定義：定義管理流程中，所涉及到的角色，包括主要職責，工作內容。比如專案組裡，包含測試工程師，測試經理，開發工程師，開發經理，專案經理。
流程定義：定義流程所有角色所遵循的規則
(1) 測試工程師發現並提交缺陷
(2) 測試經理進行卻笑的過濾
(3) 測試經理將缺陷交給開發經理
(4) 開發經理根據情況，分配開發人員修復缺陷
(5) 開發工程師確認缺陷，如果是就修復，不是就拒絕，並說明理由
(6) 如果缺陷修復了，測試人員要進行回歸測試，如果回歸測試發沒有問題，close，如果有問題reopen
(7) 如果出現矛盾，雙方闡述理由，無法達成一致，專案經理協調處理。
工具應該：
(1) 開源：excel，bugfree
(2) 商業：qc，禪道
第五章軟體缺陷管理
軟體缺陷產生原因 大多數軟體缺陷並不是由於編碼造成的，導致大多數軟體缺陷產生的最大的原因是需求分析階段，其次是在軟體設計階段 符合下面 5個規則中的乙個，就是軟體缺陷 軟體未實現產品說明書要求的功能 軟體出現了產品說明書指明不應該出現的錯誤 軟體實現了產品說明書未提到的功能 軟體未實現產品說明書雖未...
缺陷跟蹤管理
缺陷跟蹤管理是測試工作的乙個重要部分，測試的目的是為了盡早發現軟體系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發現的缺陷都能夠及時得到處理是測試工作的一項重要內容。1 缺陷跟蹤管理的目標 缺陷能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，軟體測試過程簡單說就是圍繞缺陷進行的，對缺...
5 6缺陷管理
因為發現缺陷是測試目的之一，所以應該記錄測試過程中發現的缺陷。基於測試元件或系統的上下文 測試級別和軟體開發生命週期模型的不同，記錄缺陷的方式會有所不同。任何識別的缺陷都應該被調查，並跟蹤從發現和分類到解決問題的過程 例如 修復缺陷和成功驗證解決方案，推遲到後續的發布，接受為永久性產品限制等 為了解...