缺陷管理贯穿于整个软件开发生命周期中, 是不可缺少的环节，但在国内一些中小型开发商中没有得到足够得重视。本文结合实际应用，系统地介绍了缺陷跟踪开源软件 Buggit 和 Mantis, 以期抛砖引玉，引起重视。在您的项目中,是否有遇到过这样的问题：测试人员报的缺陷被遗忘掉；延期项目终于发布，却遭遇用户频频抱怨，管理人员将矛头指向测试人员；书写不规范的错误报告，使得开发人员不得不一次次找到测试人员来重现；地域分散的开发团队，通过email和文档交流，缺陷状态混乱，相关人员无法及时获得有关的变更信息…… 那么，让测试组织使用数据库来部署产品缺陷的记录和跟踪吧！对于中小软件开发组织，或许不太可能使用动则几千美金一个许可证的商业软件，但免费而又易于维护的软件完全可以满足您80%以上的需要。如果您的组织还陷于无穷无尽的混乱不堪的缺陷之中，不要犹豫，马上行动，免费软件可以很好地管理这个过程，但在实施中对管理上提出的要求则是您应该自我提高的。下面我们看看一个中小型开发组织两年多的实施过程，或许对您有些启发。

一、项目背景、组织架构

某公司在全球航运业信息化领先，在全球设有四个研发中心，主要为公司开发航运和物流软件，大多给公司内部和业务有关的客户使用，有些成熟的软件销售给同行或作为中立的平台提供给同行使用。该公司的上海的研发中心使用的是免费或开源的软件跟踪缺陷，有独立的测试小组，工作包括功能测试、压力测试、质量保证和过程改进，使用的是免费软件Buggit。 后来为了解决异地开发过程中的缺陷跟踪问题, 开始使用Mantis 0.17.5版本（开源软件，PHP/MySQL/Web Based），开始用一个实际的项目作试点，并根据项目组不同角色成员的反馈，测试组对系统进行配置和代码的修改加以提高；由于效果很不错，几个月后就推广到其他多个项目。

二、缺陷跟踪流程

缺陷包括产品错误，需求和设计变更，新特性或扩展功能（New Feature, Enhancement）等，它存在于整个软件开发生命周期之中。使用中心数据库便于项目组和管理人员获取正确、足够的信息，简化了地域分散的组织的信息共享流程，它还可以实现工作流程的自动化，最大限度减少重复工作。

不同的组织，缺陷跟踪流程会有所不同，下图是一个典型的缺陷生命周期图。

　在alpha/beta测试期间，测试人员将发现的Bug 提交到缺陷跟踪系统，该系统至少应包含：

• 失败描述：摘要、重建步骤、隔离信息；
• 识别信息：顺序的ID号、报告作者、报告归档日期。
• 一个好的系统还需要：
• 严重性等级，以评估在测试条件下，错误在系统中的绝对影响；
• 优先级，评估顾客实际使用中发生事件的可能性，或对目标顾客的后续影响；
• 环境：系统软、硬件配置，测试版本号；
• 附件，错误信息或屏幕截图。

提交之后，Bug为"Submitted"状态，变更控制委员会（Change Control Board，视项目规模组织，可以是不同角色的几个人组成或一个人担当）评审决定：

• 是Bug，分配给相关开发人员修复，状态为"Assigned"；
• 不是Bug或其他原因，关闭，状态为"Closed"，解决方式（Resolution）根据实际情况选择；
• 是Bug，但延迟到下一个版本修复，状态为"Postponed"。
• 开发人员将Bug修复后，其状态改为"Resolved"，他们应发布到下一个测试版本（Test Build）中，测试人员测试所有"Resolved" Bug，没有问题应关闭（"Closed"状态），未修复则要重新打开（"Opened"状态）。
• 对于用户提交的Bug，有些系统会增加"Confirmed"的状态，表示经测试Bug确实存在。

对其他变更（如需求改变或新增），以上流程同样适用，但可能需要多次分配（assign），如需求变更，业务分析员要更新需求文档，系统分析员要更新设计文档，然后程序员改代码。

　系统最好还有以下功能：

• Root Cause：根本原因分析，这需开发人员的帮助；
• Close Date和Resolution：系统生成关闭日期，可选择或输入问题是如何解决的；
• 系统自动跟踪记录缺陷历史，可输入注释；
• 方便的查询功能；
• 可定制的报表，缺陷趋势图表；
• Email提醒。

三、缺陷跟踪过程实施

　流程制定并评审通过后，就应该选择合适的工具，对一个新组建的组织，也可以先选择工具，再结合特定的工具制定流程。正式实施前应对项目组所有成员进行培训，以提高工具使用效率和成员间的沟通效率。

　最初我们选择了一个十分简单而又易于维护的工具Buggit，用于项目组内部的Bug跟踪；随着跨地域开发项目的出现，沟通交流复杂性凸现，我们适时选择了Web Based系统。下面看看两个系统的具体实施。

　使用免费工具Buggit

　Buggit 是一个十分小巧的C/S结构的Access应用软件，仅限于intranet，十分钟就可以配置完成，使用十分简单，查询简便，能满足基本的缺陷跟踪功能，还有十个用户定制域，有十二种报表输出。

　我们在一个十几人的开发团队，使用了两年半时间（版本V2.20 Bld 4 for Windows 95/98 and NT ），基本没有数据丢失，有过几次数据库格式错误，一般可恢复，Email通知和缺陷趋势图功能不稳定。该系统的安全性和权限控制十分薄弱，需要团队成员按规范配合。

　详细信息请访问Buggit主页http://www- 900.ibm.com/developerWorks/cn/linux/software_engineering/l-mantis/www.pb- sys.com下图为Buggit主页面和详细缺陷报告。

　

　使用 web-based开源软件Mantis

　Mantis是PHP/MySQL/Web-based缺陷跟踪系统，即使没有经验也可以在一天内配置完成。

　由于我们的研发团队是地域分布式的，有些项目是上海、硅谷和香港的研发中心合作开发，需求、设计、开发、测试和用户反馈来自不同地区，使用电子邮件和文档来跟踪缺陷时，信息共享和错误状态更新都费时费力，随着项目的扩展，文档工作量也越来越大，这时使用web-based系统、项目组共用一个中心数据库实现工作流自动化提到议事日程。因为是选择开源软件，所以要考虑系统稳定性和安装配置、维护工作量，这项工作完全由测试组实施，我们在今年一月到四月将 Mantis安装到个人工作的PC机，请不同角色的人试用，反馈效果良好，我们马上决定将系统用于跨地域开发的项目，系统正式安装在开发用的Server 上，操作系统是Solaris，配置比Windows下稍复杂一些。使用过程中，根据开发组的反馈，由测试组通过修改源程序放宽了Assign To和缺陷更新的权限，将下一版本中的Bug History和缺陷图表包集成到目前使用的版本0.17.5，增加了CSV Export数据域。现在我们已将该系统推广到其他几个项目，总共有四十人左右使用，通过公司专线访问，在近一年的时间里，系统运行平稳，性能也比较理想，简化了流程，从而提高了工作效率。

Mantis特性

　Mantis当前版本为0.17.5，下一版0.18.0处于Beta发布阶段。

　关于产品详细信息和支持，请访问主页http://mantisbt.sourceforge.net/，下图为查看所有Bug和查看详细Bug页面。

　

　Mantis基本特性：

• 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件；
• 支持多项目、多语言；
• 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动；
• 主页可发布项目相关新闻，方便信息传播；
• 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷；
• 缺陷报告可打印或输出为CSV格式，0.18.0版：支持可定制的报表输出，可定制用户输入域；
• 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析；
• 流程定制不方便，但该流程可满足一般的缺陷跟踪。

四、项目实施经验教训

　测试作为项目开发的最后一环，错误、延时、疏忽等都可能在测试阶段表现出来，如何有序管理和分析各种问题对质量控制和过程改进非常重要，使用web based系统就是一个好的实践。

　在项目组内，对Bug采用数据库系统进行跟踪并不困难，因为主要是测试人员提交Bug报告，测试人员使用最多，相信测试人员对使用中心数据库的好处是很了解的了，只要项目经理支持就很好办了。如果要对其他缺陷，如需求变更，也这样管理就不是那么容易了，在技术上当然没有问题，难在工作方式的改变，虽然用 Email和文档管理无法实现工作流的自动化，也不如数据库系统提供那么多的分析和报告选项，但在小规模的项目中依靠人工管理也可以做得井井有条。我们在多个项目的实施中就遇到这样的情况，有的项目随时都有需求变更，而且变更的数量不少，项目组主动提出想用数据库系统来管理；有的项目刚起步，第一个阶段的开发业务功能不多，推行的时候阻力就很大。我的初级目标是有序地管理错误和变更，在实施手段上有冲突时，不要操之过急，融洽的关系对项目的成功是很重要的。往往是有了成功的案例后，回头推广又变得容易了。实施新过程时最好先局部试点，采用PDCA循环，不断总结经验，再推广。

　使用缺陷数据库，可以制作得到各种缺陷分析图表，从而预测项目风险或解释测试结果。下面两张图都是Mantis生成的缺陷图，从累积错误打开图，分析错误生成趋势，在发现错误报告未收敛时发布软件，显然风险很大，当然使用图表时还应结合实际，在曲线平坦时，是否开展了测试工作，曲线上升时，错误的严重性等级如何等。从严重性等级的柱状图可分析被测系统的总体状况。在发布管理不规范的组织中，当产品质量问题突出时，测试组可以通过解释这些图来阐述测试结果，从而规范发布过程。

　第一部分提到的根本原因（Root Cause）域，他有助于使开发人员的注意力集中到引起最严重、最频繁问题的领域，从而消耗最少的资源改进过程取得最显著的成果，这是我在过程改进时最常用到的80/20法则。在项目实施时，实际情况并不理想，因为开发人员忙于改Bug，少有主动写错误发生的根本原因的，这需要开发人员的配合和管理者的支持。

　缺陷数据的使用应谨慎，不要将错误个人化，应保证数据的真实性，否则数据对过程改进没有意义。

　实施过程中，大家会对工具提出很多需求，应评估哪些是共同需求、核心需求，系统修改复杂程度，对当前系统和系统升级的影响。测试组在实施过程中，对不同角色人员的工作流程有了深入而准确的了解，同时可以进行工作流程的改进。

　
　使用开源系统的利弊

　由于开源系统的代码是公开的，用户可自行维护和定制，大家也可以提交新特性和功能扩展要求，而不必受制于商业系统的制造商。开源系统的用户遍布世界各地， Bug反而容易发现，同时公开源代码中低效率的程序也容易被发现和修改。当然越是流行的软件，生命力越强，Bug清除和新特性增加越快。

　开源系统与其他工具的集成比较差，不如商业系统提供整个软件开发生命周期的工具的集成，如项目管理、需求管理、建模、自动化测试、缺陷跟踪、配置管理等有机集成，实现整个开发流程的自动化。但一般的中小企业，大多没有实力配置全所有系统，另外，不同厂商优势不同，主导系统也不同，有的企业需要根据自身的特点选择不同厂商的工具，所以即使购买商业工具也未必能将所有系统很好地集成。

　开源系统是免费的，但有人提供收费的系统维护和定制服务。

五、小结

　本文主要探讨缺陷跟踪管理的流程、工具和实施问题，缺陷跟踪在技术上并不难，而是难在管理上，好的工具有利于管理和交流，优秀的项目组应意识到有效的交流方式是多种多样的，不应该单依赖系统，这样才有利于提高团队的战斗力，而不是把重点放在追求系统功能的十全十美。有些缺陷跟踪系统有Knowledge Base 功能，这对公司知识库的累积也很有效；有的系统对不同用户生成相关的To-Do-List，方便日常工作；有的对每个发布版本都有详细的缺陷报告。总之，花费时间和精力完善错误管理系统是值得的，这是质量管理和提高的基础。

参考书目

　《测试流程管理》 北京大学出版社 作者Rex Black 2001年3月第一版
　《CVS开源软件开发技术》 机械工业出版社 作者Karl Fogel 2001年6月第一版

关于作者

　蔡琰，外企QA主管，有三年电子商务领域QA、测试主管经验及多年的开发经历。目前关注基于J2EE构架的web系统的功能测试和性能测试、自动化测试、过程改进。现在上海，您可以通过电子邮件cindy_cai@sina.com 和她联系。