摘要

　　本文首先介绍了Bug管理的常规过程，接着分析了应用于开源软件开发过程的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问题介绍

　　在软件开发与维护过程中，有效地进行质量控制与保证工作尤为重要。正因如此，软件缺陷跟踪与管理在现代软件过程中成为实施质量控制与保证的重要方面。软件中的缺陷(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]]。实际中，缺陷跟踪系统有必要提供适当的接口给用户。