bug管理规范及流程课件.docVIP

bug 管理规范及流程 1、概述 本文档定义 bug 的整个生命周期， 规范 bug 的解决方案及管理流程。 Bug 在流转的过程 中有章可循。 规范 bug 严重等级与 bug 解决优先级，使开发人员与测试人员能根据此文档 准确判断 bug 的严重程度并加以解决； 2、关键角色及职责 角色 职责 测试工程师 1. 根据规范提交 bug； 2. 及时验证 bug 是否已解决； 3. 及时关注开发拒绝 bug，和相关人员沟通讨论解决方式； 测试经理 1. 审核测试工程师提交的 bug； 2. 定期 review bug ，报告现状，并给出解决意见； 开发工程师 1. 以优先级为依据分析解决 bug 开发主管 1. 定期 review bug ，对 bug 多的模块加强 code review 和单元测试； 2. 分析 bug 解决进度，对产品质量及进度进行风险评估； 产品 1、当开发和测试存在意见分歧时，进行需求确认 2、从产品角度划分 bug 修改的优先级； 3、Bug 生命周期 4、Bug 书写规范 4.1 BUG标题 1) 以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题； 2) 描述问题时要简练、直接切入主题，但是要抓住要点； 3) 偶现 bug 在主题前标注出现的次数； 4) 有些模块功能比较多，可以在主题描述前标注上具体得操作； 示例： 【偶现 3 次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息 【偶现 2 次】添加载体库时程序停止运行 4.2 重现步骤 说明区域包括：步骤、预计结果、实际结果、测试环境、 bug 出现时间、截图、日志 1) 用数字编号，一步步的描述问题的重现步骤； 2) 不同的操作步骤产生不同的问题，需分别报 bug；尽量做到一个 bug 汇报一个问题； 3) 偶现问题必须明确 bug 出现的时间、提供截图以及日志； 5、Bug 解决方案 当天提交的新建状态 bug，对应的开发人员需在 2 天内全部审核一遍， 将 bug 分成以下 3 类：拒绝、进行中、延期、反馈（给产品）； 开发已修复的 bug：将 bug 状态置为已解决；同时添加说明验证版本号、错误原因、解决办 法； 示例： 验证版本： V101（1101 表示在 11 月 1 号可以验证） 问题原因：未作条件判断 解决方法：进行合理边界判断 开发认为不是 bug：将 bug 状态置为已拒绝；指派给 bug 提出者；同时注明拒绝理由； 示例： 参考 XXX设计，测试人员理解错误； bug 缺乏必要的信息， 无法重现： 将 bug 状态置为已拒绝 （无法重现 ）；指派给 bug 提出者； 同时注明拒绝理由； 示例： 缺少必须日志； 开发已修复，测试验证通过的 bug：将 bug 状态置为关闭，并注明通过版本号； 示例： V103 验证通过 开发已修复，测试验证不通过的 bug：将 bug 状态置为打回（ 激活 ），并根据实际情况注明 反馈理由； 示例： V103 版本验证此问题仍然存在； 步骤： XXX 出现时间： XXX 测试环境： XXX 截图、日志； 测试、开发有争议的 bug：指派给对应产品经理，进行讨论确认修改方案；由产品经理编辑 bug 状态为激活 /不予处理 / 转为需求，并注明理由。 示例： 测试认为 ip 地址设置错误，应该提示用户，而不应该程序出现停止运行； 无法修复的 bug：将 bug 状态修改为公认 (外部原因 /不予解决 )，并注明公认理由； 无法重现的 bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追 溯 3 个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号； 示例： V103 暂未复现，先关闭； 需延期的 bug：将 bug 状态修改为低，计划完成日期修改为计划解决 bug 的日期；并注明延 期理由； 示例： 需求变更，改动量很大，影响版本发布时间； 产品确认需要修改的 bug：将 bug 状态修改为打回，指派给对应的开发人员，并注明修改内 容； 产品确认不需要修改的 bug：将 bug 状态修改为已解决，并注明不需要修改原因； 不是本端的 bug：由 bug 所在端（本端）人员给出分析说明，转给对应端和开发人员，并口 头通知； 6、Bug 跟踪类别 bug： 测试人员判定为 bug 的问题； 优化： 功能已实现，需要做性能优化的问题； 建议： 测试对于产品的一些改进建议； 需求： 需要产品重新梳理的需求问题； 7、Bug 状态 新建： 测试人员新提交的 bug、优化或者建议的问题状态； 进行中： 开发人员已确认是 bug，需要修改的问题状态； 已解决： 开发人员已修复的问题状态； 已关闭： 测试验证，确定已解决的问题状态； 已拒绝