缺陷：
不滿足使用者確定的需求
不符合設計要求

產生缺陷原因：
人員之間溝通交流不夠，交流上有誤解，不進行交流
文件不完善
需求不斷變化
參與人員的過度自信（模組功能不除錯，多個模組不聯調）
程式設計本身有錯誤
軟體複雜性
工期短，任務重，時間壓力大
軟體開發工具與系統軟硬體的支援

確定缺陷的方法：
通過參考需求文件來確定缺陷
通過了解軟體產品的行業背景
通過溝通來確認和識別缺陷

再現（重現）與優化缺陷的必要性：
優化缺陷並不是指優化缺陷本身，而是優化缺陷的再現步驟。
隨機出現的缺陷
不能重複的bug：做好記錄，記清細節

再現（重現）與優化缺陷的方法：
1.不能想當然的接受任何假設：記下所做的每一件事－－每一個步驟、每一次停頓、每一件工作
2.查詢時間依賴和競爭條件的問題
3.用例1成功後，執行完用例2，用例1出現問題狀態缺陷僅在特定軟體狀態中顯露出來
4.考慮資源依賴性和記憶體、網路、硬體共享的相互作用
5.不要忽視硬體
6.關注軟體的失效問題，對缺陷的修改可能會引發新的缺陷從閱讀缺陷報告入手

有效記錄缺陷的方法：
1. 保證重現缺陷，不能重現的要著重記錄出現缺陷時的操作步驟和環境
2. 分析故障，使用最少步驟復現故障
3. 包含所有重現缺陷的必要步驟
4. 方便閱讀
5. 儘量簡單——一個缺陷一個報告
6. 注意自己的語氣
7. 值得注意的經驗

缺陷報告的用途：
記錄缺陷
缺陷分類
缺陷跟蹤

缺陷分類：
嚴重程度：
影響進度的問題；
宕機；
功能問題；
介面問題；
建議

按修復缺陷的優先順序：
應立即修復的問題；
在產品釋出之前必須修復的問題；
如果時間允許應該修復的問題；
可以在釋出版本中存在的問題

缺陷報告的分類：
按缺陷所處狀態分類：
待確認的
新提交的
已分配的
問題未解決的
待返測的
待歸檔的
已歸檔的

按處理意見分類：
已修改的不是問題
無法修改
以後版本解決保留（設計如此）
重複
無法重現

禪道中bug狀態為：
啟用、已解決、已關閉。

然後已解決分為：
設計如此、重複bug、外部原因、已解決、無法重現、延期處理、不予解決。

缺陷報告的處理流程：
1.測試人員：提交缺陷報告
2.測試經理或開發經理：分配缺陷報告
3.開發人員：處理缺陷報告
4.測試人員：返測報告
5.測試經理或測試人員：關閉缺陷報告

關於處理缺陷：
1.注意缺陷報告的處理成本
2.修改缺陷要量力而行
3.關注被推遲修改的缺陷
4.如果決定據理力爭就一定要贏

缺陷報告統計：
1.缺陷分佈（密度）報告：缺陷狀態與優先順序 缺陷狀態與嚴重性
2.缺陷齡期報告（多長時間處理）
3.缺陷趨勢報告（變多變少，集中分散）