【分享】BUG從誕生到滅亡——處理BUG的流程

1、什麼是bug
軟件的BUG，一般是指軟件程序的漏洞或缺陷，廣義還包括測試工程師或用戶所發現和提出的軟件可改進的細節、或與需求文檔存在差別的功能實現等。

2、bug的生命週期
生命週期中的缺陷狀態：新建-->指派-->已解決-->待驗-->關閉
發現BUG -> 提交BUG -> 指派BUG -> 研發確認BUG -> 研發去修復BUG -> 迴歸驗測試BUG -> 是否經過測試 -> 關閉BUG

一、發現bug
1）按照測試用例進行操做，發現和測試用例的預期結果不一致的能夠稱爲bug。
2）成本問題，沒有充足的時間編寫測試用例，致使出現的bug。
3）測試用例是沒法窮盡的，或者誤操做出現的bug。

二、提交bug
在提交一個缺陷的缺陷，首先儘可能描述這個缺陷的屬性。Bug重現環境，bug類型，bug等級，bug的優先級以及詳細的重現步驟，結果與指望等。
固然，咱們在提交一個問題以前首先應該保證，這個缺陷是沒有被提過的，以避免形成重複缺陷單。

三、指派bug
這一步不是必須的，跟項目模式有關，有些公司測試部門與開發部門獨立，那麼測試人員就不肯定本身測試的模塊是由哪位開發人員負責的，在這種狀況下，測試人員統一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認後再次分配給相應的開發人員。
有些測試人員是穿插到不一樣研發團隊中的，因此對不一樣的開人發員負責的開發模塊很是清楚，這個時候就能夠將問題直接指派給相應的開發人員。
也有一種狀況，原本此問題應該由A開發人員負責，但因爲A開發人員的調離或辭職，些問題爲轉交給其它人員處理。「分配」強調是上級對下級；「轉交」強調的是平級之間。

四、確認缺陷
當開發人員接到一個缺陷時，首先是對其進行分析與重現，若是對其進行分析發現不是缺陷（可能因爲測試人員不瞭解需求）或沒法對此問題進行重現，那麼就須要將此問題反回給測試人員，並註明緣由。若是確認爲缺陷則須要對其進行處理。
五、修復BUG
推遲處理
在處理問題以後，還須要進行一次判斷，是否須要推遲處理，有些需求已經確認了是問題，因爲其可能在極端狀況下才會出現，或須要對系統架構進行改動，或其優先級很是低，因此暫時不須要對此問題進行處理（或到下個版本進再進行修復）。
固定
對於推遲處理的問題能夠暫時進行固定（「固定」爲QC中的叫法。）通常固定的問題須要通過項目經理與測試經理協商後才能固定。
處理缺陷
開發人員在確認完一個問題須要處理時，那麼就對其進行處理工做。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，固然，對於短期內能夠修復的問題就不必時時的去更新處理進度。）

六、迴歸驗證BUG
迴歸缺陷對於測試人員來講是很是重要的工做，其有三個入口兩個出口。
確認非缺陷問題：對於提交的一個缺陷，開人員處理爲非問題或沒法重現，而後直接轉交給測試人員迴歸。測試人員再次確認，若是真如開發人員所說，則將問題關閉。若是非開發人員所說，是因爲問題描述模糊或其它緣由喂重現問題，則再次註明緣由轉給開發人員。
確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不經過，將問題再次打開並轉給開發人員。
確認固定問題：有計劃的對固定問題進行確認，有些固定問題隨着時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對於這類問題應該及時打開交給開發人員處理。

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

3、使用工具
合適的工具能夠有效縮短BUG處理流程，提升工做效率。我使用的是Eolinker接口管理系統，是個國產Saas工具，測試功能和權限管理分配功能都比較完善，對咱們開發團隊幫助也挺大的。
使用地址：www.eolinker.com