待确认：测试方认为该问题是一个缺陷， 待与需求或开发进一步确认 （中 间过程状态，未确定是否为有效缺陷） 待修改： 开发修改中（有效缺陷） 验证中： 该缺陷开发已修复，测试方正对该问题进行回归测试中（有效 缺陷） 退回修改： 该缺陷回归测试不通过，重新退回给开发修改（有效缺陷） 仲裁： 测试方和需求方或开发方对该缺陷是否有效未能达成一致意见， 问题已提交相关人员进行仲裁中。 （中间过程状态，未确定是否为有效缺 陷） 修改确认通过： 开发已修复，且测试方已回归测试通过（有效缺陷） 关闭： 经确认或仲裁为无效缺陷 遗留： 有效缺陷，但经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理 注: 测试完成后，只允许修改确认通过、关闭、遗留这三种状态存在。
5
2.2
流程说明 ............................................................................
5
2.2.1
提交问题 .......................................................................
文件编号：
缺陷管理流程
修改编号 1
版本 V0.1
修改履历
修改条款及内容 初稿
修改日期
目录
1. 概述 ...................................................................................
4
1.1
目的 ................................................................................
9
1. 概述
1.1 目的
本文为缺陷管理模块缺陷跟踪处理流程介绍及操作指南，目的是对测试室在 进行缺陷管理的过程中提供参考。
1.2 适用范围
本流程适用于银行测试缺陷管理工作。
1.3 角色职责
角色（岗位）
职责
测试执行岗
1. 执行测试工作， 负责提出新问题， 并对开发岗已修改的 问题进行验证
开发岗
1. 负责对待修改的问题进行修复
6
2.2.6
测试监控 .......................................................................
6
3. 缺陷定义 ...............................................................................
2. 流程
2.1 流程图
缺陷管理流程
输入
测试用例
测试执行岗
开发岗
需求分析岗
提交新问题 待确认
确认是否为缺陷 是
确认为开发问 题
分歧 是
仲裁
是否为程序 缺陷
否 打开问题
待修改
修改问题
需求缺陷 无效缺陷
验证中
是否通过 否
退回修改 是
待验证
修改确认 通过
待验证
待修改
修改问题
关闭
输出
含结果测试用 例
缺陷跟踪表
3.1.2 缺陷类型
需求缺陷： 业务需求错误。包含需求功能流程错误、需求不完整、不一 致、有遗漏、不可行、描述不清晰等。 开发缺陷： 开发修改引起的问题。 历史遗留： 不属于此测试任务的问题 , 属于历史遗留问题 , 如果对此问题 修改后出现其它问题的话 , 衍生的问题应填相应的其它缺陷类型。 建议改善： 易用性、界面风格等建议改善。 操作错误： 测试人员操作错误或理解错误 , 属于无效缺陷。 环境问题： 本测试任务的环境问题。 跑批问公式
缺陷总数 本月发现的总有效缺陷数
缺陷密度
缺陷有效率
缺陷严重程度 缺陷修复质量 缺陷修复速度 缺陷修复程度
缺陷分布
反映测试小组发现缺陷的能 力和开发质量 反映测试小组发现缺陷的能 力和开发质量 说明缺陷给最终交付的系统 或产品可能造成的影响程度 缺陷的问题验证通过次数 缺陷修复延误天数 遗留缺陷为有效而未修复的 缺陷 缺陷分布各室的数量
7
3.1.3
缺陷严重级别 ...................................................................
7
3.1.4
缺陷优先级别 ...................................................................
2) 如果确认中，该问题经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理，为有效缺陷。 （如何定义哪些是遗留，是指缺陷难以重 现、技术问题暂时无法解决的情况吗？）
2.2.3 修改缺陷
确认为程序缺陷后，测试执行岗打开问题，开发岗对待修改的缺陷进行 修复。在进行修改时，开发岗需对缺陷做原因分析等注释。 2.2.4 验证缺陷
4
2. 流程 ...................................................................................
5
2.1
流程图 ..............................................................................
3.1.4 缺陷优先级别
表明缺陷需要被解决的紧急程度，包括四个级别： 紧急：要求在 4 工时内解决，对系统大部分功能、或主要功能有影响 高：要求在一个工作日内解决，影响了系统的部分功能 中：要求在两个工作日内解决，对其它功能模块影响较小 低：要求在当前版本解决，对其它功能模块无影响
4. 度量指标
收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
1) 开发岗修复完缺陷后提交给测试执行岗进行回归测试，结果一般会出现 以下两种情况： 如果该缺陷经验证不通过，测试执行岗退回修改给开发岗，开发岗需 对待修改的缺陷进行修复并提交给测试执行岗进行重新验证，直至验 证通过。 如果通过测试验证，则该问题便是修改确认通过。
2) 如果验证中，该缺陷经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理，为有效缺陷。 （如何详细定义遗留问题？后续如何跟 进？）
4
1.4
入口标准 ............................................................................
4
1.5
输入 ................................................................................
4
1.6
输出 ................................................................................
4
1.7
出口标准 ............................................................................
需求分析岗 1. 分析缺陷，并为测试方和开发方在缺陷有效性的分歧 上，进行仲裁
测试主管岗 1. 测试执行过程中， 对缺陷提交情况、 修复情况进行监控
1.4 入口标准
正式执行测试，测试方发现问题
1.5 输入
测试用例
1.6 输出
含结果测试用例 缺陷跟踪表
1.7 出口标准
完成测试，所有问题进行修复验证或其他方式处理 缺陷数量按版本呈明显收敛趋势 遗留缺陷不能大于有限缺陷的 8%
7
3.1.1
缺陷状态 .......................................................................
7
3.1.2
缺陷类型 .......................................................................
3.1.3 缺陷严重级别
严重 级别
致命
描述
不能执行正常工作或重 要功能、 导致系统崩溃或 资源严重不足、 造成数据 丢失
详细说明
功能未实现或实现错误 数据计算错误、产生错误结果 程序死循环、数据库发生死锁 因错误操作导致的程序中断
严重
严重影响系统要求或基 本功能实现、 且不存在可 替代的解决方法或方式
4
1.2
适用范围 ............................................................................
4
1.3
角色职责 ............................................................................
5
2.2.2
分析定位缺陷 ...................................................................
6
2.2.3
修改缺陷 .......................................................................
8
4. 度量指标 ...............................................................................
8
5. 沟通机制 ...............................................................................