軟件缺陷(bug)的處理流程(2)

　　嚴重程度優先級不一定低

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

　　缺陷狀態

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

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

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

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

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

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

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

　　Bug處理流程

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

　　提交(打開)缺陷

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

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

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

　　分配(轉交)缺陷

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

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

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

　　確認缺陷

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

　　推遲處理

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

　　固定

　　對于推遲處理的問題可以暫時進行固定(“固定”為QC中的叫法。)一般固定的問題需要經過項目經理與測試經理協商后才能固定。

　　處理缺陷

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

　　回歸缺陷

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

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

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

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

　　關閉缺陷

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

　　注1： 文中提到了產品與項目，好多人分不清項目與產品，各自有各自的理解。我個人從用戶群上來劃分。如果面向的是特定客戶的需求，那么稱其為項目，如某醫院的醫療系統，某公司的管理系統。面向大眾用戶且長期運營的需求，稱為產品，如，某網站，某網絡游戲。

　　如果小A讓我給他做一個網站呢?對于我來說，小A是我的客戶，這個網站對我來說就是一個項目，對于小A來說，他的網站是面向大眾用戶的，那么對于小A來說，網站就是自己的產品。

　　富士康帶工蘋果手機是一樣的道理，富士康接到蘋果的訂單，那么對富士康來說是個項目，完成項目，拿到錢就算項目結束。蘋果手機對蘋果公司來說是一個產品，它長期持有這個產品的所有權，并且不段的更新自己的產品。

　　注2： 本文中用到了 bug、缺陷、問題等三個詞語，用詞比較模糊，本文中表示為一個事物。

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