軟體測試 BUG的生命週期

測試人員最本質的工作就是尋找bug，提交bug、驗證bug、推進bug的解決，直至軟體達到發布的標準，提高軟體的質量，及研發的工作效率和質量。

軟體的bug,狹義概念是指軟體程式的漏洞或缺陷，廣義概念除此之外還包括測試工程師或使用者所發現和提出的軟體可改進的細節、或與需求文件存在差異的功能實現等。

生命週期中缺陷狀態：新建–>指派–>已解決–>待驗–>關閉

發現bug–>提交bug–>指派bug–>研發確認bug–>研發去修復bug–>回歸驗證bug–>是否通過驗證–>關閉bug

1、發現bug

1）按照測試用例進行操作，發現和測試用例的預期結果不一致的,都可以被稱之為bug。

2）測試用例不可能窮盡，總有超出你預料之外的因素,或者是神操作出現的bug。

3）成本問題，沒有充足的時間編寫測試用例，發現的bug

2、提交bug

在提交乙個缺陷的缺陷，首先盡量描述這個缺陷的屬性。bug重現環境，bug型別，bug等級，bug的優先順序以及詳細的重現步驟，結果與期望等。

當然，我們在提交乙個問題之前首先應該保證，這個缺陷是沒有被提過的，以免造成重複缺陷單。

3、指派bug

這一步不是必須的，跟專案模式有關，有些公司測試部門與開發部門獨立，那麼測試人員就不確定自己測試的模組是由哪位開發人員負責的，在這種情況下，測試人員統一把問題指派給專案組長或經理，由專案組長（或經理）對問題進行確認後再次分配給相應的開發人員。

有些測試人員是穿插到不同研發團隊中的，所以對不同的開人發員負責的開發模組非常清楚，這個時候就可以將問題直接指派給相應的開發人員。

也有一種情況，本來此問題應該由a開發人員負責，但由於a開發人員的調離或辭職，些問題為轉交給其它人員處理。「分配」強調是上級對下級；「轉交」強調的是平級之間。

4、確認缺陷

當開發人員接到乙個缺陷時，首先是對其進行分析與重現，如果對其進行分析發現不是缺陷（可能由於測試人員不了解需求）或無法對此問題進行重現，那麼就需要將此問題反回給測試人員，並註明原因。如果確認為缺陷則需要對其進行處理。

5、修復bug

推遲處理

在處理問題之後，還需要進行一次判斷，是否需要推遲處理，有些需求已經確認了是問題，由於其可能在極端情況下才會出現，或需要對系統架構進行改動，或其優先順序非常低，所以暫時不需要對此問題進行處理（或到下個版本進再進行修復）。

固定對於推遲處理的問題可以暫時進行固定（「固定」為qc中的叫法。）一般固定的問題需要經過專案經理與測試經理協商後才能固定。

處理缺陷

開發人員在確認完乙個問題需要處理時，那麼就對其進行處理工作。（例如，redmine 是支援處理人時時更新問題處理進度的，如已處理30% ，已處理80% 等，當然，對於短時間內可以修復的問題就沒必要時時的去更新處理進度。）

6、回歸驗證bug

回歸缺陷對於測試人員來說是非常重要的工作，其有三個入口兩個出口。

確認非缺陷問題：對於提交的乙個缺陷，開人員處理為非問題或無法重現，然後直接轉交給測試人員回歸。測試人員再次確認，如果真如開發人員所說，則將問題關閉。如果非開發人員所說，是由於問題描述模糊或其它原因喂重現問題，則再次註明原因轉給開發人員。

確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次開啟並轉給開發人員。

確認固定問題：有計畫的對固定問題進行確認，有些固定問題隨著時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對於這類問題應該及時開啟交給開發人員處理。

7、關閉缺陷

對於已經修復的缺陷進行關閉，這也是乙個缺陷的最後乙個狀態。

在做介面測試的時候可以使用國產的介面測試和介面文件生成工具apipost