缺陷管理

缺陷管理

缺陷管理分为三部分: 缺陷描述, 缺陷级别, 缺陷状态及状态转换

1. 缺陷描述

要素: (和测试用例里面的要素是一样的)

环境, 数据, 步骤, 版本, 预期结果, 实际结果, 附件, 级别, 优先级...

这里比测试用例的要素多"实际结果"这一要素, 目的是将实际结果和预期结果进行对比, 如果结果一致, 代表功能正确, 如果不一致, 就是缺陷. 是需要进行对比的.

对于"附件" 这一要素, 当语言描述不清时, 可以从服务器里面抓取相关日志存到文档里, 将它附在研发人员的缺陷里, 这时研发人员就可以从附件里查看缺陷, 分析原因然后进行处理.

2. 缺陷级别

缺陷是分级别的, 级别是缺陷的严重程度. 优先级是修改缺陷的优先级. 原则上缺陷的级别越高, 修改的优先级越高. 但也有个别缺陷级别高, 但是修改的优先级低.

缺陷级别分为4个: 崩溃, 严重, 一般, 次要, 建议

大部分公司会有个 建议性的bug, 表示功能是没有缺陷的, 比如可能为了页面更美观, 但并非bug, 所以叫做 建议性bug.

现在企业都会有5个缺陷级别. 对应着为 A, B, C, D, F(或者为1. 2. 3. 4. 5).

3. 缺陷状态及状态转换

缺陷的7个状态: NEW OPEN FIXED DELAY REJECTED CLOSED REOPEN

标准规范的缺陷状态转换图是以 "start"开始, 以 "end"结束.

以下, 是我画出的缺陷状态转换图:

NEW 状态是由测试人员发现这个缺陷之后, 把它提交到缺陷管理平台上后, 默认状态就是NEW. 因此, NEW状态由测试人员来操作

OPEN 状态表示测试人员将bug分配给bug对应模块的研发人员后, 状态就由变为OPEN. OPEN状态由测试人员来操作.

FIXED 状态表示研发人员验证是bug, FIXED状态由研发人员来操作, 因此研发人员对bug有 3 中处理方式:

• 第一种, 研发人员验证完认为这不是缺陷, 将状态置为 REJECTED(拒绝)
• 第二种, 研发人员验证完认为这是缺陷, 但是影响不大或自己目前任务较多, 没有时间修改,暂时不影响其他核心功能, 因此将它推迟到下个版本修改.将状态置为 DELAY
• 第三种, 研发人员验证完发现它是一个缺陷, 进行修改完之后, 将状态置为 FIXED

对于修改完的缺陷, 测试人员是不可以直接关闭的, 需要先进行验证.

• 验证通过, 测试人员就将状态置为CLOSED,
• 验证失败就需要研发人员重新修改bug, 测试人员将状态置为 REOPEN

状态置为 REOPEN的bug, 就不需要再次验证了, 因为已知它是bug了, 因此就直接发给研发人员, 让研发人员进行修改.

有两个无效的缺陷: (测试人员要避免少提无效的缺陷, 在工作中影响绩效考核.)

1. 测试人员提交的缺陷, 研发人员无法验证和处理. NEW-OPEN-REJECTED-CLOSED
2. 测试人员自己提交的缺陷, 自己无法复现出来. 说明这不是一个bug, 是测试人员这边出了问题 NEW-OPEN-CLOSED

REJECTED状态和DELAY状态, 需要进行评审(因为可能研发人员和测试人员对某些缺陷有争议, 所以进行这两个状态时需要进行评审; 但不是每一次这两个状态都需要评审.)

注意:

1.评审是测试人员和研发人员有争议的时候,

2.在每轮测试之前会组织一场会议, 将所有REJECTED和DELAY状态的缺陷统一进行评审, 并不是发现一个缺陷就进行评审