認識缺陷報告
- 缺陷報告的重要性
軟件缺陷的描述是軟件缺陷報告的基礎部分，需要使用簡單、準確、專業的術語來描述缺陷。否則，它就會含糊不清，可能會誤導開發人員，影響開發人員的效率，也會影響測試人員自身的聲譽，準確報告缺陷是非常重要的。
清晰準確的軟件缺陷描述可以減少開發人員退回來的缺陷數量，可以節省開發人員和測試人員的時間。 提高軟件缺陷修復的速度，使項目組能夠有效地工作。
提高測試人員的可信任程度，可以得到開發人員對有效缺陷的及時響應。 加強開發人員、測試人員和管理人員的協同工作，讓他們更好的工作 - 缺陷報告的注意事項
儘量確保缺陷可以重現
如果提交的缺陷無法重現，會影響開發人員的工作效率。
簡潔、準確、完整
測試人員在提交缺陷報告時，要站在開發人員的角度上思考問題，要確保開發人員能迅速定位問題，而不會產生理解上的歧義。
一個缺陷一個報告
有的測試人員喜歡在一個缺陷報告裏提交多個缺陷，這種習慣不提倡，原因有以下兩點： 不便於分配。
比如缺陷報告有2個缺陷，分別屬於不同的開發人員，到底該分配給誰呢？ 不便於驗證。
比如一個缺陷報告裏面有2個缺陷，缺陷1已經解決，缺陷2還沒有解決，那麼這個缺陷報告該不該關閉呢？ - 缺陷書寫規範
標題：應保持簡短、準確，提供缺陷的本質信息
儘量按缺陷發生的原因與結果的方式書寫；
避免使用模糊不清的詞語，例如：“功能中斷，功能不正確，行爲不起作用”等。應該使用具體文字說明缺陷的症狀； 爲了便於他人理解，避免使用俚語或過分具體的測試細節。
復現步驟：應包含如何使別人能夠很容易的復現該缺陷的完整步驟。
爲了達到這個要求，復現步驟的信息必須是完整的、準確的、簡明的、可復現的。常見問題： 包含了過多的多餘步驟，且句子結構混亂，可讀性差，難以理解；
包含的信息過少，丟失了操作的必要步驟；
復現步驟的正確書寫方式:
提供測試的環境信息；
簡單地一步步引導復現該缺陷，一個步驟包含的操作不要多； 每個步驟前使用數字對步驟編號；
儘量使用短語或短句，避免複雜句型句式； 復現的步驟要完整、準確、簡短；
將常見步驟合併爲較少步驟；
按實際需要決定是否包含步驟執行後的結果。
實際結果: 是執行復現步驟後軟件的現象和產生的行爲。
實際結果的描述應向標題信息那樣，要列出具體的缺陷症狀，而不是簡單地指出“不正確”或“不起作用”。
期望結果:描述應與實際結果的描述方式相同。通常需要列出期望的結果是什麼。
附件：對缺陷描述的補充說明，可以是以下一些類型：
缺陷症狀的截圖；
測試使用的數據文件;
其他：
選擇合適的缺陷嚴重性屬性；
按相應的規定，填寫相應的字段信息
3.1避免常見錯誤
避免使用我、你等人稱代詞，可以直接使用動詞或必要時使用“用戶”代替避免使用情緒化的語言和強調符號；
避免使用諸如“似乎”、“看上去可能”等含義模糊的詞彙，而需要報告確定的缺陷結果； 避免使用自認爲比較幽默的語句，只需客觀地描述缺陷的信息；
避免提交不確定的測試問題，自己至少需要重現一次再提交。 反面的示例：
上海人：哪能查詢到的結果和查詢條件不搭噶的。
北京人：哥們好不容易輸入一堆個人詳細信息後，點擊保存後全瞎了
3.2 缺陷報告
3.3 缺陷處理流程
3.4缺陷跟蹤
新提交的缺陷爲新建狀態，確認有效後爲打開狀態，經開發人員修改後，缺陷變爲已修復（待驗證）狀態。此時就需要測試人員對缺陷進行迴歸測試，驗證問題是否修復。
如果問題仍然存在，則測試人員將該缺陷的狀態修改爲重新打開；
如果問題已經修復，則測試人員將該缺陷的狀態置爲關閉狀態（驗證通過），同時添加回測說明如“該缺陷已解決”。
還有一種情況：開發人員認爲缺陷在當前版本可以暫不修改，而考慮在後續版本中再做修正，缺陷的對應狀態爲延期。
對於這種情況，項目負責人應召集開發人員、測試人員和其他項目相關人員進行討論，如果討論結果爲同意則延期，如果不同意，則重新打開缺陷。
3.5 缺陷統計
缺陷按活動分佈
缺陷按嚴重程度分佈
缺陷按引入源分佈
3.6 缺陷數據分析
1）缺陷數據分析關注的問題
2）缺陷數據分析的重要性
3）缺陷數據分析的數據指標
3.7 缺陷數據分析關注的問題
正在測試的軟件哪個模塊的問題最多測試人員中誰報告的軟件缺陷最多
各類缺陷所佔的數量百分比分別是多少開發人員能及時修復軟件缺陷嗎
開發人員一次正確修復缺陷的百分比是多少正在開發的軟件能否在計劃的時間內正常發佈