51Testing软件测试网

目标

这个标准的首要目的是定制一个软件的标准方法以作为声音软件工程实践的基础。

第二个目标是描述基于这个标准方法的软件工程的概念和测试假设。

第三个目标是提供指导和资源信息以辅助实施和使用标准单元测试方法。这个信息包含在附录A,C,D。注意这些附录不属于这个标准的一部分。

动机

声音单元测试的一个共识定义为评估特定方法提供了基准。它也通过提供一个单元测试过程的标准分解以帮助沟通。

听众

首要听众是单元测试者和单元测试管理者。这个标准被开发出来以辅助那些需要管理、监控和评估单元测试的人。

与其他软件工程标准的关系

这个标准属于一个系列中的一员，其目的是建立软件工程领域的专业实践。任何其他同系列的软件工程标准可以与其一同使用。

概览

单元测试过程由三个阶段组成，其被区分成总共8个基础行为，如下：

1) 完成测试计划

a) 为通用方法、资源和调度制定计划

b) 决定需要测试的特性

c) 精炼通用计划

2) 获取测试集

a) 设计测试集

b) 实施和精炼计划和设计

3) 测量单元

a) 执行测试过程

b) 终止检查

c) 评估测试工作量和单元

各阶段的主要数据流入和流出图如下：

这里写图片描述

在每个阶段内，各个标准行为与它自己的输入集和输出集有关，且由一系列任务组成。这个标准制定了每个行为的输入、任务和输出。

所有行为的输出集必须包含有效信息以创建至少两个文件——测试设计规范和测试概述。这两个文件必须符合ANSI/IEEE Std 829-1983规范。

1. 范围和参考

1.1 范围内的

软件单元测试是一个流程，包含履行测试计划、获取测试集、根据测试要求测量测试单元。测试意味着使用采样数据以测试单元，以及对比单元实际行为与在单元需求文档中制定的需求行为之间的不同。

这个标准定义了一个集成的方法以系统化和文档化单元测试。这个方法使用单元设计和单元实施信息，而不是单元需求，以决定测试的完整性。

这个标准描述一个测试流程，包括各阶段的层次结构、行为、任务和为每个行为定义一个最小数量的任务集。额外的任务可以被添加到任何行为。

这个标准需要每个行为的履行。对每个行为内的任务而言，这个标准需要认真被履行，或之前的结果是可用且可重现的。这个标准也需要准备两个ANSI/IEEE Std 829-1983制定的文档。这些文档是测试设计规范和测试概述记录。

通用单元测试计划应发生于整个测试计划期间。这个通用单元测试计划行为被包含在这个标准内，虽然整个测试计划流程的平衡性已经超出这个标准的范围。

这个标准可以被应用在任何数字计算机软件或固件的单元测试。然而这个标准不能制定其必须应用在某种软件或固件的类型，也不能制定哪些软件或固件的类型必须有单元测试。这个标准应用在较新的测试开发和单元修改。

无论单元测试者是否也是开发者，这个标准都是可用的。

范围外的

一些整体测试计划的任务的结果可以应用在所有测试等级（例如身份加密和隐私限制）。这些任务不被视为单元测试流程的一部分，虽然他们直接影响了单元测试。

当标准识别到一个需要错误分析的信息和软件错误更正，不需要制定一个软件调试流程。

这个标准不需要涉及一个完整的单元确认和合法性流程的其他元件，例如评论（例如演练和检查）、静态分析（一致性检查，数据流分析）或格式分析（正确性证明，符号执行）。

这个标准不需要使用专门的测试设备和工具。这个标准不暗示任何特别方法的文件控制，，质量保证或测试过程管理。

1.3 参考

这个标准应联合如下刊物：

ANSI/IEEE Std 729-1983，IEEE 标准软件工程术语表。

ANSI/IEEE Std 829-1983，IEEE 标准文档。

3. 单元测试行为

这个章节制定了有关单元测试过程的行为且描述了相关的输入、任务和输出。

当多于1个单元需要被测试（例如他们联合组成一个软件项目），行为的计划应涉及整个测试单元集且每个测试单元都不应重复。每个单元的行为必须完成至少一次。

在通常情况下，这些行为是有序的初始化，除了执行和检查，如下图。执行计划以外的任何活动时，前者的活动或外部事件（例如时间表、需求或设计变更）可能导致需要重做一个或多个前面的活动，然后回到正在执行的行为。

在测试过程期间，测试设计规范和测试概述记录需要被开发。其他测试文件也可被开发。所有测试文件必须符合ANSI-IEEE Std 829-1983。此外，所有测试文件必须能识别作者和日期。

测试设计规范将从决定、精炼和设计行为中采集信息。测试概述记录将从所有行为中采集信息。

3.1 计划通用方法、资源和时间表

通用单元测试计划应在所有测试计划前发生，且应记录在相关的计划文档内。

3.1.1 计划输入

1) 项目计划

2) 软件需求文档

3.1.1 计划任务

（1）制定一个通用单元测试方法。识别测试要解决的风险领域。在特性描述中制定限制（必须测试的特性），测试设计或测试实施（必须的测试集）。

识别已存在的输入、输出和状态数据的来源（测试文件、生产文件、测试数据生成器）。识别数据验证的通用。识别输出记录、收集、还原和验证的通用技术。描述被测单元与应用软件之间的直接接口。

（2）制定完整度需求。识别单元测试集覆盖的区域（特性、过程、状态、功能、数据特征、指令）和每个区域需要覆盖的程度。

当在期间内测试一个单元时，每个软件的特性必须被一个或一个批准的例外覆盖，除了模块包含的已经被另外单元测试的指令。软件维护期间的单元测试的实施应保持相同的程序语言。

（3）制定终止需求。制定单元测试过程的普通终止需求。终止需求必须包括满足完整度需求。

识别任何可能导致单元测试过程异常终止的条件（检测到主要设计错误，达到时间表截止时间）。

（4）确定资源要求。估算测试集采集、初始化执行和紧接着的重复测试行为所需的资源。需要考虑硬件、访问时间、通信和系统软件、测试工具、测试文件和其他内容。也需要考虑不常用的大量的形式和供应。

识别所需准备的资源和负责方。安排这些资源，包括需要大量交付时间的资源请求，例如定制的测试工具。

识别单元测试和单元调试的责任方。识别技能、数量和周期等需求。

（5）制定通用时间表。为所有单元测试行为制定一个受到资源和测试单元可行性限制的时间表。

3.1.3 计划输出

（1）生成单元测试计划信息（3.1.2的（1）~（5））

（2）单元测试通用资源需求——从3.1.2的（4）

3.2 确定需要测试的特性

3.2.1 确定输入

（1）单元需求文档

（2）软件架构设计文档

3.2.2 确定任务

（1）学习功能需求。学习单元需求文档内描述的每个功能。确保每个功能有一个唯一的标识。必要时，要求澄清要求。

（2）标识额外需求和相关程序。标识需求而不是与软件特性相关的功能（性能、属性或设计限制），这样在单元测试层面的测试会更有效。标识任何只与单元测试相关的用途或操作流程。确保内个额外的需求和流程有一个唯一的标识。必要时，要求澄清要求。

（3）标识单元状态。如果单元需求文档特指或隐含多种状态（不活动、等待接收、处理）软件，标识每个状态和每个状态转换。确保每个状态和状态转换有唯一标识。必要时，要求澄清要求。

（4）标识输入和输出数据特征。标识待测单元的输入和输出数据结构。对每个结构而言标识出特征，例如通过率，格式，值范围和域值之间的关系。对每个特征而言，制定有效范围。确保每个特征有唯一值。必要时要求澄清要求。

（5）选择需要包含入测试的元素。选择相关的流程，相关状态，相关状态转换和相关数据特征。需要选择无效和有效输入数据。当完整的测试是不切实际的时候，有关单元使用的信息应被用来确定选项。识别与未选中元素有关的风险。

单元测试设计规范的待测特性章节中需要输入被选特性、流程、状态、状态转换和数据特征。

3.2.3 确定输出

（1）包含在测试内的元素清单

（2）单元需求澄清要求——从3.2.2（1）到（4）来

3.3 精炼通用计划

3.3.1 精炼输入

（1）包含在测试内的元素清单（3.2.2（5））

（2）通用单元测试计划信息（3.1.2的（1）到（5））

3.3.2 精炼任务

（1）精炼方法。考虑标识现有的测试用例和测试过程的使用。标识任何专门的技术用作数据验证。标识任何专门的技术用于输出记录、收集、减少和验证。

在单元测试设计规范的方法精炼章节记录精炼方法。

（2）制定特定资源需求。标识任何在测试单元时需要的特定资源（与单元直接接口的软件）。为被标识资源开展准备工作。

在单元测试设计规范的方法精炼章节记录特定资源需求。

（3）制定一个详细的时间表。制定一个基于支持软件、特定资源、单元可用性和集成计划的单元测试时间表。在单元测试设计规范的方法精炼章节记录时间表。

3.3.3 精炼输出

（1）特定单元测试计划信息（从3.3.2（1）到（3））

（2）单元测试特定资源需求（从3.3.2（2））

3.4 设计测试集

3.4.1 设计输入

（1）单元需求文档

（2）测试内包含的元素清单（3.2.2（5））

（3）单元测试计划信息（3.1.2（1）、（2）和3.2.2（1））

（4）单元设计文档

（5）先前测试的测试规范

3.4.2 设计任务

（1）设计测试集的架构。基于待测特性以及专门的或隐含的被选定的相关元素（流程、状态转换、数据特征），设计一个逐层分解的测试目标集，这样每个最低等级的目标可以用一些测试用例直接测试。选择合适的已有测试用例。相关测试用例组用最低级目标作标识。记录目标的层级和相关的测试用例，这些用例标识在单元测试设计规范的测试标识章节。

（2）获得所需的明确的测试流程。一个有着单元需求文档、测试计划信息和测试用例规范的组合可以隐式地指定单元测试流程，因而最小化所需的明确规范。选择那些可以被修改的或不需要修改的已有的测试流程。

可以在单元测试设计规范的补充单元或另一个流程规范文档中制定任何额外的流程。无论哪种选择都必须符合ANSI/IEEE Std 829-1983需求的信息。如果测试用例和流程的相关性不明显，开发一个他们之间的关系表并添加到单元测试设计规范中。

（3） 获得测试用例规范。制定新的测试用例。已有的规范可作为参考。

可以直接记录规范，也可以参考单元测试设计规范的补充单元或另一个文档。

（4）基于设计信息按需增加测试用例集规范。基于单元设计的信息，依据3.4.2（1）按需更新测试集的架构。仔细考虑所选算法特性和内部数据结构。

标识控制流和必须记录的内部数据改变。预料可能发生的特定的记录困难，例如需要在复杂算法内跟踪控制流或需要跟踪内部数据结构的改变（栈或树）。必要时需要增强单元设计（格式化的数据结构转储能力）以增加单元的可测试性。

基于单元设计的说明，制定任何新的被标识的测试用例，并依据3.4.2（3）完成测试集规范的任何部分。

（5）完成测试设计规范。根据ANSI/IEEE Std 829-1983完成单元测试设计规范。

3.4.3 设计输出

（1）单元测试设计规范（3.4.2（5））

（2）分隔测试流程规范（3.4.2（2））

（3）分隔测试用例规范（3.4.2（3）或（4））

（4）单元设计增强需求（3.4.2（4））

3.5 实施精炼后的计划和设计

3.5.1 实施输入

（1）单元测试计划信息（3.1.2（1）、（4）、（5），3.3.2（1）到（3））

（2）单元测试设计规范或分隔文档的测试集规范（3.4.2（3）和（4））

（3）软件数据结构描述

（4）测试支持资源

（5）测试项目

（6）之前测试行为的测试数据

（7）之前测试行为的测试工具

3.5.2 实施任务

（1）获得并验证测试数据。获得一个需要修改的或无须修改的已存在的测试数据。生成任何新的所需数据。包括额外的重要数据以确保数据一致性和诚信。认证所有在软件数据结构规范内的数据。当测试用例和数据集之间的相关性不明显，开发一个记录这种关系的表并保护在单元测试设计规范中。

（2）获得特定资源。获得3.3.2（2）指定的测试支持资源

（3）获得测试项目。收集测试项目，包括可用的手册、流程、控制数据和电脑程序。获得测试计划中与测试单元直接对接的软件标识。