bug的處理流程

標籤：管理   qpi   使用者   分類   影響   nbsp   互連網   使用   for   

又屬於一篇普及文，希望自己在被各種技術吸引的同時，能時常來整理和總結軟體測試最基本的知識。

　　從剛工作時接觸的第一個缺陷管理工具禪道，到redmine、JIRA、bugzilla ，再到現在的QC，當然還有其它種的開源的或商業的缺陷管理工具，它們的本質是一樣的，就是來管理缺陷的生命週期。

　　其實，你理解任意的一款工具，其它的工具也一定能無師自通。這不談某款工具，單把它本質的一些東西抽離出來與大家分享。

 

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 的嚴重程度和優先順序是含義不同但相互聯絡密切的兩個概念，它們從不同的側面描述了軟體缺陷對軟體品質和終端使用者的影響程式和處理方式。

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

嚴重程度高優先順序不一定高：

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

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

嚴重程度優先順序不一定低

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

 

 

缺陷狀態

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

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

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

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

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

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

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

 

 

Bug處理流程

 

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

 

提交（開啟）缺陷

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

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

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

 

 

分配（轉交）缺陷

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

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

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

 

確認缺陷

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

 

延遲處理

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

 

固定

　　對於延遲處理的問題可以暫時進行固定（“固定”為QC中的叫法。）一般固定的問題需要經過專案經理與測試經理協商後才能固定。

 

處理缺陷

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

 

迴歸缺陷

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

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

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

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

 

關閉缺陷

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

 

 

 

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

　　如果小A讓我給他做一個網站呢？對於我來說，小A是我的客戶，這個網站對我來說就是一個項目，對於小A來說，他的網站是面向福士使用者的，那麼對於小A來說，網站就是自己的產品。

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

 

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

 

喜歡的請關注！一起分享、成長！

 

bug的處理流程