Bug定义、管理的一点简单思考

短命女 2022-03-06 09:20 630阅读 0赞

# 背景 #

本篇Bug分析是基于公司现状，结合实际需要进行的简要分析，以期能规范Bug提报，优化Bug管控，提高开发和测试间的协作效率，为质量度量提供参考数据。

# 一、Bug状态管理 #

1.  当前Bug状态：
    
     *  active
     *  resolved
     *  closed
     *  obsolete
2.  建议Bug状态：
    
     *  active：测试人员发现bug并提交，待修改状态。
     *  resolved：开发人员修改完bug，bug变更为已解决状态。
     *  closed：测试人员回归通过，变更为已通过状态。
     *  reopen：测试人员回归不通过，变更为需再次修改状态。
     *  postpone：经确认不需要在本次发布范围之内修改，变更为推迟修改状态。
     *  rejected：开发人员确认不是bug，变更为非bug状态。
     *  duplicated：开发人员确认是重复bug，变更为重复bug状态。
     *  obsolete：重复和非bug的，经过测试人员确认后，变更为废弃状态。
3.  在发布前，只能有closed、postpone和obsolete状态的bug留存。
4.  当状态变更为closed、postpone和obsolete时，jira单子的状态自动变成“完成”。

# 二、Bug生命周期 #

### 流程图1 ###

resolve

pass

fail

confirmed

rejected

active

confirming/debugging by dev

resolved

postpone

rejected

duplicated

testing

closed

reopen

confirming by tester

obsolete

### 流程图2 ###

resolve

pass

fail

confirmed

active

resolved

postpone

rejected

duplicated

closed

reopen

obsolete

# 三、Bug严重等级定义、bug优先级定义 #

## 3.1 Bug严重等级 ##

*  致命P1：阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷；
 *  严重P2：主要功能未实现、未达标、不可用，可能还会引起其他部分功能失效；
 *  一般P3：一般的缺陷，不影响主要功能和流程的实现；
 *  提示P4：优化建议，最好修改，但不是必须的，不影响上线发布。

## 3.2 Bug优先级 ##

*  Highest：最高优先级，必须加急解决（可以设定时间标准，比如必须2小时内解决，供参考）；
 *  High：高优先级，优先解决bug序列，在没有加急的bug前提下，需要优先处理这些bug（比如可以在下次发版前解决）；
 *  Low：低优先级，可以暂时不处理；
 *  Lowest：最低优先级：可以暂时不处理，甚至本轮发布不处理（比如postpone的bug）。

## 3.3 关于严重等级与优先级 ##

测试人员在提报bug时，需要结合bug严重等级和bug优先级来定义bug：

*  bug严重等级根据缺陷引发的影响范围，来定义缺陷严重程度的标准；
 *  bug优先级是根据项目进度和计划，来定义缺陷解决紧急程度的标准。
 *  一个小的功能未实现（P3），也可以是最高优先级（Highest），需要加急解决的；一个大的功能未实现（P2），也可以是低优先级（lowest），暂时不需要修改的。例如：商详页的某些显示，从缺陷的严重程度来说，不是很大的，不会引起系统崩溃、或者引发其他问题的严重缺陷，但是对用户的影响面很大，感知不好，这种优先级就较高；门店统计报表功能查询有问题，但是目前可能没有多少人用，或者我们有其他替代方案可以提供数据，这种功能未实现的，严重的问题，由于影响面较小，优先级也可以放低，在时间紧急的情况下，可以暂时上线其他功能。
 *  从度量角度来说，bug严重程度能反映出开发人员的代码质量，和测试人员的测试质量；
 *  从项目进度和开发人员修改bug的角度来说，bug优先级能给出解决问题的顺序。

在我们的jira里：bug严重等级叫：bug优先级；bug优先级叫：优先级。如果可以的话，建议更新一下字段名，便于区分。

# 四、Bug类型 #

从测试类型上来分：功能性缺陷、性能缺陷、易用性缺陷、安全性缺陷等；

从缺陷引发的阶段类型来分：需求缺陷、设计缺陷、编码缺陷、环境问题、数据配置问题、测试操作问题等。

我们目前主要还是以功能测试为主，接口、自动化、性能为辅，建议暂时可以不引入这些概念。如果后续需要更细粒度的度量标准，可以考虑再引入。

# 五、Bug提报规范 #

## 5.1 Bug提报结构 ##

*  标题：简单清楚地描述出是什么问题
 *  环境：测试环境
 *  详细描述：
    
     *  测试步骤/问题描述：
        
         *  对于简单的问题，简明扼要地描述测试步骤或直接描述问题；
         *  对于复杂的问题，需要细化测试步骤、预期结果和实际结果，以便开发人员能更好的理解问题。
     *  测试数据：提供测试数据，以便开发人员可以重现问题。
     *  截图/日志：有截图提供截图，有日志提供日志，截图和日志可以帮助开发人员花较少的时间来定位问题。
     *  问题分析：测试人员也需要逐步提高自己的问题定位能力，通过截图和日志来初步定位出问题，主要目的也是帮助开发人员快速定位出问题。（实际情况下，测试人员一方面要培养自己定位问题的能力，另一方面也要合理安排自己的测试进度，避免出现死磕一个问题，而影响整体测试进度的情况。）
 *  报告人：bug提出人
 *  经办人：bug指派人
 *  严重等级
 *  优先级
 *  关联的Sprint/Epic/Release tag等。

## 5.2 其他字段处理 ##

我们的jira里，创建bug时，有很多其他字段，个人建议，可以去除一部分，只留下有用的，可度量的指标性字段。可以开个脑暴会议，对照当前界面讨论一下。

### 流程图1 ###

resolve

pass

fail/reopen

not a bug

postpone

duplicated

confirmed

rejected

active