多少和什么样的覆盖率分析才足够

　　对覆盖率分析的讨论可能会提出许多不同的假设，这些假设并不总是一致的。这是否意味着检查所有代码是否已执行？这是否意味着所有要求都已得到执行和测试？它是否带来了一些 100% 以外的数字可以依赖的功能代码？我们要做的是确保自己，即使在危及生命的情况下，程序也已经过彻底的测试，可以信赖。我们如何实现这一目标以及覆盖范围的哪些方面？会让我们高枕无忧吗？

　　软件测试和分析可以被认为是由许多相互依赖的部分组成的整体活动。其中包括需求跟踪、静态和动态分析、编码标准合规性等，包括覆盖范围分析。归根结底，覆盖率分析应该让我们了解一段代码的测试程度和彻底程度。当然，这取决于其他测试方法的应用程度和彻底性及其结果。因此，它实际上是对我们测试的测试，而不是对程序本身的测试。

　　那么，是什么可以让我们很好地了解我们测试的好坏呢？

　　一种方法可能是检查程序中的所有行是否已执行。然而，仅凭这一点并不能告诉我们执行路径是如何到达这些行的，或者它以什么顺序和在什么条件下这样做。它与需求没有直接关系。毕竟，这些要求是首先生成自动和手动测试的基础。

　　覆盖率的另一个做法是分支覆盖率，它显示了代码段之间的执行路径，但不一定是每一行。分支覆盖率可以根据执行路径揭示程序的结构。分支是“这个”或“那个”。它告诉我们执行可以走哪条路，但它没有说明为什么代码会以一种或另一种方式进行。这为我们提供了执行结构的图片，但即使它揭示了所有分支在执行过程中至少执行过一次，它也没有显示从分支获取一条或另一条路径的条件。也就是说，它不一定表示所有情况（布尔表达式、条件）都经过测试，或者至少测试了所有满足要求的情况。

　　表达式“如果 A 是分支”。当然，它可能是一个更复杂的表达式，会导致真或假 A，因此 A 的结果值就是决策。决策覆盖率意味着每个点分支至少被调用过一次，并且每个分支采取的所有决策都至少执行过一次。这是比分支覆盖率更强的度量，因为它将分支链接到路径。因此，旨在执行程序中每个决策点的每个结果的测试就是分支决策测试。但是，每个结果的执行并不涉及可能导致该（如果，那么）决定的不同输入和条件。为此，我们必须转向分支/决策测试及其表亲，修改条件/决策覆盖率（MC / DC）。

　　MC/DC 使用每个条件至少调用一次程序中的每个进入和退出点，以便决策至少一次采取所有可能的结果，并且可以证明更改决策中的任何条件可以独立影响该决策。一个条件被证明通过改变该条件同时保持固定所有其他可能的条件来独立地影响决策的结果。

　　虽然指标很棒，但仅靠指标并不能帮助我们确信我们的代码将按照我们预期的方式工作。测试必须与程序的要求相关 - 程序是否做了它应该做的事情 - 并且这些测试必须是生成和跟踪适当覆盖指标的测试。这种观点 - 通过可追溯性增强覆盖范围 - 是DO-178B和IEC 61508等不同标准所描述的功能安全的关键。这种组合使我们能够知道代码做了它应该做的事情——我们已经通过测试场景执行了它。

　　审核编辑：郭婷