Bug流程规范

一、概述

本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。

二、关键角色及职责

角色	职责
测试	1.根据规范提交bug 2.及时验证bug是否已解决 3.及时关注开发拒绝bug，和相关人员沟通讨论解决方式
	1.定期审核测试提交的相关bug 2.定期review bug，报告现状，并给出解决意见
开发	以优先级为依据分析解决bug
	分析bug解决进度，对产品质量及进度进行风险评估
	对于长时间为解决的bug给予方案
产品	1.当开发和测试存在意见分歧时，进行需求确认 2.从产品角度划分bug修改的优先级

三、Bug生命周期

1.app的测试周期：测试环境——灰度环境——远程环境——发版（线上环境）

2.web端的测试周期：测试环境——灰度环境——上线

四、Bug书写规范

        1.主题

• 以一个简短的句子描述某个模块存在的问题，或者某个操作导致了什么问题
• 描述问题时要简练，直接切入主题，但是要抓住要点
• 偶现bug在主题前标注出现的次数
• 有些模块功能比较多，可以在主题描述前标注上具体的操作
• 示例：

     【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息

     【偶现2次】添加载体库时程序停止运行

        2.描述

说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志

• 用数字编号，一步步的描述问题的重现步骤
• 不同的操作步骤产生不同的问题，需要分别报bug，尽量做到一个bug汇报一个问题
• 偶现问题必须明确bug出现的时间、提供截图以及日志

示例：

标题：后端/android/ios/pc/pwa/h5 问题标题（备注：如果是适配问题 此设备的型号的信息系统要描述详细 ，比如：oopo R9 Plusm A 系统 5.1）
如果是特殊场景 出现问题的邮箱、商品id以及接口数据
操作描述：xxxx----xxx---问题的操作路径描述
期望结果 ：XXXXX
问题附件或者截图

五、Bug解决方案

当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）；

1.开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法；

示例：

     验证版本：V7.8.2等等
          问题原因：未作条件判断
          解决方法：进行合理边界判断

2.开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；

示例：

      参考XXX设计，测试人员理解错误；

3.bug缺乏必要的信息：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；

示例：

      缺少必须日志；

4.开发已修复，测试验证通过的bug：将bug状态置为已解决，并注明通过版本号；

示例：

     验证通过

5.开发已修复，测试验证不通过的bug：将bug状态置为打回，并根据实际情况注明反馈理由；

示例：

     版本验证此问题仍然存在；

     步骤：XXX

     出现时间：XXX

     测试环境：XXX

     截图、日志；

6.测试、开发有争议的bug：将跟踪类别置为需求，状态置为反馈；指派给对应产品，进行讨论确认修改方案；并注明反馈理由；

示例：

     测试认为ip地址设置错误，应该提示用户，而不应该程序出现停止运行；

7.无法修复的bug：将bug状态修改为挂起，并注明挂起理由；

8.无法重现的bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追溯3个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；

示例：

     V7/8/2暂未复现，先关闭；

9.需延期的bug：将bug状态修改为低，计划完成日期修改为计划解决bug的日期；并注明延期理由；

示例：

     需求变更，改动量很大，影响版本发布时间；

10.产品确认需要修改的bug：将bug状态修改为打回，指派给对应的开发人员，并注明修改内容；

11.产品确认不需要修改的bug：将bug状态修改为已解决，并注明不需要修改原因；

12.不是本端的bug：由bug所在端（本端）人员给出分析说明，转给对应端和开发人员，并口头通知；

六、Bug跟踪类别

bug：测试人员判定为bug的问题；

优化：功能已实现，需要做性能优化的问题；

建议：测试对于产品的一些改进建议；

需求：需要产品重新梳理的需求问题；

七、Bug状态

新建：测试人员新提交的bug、优化或者建议的问题状态；

进行中：开发人员已确认是bug，需要修改的问题状态；

已解决：开发人员已修复的问题状态；

已关闭：测试验证，确定已解决的问题状态；

已拒绝：开发认为不是bug，拒绝给测试的问题状态；

反馈：反馈给产品确认的问题状态；

公认：确认是bug，但是无法解决的问题状态；

打回：测试验证已解决bug，仍然没有修复的问题状态；

八、Bug等级

非常严重：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题

示例：

       程序无法启动，或者登录；

       程序崩溃、停止运行，系统死机，无法进行下一步的操作

       功能未实现、

       流程不通 

严重：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；

示例：

      偶现的程序崩溃、停止运行

      功能未实现

      数据不同步

      功能错误，无法进行后续操作

       数据没有返回

       页面崩溃

       页面报错 

一般：次要功能或者界面存在的一些错误，不影响正常测试；

示例：

      界面返回的数据不符

      提示语不正确；

      错别字；

       查询结果显示错误

      没有提示语

轻微：界面的UI问题

示例

      界面UI显示和效果图不一致；

     文字大小

     文字颜色等不一致

九、其它注意事项

1)   开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；

2)   开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；

3)   测试需及时验证已修复bug；

4)   产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；

5)   重新指派bug后，需要口头或者企业微信告知对方；

6)   bug的优先级划分比较重要；