通过覆盖分析深入研究安全关键代码测试

对于安全关键代码，确保应用程序执行它应该执行的操作并正确执行这些操作的功能测试只是表面上的问题。应用程序包含隐藏的复杂性，这些复杂性可能会在不可预测的条件下出现。如果编码不正确，它们可能会导致灾难。开发人员必须深入挖掘以测试所有底层代码是否存在细微错误。但这究竟是什么意思？

虽然可以从系统需求文档手动生成基本功能测试，但使用自动化工具（生成测试工具和测试用例的工具、运行这些测试的工具以及评估测试有效性的工具）进行更深层次的测试会更有效。 最后，关键活动是通过覆盖分析完成的。

在基本层面上，函数（或过程）覆盖分析显示每个函数是否已被调用。语句覆盖更进一步，提供了一种方法来确保每一行代码至少被执行一次。但是虽然这些都很有用，但覆盖分析不仅仅是函数和语句覆盖。

安全关键代码需要更深入的分析

可以在多个级别测试代码，安全关键代码需要深入、彻底的研究。分支/决策覆盖提供了更彻底的检查，旨在证明每个分支至少被采用一次，而分支条件组合覆盖需要测试所有可能的条件组合。

这听起来很简单，但如果一个决定取决于四个或更多条件，那么测试每个组合的要求就会变得不合理。修改条件/决策覆盖或 MC/DC 旨在提供一种实用的替代方案。MC/DC 确保：

调用每个入口和出口点

每一个决定都有每一个可能的结果

决策中的每个条件都包含所有可能的结果

决策中的每个条件都显示为独立地影响决策的结果

函数调用覆盖扩展了该查询线，并通过生成有关已执行哪些函数调用的信息来构建函数覆盖概念。这很重要，因为错误通常发生在模块之间的接口中。

在某些情况下，例如受 DO-178C 等标准约束的关键航空电子应用，还需要进行更苛刻的测试。对于最关键的“DAL A”应用，DO-178C 需要目标代码验证，其中包括分析汇编代码和源代码的覆盖信息。

动态测试通常使用软件工具进行，该工具检测源代码的副本以在运行时提供覆盖率数据。随后分析该数据以准确揭示代码的哪些部分已被执行，以及执行到什么级别。它以数据和控制流程图以及带有符号的源代码等显示形式使开发人员可以看到结果（图 1）。

【图1 | LDRA 的 TBvision 代码覆盖为 DO-178C 等安全关键标准提供语句、分支和 MC/DC 覆盖。背景是一个分支/决策图，交叉引用了带注释的源代码。前景是每个功能和通过/失败结果的覆盖范围摘要。］

使用自动化工具减轻琐碎的测试任务

动态分析可以应用于完整的应用程序（系统测试）或它的子集（单元测试，包括集成组件测试），并且通常在完整系统可用时使用这两种方法的组合。一个集成的工具套件整理来自两个来源的信息，以提供整体覆盖率指标。单元测试工具通过静态分析代码结构，然后围绕应用程序创建一个“线束”或框架，在测试期间注入输入并接收输出，从而减轻了设置测试环境的繁琐工作。对于安全关键型应用程序，“测试向量”必须基于要求，以提供证据证明代码对预期和未预期的输入都按预期执行，但仍满足要求，仅此而已。

还可以通过对源代码的深入静态分析自动生成测试向量，这通常会导致在运行时覆盖 50% 到 75% 的代码。显然，这并不能提供正确功能的证据，但它确实在非关键应用程序中占有一席之地，否则覆盖率分析可能不会发生。即使在关键应用程序中，这种方法通过验证面对边界值、空指针和默认 switch 语句条件等数据的稳健行为，将动态分析超越了基于需求的测试。

在开发周期中尽早开始单元测试是最具成本效益的，甚至可能在目标硬件可供开发人员使用之前。这意味着使用在主机开发系统和目标硬件上应用相同测试向量的工具非常重要，以便生成一次测试用例，从而节省时间和金钱。

一个完整的工具套件还可以提供数据和控制流分析形式的分析，这是 DO-178C（航空电子）和 ISO 26262（汽车）等标准所要求的，以确保功能的每次调用都已执行，并且对数据的每次访问都已执行。它通过源代码跟踪变量并报告异常使用（图 2）。

【图2 | 基于当前测试运行的变量和参数使用报告突出显示文件中使用变量的文件和位置，并使用允许更精细测试的自定义过滤器。］

这种深层次的测试——以及对测试的彻底和严格的评估——只有使用一套集成的软件分析工具才能可靠地完成。

审核编辑：郭婷