IEEE 软件单元测试标准

目标

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

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

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

动机

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

听众

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

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

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

概览

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

• 1) 完成测试计划
  
  • a) 为通用方法、资源和调度制定计划
  • b) 决定需要测试的特性
  • c) 精炼通用计划
• 2) 获取测试集
  
  • a) 设计测试集
  • b) 实施和精炼计划和设计
• 3) 测量单元
  
  • a) 执行测试过程
  • b) 终止检查
  • c) 评估测试工作量和单元

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

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

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）获得测试项目。收集测试项目，包括可用的手册、操作系统流程、控制数据和电脑程序。获得测试计划中与测试单元直接对接的软件标识。

当使用一个程序语言实施单元测试时，确保执行跟踪信息将可用于评估基于代码完整性要求的满意度。

在单元测试概要记录的概要章节记录每个项目的标识。

3.5.3 实施输出

（1）验证后的测试数据（3.5.2（1））
（2）测试支持资源（3.5.2（2））
（3）配置测试项目（3.5.2（3））
（4）初始化概要信息（3.5.2（3））

3.6 执行测试流程

3.6.1 执行输入

（1）验证后的测试数据（3.5.2（1））
（2）测试支持资源（3.5.2（2））
（3）配置测试项目（3.5.2（3））
（4）测试用例规范（3.4.2（3）和（4））
（5）测试流程规范（3.4.2（2））
（6）错误分析结果（调试阶段）

3.6.2 执行任务

（1）运行测试。配置测试环境，运行测试集。在单元测试概览记录的结果概览章节记录所有测试事件。

（2）确定结果。对每个测试用例而言，基于用例描述的需求结果规范确定单元测试成功或失败。在单元测试概览记录中的概览结果章节记录通过或失败结果。在记录的概览行为章节记录资源消耗数据。当使用一个程序语言测试单元时，收集执行跟踪概览信息并附加到记录中。

对每个失败而言，分析失败原因并将失败信息记录到测试概览记录的概览结果章节。然后选择可用的用例并完成相关动作：

• 用例1：测试规范或测试数据的错误。手机错误，在测试概览记录中记录错误更正，然后重新运行失败的测试用例。

• 用例2：测试流程执行的错误。重新运行不正确的执行流程。

• 用例3：测试环境的错误（系统软件）。修正环境，在测试概览记录的概览行为章节记录错误更正并重新运行测试或在测试概览记录的概览行为章节记录不能纠正环境的原因并准备异常终止，然后继续检查终止。

• 用例4：单元实施的错误。更正单元或在测试概览记录的概览行为章节记录错误更正并重新运行所有测试或在测试概览记录的概览行为章节记录不能纠正单元的原因并准备异常终止，然后继续检查终止。

• 用例5：单元设计的错误。更正单元和设计，修改测试规范和数据，在测试概览记录的概览行为章节记录错误更正并重新运行所有测试或在测试概览记录的概览行为章节记录不能纠正设计的原因并准备异常终止，然后继续检查终止。

注意：执行和检查的任务周期必须一直持续直到满足3.1.2（3）定义的终止条件。执行行为的控制流如下图：

执行输出

（1）执行信息录入测试概览记录，包括测试结果、测试事件描述、失败分析结果、失败更正行为、不正确失败原因、资源消耗数据，实施程序语言、跟踪概览信息（3.6.1（1）和（2））
（2）修改测试规范（3.6.2（2））
（3）修改测试数据（3.6.2（2））

3.7 检查终止

3.7.1 检查输入

（1）完整性和终止要求（3.1.2（2）和（3））
（2）执行信息（3.6.1（1）和（2））
（3）测试规范（3.4.2（1）到（3））
（4）软件数据架构描述

3.7.2 检查任务

（1）检查测试过程的一般终止。确定基于完整性要求或有关失败历史的的额外测试。对实施程序语言而言，分析执行跟踪概览信息（变量、流）

如果不需要额外测试，在测试概览记录的概览行为章节记录一般终止并继续评估测试效果和单元。

（2）检查测试过程的异常终止。如果满足异常终止的条件（不正确的组主要失败、超时），确保导致终止的特定情况、未完成的测试和任何不能更正的失败都被记录在测试概览记录的概览行为章节。然后继续评估测试效果和单元。

（3）补充测试集。当需要额外的测试且异常终止条件并不满足，按照如下步骤补充测试集。
– （a）根据3.4.2（1）更新测试集架构且根据3.4.2（3）获取额外测试集
– （b）根据3.4.2（2）修改测试流程规范
– （c）根据3.5.2（1）获得额外测试数据
– （d）在测试概览记录的概览行为章节记录例外情况
– （e）执行额外测试

3.7.3 检查输出

（1）检查信息记录在测试概览记录，包括终止条件和任何额外测试用例行为
（2）额外或更正的测试规范（3.7.2（3））
（3）额外的测试数据（3.7.2（3））

3.8 评估测试效果和单元

3.8.1 评估输入

（1）单元测试设计规范（3.4.2（5））
（2）执行信息（3.6.2（1）和（2））
（3）检查信息（3.7.2（1）到（3））
（4）分隔测试用例规范（3.4.2（3）和（4））

3.8.2 评估任务

（1）描述测试状态。在测试概览记录的差异章节记录测试计划和测试规范的差异。

对所有异常终止而言，识别测试不能有效覆盖的区域并在测试概览记录的全面性评估章节记录原因。

标识不能解决的测试事件和原因作为缺陷原因并记录在测试概览记录的概览结果章节。

（2）描述单元状态。在测试概览记录的差异章节记录测试时显露的单元本身与它的需求文档之间的不同。

基于测试结果和失败信息评估单元设计和实施时与需求的不同。在测试概览记录中记录评估信息。

（3）完成测试概览记录。根据ANSI/IEEE Std 829-1983完成单元测试概览记录。

（4）确保测试产品的保存。确保测试产品被收集、组织，并存储以用作参考和重新使用。这些产品包括测试设计规范、分隔测试用例规范、分隔测试流程规范、测试数据、测试数据生成流程、测试驱动和存根、测试概览记录。

3.8.3 评估输出

（1）完整的测试概览记录（3.8.2（3））
（2）完成、存储收集测试产品（3.8.2（4））

文章知识点与官方知识档案匹配，可进一步学习相关知识C技能树C语言概述C语言标准115637 人正在系统学习中