缺陷管理贯穿于整个软件开发生命周期中 是不可缺少的环节但在国内一些中小型开发商中没有得到足够得重视本文结合实际应用系统地介绍了缺陷跟蹤开源软件 Buggit 和 Mantis 以期抛砖引玉引起重视在您的项目中是否有遇到过这样的问题测试人员报的缺陷被遗忘掉;延期项目终于发布却遭遇用户频频抱怨管理人员将矛头指向测试人员;书写不规范的错误报告使得开发人员不得不一次次找到测试人员来重现;地域分散的开发团队通过email和文档交流缺陷状态混乱相关人员无法及时获得有关的变更信息…… 那么让测试组织使用数据库来部署产品缺陷的记录和跟蹤吧!对于中小软件开发组织或许不太可能使用动则几千美金一个许可证的商业软件但免费而又易于维护的软件完全可以满足您%以上的需要如果您的组织还陷于无穷无尽的混乱不堪的缺陷之中不要犹豫马上行动免费软件可以很好地管理这个过程但在实施中对管理上提出的要求则是您应该自我提高的下面我们看看一个中小型开发组织两年多的实施过程或许对您有些启发
一项目背景组织架构
某公司在全球航运业信息化领先在全球设有四个研发中心主要为公司开发航运和物流软件大多给公司内部和业务有关的客户使用有些成熟的软件销售给同行或作为中立的平台提供给同行使用该公司的上海的研发中心使用的是免费或开源的软件跟蹤缺陷有独立的测试小组工作包括功能测试压力测试质量保证和过程改进使用的是免费软件Buggit 后来为了解决异地开发过程中的缺陷跟蹤问题 开始使用Mantis 版本(开源软件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十分钟就可以配置完成使用十分简单查询简便能满足基本的缺陷跟蹤功能还有十个用户定制域有十二种报表输出
我们在一个十几人的开发团队使用了两年半时间(版本V Bld for Windows / and NT )基本没有数据丢失有过几次数据库格式错误一般可恢复Email通知和缺陷趋势图功能不稳定该系统的安全性和权限控制十分薄弱需要团队成员按规范配合
详细信息请访问Buggit主页http://www ibmcom/developerWorks/cn/linux/software_engineering/lmantis/wwwpb syscom下图为Buggit主页面和详细缺陷报告
使用 webbased开源软件Mantis
Mantis是PHP/MySQL/Webbased缺陷跟蹤系统即使没有经验也可以在一天内配置完成
由于我们的研发团队是地域分布式的有些项目是上海硅谷和香港的研发中心合作开发需求设计开发测试和用户反馈来自不同地区使用电子邮件和文档来跟蹤缺陷时信息共享和错误状态更新都费时费力随着项目的扩展文档工作量也越来越大这时使用webbased系统项目组共用一个中心数据库实现工作流自动化提到议事日程因为是选择开源软件所以要考虑系统稳定性和安装配置维护工作量这项工作完全由测试组实施我们在今年一月到四月将 Mantis安装到个人工作的PC机请不同角色的人试用反馈效果良好我们马上决定将系统用于跨地域开发的项目系统正式安装在开发用的Server 上操作系统是Solaris配置比Windows下稍复杂一些使用过程中根据开发组的反馈由测试组通过修改源程序放宽了Assign To和缺陷更新的权限将下一版本中的Bug History和缺陷图表包集成到目前使用的版本增加了CSV Export数据域现在我们已将该系统推广到其他几个项目总共有四十人左右使用通过公司专线访问在近一年的时间里系统运行平稳性能也比较理想简化了流程从而提高了工作效率
Mantis特性
Mantis当前版本为下一版处于Beta发布阶段
关于产品详细信息和支持请访问主页http://mantisbtsourceforgenet/下图为查看所有Bug和查看详细Bug页面
Mantis基本特性
个人可定制的Email通知功能每个用户可根据自身的工作特点只订阅相关缺陷状态邮件;
支持多项目多语言;
权限设置灵活不同角色有不同权限每个项目可设为公开或私有状态每个缺陷可设为公开或私有状态每个缺陷可以在不同项目间移动;
主页可发布项目相关新闻方便信息传播;
方便的缺陷关联功能除重复缺陷外每个缺陷都可以链接到其他相关缺陷;
缺陷报告可打印或输出为CSV格式版支持可定制的报表输出可定制用户输入域;
有各种缺陷趋势图和柱状图为项目状态分析提供依据如果不能满足要求可以把数据输出到Excel中进一步分析;
流程定制不方便但该流程可满足一般的缺陷跟蹤
四项目实施经验教训
测试作为项目开发的最后一环错误延时疏忽等都可能在测试阶段表现出来如何有序管理和分析各种问题对质量控制和过程改进非常重要使用web based系统就是一个好的实践
在项目组内对Bug采用数据库系统进行跟蹤并不困难因为主要是测试人员提交Bug报告测试人员使用最多相信测试人员对使用中心数据库的好处是很了解的了只要项目经理支持就很好办了如果要对其他缺陷如需求变更也这样管理就不是那么容易了在技术上当然没有问题难在工作方式的改变虽然用 Email和文档管理无法实现工作流的自动化也不如数据库系统提供那么多的分析和报告选项但在小规模的项目中依靠人工管理也可以做得井井有条我们在多个项目的实施中就遇到这样的情况有的项目随时都有需求变更而且变更的数量不少项目组主动提出想用数据库系统来管理;有的项目刚起步第一个阶段的开发业务功能不多推行的时候阻力就很大我的初级目标是有序地管理错误和变更在实施手段上有沖突时不要操之过急融洽的关系对项目的成功是很重要的往往是有了成功的案例后回头推广又变得容易了实施新过程时最好先局部试点采用PDCA循环不断总结经验再推广
使用缺陷数据库可以制作得到各种缺陷分析图表从而预测项目风险或解释测试结果下面两张图都是Mantis生成的缺陷图从累积错误打开图分析错误生成趋势在发现错误报告未收敛时发布软件显然风险很大当然使用图表时还应结合实际在曲线平坦时是否开展了测试工作曲线上升时错误的严重性等级如何等从严重性等级的柱状图可分析被测系统的总体状况在发布管理不规范的组织中当产品质量问题突出时测试组可以通过解释这些图来阐述测试结果从而规范发布过程
第一部分提到的根本原因(Root Cause)域他有助于使开发人员的注意力集中到引起最严重最频繁问题的领域从而消耗最少的资源改进过程取得最显着的成果这是我在过程改进时最常用到的/法则在项目实施时实际情况并不理想因为开发人员忙于改Bug少有主动写错误发生的根本原因的这需要开发人员的配合和管理者的支持
缺陷数据的使用应谨慎不要将错误个人化应保证数据的真实性否则数据对过程改进没有意义
实施过程中大家会对工具提出很多需求应评估哪些是共同需求核心需求系统修改复杂程度对当前系统和系统升级的影响测试组在实施过程中对不同角色人员的工作流程有了深入而准确的了解同时可以进行工作流程的改进
使用开源系统的利弊
由于开源系统的代码是公开的用户可自行维护和定制大家也可以提交新特性和功能扩展要求而不必受制于商业系统的制造商开源系统的用户遍布世界各地 Bug反而容易发现同时公开源代码中低效率的程序也容易被发现和修改当然越是流行的软件生命力越强Bug清除和新特性增加越快
开源系统与其他工具的集成比较差不如商业系统提供整个软件开发生命周期的工具的集成如项目管理需求管理建模自动化测试缺陷跟蹤配置管理等有机集成实现整个开发流程的自动化但一般的中小企业大多没有实力配置全所有系统另外不同厂商优势不同主导系统也不同有的企业需要根据自身的特点选择不同厂商的工具所以即使购买商业工具也未必能将所有系统很好地集成
开源系统是免费的但有人提供收费的系统维护和定制服务
五小结
本文主要探讨缺陷跟蹤管理的流程工具和实施问题缺陷跟蹤在技术上并不难而是难在管理上好的工具有利于管理和交流优秀的项目组应意识到有效的交流方式是多种多样的不应该单依赖系统这样才有利于提高团队的战斗力而不是把重点放在追求系统功能的十全十美有些缺陷跟蹤系统有Knowledge Base 功能这对公司知识库的累积也很有效;有的系统对不同用户生成相关的ToDoList方便日常工作;有的对每个发布版本都有详细的缺陷报告总之花费时间和精力完善错误管理系统是值得的这是质量管理和提高的基础
参考书目
《测试流程管理》 北京大学出版社 作者Rex Black 年月第一版
《CVS开源软件开发技术》 机械工业出版社 作者Karl Fogel 年月第一版
关于作者
蔡琰外企QA主管有三年电子商务领域QA测试主管经验及多年的开发经历目前关注基于JEE构架的web系统的功能测试和性能测试自动化测试过程改进现在上海您可以通过电子邮件cindy_cai@sinacom 和她联系
