禅道bug流程.doc

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解决方案
Bug解决方案分为：已解决、外部原因、设计如此、重复bug、无法重现、延期解决、不予解决

一、无争议类
A. 解决方案 已解决
开发已修复的bug：bug解决方案置为已解决；同时添加说明错误原因、解决办法；
示例：
          问题原因：未作条件判断
          解决方法：进行合理边界判断

B.解决方案 外部原因
开发认为不是bug：bug解决方案置为外部原因；指派给bug提出者；同时注明置为外部原因的理由；
示例：

C.解决方案 无法重现
无法重现的bug：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追溯3个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；
D.解决方案 延期解决
需延期的bug：将bug解决方案置为延期解决，并注明延期理由；
示例：

E．解决方案 重复bug
开发认为bug重复：将bug解决方案置为重复bug，并标注重复bug的ID，并备注原因。

二、争议类
测试、开发有争议的bug：备注争议内容，并指派给对应产品，进行讨论确认修改方案；讨论后产品备注解决办法，并指派给对应的开发or测试；
A、 产品确认需要修改的bug：将bug指派给对应的开发人员，并注明修改内容；
示例：

B、 产品确认不需要修改的bug：将bug解决方案置为设计如此、不予解决，并注明不需要修改原因，指派给bug创建人员；
示例：

三、测试关注点：
开发已修复，测试验证通过的bug：关闭bug，并注明通过或者现状；
示例：
    验证通过
开发已修复，测试验证不通过的bug：将bug激活，并根据实际情况注明激活理由；
示例：

5     Bug状态
激活：开发还未解决的问题状态；
已解决：开发人员已确认或已修复的问题状态；
已关闭：测试验证，确定已解决的问题状态；
6    Bug严重程度
1级：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题
示例：
       程序无法启动，或者登录；
       程序崩溃、停止运行，系统死机，无法进行下一步的操作
2级：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；
示例：
      偶现的程序崩溃、停止运行
      功能未实现
      数据不同步
      功能错误，无法进行后续操作
3级：次要功能或者界面存在的一些错误，不影响正常测试；
示例：
      界面UI显示和效果图不一致；
      提示语不正确；
      错别字；
      查询结果显示错误
4级：测试对于产品的一些改进建议；
7    Bug优先级
4级：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；
3级：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；
2级：必须在版本发布之前修改完；
1级：影响测试，需立即或者下一个版本修复；

8   其他注意事项
1)   开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；
2)   开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；
3)   测试需及时验证已修复bug；
4)   产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；
5)   重新指派bug后，需要口头或者QQ告知对方；
6)   bug的优先级划分比较重要；
7) 开发人员解决bug时，动了已经测试通过的模块，需要备注一下影响范围；