bug管理规范及流程.pdf

《bug管理规范及流程.pdf》由会员分享，可在线阅读，更多相关《bug管理规范及流程.pdf（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、bug 管理规范及流程 1、概述 本文档定义 bug 的整个生命周期,规范 bug 的解决方案及管理流程。Bug 在流转的过程中有章可循。规范 bug 严重等级与 bug 解决优先级，使开发人员与测试人员能根据此文档准确判断 bug 的严重程度并加以解决；2、关键角色及职责 角色 职责 测试工程师 1。根据规范提交bug；2.及时验证 bug 是否已解决；3.及时关注开发拒绝 bug,和相关人员沟通讨论解决方式；测试经理 1.审核测试工程师提交的 bug;2。定期 review bug，报告现状，并给出解决意见；开发工程师 1.以优先级为依据分析解决 bug 开发主管 1。定期 review

2、bug，对 bug 多的模块加强 code review 和单元测试；2。分析 bug 解决进度，对产品质量及进度进行风险评估；产品 1、当开发和测试存在意见分歧时,进行需求确认 2、从产品角度划分 bug 修改的优先级;3、Bug 生命周期 4、Bug 书写规范 4.1 BUG 标题 1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题;2)描述问题时要简练、直接切入主题,但是要抓住要点；3)偶现 bug 在主题前标注出现的次数；4)有些模块功能比较多,可以在主题描述前标注上具体得操作；示例：【偶现 3 次】【账号切换】登录非本机手机号,切换回本机号码登录后,收不到消息【偶

3、现 2 次】添加载体库时程序停止运行 4。2 重现步骤 说明区域包括：步骤、预计结果、实际结果、测试环境、bug 出现时间、截图、日志 1)用数字编号，一步步的描述问题的重现步骤；2)不同的操作步骤产生不同的问题,需分别报 bug；尽量做到一个 bug 汇报一个问题；3）偶现问题必须明确 bug 出现的时间、提供截图以及日志；5、Bug 解决方案 当天提交的新建状态bug，对应的开发人员需在 2 天内全部审核一遍，将 bug 分成以下3 类：拒绝、进行中、延期、反馈(给产品）；开发已修复的 bug：将 bug 状态置为已解决;同时添加说明验证版本号、错误原因、解决办法；示例：验证版本：V1.0

4、.1。1101（1101 表示在 11 月 1 号可以验证）问题原因：未作条件判断解决方法：进行合理边界判断 开发认为不是 bug:将 bug 状态置为已拒绝;指派给 bug 提出者；同时注明拒绝理由；示例：参考 XXX 设计,测试人员理解错误；bug 缺乏必要的信息，无法重现:将 bug 状态置为已拒绝（无法重现）；指派给 bug 提出者；同时注明拒绝理由;示例：缺少必须日志;开发已修复,测试验证通过的 bug:将 bug 状态置为关闭,并注明通过版本号；示例：V1.0。1。1103 验证通过 开发已修复，测试验证不通过的 bug:将 bug 状态置为打回（激活）,并根据实际情况注明反馈理由

5、；示例:V1.0.1.1103 版本验证此问题仍然存在；步骤:XXX 出现时间：XXX 测试环境：XXX 截图、日志；测试、开发有争议的 bug:指派给对应产品经理，进行讨论确认修改方案；由产品经理编辑 bug 状态为激活/不予处理/转为需求，并注明理由。示例：测试认为 ip 地址设置错误，应该提示用户,而不应该程序出现停止运行;无法修复的 bug：将 bug 状态修改为公认（外部原因/不予解决），并注明公认理由；无法重现的 bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追溯 3 个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号;示例：V1.0.1

6、。1103 暂未复现，先关闭；需延期的 bug：将 bug 状态修改为低，计划完成日期修改为计划解决 bug 的日期；并注明延期理由;示例:需求变更，改动量很大，影响版本发布时间；产品确认需要修改的 bug：将 bug 状态修改为打回，指派给对应的开发人员，并注明修改内容；产品确认不需要修改的 bug：将 bug 状态修改为已解决，并注明不需要修改原因；不是本端的 bug：由 bug 所在端(本端）人员给出分析说明,转给对应端和开发人员，并口头通知；6、Bug 跟踪类别 bug：测试人员判定为 bug 的问题；优化：功能已实现，需要做性能优化的问题;建议：测试对于产品的一些改进建议；需求:需要

7、产品重新梳理的需求问题；7、Bug 状态 新建：测试人员新提交的 bug、优化或者建议的问题状态；进行中：开发人员已确认是 bug,需要修改的问题状态；已解决：开发人员已修复的问题状态；已关闭：测试验证，确定已解决的问题状态;已拒绝：开发认为不是 bug，拒绝给测试的问题状态；反馈:反馈给产品确认的问题状态;公认：确认是 bug，但是无法解决的问题状态；打回：测试验证已解决 bug，仍然没有修复的问题状态；8、Bug 严重程度 致命：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题 示例：程序无法启动，或者登录；程序崩溃、停止运行，系统死机，无法进行下一步的操作 严重：部分

8、功能存在严重缺陷，尚可继续测试，不影响产品稳定性；示例：偶现的程序崩溃、停止运行 功能未实现 数据不同步 功能错误,无法进行后续操作 一般：次要功能或者界面存在的一些错误，不影响正常测试；示例:界面 UI 显示和效果图不一致;提示语不正确;错别字;查询结果显示错误 建议：测试对于产品的一些改进建议;9、Bug 优先级 4 低：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；3 中：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；2 高：必须在版本发布之前修改完；1 紧急：影响测试，需立即或者下一个版本修复;10、其他注意事项 1)开发人员没有关闭 bug 的权限，所有问

9、题均需经过测试验证无误后才可关闭；2）开发、测试双方有争议的 bug,必须经过产品的确认才可进行下一步的操作;3)测试需及时验证已修复 bug；4)产品人员可以根据产品的阶段性需求重新分配 bug 解决的优先级；5)重新指派 bug 后，需要口头或者 QQ 告知对方；6)bug 的优先级划分比较重要；11、禅道 bug 提交流程参考：http:/www.zentao。net/book/zentaopmshelp/133。html 附件:禅道 bug 管理规范 V1。0 禅道系统 bug 严重程度（即 bug 等级)1=致命 bug，2=严重 bug，3=一般 bug，4=建议.致命 bug：不能完全满足应用要求导致应用闪退和应用停止运行 严重 bug：严重地影响应用需求或基本功能的实现,使应用不稳定、或破坏数据、或产生错误结果，或部分功能无法执行。一般 bug:使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能 建议：希望提出的建议进行修改，但不强制要求修改。不会给发布的准确性或可用性带来任何严重影响。Bug 类型:代码错误取 1、2、3，默认值取 3；界面优化取 3、4，默认值取 4；设计缺陷取 1、2,设计缺陷默认取 2。BUG 类型指派说明：代码错误-程序问题-开发人员 界面优化-建议-产品经理 设计缺陷-需求-产品经理