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