bug的處理流程(2)

　　嚴重

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

　　一般

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

　　輕微

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

　　建議

　　增加用戶使用體驗的建議性問題。(一般情況下，建議也為做為缺陷的一種。這個跟系統的類型與需求有關)

　　缺陷優先級(priority)

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

　　優先級的劃分：

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

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

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

　　一般地，嚴重程序高的軟件缺陷具有較高的優先級。嚴重程度高說明缺陷對軟件造成的危害性大，需要優先處理，而來嚴重程序低的缺陷可能只是軟件不太盡善盡美，可以稍后處理。

　　嚴重程度高優先級不一定高：

　　如果某個嚴重的軟件缺陷只在非常極端的條件下產生，則沒有必要馬上處理。

　　如果某一個軟件缺陷，需要重新修改軟件的整體架構，可能會產生更多的潛在缺陷，而且軟件由于市場的壓力必須盡快發布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。

　　嚴重程度優先級不一定低

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

　　缺陷狀態

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

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

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

　　處理 ： 問題在處理中，尚未完成。

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

　　回歸 ： 對已經修復的問題進行回歸確認。Reopened :

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

　　Bug處理流程

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

　　提交(打開)缺陷

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

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

　　如果是回歸不通過的缺陷，其狀態又會變為打開狀態。

　　分配(轉交)缺陷

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

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

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

　　確認缺陷

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

　　推遲處理

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

原文轉自：http://www.uml.org.cn/Test/201301232.asp