软件测试过程模型

发表于:2015-08-28来源:uml.org.cn作者:不详点击数: 标签:软件测试过程
针对每个测试级别,将适当的执行如下活动: 一、创建测试策略: 输入: · 要求硬件和软件组件的详细说明,包括测试工具(测试环境,测试工具数据)。

  针对每个测试级别,将适当的执行如下活动:

  一、创建测试策略:

  输入:

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

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

  · 测试方法(标准)

  · 应用程序的功能性和技术性需求(需求,变更请求,技术性和功能性设计文档)

  · 系统无法提供的需求(系统局限)

  输出:

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

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

  过程:

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

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

  二、创建测试计划/设计

  输入:

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

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

  · 作为一种测试的结果(有关测试文档的问题),测试文档中没有说明的问题

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

  输出:

  · 设计时发现的问题反馈给开发人员(软件设计,代码问题)

  · 已批准的测试场景,条件和脚本(测试设计,用例和脚本)

  · 测试数据

  过程:

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

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

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

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

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

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

  三、执行测试

  输入:

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

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

  · 设计的变更(变更请求)

  · 测试数据

  · 测试和项目组的可用性(项目人员,测试小组)

  · 概要和详细设计文档(需求,软件设计)

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

  · 测试就绪文档

  · 修订文档

  输出:

  · 代码的变更(测试修复项)

  · 作为一种测试的结果(测试文档问题),测试文档没有说明的问题

  · 设计时发现的问题,反馈给开发人员和客户(需求,设计,代码问题)

  · 测试事故的正式记录(问题跟踪)

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

原文转自:http://www.uml.org.cn/Test/200709263.asp