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. 跟踪类型为【需求确认】的管理

注解:绿色代表的是由测试人员操作

紫色代表的是由需求人员操作

红色代表的是由开发人员操作