|
级别: 初级 蔡琰 (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 提交到缺陷跟踪系统,该系统至少应包含:
一个好的系统还需要:
提交之后,Bug为"Submitted"状态,变更控制委员会(Change Control Board,视项目规模组织,可以是不同角色的几个人组成或一个人担当)评审决定:
开发人员将Bug修复后,其状态改为"Resolved",他们应发布到下一个测试版本(Test Build)中,测试人员测试所有"Resolved" Bug,没有问题应关闭("Closed"状态),未修复则要重新打开("Opened"状态)。 对于用户提交的Bug,有些系统会增加"Confirmed"的状态,表示经测试Bug确实存在。 对其他变更(如需求改变或新增),以上流程同样适用,但可能需要多次分配(assign),如需求变更,业务分析员要更新需求文档,系统分析员要更新设计文档,然后程序员改代码。 系统最好还有以下功能:
流程制定并评审通过后,就应该选择合适的工具,对一个新组建的组织,也可以先选择工具,再结合特定的工具制定流程。正式实施前应对项目组所有成员进行培训,以提高工具使用效率和成员间的沟通效率。 最初我们选择了一个十分简单而又易于维护的工具Buggit,用于项目组内部的Bug跟踪;随着跨地域开发项目的出现,沟通交流复杂性凸现,我们适时选择了Web Based系统。下面看看两个系统的具体实施。
测试作为项目开发的最后一环,错误、延时、疏忽等都可能在测试阶段表现出来,如何有序管理和分析各种问题对质量控制和过程改进非常重要,使用web based系统就是一个好的实践。 在 项目组内,对Bug采用数据库系统进行跟踪并不困难,因为主要是测试人员提交Bug报告,测试人员使用最多,相信测试人员对使用中心数据库的好处是很了解 的了,只要项目经理支持就很好办了。如果要对其他缺陷,如需求变更,也这样管理就不是那么容易了,在技术上当然没有问题,难在工作方式的改变,虽然用 Email和文档管理无法实现工作流的自动化,也不如数据库系统提供那么多的分析和报告选项,但在小规模的项目中依靠人工管理也可以做得井井有条。我们在 多个项目的实施中就遇到这样的情况,有的项目随时都有需求变更,而且变更的数量不少,项目组主动提出想用数据库系统来管理;有的项目刚起步,第一个阶段的 开发业务功能不多,推行的时候阻力就很大。我的初级目标是有序地管理错误和变更,在实施手段上有冲突时,不要操之过急,融洽的关系对项目的成功是很重要 的。往往是有了成功的案例后,回头推广又变得容易了。实施新过程时最好先局部试点,采用PDCA循环,不断总结经验,再推广。 使 用缺陷数据库,可以制作得到各种缺陷分析图表,从而预测项目风险或解释测试结果。下面两张图都是Mantis生成的缺陷图,从累积错误打开图,分析错误生 成趋势,在发现错误报告未收敛时发布软件,显然风险很大,当然使用图表时还应结合实际,在曲线平坦时,是否开展了测试工作,曲线上升时,错误的严重性等级 如何等。从严重性等级的柱状图可分析被测系统的总体状况。在发布管理不规范的组织中,当产品质量问题突出时,测试组可以通过解释这些图来阐述测试结果,从 而规范发布过程。 第一部分提到的根本原因(Root Cause)域,他有助于使开发人员的注意力集中到引起最严重、最频繁问题的领域,从而消耗最少的资源改进过程取得最显著的成果,这是我在过程改进时最常用到的 80/20法则。在项目实施时,实际情况并不理想,因为开发人员忙于改Bug,少有主动写错误发生的根本原因的,这需要开发人员的配合和管理者的支持。 缺陷数据的使用应谨慎,不要将错误个人化,应保证数据的真实性,否则数据对过程改进没有意义。 实施过程中,大家会对工具提出很多需求,应评估哪些是共同需求、核心需求,系统修改复杂程度,对当前系统和系统升级的影响。测试组在实施过程中,对不同角色人员的工作流程有了深入而准确的了解,同时可以进行工作流程的改进。 ![]() ![]() 使用开源系统的利弊 由 于开源系统的代码是公开的,用户可自行维护和定制,大家也可以提交新特性和功能扩展要求,而不必受制于商业系统的制造商。开源系统的用户遍布世界各地, Bug反而容易发现,同时公开源代码中低效率的程序也容易被发现和修改。当然越是流行的软件,生命力越强,Bug清除和新特性增加越快。 开 源系统与其他工具的集成比较差,不如商业系统提供整个软件开发生命周期的工具的集成,如项目管理、需求管理、建模、自动化测试、缺陷跟踪、配置管理等有机 集成,实现整个开发流程的自动化。但一般的中小企业,大多没有实力配置全所有系统,另外,不同厂商优势不同,主导系统也不同,有的企业需要根据自身的特点 选择不同厂商的工具,所以即使购买商业工具也未必能将所有系统很好地集成。 开源系统是免费的,但有人提供收费的系统维护和定制服务。
本 文主要探讨缺陷跟踪管理的流程、工具和实施问题,缺陷跟踪在技术上并不难,而是难在管理上,好的工具有利于管理和交流,优秀的项目组应意识到有效的交流方 式是多种多样的,不应该单依赖系统,这样才有利于提高团队的战斗力,而不是把重点放在追求系统功能的十全十美。有些缺陷跟踪系统有Knowledge Base 功能,这对公司知识库的累积也很有效;有的系统对不同用户生成相关的To-Do-List,方便日常工作;有的对每个发布版本都有详细的缺陷报告。总之, 花费时间和精力完善错误管理系统是值得的,这是质量管理和提高的基础。
|
联系客服