用于验证错误优化的静态测试用例和测试过程分析工具

效率和质量在任何领域都很重要，软件验证也不例外。“静态测试用例和测试过程分析工具”提高了验证项目中工件的质量，并有助于纠正其中引入的人为错误。

介绍：

客观的：

在航空电子领域，安全关键软件必须通过 DO-178B/C 合规方式遵守联邦航空法规。航空无线电技术委员会 （RTCA） 和欧洲民用航空设备组织 （EUROCAE） 联合开发了DO-178 机载系统和设备认证中的软件注意事项。DO-178B/C 是处理机载系统中使用的安全关键软件的安全性的指南，旨在满足适航系统的需求。机载系统中使用的软件必须满足标准和相关认证目标。

DO-178B/C 的目标之一是“对软件产品进行符合性审查”。同行评审的目的是确保完成软件生命周期，并交付优质产品进行认证。在同行评审过程中，评审者必须评审在评审过程中添加的所有工件，并确保这些工件没有缺陷。如果发现任何缺陷，审核者需要将其作为发现来捕获。

在下一步中，实施者必须针对这些缺陷提供适当的解决方案。在进行航空电子软件验证时，我们的团队遇到了许多与拼写错误、同一测试（或同一单元）内重复要求、冗余空格（前导、尾随、单词之间等）、HLR-to -LLR 可追溯性，以及缺少特定要求的测试用例。

审查者和实施者都需要花费大量时间来捕捉和解决这些发现。如果工件数量增加，识别和解决此类错误所需的时间也会增加。因此，为了避免此类发现，我们的团队提出了“静态测试用例和测试过程分析工具”。该工具是用 Python 开发的，可以捕获上述错误。它有助于实施者在初始阶段修复此类错误，并有助于减少审查过程的时间。

概述：

开发静态测试用例和测试过程分析工具的主要目标是尽量减少用户在搜索拼写错误的单词、空格、需求可追溯性问题（在 HLR 和 LLR 之间）和丢失的测试用例（未测试的需求）方面的工作量。

在这里，测试用例在 excel 或文本文件中开发并添加到工具中。测试用例包含测试用例 ID、低级和高级需求的跟踪、测试用例的目标以及包含输入/输出的测试步骤以及每个步骤的目的。

手动生成的文档必然存在容易被忽略的错误。但是，该工具会扫描整个文档并识别文本中的拼写错误、文本中存在的额外空格以及连续的重复单词。它还检查测试用例文件名和测试用例 ID 的命名约定，并将其记录在要显示的文本文件中。

虽然，excel提供了检查文本拼写的功能。它遍历每个单词并需要更多时间，而该工具可以直接显示错误及其位置。

分析需求可追溯性和定位缺失的测试用例是该工具的另一个特点。在验证中，需求覆盖率是一个非常重要的方面，也是 DO-178B/C 标准的核心目标之一。DO-178B/C 第 A-7.4 节和 A-4.6 节的目标分别是“实现低级需求的测试覆盖”和“低级需求可追溯至高级需求”。

工程师必须检查需求是否经过测试，以及每个低级需求 （LLR） 是否都有相应的高级需求 （HLR） 可追溯。静态测试用例和测试过程分析工具从测试用例文件中收集数据并维护 LLR 和 HLR 列表，以便用户可以轻松查看并交叉检查 LLR 到 HLR 的可追溯性。

该工具检查每个 LLR 是否有与之关联的测试，并记录同一单元格中 LLR 和 HLR 的重复项，帮助用户最大限度地减少检查整个测试文件的工作量。

设计细节：

静态测试用例和测试过程分析工具主要分为两部分：1）需求追溯分析，2）发现拼写错误、空行、多余的空格和错误的测试用例ID（静态分析和清理）。

在需求追溯分析部分，.xlsx 中的测试用例和 .csv 中被测模块的需求列表作为该工具的输入提供。它会生成包含 LLR 和相关测试 ID 的 CSV 文件、包含测试 ID、HLR、LLR 的解析数据的 excel 文件，以及带有 LLR 和 HLR 的任何重复项的文本文件。

图 2.1：工具的需求追溯分析功能

该工具的需求可追溯性分析部分执行以下功能：

HLR 和 LLR 之间的可追溯性 —— CSV 格式的测试用例文件和被测模块的需求列表作为输入提供给为检查需求可追溯性而开发的功能。它根据测试用例 ID、LLR 和 HLR 解析测试用例文件，并将其放入新创建的 xlsx 文件中。输入 CSV 文件包含特定模块的要求列表。

需求测试可追溯性 ——该函数从 CSV 文件中读取需求并将它们搜索到已解析的 HLR 和 LLR xlsx 中。如果 LLR 存在于已解析的工作表、LLR 和 HLR 中，它会捕获相应的测试用例 ID。该工具创建一个新的 CSV 并在其中写入 LLR 及其各自的测试用例 ID。如果 LLR 不存在，则会导致字符串显示“需求未测试”。

重复需求识别 - 该工具识别解析的 HLR LLR xlsx 文件中的单元格是否包含重复的 HLR 或 LLR，并在文本文件中记录这些需求。

在工具的静态分析和清理部分，提供一个或多个不同格式的测试文件（例如 .xlsx 或 .txt）作为输入，这些错误的结果记录在一个文本文件中。

图 2.2：工具的静态分析和清理功能

静态分析和清理部分执行以下功能：

捕获静态错误（拼写错误、多余的空格、连续重复的单词等）——用户可以选择一个或多个测试用例文件并将它们作为输入提供给检查测试用例文件中的静态错误的函数。该工具检查测试用例文件名和测试 ID 名称是否符合指南，并在文本文件中记录所有错误。它还报告测试用例文件中未使用的行。

结果：

该工具生成四个结果文件：

静态错误报告 （.txt）

HLR 和 LLR 之间的可追溯性报告 （.xlsx）

需求和测试之间的可追溯性报告 （.csv）

重复要求 （.txt）

以下片段可帮助用户了解该工具如何工作并产生结果。

图 3.1：测试用例中的静态错误报告

图 3.2：HLR 和 LLR 之间的可追溯性报告

图 3.3：需求和测试之间的可追溯性报告

图 3.4：显示重复需求的报告

静态测试用例和测试过程分析工具与 C# 开发的 GUI 的集成：

我们已经成功地将我们团队创建的静态测试用例和测试过程分析工具与另一个团队实现的 GUI 工具集成在一起。挑战在于 GUI 工具是用 C# 实现的，而静态测试用例和测试过程分析工具是用 Python 实现的。

集成两者的想法使用户能够保持他们一直在使用的相同 GUI，并具有用于检查他们正在处理的 TC 中的静态错误的附加功能。集成过程包括启用 python 脚本以提供与基于 C# 的 GUI 的接口（即，使函数以测试用例列表作为参数在命令行上执行），从 C# 调用 python 脚本，以及从 C# 执行文件操作生成日志文件。

以下是此集成的功能：

节省单独操作工具的开销

GUI工具本身提供了选择TC、执行工具、分析报告等所有界面，节省了工程师执行每个步骤的时间

执行活动与 GUI 工具中的时间戳（以活动日志的形式）一起监控，让用户知道执行是如何工作的

案例分析：

如引言中所述，如果在实施阶段没有发现和解决错误，则在审查过程中纠正错误的实施和审查工作会更大。本案例研究包括同行评审过程中确定的一项发现以及解决该问题所需时间的估计。下面提供的分析显示了在此工具的帮助下可以节省多少实施和审查时间。

同行评审结果描述：

清除单词“contrl”的所有拼写错误，即测试 1 中的目的陈述 - “Slider contrl”应该是“Slider control”。

工件需要重命名。根据指南重命名它。

描述大概时间

大约。是时候让审阅者发现错误并记录下来了。5分钟。

大约。是时候让实施者进行清理了。1分钟。

大约。实施者提交更改、重新生成日志和响应解决方案的时间。10 分钟。

总周转时间15 分钟。

现在，如果在实施时发现相同的错误，它可以在不到 5 分钟的时间内修复。

表 5.1：工具的有效性

优点：

该工具的有效性随着多个工件和多个 TC 的审查而增加

将修复错误的周转时间缩短 70%

减少与拼写、命名约定和 HLR-LLR 可追溯性问题相关的发现数量

未来范围：

它将 LLR 和相应的 HLR 作为需求管理工具的输入，并检查测试用例是否包含正确的 LLR 到 HLR 可追溯性。

基于解析的 LLR，它生成一个 TC 模板，该模板将根据需求准备好一些基本字段，如目标、目的、输入/输出。

支持以 .c、.py 或 .xml 格式手动创建的测试程序文件。

支持 pdf 标记。

结论：

该工具的目的是通过消除需求可追溯性问题和错误（例如空格、重复单词、拼写错误的单词和命名约定）来生成健壮或高质量的工件。它可以节省大约 10 分钟。对于每个工件。

当有多个工件时，该工具会更有效，并节省大约 70% 的周转时间。通过持续使用该工具，我们的团队消除了与上述所有错误相关的发现，显着提高了工件质量和工作效率。

审核编辑：郭婷