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 附件
文件编号
文件名称
保存时间
保管部门
附件