功能测试缺陷管理规范

功能测试缺陷管理规范

北京天阳宏业软件技术有限公司

2011年7月

功能测试缺陷管理规范

目 录

1.

概述 .................................................................................................................................................. 2 1.1 1.2 1.3 1.4 2. 3.

编写目的 ................................................................................................................................. 2 范围 ......................................................................................................................................... 2 角色与职责 ............................................................................................................................. 2 名词解释 ................................................................................................................................. 2

缺陷状态关系示意图 ...................................................................................................................... 3 缺陷流转的过程及处理 .................................................................................................................. 3 3.1

测试缺陷的处理步骤 ............................................................................................................. 3

4. 缺陷页面部分字段详解 .................................................................................................................. 4

1

功能测试缺陷管理规范

1. 概述

1.1 编写目的

为规范QC的合理使用，方便各项目组管理测试过程，测试管理人员正确使用QC而编写。

1.2 范围

本规范适用于功能测试有关工作，功能测试中的缺陷要求全部采用QC进行管理。

1.3 角色与职责

角色名称 测试经理 测试人员 开发人员 职责描述 申请QC项目建立，分配有关人员权限 登记测试缺陷，跟踪和修改缺陷状态，并进行复测 从QC中获取缺陷信息，修复缺陷，并修改QC缺陷状态及分析记录缺陷相关内容 1.4 名词解释

QC：QC（Quality Center），也被称为MQC（Mercury Quality Center）。不仅可以在一个项目组内进行质量控制和管理，也可以在跨地域的不同项目组内部进行质量控制和管理，从而可以保证应用系统的质量。通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等，QC可以地加速测试过程执行。

2

功能测试缺陷管理规范

2. 缺陷状态关系示意图

3. 缺陷流转的过程及处理

参与缺陷流转的角色有三个：测试经理、测试人员和开发人员。

测试人员开发人员测试人员重现待验证提出处理 拒绝

缺陷的处理步骤如下： 1.登记缺陷：

测试人员负责在QC中登记新缺陷，并对缺陷的基本情况进行描述。缺陷的基本信息主要包括：缺陷描述、紧急程度、严重程度、处理子系统等。

3

关闭 功能测试缺陷管理规范

测试人员在登记缺陷时，必须确定所输入的缺陷内容要描述清楚，产生缺陷的步骤描述要完整，使缺陷能够被重现出来。在描述缺陷产生的步骤上，务必简易清楚。测试人员可以利用错误抓图等方式进行补充描述。

2.修复缺陷

当有多个缺陷同时打开时，开发人员应首先修复紧急程度更高的缺陷。开发人员首先分析缺陷，并将缺陷状态更改为“处理”中。

当该缺陷不是有效的缺陷时，则将“缺陷状态”更改为“拒绝”，并在“缺陷详细信息” 模块中的“分析和修改内容”中使用“添加注释”按钮详细填写拒绝的原因。

当确认该缺陷有效时，开发人员应按照要求修复缺陷。缺陷修复后，开发人员需在“缺陷详细信息” 模块中的“分析和修改内容”中使用“添加注释”按钮详细填写修复的内容，并填写缺陷起源、缺陷归属子系统，更改“缺陷状态”为“待验证”。

当确认该缺陷不是本系统引起，需要其它项目组协同进行分析解决，开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理子系统”改为相应的项目组或系统，以便缺陷能及时流转。

3.验证缺陷

测试人员负责验证缺陷是否已解决，如已解决则由缺陷原提出人关闭缺陷，否则将“缺陷状态”更改为“重现”，以便开发人员重新对此缺陷进行处理。

4. 缺陷页面部分字段详解

 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。 包括：提出、处理、拒绝、待验证、重现、关闭

 缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，开发人员负责确认。 包括：严重、一般、轻微

 缺陷紧急程度：指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以项目组

具体协商约定紧急程度的具体含义。 包括：高、中、低

 缺陷起源：指引起缺陷的起因。

包括：需求、架构、设计、编码、测试、环境、数据、拒绝

4

功能测试缺陷管理规范 缺陷起源类型 需求 架构 设计 编码 测试 环境 数据 含义 由于需求定义或需求分析引起的缺陷 由于企业架构设计的问题引起的缺陷 由于本系统设计原因引起的缺陷 由于编码的问题引起的缺陷 由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷 由于测试环境的问题引起的缺陷 由于测试数据的问题引起的缺陷 重复。表示该缺陷已经被其它提交人找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等） 不可复现。不能重现（如因缺陷出现的环境重现不了），或以前出现的某个缺陷自动消失了（可能是在处理其他缺陷的时候把这个缺陷 一并修复掉了） 拒绝 是按照需求和设计实现的，不属于缺陷 延后解决。由于时间、进度、重要程度或者技术/需求等方面的原因，认为目前不能解决或由于时间关系，须延期解决或者本版暂不解决留待到后续版本解决的缺陷 这个缺陷是一个错误，但非常轻微，对系统几乎无影响，可以忽略不计

5