使用开源软件 Mantis 实施缺陷跟踪的成功实践

来源:百度文库 编辑:神马文学网 时间:2024/03/29 15:02:13

使用开源软件 Mantis 实施缺陷跟踪的成功实践

文档选项

未显示需要 JavaScript 的文档选项


拓展 Tomcat 应用

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1


级别: 初级

蔡琰 (cindy_cai@sina.com), QA 主管, 外企

2003 年 12 月 01 日

缺陷管理贯穿于整个软件开发生命周期中, 是不可缺少的环节,但在国内一些中小型开发商中没有得到足够得重视。本文结合实际应用,系统地介绍了缺陷跟踪开源软件 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主页 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和她联系。