开源软件Bug跟踪与管理探讨

2010-05-11 作者：WolfFlower 来源：WolfFlower的blog

摘要

本文首先介绍了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]]。实际中，缺陷跟踪系统有必要提供适当的接口给用户。

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

致谢

在研究过程中，我们小组成员进行了很好的沟通和交流，在某些问题上相互交换了意见，形成了良好的团队氛围。同时感谢*老师给予的指导和帮助。

参考资料

--------------------------------------------------------------------------------

[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 实施缺陷跟踪的成功实践>>. 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.

注:引用本文请注明相关观点来源