测试体系建设与软件测试流程图.docx

测试体系建设与软件测试流程图.docx

《测试体系建设与软件测试流程图.docx》由会员分享，可在线阅读，更多相关《测试体系建设与软件测试流程图.docx（15页珍藏版）》请在冰豆网上搜索。

测试体系建设与软件测试流程图

测试体系建设与软件测试流程

（初稿）

物合智联科技

修改历史

日期

版本

修改容

作者

2016/7/11

1.0

新建

沙莎

正式批准

角色

签名

日期

备注

1.目的

本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规，以有效保证软件质量。

2.围

本文适用于所有软件测试人员。

3.测试过程描述

3.1测试流程图

3.2活动说明

3.2.1需求评审

3.2.1.1目的

从源头把握软件质量，并确保开发结果与实际需求相一致

3.2.1.2角色与职责

需求人员：

《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修

正；

评审人员：

评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方

面检、查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺

陷直至需求缺陷验证关闭。

3.2.1.3启动标准

《软件需求规格说明书SRS》编写完成

3.2.1.4工作流程图

3.2.1.5输入/输出

输入：

《需求规格说明书》

输出：

需求缺陷

3.2.2测试计划

3.2.2.1目的

明确测试容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。

3.2.2.2角色与职责

测试负责人：

根据《软件开发计划》、《需求规格说明书》编制《测试计划》，明确测试

容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便

测试工作正常开展，测试计划实际编写容参见《项目测试计划模版》。

3.2.2.3启动标准

需求评审完成，《项目整体计划》编制完成。

3.2.2.4工作流程图

3.2.2.5输入/输出

输入：

《软件需求规格说明书》、《软件开发计划》

输出：

《测试计划》、《测试方案》

3.2.3测试设计

3.2.3.1目的

通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性，从而提升软件质量。

3.2.3.2角色和职责

测试人员：

采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修

正。

评审人员：

对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪

直至用例缺陷的验证关闭。

3.2.3.3启动标准

需求文档评审完成且测试计划制定完成

3.2.3.4工作流程图

3.2.3.5输入输出

输入：

《软件需求规格说明书》、《测试计划》、《测试方案》

输出：

《测试用例》、测试用例评审缺陷

3.2.4功能测试执行

3.2.4.1目的

依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。

3.2.4.2角色与职责

测试人员：

依据测试计划，按照测试用例对软件功能进行测试。

对于发现的缺陷必须记

录，并且跟踪缺陷的状态，直至缺陷的验证关闭。

在测试执行过程中发现的

遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。

开发人员：

对于测试人员提交的缺陷进行确认、修复。

开发经理：

对测试人员与实际开发人员意见不一的问题进行裁决。

3.2.4.3启动标准

测试用例编写完成且用例评审完成

3.2.4.4工作流程图

3.2.4.5输入输出

输入：

功能测试用例

输出：

功能测试报告，缺陷报告单

3.2.5集成/性能测试设计

3.2.5.1目的

为集成测试提供测试依据，记录并保证集成测试覆盖度；

依据《测试计划》及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。

3.2.5.2角色和职责

测试人员：

以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；

依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开

发。

3.2.5.3启动标准

功能测试完成且软件功能无中断

3.2.5.4工作流程图

3.2.5.5输入输出

输入：

《功能测试用例》、功能测试缺陷、《测试计划》、性能指标

输出：

《集成测试用例》、《性能测试计划》、《性能测试用例》、性能测试脚本

3.2.6集成测试/性能测试

3.2.6.1目的

以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。

3.2.6.2角色和职责

测试人员：

以整个软件为对象，以测试计划为指导，按照集成测试测试用例对新功能、

老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。

3.2.6.3启动标准

集成/性能测试设计完成

3.2.6.4工作流程图

3.2.6.5输入输出

输入：

《集成测试用例》、《测试计划》之集成测试事项、《性能测试计划》、《性能测试用

例》

输出：

集成测试缺陷

3.2.7文档测试

3.2.7.1目的

保证对客户的指导与实际系统的使用状况相一致。

3.2.7.2角色和职责

测试人员：

对《用户操作手册》及在线帮助进行测试，记录文档描述缺陷，并跟踪直至

缺陷的验证关闭。

需求人员：

对测试人员提出的文档描述缺陷进行修正。

3.2.7.3启动标准

《用户操作手册》或在线帮助编写完成

3.2.7.4工作流程图

3.2.7.5输入输出

输入：

《用户操作手册》、在线帮助

输出：

文档缺陷

3.2.8测试报告

3.2.8.1目的

真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。

3.2.8.2角色与职责

测试负责人：

真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像

的形式对实际情况进行分析，真实反映软件实际测试状况。

3.2.8.3启动标准

集成测试完成

3.2.8.4工作流程图

3.2.8.5输入输出

输入：

各测试阶段、测试项实际测试情况

输出：

《项目测试报告》

4.缺陷管理

4.1概述

4.1.1编写目的

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

4.1.2适用围

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

4.1.3角色和职责

角色名称

职责描述

测试经理

申请QC项目建立，分配有关人员权限

测试人员

登记测试缺陷，跟踪和修改缺陷状态，并进行复测

开发人员

从QC中获取缺陷信息，修复缺陷，并修改QC缺陷状态及分析记录缺陷相关容

4.1.4名词解释

QC：

QC（QualityCenter），也被称为MQC（MercuryQualityCenter）。

不仅可以在一个项目组进行质量控制和管理，也可以在跨地域的不同项目组部进行质量控制和管理，从而可以保证应用系统的质量。

通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等，QC可以地加速测试过程执行。

4.2缺陷状态关系示意图

4.3缺陷流转的过程及处理

参与缺陷流转的角色有三个：

测试经理、测试人员和开发人员。

缺陷的处理步骤如下：

4.3.1新建缺陷

测试人员负责在QC中新建缺陷，并对缺陷的基本情况进行描述。

缺陷的基本信息主要包括：

缺陷描述、紧急程度、严重程度、处理子系统等。

测试人员在登记缺陷时，必须确定所输入的缺陷容要描述清楚，产生缺陷的步骤描述要完整，使缺陷能够被重现出来。

在描述缺陷产生的步骤上，务必简易清楚。

测试人员可以利用错误抓图等方式进行补充描述。

4.3.2修复缺陷

当有多个缺陷同时打开时，开发人员应首先修复紧急程度更高的缺陷。

开发人员首先分析缺陷，并将缺陷状态更改为“处理”中。

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

当确认该缺陷有效时，开发人员应按照要求修复缺陷。

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

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

4.3.3验证缺陷

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

4.4缺陷页面部分字段详解

◆缺陷状态：

指缺陷通过一个跟踪修复过程的进展情况。

包括：

新建、打开、已修改、重新打开、关闭、拒绝、延迟

◆缺陷严重程度：

是指因缺陷引起的故障对系统的影响程度。

由提出人初步指定，开发人员负责确认。

包括：

致命、严重、一般、轻微

◆缺陷紧急程度：

指缺陷必须被修复的紧急程度。

由提出人指定。

各测试小组可以项目组具体协商约定紧急程度的具体含义。

包括：

高、中、低提出、处理、拒绝、待验证、重现、关闭

◆缺陷起源：

指引起缺陷的起因。

包括：

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

缺陷起源类型

含义

需求

由于需求定义或需求分析引起的缺陷

架构

由于企业架构设计的问题引起的缺陷

设计

由于本系统设计原因引起的缺陷

编码

由于编码的问题引起的缺陷

测试

由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷

环境

由于测试环境的问题引起的缺陷

数据

由于测试数据的问题引起的缺陷

拒绝

重复。

表示该缺陷已经被其它提交人找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）

不可复现。

不能重现（如因缺陷出现的环境重现不了），或以前出现的某个缺陷自动消失了（可能是在处理其他缺陷的时候把这个缺陷一并修复掉了）

是按照需求和设计实现的，不属于缺陷

延后解决。

由于时间、进度、重要程度或者技术/需求等方面的原因，认为目前不能解决或由于时间关系，须延期解决或者本版暂不解决留待到后续版本解决的缺陷

这个缺陷是一个错误，但非常轻微，对系统几乎无影响，可以忽略不计

5.配置管理

软件测试过程是一个复杂性的劳动，测试过程中会产生大量测试文档，主要通过相关管理工具的方式实行对文档的管理。

在文档的管理方面，按照公共类、项目类、软件缺陷类、开发人员类、测试工具类等：

1）公共类主要放置测试模板及测试规程说明，测试经验共享文档，开发技术规等。

2）项目类主要包括项目各阶段文档，如需求分析、测试计划、测试用例设计、分析报告等。

3）开发人员类是针对每个开发人员易犯错误的总结。

4）测试工具类主要放置常用的测试工具svn。

6.人员培养

一个优秀的测试团队的形成并非一朝一夕能形成。

软件测试和软件开发一样，是一项高智力的活动。

在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、怀疑精神、洞察力、有条理和注意细节八方面进行考虑。

对于新进入的测试人员，无论是否有测试经验或编程经验，都应进行测试的技术和管理规培训，同时根据他们以往知识和个人特点给他们定位合适的测试方向。