3典型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的運行將更加有效，對于開源軟件的進步也許會發揮重要作用。
