禅道bug流程文档格式.docx

禅道bug流程文档格式.docx

《禅道bug流程文档格式.docx》由会员分享，可在线阅读，更多相关《禅道bug流程文档格式.docx（10页珍藏版）》请在冰豆网上搜索。

测试工程师

1.根据规范提交bug；

2.及时验证bug是否已解决；

3.及时关注开发拒绝bug，和相关人员沟通讨论解决方式；

测试负责人

1.审核测试工程师提交的bug；

2.定期reviewbug，报告现状，并给出解决意见；

开发工程师

1.以优先级为依据分析解决bug

研发经理

1.定期reviewbug，对bug多的模块加强codereview和单元测试；

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优先级

对产品的影响比较小，在时间不允许的情况下可以暂时不修改；

必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；

必须在版本发布之前修改完；

影响测试，需立即或者下一个版本修复；

8 

其他注意事项

1） 

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

2） 

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

3） 

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

4） 

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

5） 

重新指派bug后，需要口头或者QQ告知对方；

6） 

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

7）开发人员解决bug时，动了已经测试通过的模块，需要备注一下影响范围；