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

1

什麼是Bug?

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

2

缺陷是什麼?

缺陷的英文：Defect，缺陷是指不符合最初定義的業務需求，其覆蓋範圍高於

3

缺陷報告應該包括的資訊

當向開發人員反饋缺陷時，您的缺陷報告應該包含以下資訊：
缺陷ID：缺陷的唯一標識號。
缺陷描述：詳細描述缺陷，包括髮現缺陷的模組的資訊。
軟體版本：發現缺陷的軟體程式的版本號。
復現步驟：詳細的步驟，以及開發人員可以復現缺陷的螢幕截圖。
缺陷提交日期：

4

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

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

5

缺陷管理的流程

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