RedMine的问题管理流程
- 格式:docx
- 大小:180.58 KB
- 文档页数:7
管理手册
1 / 7
Redmine的
Bug管理手册
版本更新列表
序号 版本号 作者 日期
1 1.0 刘玲,张新婷 2012-11-26
管理手册
2 / 7
目录
1. 编写目的 ..................................................................................................... 3
2. 跟踪类型为【缺陷】的管理 ........................................................................... 3
2.1 报告缺陷注意事项 .................................................................................. 3
2.2 Bug的优先级别 .................................................................................. 4
2.3 BUG生命周期 ..................................................................................... 5
2.4 Bug的一般管理流程 ............................................................................ 6
3. 项目组各角色在Redmine中bug管理的权限: ................... 错误!未定义书签。
4. 跟踪类型为【需求确认】的管理 ..................................................................... 7
管理手册
3 / 7
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(不可重现)”打回给你时,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再管理手册
4 / 7
去找研发人员。研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项;
测试人员在精简描述的同时,应该再仔细检查报告是否会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语;
不要使用感叹号或其它表现个人感情色彩的词语或符号;
不要使用含糊的词语(例如,好像,似乎)来描述发现的现象;
当BUG指派给你,在下一个版本发布之后,第一时间跟踪BUG的修复情况
2.2 Bug的优先级别
Bug优先级别 描述
Urgent—严重错误 包括以下各种错误: 由于程序所引起的死机,非法退出 死循环,数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误
Very High—较严重错误 程序错误,程序接口错误
High—一般性错误 操作界面错误(包括数据窗口内列名定义、含义是否一致) 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段
Medium—一般性小错误 界面不规范;辅助说明描述不清楚;输入输出不规范;
Low—轻微错误 界面操作用户提示不友好;提示窗口文字未采用行业术语;可输入区域和只读区域没有明显的区分。
管理手册
5 / 7
2.3 BUG生命周期
在软件开发过程中,缺陷拥有自身的生命周期。缺陷在走完其生命周期最终会关闭。确定的生命周期保证了过程的标准化。缺陷在其生命周期中会处于许多不同的状态。缺陷的状态描述图如下:
注解:绿色代表的是由测试人员操作
蓝色代表的是由测试负责人操作
黑色代表的是由开发人员操作
状态 描述
New 新建:当缺陷被第一次递交的时候,它的状态即为“New”。这也就是说缺陷未被确认其是否真正是一个缺陷 管理手册
6 / 7
Open 打开:在测试者提交一个缺陷后,测试经理确认其确实为一个缺陷的时候他会把状态置为“打开”
Nonreproducible 不可重现:开发人员对于不可重现的问题置为此状态
Won’t fix 不解决:开发人员经过与需求业务人员讨论并确认该问题为无效时,可置此状态
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 / 7
4. 跟踪类型为【需求确认】的管理
注解:绿色代表的是由测试人员操作
紫色代表的是由需求人员操作
红色代表的是由开发人员操作