管理手册1/8Redmine的Bug管理手册版本更新列表序号版本号作者日期11.0刘玲,张新婷2012-11-26管理手册2/8目录1.编写目的.....................................................................................................32.跟踪类型为【缺陷】的管理...........................................................................32.1报告缺陷注意事项..................................................................................32.2Bug的优先级别..................................................................................42.3BUG生命周期.....................................................................................52.4Bug的一般管理流程............................................................................73.项目组各角色在Redmine中bug管理的权限:.....................错误!未定义书签。4.跟踪类型为【需求确认】的管理.....................................................................8管理手册3/81.编写目的该文档主要面对开发人员和测试人员和需求分析人员,在RedMine的bug管理系统中,缺陷类bug和需求确认类bug的状态变化,如何进行bug状态的更新。2.项目组各角色在Redmine中bug管理的权限:管理员:全部权限测试组长/经理:拥有测试人员的所有权限,同时可打开测试人员提交的问题。测试人员:可添加Bug、不能删除Bug、可添加注释评论(R&DComments)、不可修改他人所提Bug、可调整:Bug概要(题目,Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&DComments)、复测人、复测日期、修改人发开发人员。需求人员:不能删除Bug、可添加注释评论(R&DComments)、可调整:注释评论(R&DComments)、是否复现、Bug状态(不过无法直接标为closed)、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。开发组长/经理/需求经理:除了开发人员的权限,还可调整:优先级别、责任人、Bug概要(题目,Summary)、附件附图(Attachments)3.跟踪类型为【缺陷】的管理2.1报告缺陷注意事项请测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图;单一:尽量一个报告只针对一个软件缺陷,报告形式应方便阅读。在主报告之后应注明不同的条件;当你的BUG报告以“Nonreproducible(不可重现)”打回给你时,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再管理手册4/8去找研发人员。研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项;测试人员在精简描述的同时,应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语;不要使用感叹号或其它表现个人感情色彩的词语或符号;不要使用含糊的词语(例如,好像,似乎)来描述发现的现象;当BUG指派给你,在下一个版本发布之后,第一时间跟踪BUG的修复情况2.2Bug的优先级别Urgent—危机严重错误、VeryHigh—严重错误High—一般性错误Medium—一般性错误Low—轻微建议错误缺陷严重程度:A)Urgent危急:由于程序所引起的死机,非法退出、死循环,数据丢失等,引起系统“挂起”或“崩溃”“数据丢失”的错误;B)VeryHigh非常严重:主要流程功能完全丧失的程序错误;C)High严重:操作性错误、结果错误等,功能不实现或者是实现错误、不能完成软件说明书定义的功能的错误;D)Medium中等/一般:界面图片样式错别字,提示信息不准确等,界面不规范、辅助说明描述不清楚、输入输出不规范错误;E)Low低(建议):不影响使用的“轻微”的问题或更好的实现建议、增强或者改进等。Bug优先级别描述Urgent—严重错误包括以下各种错误:由于程序所引起的死机,非法退出、死循环、数据库发生死锁、因错误操作导致的程序中断、功能错误、与数据管理手册5/8库连接错误。VeryHigh—较严重错误程序错误,程序接口错误High—一般性错误操作界面错误(包括数据窗口内列名定义、含义是否一致)打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示数据库表中有过多的空字段Medium—一般性小错误界面不规范;辅助说明描述不清楚;输入输出不规范;Low—轻微错误界面操作用户提示不友好;提示窗口文字未采用行业术语;可输入区域和只读区域没有明显的区分。2.3BUG生命周期在软件开发过程中,缺陷拥有自身的生命周期。缺陷在走完其生命周期最终会关闭。确定的生命周期保证了过程的标准化。缺陷在其生命周期中会处于许多不同的状态。缺陷的状态描述图如下:管理手册6/8注解:绿色代表的是由测试人员操作蓝色代表的是由测试负责人操作黑色代表的是由开发人员操作状态描述New新建:当缺陷被第一次递交的时候,它的状态即为“New”。这也就是说缺陷未被确认其是否真正是一个缺陷Open打开:在测试者提交一个缺陷后,测试经理确认其确实为一个缺陷的时候他会把状态置为“打开”Nonreproducible不可重现:开发人员对于不可重现的问题置为此状态Won’tfix不解决:开发人员经过与需求业务人员讨论并确认该问题为无效管理手册7/8时,可置此状态Deferred延迟解决:经开发人员,测试者,业务相关人员讨论后,认为该问题可以延迟解决,置此状态Fixed已解决:开发人员已经解决该问题,置此状态。Reopen重新打开:测试人员验证后,发现该问题还能重现,可置此状态。Closed关闭:已经回归通过的bug,测试人员关闭该问题。2.4Bug的一般管理流程测试组长:验证提交为New状态的缺陷,如果确认是bug,分配给相应的开发人员,设置状态为Open。如果不是bug,则删除该bug。开发人员:查询状态为Open的Bug,如果不能重现该bug,则置状态为Nonreproducible;如果认为不是bug,则置状态为Won'tfix;如果认为该bug可以推迟解决,则置状态为Deferred;如果是Bug,则修复并置状态为fixed。对于Won'tfix和Deferred的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。测试人员:查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为Closed,如没有解决置状态为Reopen,并添加相应的说明。管理手册8/84.跟踪类型为【需求确认】的管理注解:绿色代表的是由测试人员操作紫色代表的是由需求人员操作红色代表的是由开发人员操作