Bug管理规范及流程.docx

Bug管理规范及流程.docx

《Bug管理规范及流程.docx》由会员分享，可在线阅读，更多相关《Bug管理规范及流程.docx（7页珍藏版）》请在冰豆网上搜索。

Bug管理规范及流程

Bug属性规范及流程

版本

时间

创建人

1.0

2018619

Bug属性规范及流程1

1.目的3

2.范围3

3.工具3

4.角色和职责3

5.Bug属性定义4

5.1.bug类型4

5.2•bug严重性5

5.3bug优先级5

6.Bug管理流程6

6.1提交bug6

6.2分配bug6

6.3解决bug7

6.4验证bug7

6.5遗留bug7

6.5.1跟踪遗留bug7

6.5.2产品发布后发现的bug8

6.6bug分析8

1.目的

本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。

Bug在流转的过

程中有章可循。

规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据

此文档准确判断bug的严重程度并加以解决；

2.范围

开发人员、测试人员

3.工具

禅道:

4.角色和职责

5・Bug属性定义

描述

属性名称

来源

包含所属产品、所属模块、所属项目、影响版本，选择bug来源利于开发

定位并解决;

附件

为bug添加更核心的说明，更有说服力的证据，包括截图、视频、log等

5.1

.bug类型

功能

产品功能方面的bug:

包括模块功能实现、功能使用性、逻辑性等bug

接口

与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的bug不满足系统可测量的属性值，如：

并发量、数据量、事务处理速度等

5.2.bug严重性

Bug严重性

描述

致命

（1）

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

问题

严重⑵

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

一般（3）

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

优化⑷

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

5.3bug优先级

Bug优先级

描述

紧急⑴

影响测试，需立即修复；

高⑵

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

中⑶

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

低⑷

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

6.Bug管理流程

6.1提交bug

在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。

当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。

提交后的bug状态为：

激活

6.2分配bug

开发经理对bug进行初步评审，确定并指派到相应开发人员；

分配后的bug状态为：

已确认

6.3解决bug

开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。

解决后的bug状态为：

已解决

6.4验证bug

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

确认非缺陷问题：

对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转

交给测试人员回归。

测试人员再次确认，如果真如开发人员所说，则将问题关闭。

如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

确认修复问题：

对开发人员修复的问题再次进行确认，确认能过，则关闭问题。

确认不

通过，将问题再次打开并转给开发人员。

确认固定问题：

有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的

更新或已经不存在了，对这类问题应该及时关闭。

有些固定问题依然存在且变得紧急，对于

这类问题应该及时打开交给开发人员处理。

验收通过的bug状态为：

已关闭；

验收不通过的bug状态为：

激活；

6.5遗留bug

6.5.1跟踪遗留bug

对于让步发布的产品，需要跟踪产品发布后的允许情况。

对遗留的bug跟踪记录并分析其

影响范围，知道遗留bug形成解决结果。

6.5.2产品发布后发现的bug

产品发布后的bug来源有：

客户、开发、测试人员。

该类bug在发现后需要提交给项目组，纳入bug管理，该类bug的发现阶段标识为已发布，便于分析原因。

6.6bug分析

通过bug的数据分析，总结bug出现的原因、类型、规律，采取相应措施避免该类型bug

再次出现，提高产品质量。

1）统计项目组阶段bug的趋势图，用于分析产品的质量。

2）测试人员的每个项目的测试结束以后，将bug分析结果写在《测试报告》中。