摘要
本文首先介紹了Bug管理的常規過程，接著分析了應用於開源軟體開發過程的Bug跟蹤與管理系統的特點，描述了一個典型的Bug生命週期過程，並對完成一個合格的Bug報告做出瞭解釋。文章還簡單介紹了比較流行的缺陷跟蹤與管理系統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問題介紹
在軟體開發與維護過程中，有效地進行品質控制與保證工作尤為重要。正因如此，軟體缺陷跟蹤與管理在現代軟體過程中成為實施品質控制與保證的重要方面。軟體中的缺陷（Defect或Bug）是軟體開發過程中的"副產品"。通常，缺陷會導致軟體產品在某種程度上不能滿足使用者的需要[[1]]。開源軟體組織宣稱，開源的目的是獲得更好的品質、更高的可靠性、更強的靈活性、低成本和對掠奪式賣主禁閉行為的終結[[2]]。如其所言，開源軟體自由和開放的精神迎來了一些擁護者。雖然如此，軟體缺陷始終存在，如何實施對開源軟體Bug的跟蹤與管理呢？它與商業軟體缺陷管理又有什麼區別呢？開源的人們又在使用哪些他們的Bug跟蹤系統呢？帶著疑問與不解，我開始了對開源軟體Bug跟蹤與管理的探討。
2 Bug跟蹤與開源軟體Bug管理
2.1缺陷管理一般過程
軟體不是完美無缺的，正常情況下，出現惹人厭煩的Bug不可能成為軟體工程師們的期待。缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了儘早發現軟體系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發現的缺陷都能夠及時得到處理是測試工作的一項重要內容[[3]]。沒有人希望自己的產品存在太多的缺陷，但既然存在缺陷，就應該跟蹤和管理它。在介紹開源軟體缺陷跟蹤與管理之前，我們有必要對一般的缺陷管理過程有一個系統的認識。
軟體存在的錯誤(Bug)一般是在測試過程中發現出來的，對於如何處理測試中發現的錯誤，將直接影響到測試的效果。對於測試中發現的Bug，需要有一個明確的管理流程。首先，測試人員提交新的Bug入庫，錯誤狀態為New；然後，進階測試人員驗證錯誤，如果確認是錯誤，分配給相應的開發人員，設定狀態為Open；如果不是錯誤，則拒絕，設定為Declined狀態；之後，開發人員查詢狀態為Open的Bug，如果不是錯誤，則置狀態為Declined；如果是Bug則修複共置狀態為Fixed。對於不能解決的Bug，要留下文字說明及保持Bug為Open狀態，但對於不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可。最後，測試人員查詢狀態為Fixed的Bug，然後驗證Bug是否已解決，如解決置Bug的狀態為Closed，如沒有解決置狀態為Reopen[[4]]。這個過程中，我們可以發現它對測試人員的要求較高,如對於那些可能不是錯誤的問題就不應該被當作Bug處理。
2.2開源軟體Bug管理
相對於常規的Bug管理流程，開源軟體的缺陷跟蹤與管理理所當然不能超越它。但是，正如我們所提到的，開源軟體的開發模式的特殊性對其Bug跟蹤與管理過程也提出了新的更嚴格的過程要求。在此，首先有必要對缺陷跟蹤系統(Bug Tracker)有一個比較正確的認識。缺陷包括產品錯誤，需求和設計變更，新特性或擴充功能（New Feature, Enhancement）等，它存在於整個軟體開發生命週期之中[[5]]。那麼，一個Bug Tracker 究竟要儲存哪些資訊呢？Bug跟蹤系統在軟體開發過程中也常常用來記載新的功能需求、任務日誌、補丁包等，只要是具有明確的開始和結束狀態的東西，它們以及在這個過程中的轉變以及產生的資訊都應當儲存到系統中。相比於商業軟體開發過程，在開源軟體開發過程中，一個Bug的典型生命週期是這樣的：問題報告者（可能對項目一無所知）總結出現的問題，給出恰當的初始描述，將這些資訊加以歸檔，然後提交到系統；其他使用者或測試者讀到Bug資訊，可能給出進一步的注釋，在此過程中可能會通過適當的方式要求歸檔者澄清一些問題；問題在其他使用者體驗過程中再次出現，多次的重現表明這個問題確實存在，這個過程其實是一個Bug生命期的重要階段，因為一個不真實的Bug可能在這個階段被關閉或刪除；問題或缺陷得到診斷，並且解決它需要付出的代價也有了估計，這個過程可能由開發成員完成，但也可能是熱情的使用者；問題解決時間有了初步規劃，可能在某一個但不一定是下一個版本中，問題會被解決；最後，問題得到解決，相關的更改應該被記錄下來後，應該關閉這個問題。
但是，上面的過程可能會中途停止。那麼，為什麼一個Bug會中途夭折呢？其實可以想到，Bug報告者可能對項目或軟體產品不熟悉，這樣他可能提交一個錯誤的問題報告。這樣，這個Bug可能很快被關掉。另一個變化因素是，同樣的問題在系統中已經有了記載，甚至可能被解決了。在這種情況下，這個冗餘的Bug會被刪除。當然，開發人員也許自以為是地認為，某個Bug根本不存在，或者開發人員簡單地改動一些地方後就認為Bug不再存在，於是他可能把實際上沒有解決的問題給關掉了[[6]]。
2.3Bug報告
支援人員被認為是一件可怕的工作，因為有拙劣的bug報告需要處理[[7]]。我們可以看到，當出現問題或缺陷後，系統可能得到許多使用者和測試者的報告，那麼，如何有效地實施Bug Tracker呢？
一個開源項目啟動後，Bug跟蹤系統也就開始運行，它一般運行於C/S或B/S架構的伺服器上。在用戶端，它提供一種或多種使用者介面，如Web表單、郵件等，有些缺陷跟蹤系統還提供一些提交工具，簡化了使用者操作。我們先關注針對用戶端的介面，比如，一個測試者想要報告一個Bug，他首先進入Bug報告介面，但更多的時候，系統總是提示測試者要注意的事項。實際上，在報告Bug前最重要的當然是發現Bug並試圖找出它的原因了。正如linux新手可能會被告知：盡量關注當前出現的問題並且試圖找出原因[[8]]。一個友好的Bug報告者不能是只知道抱怨，在報告中胡亂地描述著：彈出討厭的視窗。這樣的報告會產生歧義，那麼，如何提交一個合格的Bug報告呢？Elisabeth Hendrickson在他的一本著作中寫道：當你編寫bug報告時，記住你的聽眾，選擇一個好的標題，清楚的記錄步驟並解釋錯誤的影響；你的bug report將會因為你花在它上面的格外努力而更好，並且有更多的錯誤被修複；最終將達到我們期望的結果－使錯誤在傷害使用者之前得到修複[[9]]。著名的開源軟體品質控制與保證平台Mozilla規定了一個良好的Bug報告應該包含以下資訊：軟體版本序號、運行環境、錯誤現場資訊、調試與警告資訊等[[10]]。實際中，缺陷跟蹤系統有必要提供適當的介面給使用者。
Bug Tracker介紹
開源軟體領域，存在的Bug Tracker很多，比較有名的有BugZilla、GNATS、Buggit、Mantis、DBTS等。這些缺陷跟蹤與管理系統為開源軟體管理提供了一個良好的控制手段。軟體開發需要Bug Tracker的存在，開源軟體的開發更加離不開它們。曾就職於微軟公司的開源Bug Tracker BugFree發起者劉振飛先生說過：在（微軟）所有的工具中，我最佩服的就是其Bug管理系統Raid（現在叫Product Studio）；Raid的價值在於它密切跟蹤當前產品的實際Bug狀態，使項目組中的成員非常有效協調他們的工作[[11]]。
同樣，開源軟體沒有合適的Bug管理軟體支撐，恐怕也很難開發出優秀的產品。下面我們可以瞭解這個領域一些主流的系統，Mozilla公司提供的Buzilla是一個產品缺陷的記錄及跟蹤工具，它能夠為你建立一個完善的Bug跟蹤體系，包括報告Bug、查詢Bug記錄併產生報表、處理解決、管理員系統初始化和設定四個部分。它具有如下特點：基於Web方式，安裝簡單、運行方便快捷、管理安全；有利於缺陷的清楚傳達；系統靈活，強大的可配置能力；支援自動發送Email[[12]。相比之下，Mantis則是PHP/MySQL/Web-based缺陷跟蹤系統，它具有個人可定製的Email通知功能、支援多項目、多語言等優點[[13]]。另外，線上Bug跟蹤與管理系統如TrackStudio、Bugols提供了優秀的使用者介面。特別地，Bugols在它的首頁上宣言它們的理想是讓每個程式員都能輕輕鬆鬆地發布和維護自己的程式，它們的使命是通過精湛的技術構建全球最方便、最易用、最人性化的線上Bug管理工具[[14]]。]
然而，大多缺陷跟蹤系統似乎過多地關注如何進行Bug的管理，卻忽略了與自動化品質評估工具的有效結合。另一方面，許多研究者嘗試運用開源項目的原始碼和測試資料的易得性來設計新的項目品質評估工具[[15]]。也許他們可以在Bug跟蹤與管理系統的設計上下更多的工夫。
4結論
本文在系統介紹了Bug跟蹤與管理的知識後，特別針對開源軟體的跟蹤與缺陷管理展開了分析。研究中發現，如何提交一個友好的Bug報告到Bug Tracker對於及時、有效、正確地解決問題非常重要。然而，大多基於Web的Bug Tracker在用戶端提供了詳細的空白Bug清單供使用者填寫，雖然這樣的做法為系統有效接受和處理Bug帶來的方便，
卻忽略了豐富而繁雜的表單是否超過了Bug提交者所能承受的極限。當然，這些系統採取了一些下拉式清單選擇項，但是過多的使用者必須操作勢必不讓人滿意。另外，這些系統的介面也顯得不夠漂亮，試想一個非專業人士來報告一個Bug時，不夠友好的介面也許會使他放棄報告一個可能致命的Bug。解決的辦法是，在必須資訊和附加資訊之間選擇一個平衡點，同時提供一個清潔的介面。另外一個問題是，多數Bug Tracker都會拒絕重複提交的Bug；可是，Bug的類型、報告時間與報告頻率都是重要的評估參數[[16]]。這樣，如果系統一味地拒絕提交重複的Bug，恐怕統計一個Bug的出現頻率也會是一個難題。
實際中發現，多數Bug Tracker具有過濾Bug報告的功能，以抵制重複提交的報告或已存在的問題報告，有些系統還能夠完全接受E-mail提交的報告或者與郵件清單可以協調工作；但是，過濾機制實際上是一個需要技巧與優秀演算法的東西。試想一個問題提交者提交了一個報告主題與報告中問題描述不一致的問題報告，結果會怎樣呢？可能這會是一個重要的報告，只是報告者一時疏忽才犯了錯誤，但系統卻將它當作一個已有的簡單的錯誤而拒絕了它。問題就出在這，項目的下一個版本可能因為那個Bug而失敗，後果也許非常嚴重。其實，這裡想要指出的問題是，如何有效而準確地過濾Bug報告？其實這裡牽涉到一些搜尋和匹配技術，系統不但要檢查Bug主題，還要檢查它的內部資訊。如何高效實現它呢？這是一讓人困惑而又親近的話題。也許我們可以期待機器學習理論和應用的進步，當系統具有相當智能的時候，也許可以快速地撲捉到可能的Bug，並自動修改可能的錯誤，使一個Bug報告是完備的、一致的、準確的。那樣的話一個Bug Tracker的運行將更加有效，對於開源軟體的進步也許會發揮重要作用。
致謝
在研究過程中，我們小組成員進行了很好的溝通和交流，在某些問題上相互交換了意見，形成了良好的團隊氛圍。同時感謝*老師給予的指導和協助。
參考資料
[1] 劉寅. <<軟體缺陷管理>>.希賽網, 2005.
[[2]] http://www.opensource.org/
[[3]] 關河. <<也談缺陷跟蹤管理>>. On http://www.testage.net/TestTech/BugM/200601/120.htm . 2006.
[[4]] 崔啟亮. <<Bug管理的一般流程>>. http://www.51testing.com/html/34/1275.html, 2006.
[[5]] 蔡琰. <<使用開源軟體 Mantis 實施缺陷跟蹤的成功實踐>>.perworks/cn/linux/software_engineering/l-mantis/index.html">http://www-128.ibm.com/developerworks/cn/linux/software_engineering/l-mantis/index.html , 2003.
[[6]] Karl Fogel. Producing Open Source Software : Bug Tracker.O’Reilly,2005.
[[7]]http://www.cndw.com/tech/php/2006041847238.asp
[[8]] Found Bug . On http://kernelnewbies.org/FoundBug
[[9]] Elisabeth Hendrickso著, 譯. 《Writing Effective Bug Reports》.On http://www.51testing.com/html/34/67.html , 2005.
[[10]] ChrisYeh. how to write a good bug report.http://www.mozilla.org/bugs/bug-reporting.html
[[11]] 劉振飛. Bug管理的經驗和實踐.On http://bugfree.newsky.cn/zhenfei/Document/BugFree.htm .
[[12]] 徐異婕. 測試跟蹤工具Bugzilla介紹.
On http://www.csai.cn.
[[13]] 同[5].
[[14]] Bugols. On http://www.bugols.com.
[[15]] Georgios Gousios,Vassilios Karakoidas, Konstantinos Stroggylos, Panagiotis Louridas, Vasileios Vlachos, and Diomidis Spinellis. Software Quality Assessment of Open Source Software. New Technologies Publications, 2007.
[[16]] Adriaan de Groot1, Sebastian K¨ugler1, Paul J. Adams2, and Giorgos Gousios3. Call for Quality:Open Source Software Quality Observation. The Second International Conference on Open Source Systems, 2006. 注:引用本文請註明相關觀點來源
