软件测试过程模型

    

    一、创建测试策略：

输入：

·   要求硬件和软件组件的详细说明，包括测试工具（测试环境，测试工具数据）。

·   针对测试和进度约束（人员，进度表）所需资源的角色和职责说明

·   测试方法（标准）

·   应用程序的功能性和技术性需求（需求，变更请求，技术性和功能性设计文档）

·   系统无法提供的需求（系统局限）

输出：

·  已批准和签署的测试策略文档，测试计划，测试用例

·  需要解决方案的测试项目（通常要求客户项目的管理层协调）

 

过程：

·   测试策略是关于如何测试系统XYZ的正式描述，要求开发针对所有测试级别的测试策略。测试小组分析需求，编写测试策略并且和项目小组一起复审计划。

·   测试计划应该包括测试用例和条件，测试环境，与任务相关的测试，通过/失败的准则和测试风险评估。测试进度表将识别所有要求有成功的测试成果的任务，活动的进度和资源要求。

 

    二、创建测试计划/设计

输入：

·   已批准的测试策略文档。

·   如果测试工具适用，自动化测试软件和以前开发的测试脚本

·   作为一种测试的结果（有关测试文档的问题），测试文档中没有说明的问题

·   从概要和详细设计文档（软件设计，代码和复杂的数据）中导出的对软件复杂性和模块路径覆盖的理解

 

输出：

·   设计时发现的问题反馈给开发人员（软件设计，代码问题）

·   已批准的测试场景，条件和脚本（测试设计，用例和脚本）

·   测试数据

 

过程：

·   通过复审发布版本的功能需求和准备能够更好的拆分为测试脚本的业务功能逻辑集合，准备测试场景和用例。测试将定义为测试条件，用于测试的数据和期望的结果（数据库更新，文件输出，报告结果等等）。将可能在应用程序中出现的既普通又异常的情况描绘为测试场景。

·   项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前，开发人员同时也负责执行单元测试用例。

·   在开发人员和客户的协助下，测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下开发。

·   通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。

·   在测试之前，捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照，一些输出的数据也被基线化。在回归测试时，基线化的数据用于支持以后的系统维护。

·   为评定应用程序的就绪情况、环境和被测试的数据，应召开测试准备会议。为了指出发本版本的入口标准状态，应创建测试就绪文档。

    三、执行测试

输入：

·    已批准的测试文档（测试计划、用例、程序）

·    如果适用测试工具，自动化测试软件和编写好的脚本

·    设计的变更（变更请求）

·    测试数据

·    测试和项目组的可用性（项目人员，测试小组）

·    概要和详细设计文档（需求，软件设计）

·    通过配置/构建人员能够完全转移到测试环境（单元测试过的代码）的开发环境

·    测试就绪文档

·    修订文档

 

输出：

·    代码的变更（测试修复项）

·    作为一种测试的结果（测试文档问题），测试文档没有说明的问题

·    设计时发现的问题，反馈给开发人员和客户（需求，设计，代码问题）

·    测试事故的正式记录（问题跟踪）

·    为向下一级别转移而准备的基线化包（已测试的源代码和对象代码）

·    测试结果的日志和总结

·    已批准和带有修订测试交付项的签署文档（已更新的交付项）

 

过程：

·    在执行阶段中应召开Checkpoint 会议。(如果由需要，)每天应召开Checkpoint 会议处理和讨论测试中的问题，状态和活动。

·    通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时，为了记录程序的执行和测试程序找出的任何缺陷，应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。

·   为了确定是否可以得到预期的结果，测试结果应该由适当的项目组员评估（，适合于测试的所有级别）。记录并和软件开发经理/程序员讨论所有差异/异常，为了以后的调查和解决应该将它文档化（每个客户可能有不同的记录日志和报告bug/defect的过程，通过Configuration Management (CM)小组校验这些过程）。通过/失败的准则用来确定问题的严重级别，结果记录到测试总结报告中。

·   根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。

·   基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后，测试组的成员应准备一份总结报告。总结报告要由项目经理，客户，SQA和/或测试组长复审。

·   在证实达到一个指定的测试级别后，配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。

·   测试小组在复审测试和更新的文档中发现的测试文档的问题。有些问题可能是由于技术性和功能性之间的不一致或修改所造成的。