缺陷管理作业流程V.docVIP

文件编号：

缺点管理步骤

修改履历

修改编号

版本

修改条款及内容

修改日期

1

V0.1

初稿

目录

TOC\o1-3\h\z\u1. 概述 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

概述

目标

本文为缺点管理模块缺点跟踪处理步骤介绍及操作指南，目标是对测试室在进行缺点管理过程中提供参考。

适用范围

本步骤适适用于银行测试缺点管理工作。

角色职责

角色（岗位）

职责

测试实施岗

实施测试工作，负责提出新问题，并对开发岗已修改问题进行验证

开发岗

负责对待修改问题进行修复

需求分析岗

分析缺点，并为测试方和开发方在缺点有效性分歧上，进行仲裁

测试主管岗

测试实施过程中，对缺点提交情况、修复情况进行监控

入口标准

正式实施测试，测试方发觉问题

输入

测试用例

输出

含结果测试用例

缺点跟踪表

出口标准

完成测试，全部问题进行修复验证或其它方法处理

缺点数量按版本呈显著收敛趋势

遗留缺点不能大于有限缺点8%

步骤

步骤图

步骤说明

提交问题

测试实施岗在实施测试中，若发觉问题，登录缺点管理系统进行新问题提交，描述问题时必需具体（必需时需附上截图），确保内容正确，定位正确。（有没有对缺点处理时间要求？）

分析定位缺点

提交问题后，测试实施岗同开发岗对该问题进行深入确定是否为开发方缺点。结果通常会出现以下两种情况：

假如双方发生分歧异议，测试实施岗提交问题给需求分析岗进行分析定位并仲裁：

若仲裁为开发方缺点，那开发岗需进行下一步修复；

若定位为需求缺点，进行修改确定经过，为有效缺点；（那便是closed状态，后续还需要进行其它方法跟进吗？）

若是测试岗对需求了解错误等，关闭该问题，为无效缺点；

假如确定为开发方缺点，那开发岗需进行下一步修复。

假如确定中，该问题经开发或需求方等确定不纳入本测试任务修改范围，作遗留处理，为有效缺点。（怎样定义哪些是遗留，是指缺点难以重现、技术问题临时无法处理情况吗？）

修改缺点

确定为程序缺点后，测试实施岗打开问题，开发岗对待修改缺点进行修复。在进行修改时，开发岗需对缺点做原因分析等注释。

验证缺点

开发岗修复完缺点后提交给测试实施岗进行回归测试，结果通常会出现以下两种情况：

假如该缺点经验证不经过，测试实施岗退回修改给开发岗，开发岗需对待修改缺点进行修复并提交给测试实施岗进行重新验证，直至验证经过。

假如经过测试验证，则该问题便是修改确定经过。

假如验证中，该缺点经开发或需求方等确定不纳入本测试任务修改范围，作遗留处理，为有效缺点。（怎样具体定义遗留问题？后续怎样跟进？）

假如验证中，测试方和开发方对该缺点是否有效未能达成一致意见，问题提交需求分析岗进行仲裁。

统计数据

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

测试监控

测试主管岗在测试实施中需对缺点提交情况、修复情况进行监控，确保按质按时完成任务。

缺点定义

缺点状态

待确定：测试方认为该问题是一个缺点，待和需求或开发深入确定（中间过程状态，未确定是否为有效缺点）

待修改：开发修改中（有效缺点）

验证中：该缺点开发已修复，测试方正对该问题进行回归测试中（有效缺点）

退回修改：该缺点回归测试不经过，重新退回给开发修改（有效缺点）

仲裁：测试方和需求方或开发方对该缺点是否有效未能达成一致意见，问题已提交相关人员进行仲裁中。（中间过程状态，未确定是否为有效缺点）

修改确定经过：开发已修复，且测试方已回归测试经过（有效缺点）

关闭：经确定或仲裁为无效缺点

遗留：有效缺点，但经开发或需求方等确定不纳入本测试任务修改范围，作遗留处理

注:测试完成后，只许可修改确定经过、关闭、遗留这三种状态存在。

缺点类型

需求缺点：业务需求错误。包含需求功效步骤错误、需求不完整、不一致、有遗漏、不可行、描述不清楚等。

开发缺点：开发修改引发问题。

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

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

操作错误：测试人