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