在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结构的Aclearcase/" target="_blank" >ccess应用软件,仅限于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主页面和详细缺陷报告。