一個bug的生命週期 ------做者 蟲師

Bug的屬性

---

Bug重現環境

這個應該是咱們重現bug的一個前提，若是沒有這個前提，咱們可能會沒法重現問題，或者跟本就無從下手。

• 操做系統

這個是通常軟件運行的一大前提，基本上全部的軟件都依賴於操做系統之上的，對於一個軟件來講，要想在某個操做系統上運行，必需要對這個操做系統支持，這就須要有真對性的設計與開發。對於不一樣的操做系統，其可能存在差別（如：win xp 與 win 7）或本質的區別（如 win 7 與 CentOS linux ），因此，操做系統環境是重現問題的一個重要前提。

• 瀏覽器

對於B/S系統，或面向大衆的互聯網產品（網站，郵箱等），瀏覽器的兼容性也是必須測試的一個重點，對於如今的瀏覽器市場，各式的瀏覽器都有其用戶羣，要想使產品大衆化，必須考慮這些產品的兼容性問題。

不一樣的瀏覽器之間（IE、 firefox、chrome、opera 等），甚至同一系列不一樣版本（ie6/ie7/ie8/ie9等）均可能存在兼容性問題，因此，對於這類應用，瀏覽器環境重現bug前提條件之一。

• 其它（這個「其它」很是重要）

對於不一樣的系統發現重現問題，都會有其特定的前提，拿我測試的郵箱來講，必需要描述其是在測試線仍是現網環境，並且還要附帶一重現問題的賬號等。

對於c/s軟件，可能還要考慮與其它經常使用軟的兼容等，例如，是在安裝的某款軟件後，對本軟件的安裝和使用形成影響。這些都是重現問題的必須描述的環境。

問題類型

根據JIRA的管理系統的劃分，bug 只是問題的一種，它能夠用於跟蹤多種不一樣類型的問題（其實，他只是將bug作爲一子類而已）。

JIRA系統缺省提供的問題類型（大部分的系統均可以自定義類型的，這樣就增長了靈活性。）

• Bug : 測試過程、維護過程發現影響系統運行的缺陷。（這就是通常測試人員所提交的bug）

• New Feature : 對系統提出的新功能。（單個的小需求能夠，若是大的話，就至關於一個需求，放到這裏是不合理的。）

• Task : 須要完成的一任務。（開發或測試任務指派。）

• Improvement : 對現有系統功能的改進。（通常產品經理或產品體驗師作的事）

固然，不一樣的公司，他們的人員定位與職責是不太相同的，按照上面的分類，JIRA就不是簡單的缺陷管理系統了，它涵蓋一項目（或產品）所須要處理的任務、需求與缺陷。

Bug 類型

這裏縮小範圍，單指咱們測試人員在測試過程當中發現的缺陷，發現產品缺陷其實就是測試人員工做的主要目的。固然，你要肯定一個問題的類型，也須要對項目（或產品）有比較深的理解。是代碼缺陷仍是設計缺陷有時候就不太容易區分，固然，這個劃分，對於開發定位問題影響很小，但對於問題類型的統計就比較重要了。

下面看一些常見的分類：

劃分方式一：

　　* 代碼錯誤

　　* 設計缺陷

　　* 界面優化

　　* 配置相關

　　* 安裝部署

    * 性能問題

　　* 標準規範

　　* 測試代碼

　　* 其它

劃分方式二：

　　* 功能類（function） 　　* 性能類（performance） 　　* 界面類（UI） 　　* 易用性類（usability） 　　* 兼容性類（compatibility） 　　* 其它（else） 

這個分類固然是能夠自定義的，具我接觸的缺陷管理都是能夠自定義的，既然是對問題的管理，那麼你固然能夠拿來作特定環境下的系統來使用，或我就想用這個系統來指派任務，那麼個人自定義類型爲前端任務、後端任務、測試任務、配置部署…

缺陷等級

缺陷等級，這個劃分也比較靈活，有分三級或四級，也有分五級的。

• 致命

一招斃命的缺陷，使你的系統沒法運行，有形成數據泄漏的安全性問題。

• 嚴重

能夠引發易於糾正的異常狀況、可能引發易於修復的故障或對產品外觀難以接受的缺陷。

• 通常

指不影響產品的運轉和運行、不會成爲故障原由，但對產品外觀和下道工序影響較大的缺陷

• 輕微

輕微缺陷是指對產品外觀和下道工序可能會有輕微影響的缺陷

• 建議

增長用戶使用體驗的建議性問題。（通常狀況下，建議也爲作爲缺陷的一種。這個跟系統的類型與需求有關）

缺陷優先級（priority）

當問題處理人員在面對許多問題須要處理進，就須要問題進行優先級排序。咱們作事情的安排，操做系統有處理進程等都在使用着優先級。

優先級的劃分：

低——>中——>高——>緊急

延遲處理——>正常排隊——>優先處理——>緊急處理

Bug的嚴重程度和優先級是含義不一樣但相互聯繫密切的兩個概念，它們從不一樣的側面描述了軟件缺陷對軟件質量和最終用戶的影響程序和處理方式。

通常地，嚴重程序高的軟件缺陷具備較高的優先級。嚴重程度高說明缺陷對軟件形成的危害性大，須要優先處理，而來嚴重程序低的缺陷可能只是軟件不太盡善盡美，能夠稍後處理。

• 嚴重程度高優先級不必定高：

若是某個嚴重的軟件缺陷只在很是極端的條件下產生，則沒有必要立刻處理。

若是某一個軟件缺陷，須要從新修改軟件的總體架構，可能會產生更多的潛在缺陷，並且軟件因爲市場的壓力必須儘快發佈，此時即便缺陷的嚴重性很高，是否須要修正，須要全盤考慮。

• 嚴重程度優先級不必定低

若是是軟件名稱或公司名稱的拼寫錯誤，雖說其屬於界面錯誤，嚴重程度不高，但其關係到軟件和公司的市場開解，必須儘快修正。

缺陷狀態

對於一個問題，其處理過程是一個週期，週期的不一樣階段，其所處的狀態也是不同的。不一樣狀態所對應的處理人也是不同的。

• 打開： 表示問題被提交等待有人處理。

• 從新指派 ： 問題被從新指派給某人處理。

• 處理 ： 問題在處理中，還沒有完成。

• 固定 ： 確認此問題存在，但暫時不進行處理。

• 迴歸 ： 對已經修復的問題進行迴歸確認。

• 關閉 ： 問題的最後一個狀態。

 

一個bug的生命週期

---

下面經過一個比較完整的bug的處理流程圖，更深入的理解bug的狀態以一個bug的生命週期。

提交（打開）缺陷

在提交一個缺陷的缺陷，首先儘可能描述這個缺陷的屬性。Bug重現環境，bug類型，bug等級，bug的優先級以及詳細的重現步驟，結果與指望等。

固然，咱們在提交一個問題以前首先應該保證，這個缺陷是沒有被提過的，以避免形成重複缺陷單。

若是是迴歸不經過的缺陷，其狀態又會變爲打開狀態。

分配（轉交）缺陷

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

有些測試人員是穿插到不一樣研發團隊中的，因此對不一樣的開人發員負責的開發模塊很是清楚，這個時候就能夠將問題直接指派給相應的開發人員。

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

確認缺陷

當開發人員接到一個缺陷時，首先是對其進行分析與重現，若是對其進行分析發現不是缺陷（可能因爲測試人員不瞭解需求）或沒法對此問題進行重現，那麼就須要將此問題反回給測試人員，並註明緣由。若是確認爲缺陷則須要對其進行處理。

推遲處理

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

固定

對於推遲處理的問題能夠暫時進行固定（「固定」爲QC中的叫法。）通常固定的問題須要通過項目經理與測試經理協商後才能固定。

處理缺陷

開發人員在確認完一個問題須要處理時，那麼就對其進行處理工做。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，固然，對於短期內能夠修復的問題就不必時時的去更新處理進度。）

迴歸缺陷

迴歸缺陷對於測試人員來講是很是重要的工做，其有三個入口兩個出口。

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

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

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

關閉缺陷

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

最後，「狀態」和「指派人」的對應關係若是更加細化，對項目而言是有益的：

已關閉--->指派給修復這個bug的開發工程師。 無需解決，不是bug--->指派給提交這個bug的測試人員。 無需解決，迭代待解決--->指派給項目的產品經理。