BUG管理规范与流程.docx
《BUG管理规范与流程.docx》由会员分享,可在线阅读,更多相关《BUG管理规范与流程.docx(14页珍藏版)》请在冰豆网上搜索。
BUG管理规范与流程
BUG管理流程与规范
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)当开发和测试存在意见分歧时,进行需求确认。
3Bug流程图
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个
工作日
5BUG书写规范
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:
现象:
修改后:
6BUG严重等级
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.提示窗口文字未采用行业术语
7BUG优先级
7.1紧急
阻止与此密切相关功能的进一步测试,需要立即修复
7.2高
必须修改,发版前必须修正
7.3中
必须修改,不一定马上修改,但需确定在某个特定里程碑结束前须修正
7.4低
对系统的影响较小,如果时间允许应该修改
8BUG解决方案
8.1设计如此
设计如此,测试人员理解错误,无需改动,即无效的bug
8.2重复bug
以前已经有同样的bug。
8.3已解决
Bug已经被修改正确,待测试进行验证
8.4无法重现
根据测试写的重现步骤,无法重现bug。
8.5延期处理
确实是bug,但现在不解决,以后处理。
8.6新增/变更需求
分析确实是存在问题,但需求没有描述清晰,应指派给需求确认,进行需求的新增或变更。
9BUG状态
9.1激活
1.新创建的bug;
2.已关闭的bug重新出现需要再次激活;
3.已解决但验证未通过的bug。
9.2已解决
开发已经修改完成的bug。
9.3关闭
已验证通过的bug或系统工程师确认转为需求的bug。
10其他要求
Bug的描述与Bug的流向严格遵守流程规范。
11相关文件
文件编号
文件名称
12附件
文件编号
文件名称
保存时间
保管部门
附件