摘要

　　本文首先介紹了Bug管理的常規(guī)過程，接著分析了應用于開源軟件開發(fā)過程的Bug跟蹤與管理系統的特點，描述了一個典型的Bug生命周期過程，并對完成一個合格的Bug報告做出了解釋。文章還簡單介紹了比較流行的缺陷跟蹤與管理系統bugglgj/bugzilla/' target='_blank'>Bugzilla等，并給出了個人的想法。

　　關鍵詞：Bug管理，生命周期，缺陷跟蹤與管理系統

　　Abstract-This paper introduces a normal bug management process， analyzes characteristics of bug tracking and management in development of open source software， describes a classic bug life cycle， and explains how to accomplish an eligible bug report. Also， some popular bug tracking and management systems such as Bugzilla are introduced， following with some personal thoughts.

　　Key Words: Bug management， life cycle， bug tracking and management system

　　1問題介紹

　　在軟件開發(fā)與維護過程中，有效地進行質量控制與保證工作尤為重要。正因如此，軟件缺陷跟蹤與管理在現代軟件過程中成為實施質量控制與保證的重要方面。軟件中的缺陷(Defect或Bug)是軟件開發(fā)過程中的"副產品"。通常，缺陷會導致軟件產品在某種程度上不能滿足用戶的需要[[1]]。開源軟件組織宣稱，開源的目的是獲得更好的質量、更高的可靠性、更強的靈活性、低成本和對掠奪式賣主禁閉行為的終結[[2]]。如其所言，開源軟件自由和開放的精神迎來了一些擁護者。雖然如此，軟件缺陷始終存在，如何實施對開源軟件Bug的跟蹤與管理呢?它與商業(yè)軟件缺陷管理又有什么區(qū)別呢?開源的人們又在使用哪些他們的Bug跟蹤系統呢?帶著疑問與不解，我開始了對開源軟件Bug跟蹤與管理的探討。

　　2 Bug跟蹤與開源軟件Bug管理

　　2.1缺陷管理一般過程

　　軟件不是完美無缺的，正常情況下，出現惹人厭煩的Bug不可能成為軟件工程師們的期待。缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發(fā)現軟件系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發(fā)現的缺陷都能夠及時得到處理是測試工作的一項重要內容[[3]]。沒有人希望自己的產品存在太多的缺陷，但既然存在缺陷，應該跟蹤和管理它。在介紹開源軟件缺陷跟蹤與管理之前，我們有必要對一般的缺陷管理過程有一個系統的認識。

　　軟件存在的錯誤(Bug)一般是在測試過程中發(fā)現出來的，對于如何處理測試中發(fā)現的錯誤，將直接影響到測試的效果。對于測試中發(fā)現的Bug，需要有一個明確的管理流程。首先，測試人員提交新的Bug入庫，錯誤狀態(tài)為New;然后，高級測試人員驗證錯誤，如果確認是錯誤，分配給相應的開發(fā)人員，設置狀態(tài)為Open;如果不是錯誤，則拒絕，設置為Declined狀態(tài);之后，開發(fā)人員查詢狀態(tài)為Open的Bug，如果不是錯誤，則置狀態(tài)為Declined;如果是Bug則修復并置狀態(tài)為Fixed。對于不能解決的Bug，要留下文字說明及保持Bug為Open狀態(tài)，但對于不能解決和延期解決的Bug，不能由開發(fā)人員自己決定，一般要通過某種會議(評審會)通過才能認可。后，測試人員查詢狀態(tài)為Fixed的Bug，然后驗證Bug是否已解決，如解決置Bug的狀態(tài)為Closed，如沒有解決置狀態(tài)為Reopen[[4]]。這個過程中，我們可以發(fā)現它對測試人員的要求較高，如對于那些可能不是錯誤的問題不應該被當作Bug處理。

　　2.2開源軟件Bug管理

　　相對于常規(guī)的Bug管理流程，開源軟件的缺陷跟蹤與管理理所當然不能超越它。但是，正如我們所提到的，開源軟件的開發(fā)模式的特殊性對其Bug跟蹤與管理過程也提出了新的更嚴格的過程要求。在此，首先有必要對缺陷跟蹤系統(Bug Tracker)有一個比較正確的認識。缺陷包括產品錯誤，需求和設計變更，新特性或擴展功能(New Feature， Enhancement)等，它存在于整個軟件開發(fā)生命周期之中[[5]]。那么，一個Bug Tracker 究竟要保存哪些信息呢?Bug跟蹤系統在軟件開發(fā)過程中也常常用來記載新的功能需求、任務日志、補丁包等，只要是具有明確的開始和結束狀態(tài)的東西，它們以及在這個過程中的轉變以及產生的信息都應當存儲到系統中。相比于商業(yè)軟件開發(fā)過程，在開源軟件開發(fā)過程中，一個Bug的典型生命周期是這樣的：問題報告者(可能對項目一無所知)總結出現的問題，給出恰當的初始描述，將這些信息加以歸檔，然后提交到系統;其他用戶或測試者讀到Bug信息，可能給出進一步的注釋，在此過程中可能會通過適當的方式要求歸檔者澄清一些問題;問題在其他用戶體驗過程中再次出現，多次的重現表明這個問題確實存在，這個過程其實是一個Bug生命期的重要階段，因為一個不真實的Bug可能在這個階段被關閉或刪除;問題或缺陷得到診斷，并且解決它需要付出的代價也有了估計，這個過程可能由開發(fā)成員完成，但也可能是熱情的用戶;問題解決時間有了初步規(guī)劃，可能在某一個但不一定是下一個版本中，問題會被解決;后，問題得到解決，相關的更改應該被記錄下來后，應該關閉這個問題。

　　但是，上面的過程可能會中途停止。那么，為什么一個Bug會中途夭折呢?其實可以想到，Bug報告者可能對項目或軟件產品不熟悉，這樣他可能提交一個錯誤的問題報告。這樣，這個Bug可能很快被關掉。另一個變化因素是，同樣的問題在系統中已經有了記載，甚至可能被解決了。在這種情況下，這個冗余的Bug會被刪除。當然，開發(fā)者也許自以為是地認為，某個Bug根本不存在，或者開發(fā)者簡單地改動一些地方后認為Bug不再存在，于是他可能把實際上沒有解決的問題給關掉了[[6]]。

　　2.3Bug報告

　　技術支持被認為是一件可怕的工作，因為有拙劣的bug報告需要處理[[7]]。我們可以看到，當出現問題或缺陷后，系統可能得到許多用戶和測試者的報告，那么，如何有效地實施Bug Tracker呢?

　　一個開源項目啟動后，Bug跟蹤系統也開始運行，它一般運行于C/S或B/S架構的服務器上。在客戶端，它提供一種或多種用戶接口，如Web表單、郵件等，有些缺陷跟蹤系統還提供一些提交工具，簡化了用戶操作。我們先關注針對客戶端的接口，比如，一個測試者想要報告一個Bug，他首先進入Bug報告界面，但更多的時候，系統總是提示測試者要注意的事項。實際上，在報告Bug前重要的當然是發(fā)現Bug并試圖找出它的原因了。正如linux新手可能會被告知：盡量關注當前出現的問題并且試圖找出原因[[8]]。一個友好的Bug報告者不能是只知道抱怨，在報告中胡亂地描述著：彈出討厭的窗口。這樣的報告會產生歧義，那么，如何提交一個合格的Bug報告呢?Elisabeth Hendrickson在他的一本著作中寫道：當你編寫bug報告時，記住你的聽眾，選擇一個好的標題，清楚的記錄步驟并解釋錯誤的影響;你的bug report將會因為你花在它上面的格外努力而更好，并且有更多的錯誤被修復;終將達到我們期望的結果-使錯誤在傷害用戶之前得到修復[[9]]。的開源軟件質量控制與保證平臺Mozilla規(guī)定了一個良好的Bug報告應該包含以下信息：軟件版本序列號、運行環(huán)境、錯誤現場信息、調試與警告信息等[[10]]。實際中，缺陷跟蹤系統有必要提供適當的接口給用戶。