一、Bug的屬性
1、Bug重現環(huán)境
操作系統(tǒng)
這個是一般軟件運行的一大前提，基本上所有的軟件都依賴于操作系統(tǒng)之上的，對于一個軟件來說，要想在某個操作系統(tǒng)上運行，必須要對這個操作系統(tǒng)支持，這就需要有真對性的設計與開發(fā)。對于不同的操作系統(tǒng)，其可能存在差異（如：win xp 與 win 7）或本質的區(qū)別（如 win 7 與 CentOS linux ），所以，操作系統(tǒng)環(huán)境是重現問題的一個重要前提。
瀏覽器
對于B/S系統(tǒng)，或面向大眾的互聯網產品（網站，郵箱
等），瀏覽器的兼容性也是必須測試的一個重點，對于現
在的瀏覽器市場，各式的瀏覽器都有其用戶群，要想使產
品大眾化，必須考慮這些產品的兼容性問題。
不同的瀏覽器之間（IE、 firefox、chrome、opera
等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都
可能存在兼容性問題，所以，對于這類應用，瀏覽器環(huán)境
重現bug前提條件之一。
其它（這個“其它”非常重要）
對于不同的系統(tǒng)發(fā)現重現問題，都會有其特定的前
提，拿我測試的郵箱來說，必須要描述其是在測試線還是
現網環(huán)境，而且還要附帶一重現問題的帳號等。
2、Bug 類型
這里縮小范圍，單指我們測試人員在測試過程中發(fā)現的缺
陷，發(fā)現產品缺陷其實就是測試人員工作的主要目的。當
然，你要確定一個問題的類型，也需要對項目（或產品）
有比較深的理解。是代碼缺陷還是設計缺陷有時候就不太
容易區(qū)分，當然，這個劃分，對于開發(fā)定位問題影響很
小，但對于問題類型的統(tǒng)計就比較重要了。
下面看一些常見的分類：
劃分方式一：
代碼錯誤
設計缺陷
界面優(yōu)化
配置相關
安裝部署
性能問題
標準規(guī)范
測試代碼
其它
劃分方式二：
功能類（function）
性能類（performance）
界面類（UI）
易用性類（usability）
兼容性類（compatibility）
其它（else）
這個分類當然是可以自定義的，具我接觸的缺陷管理
都是可以自定義的，既然是對問題的管理，那么你當然可
以拿來做特定環(huán)境下的系統(tǒng)來使用，或我就想用這個系統(tǒng)
來指派任務，那么我的自定義類型為前端任務、后端任
務、測試任務、配置部署...
3、缺陷等級
缺陷等級，這個劃分也比較靈活，有分三級或四級，
也有分五級的。
致命
一招斃命的缺陷，使你的系統(tǒng)無法運行，有造成數據
泄漏的安全性問題。
嚴重
可以引起易于糾正的異常情況、可能引起易于修復的
故障或對產品外觀難以接受的缺陷。
一般
指不影響產品的運轉和運行、不會成為故障起因，但
對產品外觀和下道工序影響較大的缺陷
輕微
輕微缺陷是指對產品外觀和下道工序可能會有輕微影
響的缺陷
建議
增加用戶使用體驗的建議性問題。（一般情況下，建
議也為做為缺陷的一種。這個跟系統(tǒng)的類型與需求有關）
4、缺陷優(yōu)先級（priority）
當問題處理人員在面對許多問題需要處理進，就需要
問題進行優(yōu)先級排序。我們做事情的安排，操作系統(tǒng)有處
理進程等都在使用著優(yōu)先級。
優(yōu)先級的劃分：
低——>中——>高——>緊急
延遲處理——>正常排隊——>優(yōu)先處理——>緊急處理
Bug 的嚴重程度和優(yōu)先級是含義不同但相互聯系密切
的兩個概念，它們從不同的側面描述了軟件缺陷對軟件質
量和最終用戶的影響程序和處理方式。
一般地，嚴重程序高的軟件缺陷具有較高的優(yōu)先級。
嚴重程度高說明缺陷對軟件造成的危害性大，需要優(yōu)先處
理，而來嚴重程序低的缺陷可能只是軟件不太盡善盡美，
可以稍后處理。
嚴重程度高優(yōu)先級不一定高：
如果某個嚴重的軟件缺陷只在非常極端的條件下產
生，則沒有必要馬上處理。
如果某一個軟件缺陷，需要重新修改軟件的整體架
構，可能會產生更多的潛在缺陷，而且軟件由于市場的壓
力必須盡快發(fā)布，此時即使缺陷的嚴重性很高，是否需要
修正，需要全盤考慮。
嚴重程度優(yōu)先級不一定低:
如果是軟件名稱或公司名稱的拼寫錯誤，雖然說其屬
于界面錯誤，嚴重程度不高，但其關系到軟件和公司的市
場開解，必須盡快修正。
5、缺陷狀態(tài)
對于一個問題，其處理過程是一個周期，周期的不同
階段，其所處的狀態(tài)也是不一樣的。不同狀態(tài)所對應的處
理人也是不一樣的。
**打開 ： **表示問題被提交等待有人處理。
重新指派 ： 問題被重新指派給某人處理。
處理 ： 問題在處理中，尚未完成。
固定 ： 確認此問題存在，但暫時不進行處理。
回歸 ： 對已經修復的問題進行回歸確認。Reopened :
關閉 ： 問題的最后一個狀態(tài)。
二、Bug處理流程
下面通過一個比較完整的bug的處理流程圖，更深刻的
理解bug的狀態(tài)以一個bug的生命周期。
Bug處理流程圖
提交（打開）缺陷
在提交一個缺陷的缺陷，首先盡量描述這個缺陷的屬
性。Bug重現環(huán)境，bug類型，bug等級，bug的優(yōu)先級以及
詳細的重現步驟，結果與期望等。
當然，我們在提交一個問題之前首先應該保證，這個
缺陷是沒有被提過的，以免造成重復缺陷單。
如果是回歸不通過的缺陷，其狀態(tài)又會變?yōu)榇蜷_狀
態(tài)。
分配（轉交）缺陷
這一步不是必須的，跟項目模式有關，有些公司測試
部門與開發(fā)部門獨立，那么測試人員就不確定自己測試的
模塊是由哪位開發(fā)人員負責的，在這種情況下，測試人員
統(tǒng)一把問題指派給項目組長或經理，由項目組長（或經
理）對問題進行確認后再次分配給相應的開發(fā)人員。
有些測試人員是穿插到不同研發(fā)團隊中的，所以對不
同的開人發(fā)員負責的開發(fā)模塊非常清楚，這個時候就可以
將問題直接指派給相應的開發(fā)人員。
也有一種情況，本來此問題應該由A開發(fā)人員負責，但
由于A開發(fā)人員的調離或辭職，些問題為轉交給其它人員處
理?！胺峙洹睆娬{是上級對下級；“轉交”強調的是平級之
間。
確認缺陷
當開發(fā)人員接到一個缺陷時，首先是對其進行分析與
重現，如果對其進行分析發(fā)現不是缺陷（可能由于測試人
員不了解需求）或無法對此問題進行重現，那么就需要將
此問題反回給測試人員，并注明原因。如果確認為缺陷則
需要對其進行處理。
推遲處理
在處理問題之后，還需要進行一次判斷，是否需要推
遲處理，有些需求已經確認了是問題，由于其可能在極端
情況下才會出現，或需要對系統(tǒng)架構進行改動，或其優(yōu)先
級非常低，所以暫時不需要對此問題進行處理（或到下個
版本進再進行修復）。
固定
對于推遲處理的問題可以暫時進行固定（“固定”為QC
中的叫法。）一般固定的問題需要經過項目經理與測試經
理協(xié)商后才能固定。
處理缺陷
開發(fā)人員在確認完一個問題需要處理時，那么就對其
進行處理工作。（例如，redmine 是支持處理人時時更新
問題處理進度的，如 已處理30% ，已處理80% 等，當
然，對于短時間內可以修復的問題就沒必要時時的去更新
處理進度。）
回歸缺陷
回歸缺陷對于測試人員來說是非常重要的工作，其有
三個入口兩個出口。
確認非缺陷問題：對于提交的一個缺陷，開人員處理
為非問題或無法重現，然后直接轉交給測試人員回歸。測
試人員再次確認，如果真如開發(fā)人員所說，則將問題關
閉。如果非開發(fā)人員所說，是由于問題描述模糊或其它原
因喂重現問題，則再次注明原因轉給開發(fā)人員。
確認修復問題：對開發(fā)人員修復的問題再次進行確
認，確認能過，則關閉問題。確認不通過，將問題再次打
開并轉給開發(fā)人員。
確認固定問題：有計劃的對固定問題進行確認，有些
固定問題隨著時間的推移，版本的更新或已經不存在了，
對這類問題應該及時關閉。有些固定問題依然存在且變得
緊急，對于這類問題應該及時打開交給開發(fā)人員處理。
關閉缺陷
對于已經修復的缺陷進行關閉，這也是一個缺陷的最
后一個狀態(tài)。
