7. Bug管理规范

1. Bug状态管理

状态	描述	备注
Active	测试人员发现bug并提交，待修改状态。	Bug初始状态
Resolved	开发人员修改完bug，bug变更为已解决状态。	Bug中间态
Closed	测试人员回归通过，变更为已通过状态。	Bug完成态
Postpone	经确认不需要在本次发布范围之内修改，变更为推迟修改状态/挂起状态。	Bug中间态
Rejected	开发人员确认不是bug，变更为非bug状态。	Bug中间态
Obsolete	重复和非bug的，经过测试人员确认后，变更为废弃状态。	Bug完成态

2. Bug生命周期流转

Resolve

Fail

Pass

Not a bug/Duplicated

Confirm

Active

Resolved

Closed

Rejected

Obsolete

Postpone

3. Bug等级与优先级

• Bug等级与优先级的定义

  Bug严重程度	描述	优先级与紧急程度
  P1，致命的	阻塞测试、引起系统崩溃、其他功能不可用和造成数据丢失等缺陷。	最高优先级，紧急，必须立即解决（可以设定时间标准，比如必须2小时内解决，供参考）。
  P2，严重的	主要功能未实现、未达标、不可用，可能还会引起其他部分功能失效。	高优先级，紧急，需要尽快解决。
  P3，一般的	一般的缺陷，不影响主要功能和流程的实现。	一般优先级，不紧急。
  P4，提示的	优化建议，最好修改，但不是必须的，不影响上线发布；或者是本轮挂起的，但是后面再修改的。	低优先级，可以暂不处理。

4. Bug类型

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

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

  Bug类型的归类，是质量分析的重要参照物，可以根据当前项目质量分析的程度，来决定要不要启用。

5. Bug提报规范

1. Bug提报原则

   • 规范问题单提报的目的，是为了提高问题处理效率。
   • 所有问题都要提单，有条件重现，无规律重现，难重现的一样提单。
   • 问题出现需要先定位，抓包、日志、数据库、截图。
   • 问题初步定位后，及时提单，避免遗忘，也给开发留有充足的时间修复。
   • P1级别Bug及时通知开发，尽快修正，避免阻塞其他测试。
   • 其他级别的Bug直接跟踪，不需要挨个确认。
   • 低级别bug（文字符号、提示信息等）可以汇总一起提个单，在描述中分条目列出；这种情况要跟开发说清楚，避免看bug时遗漏

2. Bug提报格式

   • 项目
   • 主题：【xx需求】xxx问题
   • 报告人
   • 描述
     • 【预置条件】
     • 【测试步骤】
     • 【期望结果】
     • 【实际结果】
     • 【问题描述】
     • 【截图】
     • 【日志】
   • 经办人
   • Epic Link
   • Sprint
   • bug状态
   • Bug优先级
   • Release to

3. Bug信息填写规范

   • 项目：Bug归属的项目组

   • 主题：简明扼要地描述是什么问题，归属哪个业务

   • 详细描述：

     • 测试步骤/问题描述：
       • 对于简单的问题，简明扼要地描述测试步骤或直接描述问题；
       • 对于复杂的问题，需要细化测试步骤、预期结果和实际结果，以便开发人员能更好的理解问题。
     • 测试数据：提供测试数据，以便开发人员可以重现问题。
     • 截图/日志：有截图提供截图，有日志提供日志，截图和日志可以帮助开发人员花较少的时间来定位问题。
     • 问题分析：测试人员通过抓包、日志、检查数据库等工具和手段来初步定位出问题，主要目的是帮助开发人员快速定位出问题。（实际情况下，测试人员一方面要培养自己定位问题的能力，另一方面也要合理安排自己的测试进度，避免出现死磕一个问题，而影响整体测试进度的情况。）

   • 报告人：bug提出人

   • 经办人：开发对象

   • Bug优先级（严重等级）：

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

   • Bug状态：

     Bug状态	描述
     Active	测试人员发现bug并提交，待修改状态。
     Resolved	开发人员修改完bug，bug变更为已解决状态，可验证。
     Closed	测试人员回归通过，变更为已通过状态。
     Obsoleted	重复和非bug的，经过测试人员确认后，变更为废弃状态。

   • Sprint：当前的迭代信息。

   • Epic：项目有Epic时，关联相应的Epic，方便统计。

   • Release to：没有Epic时，关联story，方便统计。

6. Bug管理与跟踪

1. Bug的解决时效根据优先级来跟踪。
2. Bug的状态需要及时更新。
3. 原则上，有未解决的Bug不能发版，需要经过项目经理、开发测试leader和产品一起评估后，才能决定是否将Bug挂起。
4. 挂起的Bug要在迭代结束后确认好解决版本，并修改相应信息。