bug管理规范与流程.docVIP

PAGE 第 PAGE 12 页 第 PAGE 1 页 BUG管理流程与规范  目 录 TOC \o 1-4 \h \z \u 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 概述 编写目的 本文档定义bug的整个生命周期，规范bug的管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。 适用范围 本文档适用测试人员、开发人员。 关键角色及应负责任 序号 角色 应负责任 01 测试工程师 提交bug，用bug级别反映bug的严重程度， 验证bug是否已被解决 02 测试负责人 审核测试人员提交的bug ； 定位测试工程师提交的bug优先级 定期对bug库进行分析，描绘出曲线图等，报告现状、预测趋势，在测试总结报告中给出意见。 分析项目测试过程中存在的风险 03 开发工程师 分析bug，写出问题原因，修改bug， 实行bug优先原则，严重程度5个以上的，停止新功能的开发。 04 开发负责人 每天对bug进行分配，标注处理意见 定期对bug库分析，对bug多的模块，进行代码走查。 分析bug修复进度，对项目的质量、进行风险评估。 跟踪被需求确认可延期处理的bug 05 系统工程师 解释需求，给出处理意见， 将bug库中的建议整理成为需求文档 当开发和测试存在意见分歧时，进行需求确认。 Bug流程图 Bug状态：激活，已修复，已关闭 解决方案：设计如此，重复Bug，已解决，无法重现，延期处理，新增/变更需求 活动描述 序号 活动名称 参与角色 活动描述 输入、输出信息 处理时限 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