BUG管理规范及流程.docx

UG管理流程与规 Word Word专业资料 1.1 1.2 编写目的适用围… 关键角色及应负责任 BUG流程圈 活动描述 BUG书写规 5J 5JJ 5.L2 5.1.3 5.1.4 测试人员BUG提交 5.1.5 5.2- 坯 也 实际结果 预期结果 益 开发人员解决BUG BUG 尸: 10 6.1 6.2 6.3 6.4 致命 严重 优化 10 10 11 11 12 12 BUG优先級 12 12 12 12 7.17.2一7.3一7.4_ 9.19^2螭..己解决 9.1 9^2 螭.. 己解决 12 13 12BUG解决方案 12 TOC \o 1-5 \h \z 8.1 设计如此 12 2 重复 BUG 12 已解决 12 无法重现 12 延期处理 12 新増/变更需求 12 ? 12BUG状态 ? 12 TOC \o 1-5 \h \z \o Current Document 其他妥求 13 \o Current Document 相关文件 13 Mit 13 1概述 1.1编写目的 本文档定义bug的整个生命周期，规bug的管理流程。Bug在流转的过程中有章可循。 Word Word专业资朴 规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） 当开发和测试存在意见分歧时，进行需求确认。 Word Word专业资料 3 Bug流程图 Bug状态：激活，已修复，已关闭 解决方案：设计如此，重复Bug,已解决，无法重现，延期处理，新增/变更需求 4活动描述 序号 活动名称费与角色 活动描述 输入、输出信息处理时限 01 提交bug 测试工程师 详细书写Bug,指派给 对应的测试负责人 輪人值息： 无 输出信息： 在禅道上提交bug — 02 Bug确认 与分配 测试贝责人 根据 软件需求》判 定是否是Bug,给出恵 见 輪人值息： 测试人员提交的bug. 测试用例,软件為求 辎岀值息： 険定bug优先级，指派 给开发负责人。 0.5个 工作日 03 分析确认 并指派 Bug 开发负责人 根据 软件需求， 判 定是否是Bug,给出息 见 输入值息： 测试负责人指派的 bug,软件需求，程序 源代码等 输出值息： 0.5个 工作日  分析Bug,指派给对应 的开发工程师，不是 bug或应该需求变更 时，指派给相关人员 04 修复Bug 开发工程师 修改Bug,给出解决方 案，修建用次激活的 bug。 ?Att 息： 开发负责人确认指派的 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。 输出信息： 给出明确处理结果，属 0.5个 工作曰 Word Word专业资料 Word Word专业资朴 于新壻/变更需求的 bug蚩要在需求文