超级会员免费看
软件集成测试自动化研究成果
在软件开发过程中，测试环节至关重要，它不仅能确保软件的质量，还能在一定程度上影响开发成本和效率。本文将探讨软件集成测试自动化的相关内容，包括项目背景、目标、使用的工具、实验结构以及最终的测试结果。
项目背景与目标
- 项目背景 ：SITAR 是一个为期 21 个月的项目，由 CEC 资助，作为欧洲系统和软件倡议（ESSI）过程改进实验的一部分。该项目的唯一参与者是 BAE SYSTEMS Avionics Limited，这是欧洲最大的航空电子和地面支持设备生产商之一，其航空电子系统部门涉及安全相关应用的软硬件开发。
-
项目目标
：SITAR 的主要业务目标是降低软件测试成本，通过提高集成过程的自动化程度，在更短时间内开发更多测试用例。具体可细化为以下技术任务：
- 评估 TestMate 在单元测试中的应用。
- 评估用增强的集成测试替代单元测试的可行性。
- 评估使用 TestMate 和 StateMate 进行自动化集成测试的效果。
软件测试级别与任务
-
测试级别 ：软件测试主要有三个级别，具体如下表所示：
| 测试级别 | 测试内容 |
| ---- | ---- |
| 软件单元测试 | 孤立地测试每个代码单元，以满足功能覆盖（如设计参数边界分析）和结构覆盖（如语句覆盖），通常使用存根例程简化测试。 |
| 软件集成测试 | 在主机环境中，使用硬件接口模型测试完整或逐步增大的软件构建，以满足功能覆盖（如需求边界分析）和结构覆盖（如每个过程或函数至少被调用一次）。 |
| 系统集成测试 | 直接根据系统需求创建测试用例，测试完整的软硬件在目标硬件上的运行情况。 | -
测试任务 ：单元或软件集成测试活动包含七个任务：
- 构建测试框架。
- 构建存根。
- 将测试用例应用于被测软件。
- 比较预期测试结果与实际测试结果。
- 计算结构测试覆盖率。
- 选择测试用例输入。
- 计算预期结果。
其中，前五个任务通常可由现有商业工具自动化完成。TestMate 不仅支持这五个自动化任务，还能提供测试用例输入生成的功能；而预期输出的自动生成则通过 StateMate 对软件需求的建模来计算。
实验使用的工具
- TestMate ：由 Rational 开发，作为其 Apex 开发环境的一部分，完全集成到开发环境中，并利用其配置管理环境。它使用表格指定输入和预期输出，允许用户存根例程和调用支持例程，还能创建所需的框架和存根例程，构建并运行测试，同时可分析测试覆盖率，测量的覆盖率包括语句、决策和 MCDC 三个级别。
- StateMate ：由 I-logix 开发，支持使用状态图进行建模，包括编辑、检查、图形动画和生成 C 代码。通过对基线项目部分需求进行状态转换图建模，并嵌入标准 C 代码实现解析器，可读取测试列表文件并生成输出，模型还可生成 C 代码，以独立可执行文件或在工具内运行，同时可创建图形界面实现输入输出。
实验结构
实验对基线项目的配置软件构建进行测试，并构建 StateMate 模型计算预期结果。测试评估分为三个阶段：
1.
单元测试
：在生命周期的正常点进行测试和重新测试，编写单元测试以实现不同级别的覆盖，依次进行语句覆盖、决策覆盖和 MCDC 覆盖测试。
2.
手动软件集成测试
：对存储管理系统（SMS）的子集进行手动测试，使用手动创建的输入和预期输出。
3.
自动化软件集成测试
：借助 StateMate 模拟自动生成输入和预期输出的测试。
将不同类型的集成测试和单元测试结果与基线项目的传统测试过程结果进行比较。
基线项目情况
- 项目概况 ：SITAR 在一个航空电子基线项目中研究新测试技术的有效性。该项目是飞机 SMS 升级的一部分，增加了新的存储类型，是一个实时嵌入式系统，用 Ada 83 编写，约 3000 行 Ada 代码，占总软件的 8%。
-
测试工具使用
：
- 单元测试：使用内部工具 THUG 自动生成测试框架和存根，应用测试用例并比较结果，测试用例以脚本文件形式创建，输入手动选择，预期结果手动计算，使用 LOGISCOPE 测量测试覆盖率。
- 集成测试：软件和硬件集成作为单一操作，手动进行集成测试，借助测试台提供输入和显示输出，输入和预期结果从需求中获取，未测量集成结构覆盖率。
- 配置管理：使用基于 VAX 的工具 LIFESPAN 配置测试描述、框架和结果以及开发的其他可配置部分。
此外，还有一个用于评估 Ada 95 中 TestMate 工具的项目，该项目使用 Apex 环境，旨在提高组件的复用性。
下面是实验流程的 mermaid 流程图：
graph LR
A[开始] --> B[单元测试]
B --> C[手动软件集成测试]
C --> D[自动化软件集成测试]
D --> E[结果比较]
E --> F[结束]
软件集成测试自动化研究成果
实验结果分析
1. TestMate 用于单元测试的评估
实验对 30 个单元进行了单元测试，其中 14 个单元在更新后进行了重新测试。以下是相关结果分析：
-
测试时间对比
：与基线项目相比，并行项目在达到决策覆盖时所需的工作量仅为基线项目的 42%。语句覆盖的成本是决策覆盖成本的 90%，从决策测试到 MCDC 覆盖则需要额外增加 40%的工作量。
| 覆盖级别 | 与基线项目所需工作量对比 |
| ---- | ---- |
| 语句覆盖 | 90%（决策覆盖成本） |
| 决策覆盖 | 42%（基线项目） |
| MCDC 覆盖 | 决策覆盖基础上额外 40% |
出现语句覆盖成本较高的情况，是因为在进行语句级测试时，虽然未刻意测试决策覆盖，但在常规测试真分支后添加测试以断言其他真分支时，忽略了已测试分支，导致假分支经常被执行。
-
测试更新时间
：更新测试以重新建立决策覆盖所需时间是创建新测试时间的 71%。这一比例较高的原因包括熟悉测试、确定现有测试失败原因、运行测试以及处理类型更改等操作所需的时间。例如，测试列表中全局变量或参数定义的类型更改，需要删除相关列并替换为使用新类型定义的列。若能合理控制全局存储的大小，这一比例可能会得到改善。
-
测试等待时间
：测试过程中 34%的时间用于等待测试完成。TestMate 创建的框架包含输入和所需输出，编译和链接该框架与其他代码可能需要大量时间，尤其是在首次运行创建测试塔时。对于一开始就使用子系统功能开发的系统，此问题可能不明显，但对于像基线项目那样导入到单个子系统中的系统，构建时间需要重点考虑。
-
TestMate 工具局限性
：TestMate 不支持分离体（separates），需要将其移动到包体中。虽然 Apex 提供了相关工具进行此操作，但会因开发构建和测试构建不同而产生配置问题。若避免使用分离体，该问题则不会出现。
-
测试有效性
：由于代码基线确定较晚且单元测试和集成测试同时进行，难以确定测试的有效性。所有发现的集成和单元测试问题（4 个）均由代码中的设计错误导致，仅靠单元测试无法检测到这些问题。使用 TestMate 降低了单元测试成本，主要得益于其更好的集成性（基线项目的覆盖率分析由单独工具完成）以及表格输入格式。这种格式易于理解，方便查看输入和输出，还鼓励通过复制粘贴操作复用测试。
以下是测试时间与单元大小关系的 mermaid 流程图：
graph LR
A[单元大小（代码行数）] --> B[测试时间]
B --> C[与平均测试时间对比]
2. TestMate 用于增强集成测试的评估
- 初始测试方案问题 ：最初计划测试系统的完整构建，但花费一天时间转换基线项目后发现此方法不可行。软件中的执行程序不允许将时间数据作为参数和全局数据输入，也无法在指定点停止执行。若要实现该方法，需要编写框架来刺激系统并观察其在特定时间的行为，然后使用测试列表与框架通信并检查结果。然而，考虑到可能已经存在用于正式鉴定的全自动测试台，需要权衡构建代表现有硬件测试台的框架成本与在测试台上测试系统所需的时间。
- Apex 组件开发优势 ：Apex 支持基于组件的开发，通过子系统将开发拆分为更易管理的部分，使 TestMate 能够采用自顶向下的方法逐个添加组件来测试系统。
- 测试特定部分系统 ：实验选择测试基线项目系统的一个部分，所有测试代码由一个单一例程开始的树调用。测试发现，全局数据在根据需求进行测试时起着重要作用。被调用例程仅返回一个参数，良好的设计有助于将数据从接口例程中抽象出来。通过为与特定例程及其调用例程相关的所有需求创建测试，实现了 100%的决策覆盖。这表明，仅根据需求进行测试通常可以获得较高的覆盖率。
- 通用测试策略 ：一般的测试策略是，当子系统 A 导入到子系统 B 时，先完全测试子系统 A 以证明其符合需求，然后测试子系统 B，重点关注 B 的覆盖要求以及 A 中支持 B 的部分。测试完成后，可将覆盖率报告合并以获得整个系统的总体覆盖结果。
- 组件开发项目应用 ：第二个基线项目旨在实现高复用率，采用了组件化的系统开发方法。每个组件（通常是单个子系统）都有自己的需求。为使该过程可行，需要在项目早期考虑使用 TestMate，以便提前开发以子系统形式存在的存根，并与系统的正常开发一起进行规划、开发和配置。
综上所述，软件集成测试自动化在降低测试成本和提高测试覆盖率方面具有一定的潜力，但在实际应用中需要考虑工具的局限性和项目的具体情况。通过合理选择工具和测试策略，可以更好地实现软件测试的目标。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
