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的运行将更加有效，对于开源软件的进步也许会发挥重要作用。