100%代码覆盖率分析是否必不可少

安全关键型软件标准高度关注如何有效地测试软件。他们指出，有效的软件测试需要一种规范的方法，其中代码覆盖率用于提供有关迄今为止测试有效性的反馈。应用于系统的测试严格程度必须由系统故障的影响决定。后果越严重，测试必须越严格。

覆盖率分析是软件安全的重要组成部分，但随之而来的是两个问题 - 覆盖率是多少 - 以及我如何最大限度地减少实施流程所涉及的工作量。让我们看一下安全关键流程标准的指南，看看它们如何讨论覆盖范围，以及覆盖范围如何影响风险管理。我们还将考虑实施工作 - 基本规则是从简单开始并建立 - 并尝试了解这些因素如何结合在一起。

在现实生活中 – 从选择承保级别的实际角度来看，始终从报表承保范围开始，并在必要时从那里开始工作。DO-178 和 ISO 26262 的指南可帮助您确定适合您项目的覆盖级别。这两个标准都要求进行系统安全评估，以确定故障的影响和系统目标故障率，这反过来又定义了证明系统已经过适当测试所需的测试级别。毋庸置疑，失败的影响越大，测试效果必须越严格。然后强制要求适当级别的代码覆盖率，以证明已达到适当的测试级别。

这导致了一些问题，例如您的系统对您的任务有多重要？我应该以什么样的故障率为目标？下表提供了一些关于选择美国联邦航空管理局 （FAA） 就 DO-178 讨论的适当覆盖范围级别的指导。

代码覆盖率作为测试严格性的衡量标准必须谨慎应用。例如，在没有测试计划的情况下执行系统所实现的覆盖范围是不合适的。执行必须由测试计划和需求驱动。通常，安全关键软件标准的指导是，为了证明适当的测试严格程度，测试必须由需求驱动并在系统级别执行。但是，根据适当的要求，您可以使用在单元级别驱动的测试来补充此测试。只有这样，才适合使用覆盖率分析来衡量测试的完整性。

在实践中，从系统级测试中实现 100% 的代码覆盖率既不合适也没有必要。实现系统的最大代码覆盖率是一个迭代过程。使用代码覆盖率结果作为反馈，可以识别测试过程中的缺陷，例如缺少需求、缺少测试用例、无法访问、不需要或失效/停用的代码。然后可以添加测试用例，解决需求，重构代码以解决提出的问题。然后可以更新和重复测试，直到满足项目的测试效果目标。这可能包括考虑未使用的代码（例如，当仅使用部分开源组件时）或用测试工具的结果增强系统级测试结果，甚至代码检查。

在选择有助于进行覆盖率测量的工具时，请务必注意，并非所有覆盖率分析工具都是平等的，选择错误的工具可能会损害您准确测量覆盖范围的能力，或者更糟的是，提供不正确的结果。以下是选择覆盖范围分析工具时需要考虑的一些问题：

• 覆盖率测量实施的内存占用量是多少，尤其是在测试嵌入式系统时？

• 该工具是否支持您的嵌入式系统？

• 运行时数据的内存占用量是多少？您的系统是否有足够的内存来进行有意义的测量？

• 检测是否会影响系统运行时行为？

DO-178 通过要求必须验证用于测量代码覆盖率的任何工具，以便在目标环境中产生准确、可靠的结果，从而为这些决策提供指导。因此，您需要确保您选择的工具符合 DO-178 的要求，以便可以放心地使用它产生的结果，而无需进一步验证。检查工具的谱系。

代码覆盖率 — 提供基本保证

任何软件项目的代码质量都可以从应用安全关键标准中的一些简单指南中受益。为了控制测试的有效性，必须使用代码覆盖率来衡量测试的影响，使用适合软件所需的测试严格程度的代码覆盖率级别。为了确保测试的严格性达到适当的水平，所有测试都必须基于需求并在系统级别执行。测试，测量，重复。如果没有代码覆盖率分析，就不可能获得提高测试有效性所需的反馈、知识和理解。选择覆盖范围分析工具时，请确保选择 DO-178 限定工具，以确保选择具有适当谱系的工具。通过遵循这些准则，任何软件项目都可以达到安全关键系统通常预期的软件质量水平。

审核编辑：郭婷