缺陷管理流程

缺陷管理流程
文件编号：
缺陷管理流程
修改履历
修改编号版本修改条款及内容修改日期1 V0.1 初稿
目录
1.概述 (4)
1.1目的 (4)
1.2适用范围 (4)
1.3角色职责 (4)
1.4入口标准 (4)
1.5输入 (4)
1.6输出 (4)
1.7出口标准 (4)
2.流程 (5)
2.1流程图 (5)
2.2流程说明 (5)
2.2.1提交问题 (5)
2.2.2分析定位缺陷 (6)
2.2.3修改缺陷 (6)
2.2.4验证缺陷 (6)
2.2.5统计数据 (6)
2.2.6测试监控 (6)
3.缺陷定义 (7)
3.1.1缺陷状态 (7)
3.1.2缺陷类型 (7)
3.1.3缺陷严重级别 (7)
3.1.4缺陷优先级别 (8)
4.度量指标 (8)
5.沟通机制 (9)
1.概述
1.1目的
本文为缺陷管理模块缺陷跟踪处理流程介绍及操作指南，目的是对测试室在进行缺陷管理的过程中提供参考。

1.2适用范围
本流程适用于银行测试缺陷管理工作。

1.3角色职责
角色（岗位）职责
测试执行岗1.执行测试工作，负责提出新问题，并对开发岗已修改的
问题进行验证
开发岗 1.负责对待修改的问题进行修复
需求分析岗1.分析缺陷，并为测试方和开发方在缺陷有效性的分歧
上，进行仲裁
测试主管岗1.测试执行过程中，对缺陷提交情况、修复情况进行监控
1.4入口标准
正式执行测试，测试方发现问题
1.5输入
测试用例
1.6输出
含结果测试用例
缺陷跟踪表
1.7出口标准
完成测试，所有问题进行修复验证或其他方式处理
缺陷数量按版本呈明显收敛趋势
遗留缺陷不能大于有限缺陷的8%
2.流程
2.1流程图
缺陷管理流程
输出
需求分析岗
开发岗
测试执行岗
输入
提交新问题
待确认
打开问题
修改问题待修改验证中待验证
是否通过
修改确认通过
测试用例
含结果测试用
例
缺陷跟踪表
退回修改
是
否修改问题
待修改
待验证
确认为开发问
题
确认是否为缺陷是仲裁分歧是否为程序
缺陷
是
否
需求缺陷修改确认通过
无效缺陷
关闭
2.2流程说明
2.2.1提交问题
测试执行岗在执行测试中，若发现问题，登录缺陷管理系统进行新问题的提交，描述问题时必须详细（必要时需附上截图），确保内容正确，定位
准确。

（有没有对缺陷处理时间的要求？）
2.2.2分析定位缺陷
1)提交问题后，测试执行岗同开发岗对该问题进行进一步确认是否为开发
方的缺陷。

结果一般会出现以下两种情况：
如果双方发生分歧异议，测试执行岗提交问题给需求分析岗进行分析定
位并仲裁：
若仲裁为开发方的缺陷，那开发岗需进行下一步的修复；
若定位为需求缺陷，进行修改确认通过，为有效缺陷；（那便是closed的状态，后续还需要进行其他方式的跟进吗？）
若是测试岗对需求理解错误等，关闭该问题，为无效缺陷；
如果确认为开发方的缺陷，那开发岗需进行下一步的修复。

2)如果确认中，该问题经开发或需求方等确认不纳入本测试任务的修改范
围，作遗留处理，为有效缺陷。

（如何定义哪些是遗留，是指缺陷难以重
现、技术问题暂时无法解决的情况吗？）
2.2.3修改缺陷
确认为程序缺陷后，测试执行岗打开问题，开发岗对待修改的缺陷进行修复。

在进行修改时，开发岗需对缺陷做原因分析等注释。

2.2.4验证缺陷
1)开发岗修复完缺陷后提交给测试执行岗进行回归测试，结果一般会出现
以下两种情况：
如果该缺陷经验证不通过，测试执行岗退回修改给开发岗，开发岗需
对待修改的缺陷进行修复并提交给测试执行岗进行重新验证，直至验
证通过。

如果通过测试验证，则该问题便是修改确认通过。

2)如果验证中，该缺陷经开发或需求方等确认不纳入本测试任务的修改范
围，作遗留处理，为有效缺陷。

（如何详细定义遗留问题？后续如何跟
进？）
3)如果验证中，测试方和开发方对该缺陷是否有效未能达成一致意见，问
题提交需求分析岗进行仲裁。

2.2.5统计数据
测试任务完成后，由相关人员整理缺陷相关数据，并进行分析处理。

2.2.6测试监控
测试主管岗在测试执行中需对缺陷提交情况、修复情况进行监控，保证按质
按时完成任务。

3.缺陷定义
3.1.1缺陷状态
待确认：测试方认为该问题是一个缺陷，待与需求或开发进一步确认（中间过程状态，未确定是否为有效缺陷）
待修改：开发修改中（有效缺陷）
验证中：该缺陷开发已修复，测试方正对该问题进行回归测试中（有效
缺陷）
退回修改：该缺陷回归测试不通过，重新退回给开发修改（有效缺陷）
仲裁：测试方和需求方或开发方对该缺陷是否有效未能达成一致意见，
问题已提交相关人员进行仲裁中。

（中间过程状态，未确定是否为有效缺
陷）
修改确认通过：开发已修复，且测试方已回归测试通过（有效缺陷）
关闭：经确认或仲裁为无效缺陷
遗留：有效缺陷，但经开发或需求方等确认不纳入本测试任务的修改范
围，作遗留处理
注:测试完成后，只允许修改确认通过、关闭、遗留这三种状态存在。

3.1.2缺陷类型
需求缺陷：业务需求错误。

包含需求功能流程错误、需求不完整、不一
致、有遗漏、不可行、描述不清晰等。

开发缺陷：开发修改引起的问题。

历史遗留：不属于此测试任务的问题,属于历史遗留问题,如果对此问题修改后出现其它问题的话,衍生的问题应填相应的其它缺陷类型。

建议改善：易用性、界面风格等建议改善。

操作错误：测试人员操作错误或理解错误,属于无效缺陷。

环境问题：本测试任务的环境问题。

跑批问题：本测试任务的跑批问题。

3.1.3缺陷严重级别
严重
级别
描述详细说明
致命不能执行正常工作或重
要功能、导致系统崩溃或
资源严重不足、造成数据
丢失
功能未实现或实现错误
数据计算错误、产生错误结果
程序死循环、数据库发生死锁
因错误操作导致的程序中断
严重严重影响系统要求或基
本功能实现、且不存在可
替代的解决方法或方式
功能未实现或实现错误
数据计算错误、产生错误结果
数据通讯错误、程序接口错误
需求功能流程错误或需求缺失
数据约束错误、数据输入输出错误财务错误
交易报错(交易报错导致交易无法继续等)
一般影响系统要求或基本功
能实现，但存在可替代的
解决方法或方式
打印内容、格式错误
简单的输入限制未放在前台进行控制
删除操作未给出提示
操作界面信息错误（包括数据窗口内
列名定义、含义是否一致）
数据库表中有过多的空字段
轻微操作不便或遇到麻烦，但
不影响执行工作或使用
重要功能
界面不规范,域控制不规范
辅助说明描述不清楚、提示窗口文字
未采用行业术语
输入输出不规范
长时间操作未给用户提示
可输入区域和只读区域没有明显的
区分标志
控件没有对齐、标点符号丢失或不正
确
需求瑕疵包括需求错别字等
3.1.4缺陷优先级别
表明缺陷需要被解决的紧急程度，包括四个级别：
紧急：要求在4工时内解决，对系统大部分功能、或主要功能有影响高：要求在一个工作日内解决，影响了系统的部分功能中：要求在两个工作日内解决，对其它功能模块影响较小
低：要求在当前版本解决，对其它功能模块无影响
4.度量指标
收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

指标含义计算公式
缺陷总数本月发现的总有效缺陷数
缺陷密度反映测试小组发现缺陷的能
力和开发质量
有效缺陷数执行用例数
缺陷有效率反映测试小组发现缺陷的能
力和开发质量
有效缺陷数总缺陷数
缺陷严重程度说明缺陷给最终交付的系统或产品可能造成的影响程度
缺陷修复质量缺陷的问题验证通过次数缺陷修复速度缺陷修复延误天数
缺陷修复程度遗留缺陷为有效而未修复的
缺陷
遗留率=遗留缺陷数总缺陷
数
缺陷分布缺陷分布各室的数量
5.沟通机制
1)当开发岗或测试岗对缺陷提出异议时，异议内容包括状态、严重级别、是
否为缺陷等，可直接向需求分析岗提出进行仲裁。

当争议比较大时，测试主管可召开会议组织相关人员参加进行讨论，需求分析岗有最终的决定权。

会议参加人员包括但不限于：需求分析岗、测试主管、开发相关人员、项目经理、邀请的技术专家等。

单纯的课本内容，并不能满足学生的需要，通过补充，达到内容的完善
教育之通病是教用脑的人不用手，不教用手的人用脑，所以一无所能。

教育革命的对策是手脑联盟，结果是手与脑的力量都可以大到不可思议。

单纯的课本内容，并不能满足学生的需要，通过补充，达到内容的完善
教育之通病是教用脑的人不用手，不教用手的人用脑，所以一无所能。

教育革命的对策是手脑联盟，结果是手与脑的力量都可以大到不可思议。

2)
3)。