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

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

　　從剛工作時接觸的第一個缺陷管理工具禪道，到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 的嚴重程度和優先級是含義不同但相互聯系密切的兩個概念，它們從不同的側面描述了軟件缺陷對軟件質量和最終用戶的影響程序和處理方式。

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

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

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

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

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