1.1 目的
系统测试的类型以及各个类型的基本测试方法，指导项目开发人员进行软件系统测试
1.2 范围
本文适用于使用RUP 的所有软件项目的系统测试工作。
1.3 文档结构
第一部分：简介，介绍软件系统测试指南的目的，本指南的适用范围，以及在本文档中使用的术语的解释。
第二部分：描述系统测试指南。包括系统测试流程、系统测试需求的获取、系统测试侧策略选择、系统测试技术和方法等。
第三部分：列出本指南使用的参考文献。
1.4 词汇表
系统测试（System Testing）：系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。
黑盒测试（Black-Box Testing）：黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做：基于规格的测试（Specification-Based Testing ）、输入输出测试（Input/Output Testing ）、功能测试（Functional Testing ）。
2. 系统测试指南
2.1 系统测试过程
|
活动名称 |
输入工件 |
输出工件 |
参与角色 |
|
制定系统测试计划 |
软件需求工件 软件项目计划 |
系统测试计划 |
测试设计员 |
|
设计系统测试
|
系统测试计划 软件需求工件 |
系统测试用例 系统测试过程
|
测试设计员 |
|
实施系统测试
|
系统测试计划 工作版本 |
系统测试脚本 |
测试设计员 |
|
执行系统测试 |
系统测试计划 系统测试用例 系统测试过程 系统测试脚本 |
测试结果 |
测试员 |
|
评估系统测试 |
测试结果 |
测试分析报告 变更请求 |
测试设计员 相关组 |
2.2 系统测试需求获取
系统测试需求所确定的是测试的内容，即测试的具体对象。系统测试需求主要来源于需求工件集，它可能是一个需求规格说明书，或是由前景、用例、用例模型、词汇表、补充规约组成的一个集合。
在分析测试需求时，可应用以下几条一般规则：
1） 测试需求必须是可观测、可测评的行为。如果不能观测或测评的测试需求，就无法对其进行评估，以确定需求是否已经满足。
2） 在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。
3） 在需求规格说明书中每一个功能描述将派生一个或多个测试需求，性能描述、安全性描述等也将派生出一个或多个测试需求。
1. 功能性测试需求
功能性测试需求来自于测试对象的功能性说明。每个用例至少会派生一个测试需求。对于每个用例事件流，测试需求的详细列表至少会包括一个测试需求。对于需求规格说明书中的功能描述，将至少派生一个测试需求。
2. 性能测试需求
性能测试需求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和资源使用率的某种评测。性能需要在各种条件下进行评测，这些条件包括：
1）不同的工作量和/或系统条件
2）不同的用例/功能
3）不同的配置
4）性能需求在补充规格或需求规格说明书中的性能描述部分中说明。
对包括以下内容的语句要特别注意：
1）时间语句，如响应时间或定时情况
2）指出在规定时间内必须出现的事件数或用例数的语句
3）将某一项性能的行为与另一项性能的行为进行比较的语句
4）将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句
5）一段时间内的操作可靠性（平均故障时间或 MTTF ）
6）配置或约束
应该为规格中反映以上信息的每个语句生成至少一个测试需求。
3. 其它测试需求
其它测试需求包括配置测试、安全性测试、容量测试、强度测试、故障恢复测试、负载测试等测试需求可以从非功能性需求中发现与其对应的描述。每一个描述信息可以生成至少一个测试需求。
2.3 系统测试策略
测试策略用于说明某项特定测试工作的一般方法和目标。系统测试策略主要针对系统测试需求确定测试类型及如何实施测试的方法和技术。
一个好的测试策略应该包括要实施的测试类型和测试的目标、所采用的技术、用于评估测试结果和测试是否完成的标准、对测试策略所述的测试工作存在影响的特殊事项等内容。
2.3.1 系统测试类型和目标
确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解（尤其是由于有些类型测试看起来非常类似，如强度测试和容量测试）。测试目标应该表明执行测试的原因。
系统测试的测试类型一般包括：功能测试（Functional Testing）、性能测试（Performance Testing）负载测试（Load Testing）、强度测试（Stress Testing）、容量测试（Volume Testing）、安全性测试（Security Testing）、配置测试（Configuration Testing）、故障恢复测试（Recovery Testing）、安装测试（Installation Testing）、文档测试（Documentation Testing）、用户界面测试（GUI Testing）等等。
其中，功能测试、配置测试、安装测试等在一般情况下是必需的。而其它的测试类型则需要根据软件项目的具体要求进行裁剪。
2.3.2 采用的测试技术
系统测试主要采用黑盒测试技术设计测试用例来确认软件满足需求规格说明书的要求。
2.4 系统测试的工作机制
1）项目组为每一个软件项目成立测试组，确定测试经理（通常由测试设计员担任）一名，测试设计员和测试员若干。
|
角色 |
职责 |
|
测试设计员 |
制定系统测试计划、设计系统测试、实施系统测试以及评估系统测试 |
|
测试员 |
执行系统测试 |
2）项目组需要提供系统测试需要的输入，建立测试环境，以及对测试工件进行配置管理。
|
角色 |
职责 |
|
系统分析员 |
生成需求工件集，管理需求。为测试设计员提供测试需求。 |
|
配置管理员 |
对测试工件进行配置管理 |
2.5 系统测试产生的工件清单
1）软件系统测试计划
2）系统测试用例
3）系统测试过程
4）测试脚本（可选）
5）测试结果
6）测试分析报告
