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)当开发和测试存在意见分歧时，进行需求确认。 |
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.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相关文件
| 文件编号 | 文件名称 |
| 文件编号 | 文件名称 | 保存时间 | 保管部门 | 附件 |
Copyright © 2019-2025 51dongshi.net 版权所有
违法及侵权请联系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
