代码覆盖率是评估汽车软件在开发过程中是否符合相关标准要求的一个常用指标。然而不应将其视为唯一目标因为即使覆盖率达到100%也无法保证验证结果的可靠性或充分性。代码覆盖率是当今任何开发流程中不可或缺的一部分并已成为软件开发中最受欢迎的指标之一因为它既易于测量又易于理解。然而100%的代码覆盖率并不意味着软件已经得到充分验证。看到100%的代码覆盖率会给人一种完整的感觉毕竟每一行代码都已执行。然而这种假设引发了几个问题。首先需要明确用于测量代码覆盖率的方法。不同的方法可能会导致不同的结果。此外还必须明确覆盖率是基于什么对象进行测量的。要回答这个问题需要进一步探讨。本文探讨了代码层面的覆盖率要求并说明了覆盖率可以且应该用于哪些方面。此外本文还举了一个仅靠代码覆盖率就可能足够的案例。本文不会解释代码覆盖率的各种类型。标准如前所述代码覆盖率测量是许多重要软件开发标准中的组成部分。汽车行业也不例外。如果你仔细查看“常见标准”就会发现不同标准对代码覆盖率的要求各不相同。汽车SPICEASPICE汽车SPICEASPICE是许多开发项目的基础。例如在3.1版本中SWE.4 软件单元验证仍然提到覆盖率目标值可以用作单元验证的标准。到了2023年底发布的4.0版本只提到了验证覆盖率。该标准目前并未明确规定具体应如何实施。ISO/SAE 21434:2021由于网络安全如今与所有使用软件的行业都息息相关因此针对汽车行业的 ISO 21434 标准如今也几乎被广泛采用。但在软件开发安全的实际实施方面该标准给出的具体规定非常少许多地方以建议为主。其中包括一条建议如果选择通过测试进行验证则应使用覆盖率指标来判断测试活动的适当性。此外还有一条注释指出单纯的语句覆盖率可能不足以满足网络安全的要求。ISO 26262: 2018道路车辆功能安全标准专门在第6部分ISO 26262-6:2018中对软件开发进行了论述。在关于软件单元验证的章节中表9明确列出了应根据关键性级别记录哪些覆盖率指标。ISO 26262 还定义了进行覆盖率测量的目标。包含表 9 的要求 9.4.4 规定应进行覆盖率测量以评估验证的完整性并提供客观证据证明单元测试目标已实现。而第 9.1 章对单元测试的目标定义如下● 证明已实现的软件单元符合设计并满足指定的软件需求。● 提供充分证据证明其中既不包含非预期功能也不包含非预期属性。或者用两个词概括就是正确性和完整性。正确性和完备性此前已指出代码覆盖率的概念与完备性概念密切相关。然而代码覆盖率无法对代码的正确性——即代码是否满足其被赋予的需求——做出任何判断。在这方面通常会使用直接基于需求的测试用例。无论该需求来自需求管理工具、用户故事还是其他形式的预期都无关紧要。一次成功的测试可以提供有关某项功能是否已实现的信息。通过用测试覆盖所有需求可以对代码的正确性做出判断。这里同样涉及“覆盖率”的概念即测试覆盖率即测试用例的覆盖率。此时代码覆盖率使得评估代码的完整性成为可能前提是在执行所有基于需求测试的过程中确定了适当的覆盖率。原则如下如果通过完整的测试覆盖率证明了正确性那么结合完整的代码覆盖可以进一步评估测试活动在代码结构层面的完备性。测试覆盖率与代码覆盖率相辅相成因此具有互补性见图1。图1 测试覆盖率和代码覆盖率结构覆盖分析的结果作为互补目标为了更好地理解如何从正确性陈述中推导出完备性有必要将视野扩展到汽车行业特定标准的范围之外。尽管 ISO 26262-6:2018 在 9.4.4 节的示例 2 中也列举了覆盖率缺失的各种原因但在其他标准中可以找到描述更为详尽的流程。航空电子领域的软件开发标准 RTCA/DO-178C 详细描述了覆盖率测量结果应如何使用。首先执行所有可用的测试并记录所达到的覆盖率。然后对未被覆盖的代码部分进行审查。这可能有多种原因图2A. 需求不完整。B. 需求尚未经过全面测试。C. 该代码是根据编码规范防御性编码而存在的或者因其他合理原因无法访问或无法获取。D. 该代码可有可无。图2 此过程中代码覆盖率不足的可能原因针对这些原因每一种都有明确的应对措施。可能是增加需求A、增加更多测试B、记录原因C或删除多余的代码D。这里可以看出这其实是一个迭代的过程而不仅仅是一次性的分析。它也表明代码覆盖不仅包括测试执行时测得的覆盖率还包括理由说明和分析特别是在情况C中这通常成为“通过分析获得的覆盖Coverage by Analysis, CBA”。如果在这个过程中实现了完整的代码覆盖可以得出以下结论● 相对于代码而言需求是完备的。● 测试已全面覆盖这些需求测试覆盖率。● 对于测试无法触及的每一段代码都有合理的说明。● 没有多余的代码。什么是代码覆盖率前文的论述始终假设代码覆盖率是基于需求驱动的测试来测量的。但这并非实现代码覆盖率的唯一途径。不过由此得出的结论也会有所不同。例如源代码覆盖率可以通过静态分析来测量。尽管人们常声称可以达到100%的覆盖率但这并非真正的代码覆盖率因为在分析过程中代码并未被执行。不过这种方法也能涵盖代码覆盖率分析的某些方面并揭示出无法执行和可省略的代码。但无法通过这种方式证明代码在指定需求方面的正确性。该评估基于源代码的结构仅检查语法正确性和逻辑结构。因此“完整性”的论断仅能指分析本身。而分析类型并不改变这一论断因为对代码的形式化分析同样属于静态分析且不会执行代码。即使是基于代码的测试——即基于代码结构而非需求进行的测试——也能实现完整的代码覆盖率尽管无法就此对正确性作出断言。尽管如此这些测试仍有其作用作为所谓的特征化测试characterization tests它们可用于描述代码当前的功能。如果源代码通过这种方式实现了全面覆盖那么对现有代码的修改就能更轻松、更高效地实施。一旦代码发生变更这些测试就能显示出代码行为在哪些地方发生了变化——无论是有意还是无意的。因此在修订或重构遗留代码时会使用这些具有完全代码覆盖率的测试。如果“在运行过程中”测量代码覆盖率这对排查故障会大有帮助。这种情况下目标既不是正确性也不是完整性。其目的是确定错误或崩溃发生的位置例如。理想情况下代码覆盖率应基于什么来衡量唯一剩下的问题是理想情况下应该基于什么来测量代码覆盖率。仔细分析后会发现有多种可能性基于原始源代码、翻译单元、汇编代码、可执行目标代码或可执行文件。1. 预处理器将源代码转换为所谓的翻译单元。2. 编译器根据翻译单元生成汇编代码。3. 汇编器将汇编代码转换为目标文件。4. 链接器将目标文件合并为可执行文件。图3 编译过程中的构建管道以及人类和机器对其可读性的评估随着每个阶段的推进关注点也在不断转变虽然源代码是为编译而写的但它仍然是为人类可读设计的。它包含注释允许简化宏还没有展开并且可能存在条件编译指令。预处理会去掉编译器不需要的内容并进行必要的替换。结果仍然可以被人阅读但已经和原始源代码有明显差别。随着进一步的步骤人类可读性会下降代码越来越被优化以便在目标系统上执行直到最终被翻译成机器码。ISO 26262 并未明确规定在构建流程的哪个阶段应显示代码覆盖率并达到目标值但其相关要求倾向于在目标系统上执行测试。如果测试在主机上进行则应单独考虑与目标系统之间的差异。这最初并不影响已达到的代码覆盖率显示的位置。出于效率考虑通常选择易于人类阅读的格式主要是翻译单元或源代码因为这样更容易据此得出结论并采取必要措施。这两种格式各有优缺点。例如翻译单元仅显示计划进行进一步编译的代码图 4。图 4在翻译单元上显示的“SourceFilePerspectiveDemo”函数的代码覆盖率然而预处理后注释会被移除而根据配置通过条件编译包含或排除的代码也只会保留当前配置对应的部分。而这正是主机与目标系统之间可能出现差异的地方因为通常必须针对主机上的编译进行调整。因此主机和目标的翻译单元之间存在差异。即使对于不仅用于一个变体的源代码原始源代码与翻译单元之间也可能存在显著差异图 5。因此建议在源代码上显示代码覆盖率因为这也能显示出当前编译中未被包含的代码段。图5 “SourceFilePerspectiveDemo”函数在源代码上的代码覆盖情况结论代码覆盖率是一个重要的指标但应该正确使用。将代码覆盖率作为孤立的目标并无太大意义仅凭代码覆盖率本身也不足以得出可靠结论。正如本文所述它更适合作为补充性证据。如果明确了测量代码覆盖率的目的并正确解读结果那么代码覆盖率就能够成为一项有力且值得记录的验证证据。