测试管理处_功能测试缺陷管理规范

                                           密级：内部公开

测试管理处

功能测试缺陷管理规范

2014年 02 月10 日

修订历史记录

                                             A –增加    M-修改   D-删除

目录

1    概述    4

1.1    目的    4

1.2    阅读对象    4

2    缺陷定义及属性    4

2.1    缺陷定义    4

2.2    缺陷属性    4

2.2.1    缺陷状态    4

2.2.2    缺陷类型    5

2.2.3    缺陷严重程度    5

2.2.4    缺陷优先级    7

3    缺陷过程活动描述    7

3.1    缺陷流程图    7

3.2    提交缺陷    9

3.2.1    缺陷头信息    9

3.2.2    缺陷过程信息以及尾信息    9

3.2.3    附件说明    9

3.3    缺陷确认    10

3.4    缺陷跟踪    10

3.5    修复缺陷    10

3.6    验证缺陷    10

4    准入/准出标准    11

4.1    准入标准    11

4.2    准出标准    11

5    工具    11

6    保障机制    11

1概述

1.1目的

为了规范数据信息中心的开发、测试人员对缺陷的认识及处理过程，降低无效缺陷率

、提高缺陷处理效率、减少缺陷交互成本而建立起来的。体现专业性，以方便相关干系人查看并以此来跟踪和处理缺陷。

1.2阅读对象

参与泰康人寿软件开发项目或维护性软件开发项目的开发人员、测试人员等。

2缺陷定义及属性

2.1缺陷定义

软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象，如：

✓软件没有达到需求说明书表明的功能。

✓软件出现了需求说明书中不一致的表现。

✓软件功能超出需求说明书的范围。

✓软件没有达到用户期望的目标(虽然需求说明书中没有要求)。

✓软件的易用性差。

软件缺陷包括检测缺陷和残留缺陷。

检测缺陷（Detected Defect）：检测缺陷是指软件在进入用户使用之前被检测出的缺陷。

残留缺陷（Residual Defect ）：残留缺陷是指软件发布后存在的缺陷，包括在用户安装前未被检测出的缺陷以及检测出但未被修复的缺陷。

软件故障（Software Failure）：软件故障是指用户使用软件时，由于残留缺陷引起的软件失效症状。

2.2缺陷属性

2.2.1缺陷状态

缺陷状态：是指测试过程中缺陷所处阶段的定义，数据依据来源RDMS。

缺陷状态说明如下： 

缺陷类型：是根据缺陷的自然属性划分的缺陷种类，数据依据来源RDMS。

缺陷类型说明如下：

缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，数据依据来源RDMS。

缺陷严重程度说明如下：

缺陷优先级：缺陷的优先级是指缺陷必须被修复的紧急程度，数据依据来源RDMS。

缺陷优先级分类如下：

3.1缺陷流程图

3.2提交缺陷

3.2.1缺陷头信息

缺陷命名，见下所示：

标题命名建议采用尽量短的语言描述来命名。推荐采用以下几种方式：

1.在……的页面上，……

2.在……的流程后，……

3.2.2缺陷过程信息以及尾信息

包含如下字段，根据项目或者任务的情况来“裁剪”或“增加”个性化的字段以及内容。我们要有条有理有据的把详细步骤写出来，减少bug往复现象的发生以避免不必要的沟通成本的上升。缺陷过程信息通过如下个性化字段按要求书写，尾信息（即注释）是主要是对此缺陷的进一步说明或者根据测试人员的水平情况定位和发现问题辅助开发人员。

【测试数据】

【测试步骤】

【期望结果】

【实际结果】

【需求描述】（可选项）

【注释】

范例如下：

【差错返回功能优化】个险-付款信息变更差错返回打回原因可以不输入（保全岗）

【测试数据】

保单号：P0010008

【测试步骤】

1.登录BPM系统(http://10.3.22.99:9080/TkBpmIII/login.jsf)

2.待办事宜->工作岗位（保全岗CSC）-查询

3.点击该模块的申请号进入并做测试点检验：点击返回按钮。

4.做测试点检验：打回原因，不能为空

【期望结果】

必须输入原因

【实际结果】

不输入

【注释】

因为点击确定之后才能看弹出的必输项校验。所以没法截图。请看此步骤之前和之后的一个截图

3.2.3附件说明

根据新建的缺陷来决定是否上传截图。截图的格式建议采用“jpg”或“png”，不推荐使用“bmp”格式，此格式截图文件很大。

截图中最好要有相应的文字说明。

注：此处附件专指截图

3.3缺陷确认

开发人员在收到测试人员提交的缺陷后，要求及时对相关缺陷进行确认，如果确认通过，则将缺陷置成“正在处理”状态，同时分配给对应的开发人员进行修复。如果开发人员认为该该缺陷为误操作或对需求理解不正确等，并非缺陷或者该缺陷影响甚小不值得修改，则将缺陷置成“不做处理”状态，同时添加必要的备注信息，说明理由。测试人员看到缺陷状态变更为“不做处理”后，与开发人员进行沟通，如果测试人员无异议，则该缺陷终止。如果测试人员对于“不做处理”的缺陷存在异议，经双方沟通后，没有达成一致意见，则将该问题提交管理人员仲裁，确认处理方案。在处理方案确定后，修改缺陷为对应状态：延后处理，正在处理，不做处理。

    测试人员对缺陷类型或者待提交的缺陷有疑问时，可以协调高级测试人员或测试组长来评估确认缺陷是否存在,相关高级测试人员或测试组长有义务对此问题予以辨别和解答。

目前规定如下缺陷类型需要确认：数据类型的缺陷和接口类型的缺陷

3.4缺陷跟踪

测试人员发布缺陷后，根据缺陷等级应及时与开发人员跟踪确认问题，敦促开发人员及时确认和修复问题，测试组长（经理）应每天（每周）跟踪缺陷情况，推进缺陷修复。对长期没有进展缺陷进行汇总和上报。 

3.5修复缺陷

开发人员，接到正在处理的缺陷后，对缺陷进行修改。完成修改后，开发提交给发布人员进行发布更新程序。开发则将已修复的缺陷状态置为“解决待关闭”。测试人员看到缺陷状态更变为“解决待关闭”，与开发人员确认是否可以复测。进行缺陷回归验证。

3.6验证缺陷

测试工程师根据修改后的程序，回归测试，验证测试结果是否正确。如果回归正确，将缺陷状态置为“关闭”。如果缺陷仍然存在，退回开发人员，将状态置为：“重新打开”。缺陷验证同时，测试工程师还要对该缺陷相关联模块进行回归测试。如果引发新的问题可以再报新的缺陷。对于轻微级别的缺陷，如果开发置为延后处理状态，测试工程师在验证时，需要将缺陷状态修改为不做处理，以关闭相关缺陷。

3.7遗留缺陷处理

在系统测试过程中，由于技术原因或者时间因素导致的需要延期处理的缺陷，作为本次任务的遗留缺陷（原则上只包括严重和中等级别的缺陷）。对于有遗留缺陷的需求或版本，在上线事务申请中由测试管理人员会签至问题管理人员（常海霞）处，流转为问题，同时将相关缺陷状态修改为已转问题。待问题流程反馈结果后由相关任务的责任人（高级测试工程师）进行后续的跟踪。 

4准入/准出标准

4.1准入标准

系统测试过程中（项目级系统测试、新产品系统测试、常规需求（新业务、需求变更）系统测试）以及紧急需求中发现的缺陷。

4.2准出标准

缺陷对应的有效测试案例执行通过；与缺陷相关联的测试案例执行通过。缺陷的最终状态为：关闭和不做处理以及退回。

5工具

测试缺陷提交在“集成化研发管理平台”,简称RDMS。缺陷提交用的是“RDMS”中的缺陷跟踪模块。

6保障机制

测试管理处内勤/测试外包经理/测试检查人员确保缺陷遵循本规程进行缺陷管理活动，定期审核缺陷管理工作是否遵守规范执行。