BUG管理标准规范与作业流程.doc

BUG管理步骤和规范

目 录

1 概述 5
1.1 编写目标 5
1.2 适用范围 5
2 关键角色及应负责任 5
3 BUG步骤图 6
4 活动描述 6
5 BUG书写规范 8
5.1 测试人员BUG提交 8
5.1.1 专题 8
5.1.2 步骤 8
5.1.3 实际结果 8
5.1.4 预期结果 8
5.1.5 备注 9
5.2 开发人员处理BUG 9
6 BUG严重等级 10
6.1 致命 10
6.2 严重 10
6.3 通常 11
6.4 优化 11
7 BUG优先级 12
7.1 紧急 12
7.2 高 12
7.3 中 12
7.4 低 12
8 BUG处理方案 12
8.1 设计如此 12
8.2 反复bug 12
8.3 已处理 12
8.4 无法重现 12
8.5 延期处理 12
8.6 新增/变更需求 12
9 BUG状态 12
9.1 激活 12
9.2 已处理 13
9.3 关闭 13
10 其它要求 13
11 相关文件 13
12 附件 13

1 概述
1.1 编写目标
本文档定义bug整个生命周期，规范bug管理步骤。Bug在流转过程中有章可循。
规范bug严重等级和bug处理优先级，使开发人员和测试人员能依据此文档正确判定bug严重程度并加以处理。

1.2 适用范围
本文档适用测试人员、开发人员。

2 关键角色及应负责任
序号
角色
应负责任
01
测试工程师
1) 提交bug，用bug等级反应bug严重程度，
2) 验证bug是否已被处理
02
测试责任人
1) 审核测试人员提交bug ；
2) 定位测试工程师提交bug优先级
3) 定时对bug库进行分析，描绘出曲线图等，汇报现实状况、估计趋势，在测试总结汇报中给出意见。
4) 分析项目测试过程中存在风险
03
开发工程师
1) 分析bug，写出问题原因，修改bug，
2) 实施bug优先标准，严重程度5个以上，停止新功效开发。
04
开发责任人
1) 天天对bug进行分配，标注处理意见
2) 定时对bug库分析，对bug多模块，进行代码走查。
3) 分析bug修复进度，对项目标质量、进行风险评定。
4) 跟踪被需求确定可延期处理bug
05
系统工程师
1) 解释需求，给出处理意见，
2) 将bug库中提议整理成为需求文档
3) 当开发和测试存在意见分歧时，进行需求确定。

3 Bug步骤图

Bug状态：激活，已修复，已关闭
处理方案：设计如此，反复Bug，已处理，无法重现，延期处理，新增/变更需求
4 活动描述
序号
活动名称
参与角色
活动描述
输入、输出信息
处理时限
01
提交bug
测试工程师
具体书写Bug，指派给对应测试责任人
输入信息：
无
输出信息：
在禅道上提交bug
----
02
Bug确定和分配
测试责任人
依据<<软件需求>>判定是否是Bug，给出意见
输入信息：
测试人员提交bug，测试用例，软件需求
输出信息：
确定bug优先级，指派给开发责任人。
0.5个
工作日
03
分析确定并指派Bug
开发责任人
依据<<软件需求>>判定是否是Bug，给出意见
输入信息：
测试责任人指派bug，软件需求，程序源代码等
输出信息：
分析Bug，指派给对应开发工程师，不是bug或应该需求变更时，指派给相关人员
0.5个
工作日
04
修复Bug
开发工程师
修改Bug，给出处理方案，修复再次激活bug。
输入信息：
开发责任人确定指派bug，软件需求
输出信息：
Bug处理方案，产生bug原因，指派给对应测试工程师
0.5个
工作日
05
验证Bug
测试工程师
验证Bug，给出验证结果
输入信息：
开发工程师指派已修复Bug，需求确定转为变更或新增需求bug
输出信息：
假如Bug未修改，激活并指派给对应开发工程师；
假如Bug已修改或系统工程师确定转为需求bug，关闭bug，
0.5个
工作日
06
确定bug延期
测试主管
分析bug，确定bug是否能延期处理
输入信息：
开发或系统工程师指派延期bug
输出信息：
确定是否能延期处理，对应延期bug在开发修复版本进行激活
视实际情况而定
07
Bug仲裁
系统工程师
依据<<软件需求>>判定是否是Bug，给出处理意见
输入信息：
测试主管指派延期bug或需要系统工程师确定bug，开发主管指派新增/变更需求bug。
输出信息：
给出明确处理结果，属于新增/变更需求bug需要在需求文档中统计相关需求。
0.5个
工作日

5 BUG书写规范
5.1 测试人员BUG提交
5.1.1 专题
•    用一个简短句子描述问题，不要写成一大段
•    以进入问题模块路径开头，方便项目经理分配任务，和开发人员定位问题
•    描述问题时要具体、简练、抓住关键点，直接切入正题，不要罗嗦
•    不要夸大或缩小问题严重程度
5.1.2 步骤
•    用数字编号，一步步描述重现问题全部操作步骤
•    提供明确再现问题步骤，避免问题被以“不能重现”关掉
•    设置区域需要具体描述，如：各设置项值为默认、**值更改为“”，其它设置项值为默认；
•    尽可能用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等
•    不要在一个步骤中描述不相关多个操作。假如是相关一系列操作，能够使用“→”来连接描述。
•    根据你写步骤去实施，看问题能否重现
•    不要在步骤中使用含糊不清缩写词描述
5.1.3 实际结果
•    实际只描述一个问题
•    一样操作步骤产生多个现象，要在一个缺点汇报中加以描述
•    不一样操作步骤产生不一样问题，分别报bug
•    假如有截图，请列出所附图片信息
5.1.4 预期结果
•    不要加入实际结果描述信息
•    描述要清楚，不要使用含糊不清缩写词描述
•    假如有截图，请列出所附图片信息
5.1.5 备注
•    避免写成大段落，要写得简单、易读
•    问题特征
•    出现问题后处理方法
•    对终端用户影响情况
•    假如有必需，列出产生问题配置环境

5.2 开发人员处理BUG
1.BUG原因。
2.BUG修改方法
3.BUG能够在哪个版本上进行验证。
4.测试人员验证bug时，需要写明：验证了什么，在什么版本验证，是否经过，假如不经过需写明原因。假如在验证目前bug时有新现象产生阻碍了验证此bug，则该bug不能关闭，写明没有验证原因，并为新现象提bug。

举例1：

现象：

修改后：

6 BUG严重等级
6.1 致命
不能实施正常工作功效或关键功效，因软件原因造成系统死机等，须立即修正致命错误。
通常有以下情况：
1.内存泄漏
2.因为实施程序引发数据库发生死锁
3.用户数据丢失或破坏
4.系统瓦解
5.死机
6.程序无法开启或异常退出
7.因错误操作造成程序中止
8.功效设计和需求严重不符

6.2 严重
影响系统功效或操作，应用模块错误使业务中止无法进行后续操作，关键功效存在严重缺点，但不会影响到系统稳定性。
具体基础上可分为：
1.功效未实现
2.功效错误
3.业务中止，无法进行后续操作
4.数据库表、业务规则、缺省值未加完整性等约束条件
5.数据库表结构错误，字段长度不够，缺乏表、存放
6.语音或数据通讯错误
7.数值计算错误
8.前台提醒存放报错
9.系统所提供功效或服务受显著影响

6.3 通常
影响系统正常运行缺点，关键功效出现错误，影响到产品使用。比如：次要功效不能正常实现； 查询错误，数据错误显示；简单输入限制未放在前台进行控制
具体基础上可分为：
1.操作界面错误（包含数据窗口内列名定义、含义是否一致）
2.报表打印内容、格式错误、取值错误
3.页面查询结果错误，自动读值项取值错误
4.边界条件下错误
5.提醒信息错误（包含未给出信息、信息提醒错误等）
6.简单输入限制未放在前台进行控制
7.长时间操作无进度提醒
8.光标跳转设置不好，鼠标（光标）定位错误

6.4 优化
使操作者不合理或不方便或操作碰到麻烦，但它不影响实施工作功效或关键功效，次要功效，对产品使用影响不大。比如：程序在部分显示上不美观，不符适用户习惯，或是部分文字错误。
具体基础上可分为：
1.界面格式等不规范
2.辅助说明描述不清楚
3.操作时未给用户提醒
4.可输入区域和只读区域没有显著区分标志
5. 部分不影响产品了解错别字
6.文字排列不整齐等部分小问题
7.提醒窗口文字未采取行业术语

7 BUG优先级
7.1 紧急
阻止和此亲密相关功效深入测试,需要立即修复
7.2 高
必需修改，发版前必需修正
7.3 中
必需修改，不一定立即修改，但需确定在某个特定里程碑结束前须修正
7.4 低
对系统影响较小，假如时间许可应该修改

8 BUG处理方案
8.1 设计如此
设计如此，测试人员了解错误，无需改动，即无效bug
8.2 反复bug
以前已经有一样bug。
8.3 已处理
Bug已经被修更正确，待测试进行验证
8.4 无法重现
依据测试写重现步骤，无法重现bug。
8.5 延期处理
确实是bug，但现在不处理，以后处理。
8.6 新增/变更需求
分析确实是存在问题，但需求没有描述清楚，应指派给需求确定，进行需求新增或变更。

9 BUG状态
9.1 激活
1.新创建bug；
2.已关闭bug重新出现需要再次激活 ；
3.已处理但验证未经过bug。
9.2 已处理
开发已经修改完成bug。
9.3 关闭
已验证经过bug或系统工程师确定转为需求bug。

10 其它要求
Bug描述和Bug流向严格遵守步骤规范。
11 相关文件
文件编号
文件名称

12 附件
文件编号
文件名称
保留时间
保管部门
附件