bug管理标准规范及作业流程.docx

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状态置为已处理；同时添加说明验证版本号、错误原因、处理措施；
示例：
验证版本：V1.0.1.1101（1101表示在11月1号能够验证）
问题原因：未作条件判定
处理方法：进行合理边界判定
开发认为不是bug：将bug状态置为已拒绝；指派给bug提出者；同时注明拒绝理由；
示例：
参考XXX设计，测试人员了解错误；
bug缺乏必需信息，无法重现：将bug状态置为已拒绝（无法重现）；指派给bug提出者；同时注明拒绝理由；
示例：
缺乏必需日志；
开发已修复，测试验证经过bug：将bug状态置为关闭，并注明经过版本号；
示例：
V1.0.1.1103验证经过
开发已修复，测试验证不经过bug：将bug状态置为打回（激活），并依据实际情况注明反馈理由；
示例：
     V1.0.1.1103版本验证此问题仍然存在；
     步骤：XXX
     出现时间：XXX
     测试环境：XXX
     截图、日志；
测试、开发有争议bug：指派给对应产品经理，进行讨论确定修改方案；由产品经理编辑bug状态为激活/不予处理/转为需求，并注明理由。
示例：
     测试认为ip地址设置错误，应该提醒用户，而不应该程序出现停止运行；
无法修复bug：将bug状态修改为公认(外部原因/不予处理)，并注明公认理由；
无法重现bug：关键依靠日志分析问题原因，然后进行对应修改；开发修改后，测试追溯3个版本、或使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；
示例：
     V1.0.1.1103暂未复现，先关闭；
需延期bug：将bug状态修改为低，计划完成日期修改为计划处理bug日期；并注明延期理由；
示例：
     需求变更，改动量很大，影响版本公布时间；
产品确定需要修改bug：将bug状态修改为打回，指派给对应开发人员，并注明修改内容；
产品确定不需要修改bug：将bug状态修改为已处理，并注明不需要修改原因；
不是本端bug：由bug所在端（本端）人员给出分析说明，转给对应端和开发人员，并口头通知；
6、Bug跟踪类别
bug：测试人员判定为bug问题；
优化：功效已实现，需要做性能优化问题；
提议：测试对于产品部分改善提议；
需求：需要产品重新梳理需求问题；
7、Bug状态
新建：测试人员新提交bug、优化或提议问题状态；
进行中：开发人员已确定是bug，需要修改问题状态；
已处理：开发人员已修复问题状态；
已关闭：测试验证，确定已处理问题状态；
已拒绝：开发认为不是bug，拒绝给测试问题状态；
反馈：反馈给产品确定问题状态；
公认：确定是bug，不过无法处理问题状态；
打回：测试验证已处理bug，仍然没有修复问题状态；

8、Bug严重程度
致命：不能实施正常功效操作，或因产品原因造成系统死机，需立即修复问题
示例：
       程序无法开启，或登录；
       程序瓦解、停止运行，系统死机，无法进行下一步操作
严重：部分功效存在严重缺点，尚可继续测试，不影响产品稳定性；
示例：
      偶现程序瓦解、停止运行
      功效未实现
      数据不一样时
      功效错误，无法进行后续操作
通常：次要功效或界面存在部分错误，不影响正常测试；
示例：
      界面UI显示和效果图不一致；
      提醒语不正确；
      错别字；
      查询结果显示错误
提议：测试对于产品部分改善提议；

9、Bug优先级
4低：对产品影响比较小，在时间不许可情况下能够临时不修改；
3中：必需修改，不一定立即修改，需讨论确定在某个特定里程碑前修改完；
2高：必需在版本公布之前修改完；
1紧急：影响测试，需立即或下一个版本修复；
10、其它注意事项
1)   开发人员没相关闭bug权限，全部问题均需经过测试验证无误后才可关闭；
2)   开发、测试双方有争议bug，必需经过产品确实定才可进行下一步操作；
3)   测试需立即验证已修复bug；
4)   产品人员能够依据产品阶段性需求重新分配bug处理优先级；
5)   重新指派bug后，需要口头或QQ通知对方
6)   bug优先级划分比较关键；

11、禅道bug提交步骤参考：

附件：

禅道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类型指派说明：
代码错误----程序问题---开发人员
界面优化----提议------产品经理
设计缺点----需求-------产品经理