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

背景

本篇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

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

confirming/debugging by dev

resolved

rejected

testing

closed

confirming by tester

obsolete

流程图2

resolve

pass

fail/reopen

not a bug

duplicated

postpone

active

resolved

rejected

closed

obsolete