RedMine的问题管理流程

1、Redmine的Bug管理手册版本更新列表序号版本号作者日期11.0刘玲，张新婷2012-11-26目录1.编写目的32.跟踪类型为【缺陷】的管理32.1 报告缺陷注意事项32.2Bug的优先级别32.3BUG生命周期42.4Bug的一般管理流程53.项目组各角色在Redmine中bug管理的权限：54.跟踪类型为【需求确认】的管理61. 编写目的该文档主要面对开发人员和测试人员和需求分析人员，在RedMine的bug管理系统中，缺陷类bug和需求确认类bug的状态变化，如何进行bug状态的更新。2. 项目组各角色在Redmine中bug管理的权限：管理员：全部权限 测试组长/经理：拥有测试人

2、员的所有权限，同时可打开测试人员提交的问题。测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人 发开发人员。需求人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本

3、、修改人、修改日期。可添加Bug。 开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附件附图(Attachments) 3. 跟踪类型为【缺陷】的管理2.1 报告缺陷注意事项 请测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图； 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件； 当你的BUG报告以“Nonreproducible（不可重现）”打回给你时，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语，再检查是否有遗漏或清晰的步

4、骤，再去找研发人员。研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项； 测试人员在精简描述的同时，应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的，不会产生争执的词语； 不要使用感叹号或其它表现个人感情色彩的词语或符号； 不要使用含糊的词语（例如，好像，似乎）来描述发现的现象； 当BUG指派给你，在下一个版本发布之后，第一时间跟踪BUG的修复情况2.2 Bug的优先级别Urgent危机严重错误、Very High严重错误High一般性错误Medium一般性错误Low轻微建议错误缺陷严重程度：A）U

5、rgent危急：由于程序所引起的死机,非法退出、死循环，数据丢失等，引起系统 “挂起”或“崩溃”“数据丢失”的错误；B）VeryHigh非常严重：主要流程功能完全丧失的程序错误；C）High严重：操作性错误、结果错误等，功能不实现或者是实现错误、不能完成软件说明书定义的功能的错误；D）Medium中等/一般：界面图片样式错别字，提示信息不准确等，界面不规范、辅助说明描述不清楚、输入输出不规范错误；E）Low低（建议）：不影响使用的“轻微”的问题或更好的实现建议、增强或者改进等。Bug优先级别描述Urgent严重错误包括以下各种错误： 由于程序所引起的死机,非法退出、死循环、数据库发生死锁、因错

6、误操作导致的程序中断、功能错误、与数据库连接错误。Very High较严重错误程序错误，程序接口错误High一般性错误 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段Medium一般性小错误界面不规范；辅助说明描述不清楚；输入输出不规范；Low轻微错误界面操作用户提示不友好；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分。2.3 BUG生命周期在软件开发过程中，缺陷拥有自身的生命周期。缺陷在走完其生命周期最终会关闭。确定的生命周期保证了过程的标准化。缺陷在其生命周期中会处于

7、许多不同的状态。缺陷的状态描述图如下：注解：绿色代表的是由测试人员操作蓝色代表的是由测试负责人操作 黑色代表的是由开发人员操作状态描述New新建：当缺陷被第一次递交的时候，它的状态即为“New”。这也就是说缺陷未被确认其是否真正是一个缺陷Open打开：在测试者提交一个缺陷后，测试经理确认其确实为一个缺陷的时候他会把状态置为“打开”Nonreproducible不可重现：开发人员对于不可重现的问题置为此状态Wont fix不解决：开发人员经过与需求业务人员讨论并确认该问题为无效时，可置此状态Deferred延迟解决：经开发人员，测试者，业务相关人员讨论后，认为该问题可以延迟解决，置此状态Fixe

8、d已解决：开发人员已经解决该问题，置此状态。Reopen重新打开：测试人员验证后，发现该问题还能重现，可置此状态。Closed关闭：已经回归通过的bug，测试人员关闭该问题。2.4 Bug的一般管理流程测试组长：验证提交为New状态的缺陷，如果确认是bug，分配给相应的开发人员，设置状态为Open。如果不是bug，则删除该bug。 开发人员：查询状态为Open的Bug，如果不能重现该bug，则置状态为Nonreproducible；如果认为不是bug，则置状态为Wont fix；如果认为该bug可以推迟解决，则置状态为Deferred；如果是Bug，则修复并置状态为fixed。 对于Wont fix和Deferred的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员：查询状