在任何軟體生命週期中，軟體缺陷的出現幾乎是不可避免的。建立一套有效的缺陷管理流程的目的是為了減少軟體缺陷出現的機率，並且大幅度降低由於軟體缺陷帶來的負面影響。對於缺陷管理流程的投資，可以大幅度的降低由於返工 /修復缺陷導致的人力，財力和時間浪費，同時提升使用者的體驗或者更多使用者留存與產品口碑，並且可以保障產品更準時的交付。
在正式開始談論產品缺陷管理流程建設之前，我們首先介紹下一些基本概念：
　 ·軟體Bug和缺陷有什麼區別？
　 ·什麼是Bug?

1

 

什麼是 Bug?

Bug最初是在軟體行業的計算機用語，是指由於錯誤編碼導致的結果。

2

 

缺陷是什麼 ?

缺陷的英文： Defect， 缺陷是指不符合最初定義的業務需求，其覆蓋範圍高於 Bug,除了錯誤編碼外其他導致不符合最初定義的業務需求問題都屬於缺陷範疇。 這兩個術語 Bug和Defect在英文中有非常細微的區別，但在行業中都是需要修復的錯誤，因此一些測試團隊並不對這兩個詞語做細分。
當測試人員執行測試用例時，他可能會遇到與預期結果不一致的測試結果。
測試結果中的這種不一致被稱為軟體缺陷。這些缺陷在不同的團隊中有不同的稱呼，如錯誤，缺陷， Bug，問題等。

3

 

缺陷報告應該包括的資訊

當向開發人員反饋缺陷時，您的缺陷報告應該包含以下資訊：
缺陷 ID： 缺陷的唯一標識號。
缺陷描述： 詳細描述缺陷，包括發現缺陷的模組的資訊。
軟體版本： 發現缺陷的軟體程式的版本號。
復現步驟： 詳細的步驟，以及開發人員可以復現缺陷的螢幕截圖。
缺陷提交日期： 提交缺陷的日期。
相關文件： 透過相關的需求、設計、架構文件並對比，能夠讓人更容易理解，例如產品需求文件，相關產品原型或者用例文件等。
提交人： 由誰發現的缺陷。
缺陷的狀態： 缺陷當前的修復狀態，我們稍後將詳細介紹。
修復人： 修復缺陷的開發人員。
缺陷關閉日期： 缺陷被關閉 /解決的日期。
缺陷等級： 描述缺陷對軟體程式的影響的嚴重程度。
缺陷優先順序： 優先順序與缺陷修復的緊迫性相關。嚴重程度優先順序可以是高 /中/低，這取決於缺陷修復對應用影響的緊急程度。

4

 

如果沒有有效的缺陷管理流程會怎麼樣？

其實無論團隊是否有花費時間和精力建立缺陷管理流程，缺陷管理流程總歸是會存在的，但這一流程並不一定有效，我見過一些團隊並沒有一套有效的流程，而是透過口頭或者郵件的方式進行著缺陷管理，這些方式可能會導致許多問題，下面我舉一個簡單的例項：
如果像上述的情況一樣透過口頭或者簡單郵件溝通進行缺陷管理，很快事情會變得十分複雜，如果你作為產品經理，想要控制和有效管理缺陷問題，壓力測試工具您需要了解一個缺陷的生命週期以及如何建立一套有效的缺陷管理流程。

5

 

缺陷管理的流程

為了能夠有效的管理缺陷問題，你需要建設一套有效的缺陷管理流程，以避免上述示例中這種無序混亂的狀態。本部分將指導您如何將缺陷管理過程應用於專案中。 管理缺陷可以分為以下步驟：
（ 1）發現缺陷：新建
一般缺陷問題有測試團隊根據用例步驟進行測試，如果不能正常透過用例則轉為缺陷問題。但是很多團隊並沒有專門的測試團隊，因此建立問題缺陷的可能來自不同團隊或者來自外部使用者提交的反饋資訊。這些缺陷反饋其缺陷狀態應該為 “新建”。
（ 2）開啟
當 QA測試團隊或者其他相同職務的團隊確認了反饋的缺陷問題後，比如可以復現，則確認反饋是一個缺陷，並等待分配給開發團隊。
（ 3）分配
當測試團隊確認缺陷後，應該將問題分配給開發團隊進行缺陷定位和修復工作。
（ 4）拒絕
如果開發團隊認為提交上來的缺陷並不是真正的缺陷，比如由於快取，網路導致的部分檔案載入失敗導致的問題等，應將缺陷狀態標記為 “拒絕”並指派回測試團隊。測試團隊需要重新測試或者提供更多的缺陷資訊。
（ 5）重複
如果開發團隊收到的缺陷是重複的，或者與其他正在進行中的缺陷問題相似，應將缺陷狀態修改為 “重複”。
（ 6）延期
部分不緊急的缺陷問題，可能會隨著日後的產品迭代中進行修復。對於這類缺陷應當標註為 “延期”。在這裡要注意，並不是所有缺陷都需要立即進行修復。每個缺陷問題在嚴重程度，影響範圍均有不同，因此優先修復的等級也不同。我會在下一篇文章中單獨講解制定優先順序別的方法。
（ 7）等待測試
當開發團隊修復缺陷後，應將缺陷狀態標記為等待測試並由測試團隊進行測試。
（ 8）關閉
在測試透過後，缺陷狀態修改為 “關閉”或者完成。
（ 9）重新開啟
如果缺陷修復後並沒有透過測試，應標記為重新開啟，並重新啟用分配流程。