测量嵌入式软件的代码覆盖率

长期以来，嵌入式软件一直被用于安全性非常重要的关键应用。由于嵌入式设备通常是与物联网 (IoT) 上的其他设备连接的客户端，因此还需要考虑安全方面。这意味着嵌入式设备的质量非常重要——无论是从安全角度还是从功能安全角度。

对于安全可靠的嵌入式设备，测试是质量保证不可或缺的一部分。安全关键型软件开发标准对测试方法和测试覆盖率设定了精确要求，这并非没有道理。通常，应用程序越关键，对代码覆盖率的要求就越高。

最重要的代码覆盖率级别是：

语句覆盖率确定测试执行了哪些指令。可以检测死代码以及尚未创建合适测试的指令。

分支覆盖记录是否所有程序分支都经过测试。这是应放在测试中的最低要求。可以通过合理的努力来实现分支覆盖。

MC/DC（Modified Condition/Decision Coverage）是标准要求的最高级别，而且相当复杂。为了尽量减少测试工作，使用复合条件的所有原子条件。对于每个原子条件，测试一个测试用例对，导致复合条件的整体结果发生变化，但只有所考虑的原子条件的真值发生变化。这里其他原子条件的真值必须保持不变。

由于代码检测，代码大小增加

为了测量软件的哪些部分已经过测试，使用了代码覆盖分析器。大多数覆盖分析器的工作原理相同：它们在将代码传递给编译器之前对其进行检测。这意味着他们将计数器添加到代码中，以计算相关代码部分是否已被执行。这些计数器通常存储为全局数组。这种检测的副作用是代码变得更加庞大。这会给 RAM 和 ROM 带来额外的负载。

该过程如图 1 所示：代码覆盖率分析器 Testwell CTC++ 将计数器添加到源代码（“仪器”）。有关计数器的信息存储在名为“符号数据”的文件中。在测试期间（图右侧），执行次数被计算并存储在“数据文件”中。在过程结束时，Testwell CTC++ 的“报告生成器”将“符号数据”和“数据文件”中的信息结合起来生成“覆盖报告”。覆盖率分析的副作用是更高的内存消耗（通过比较没有和有仪器的所需内存显示在底部）。

点击查看完整大小的图片

（来源：Verifysoft Technology）

即使是用 C 语言编写的一个小的 While 条件也可以通过这种方式显着增长。

初始结构

而（！b == 0）
{
r = a % b;
a = b;
b = r;
}
结果=一个；

通过使用代码覆盖率分析器 Testwell CTC++ 进行检测，变为以下内容：

而 (((! b == 0) ? (ctc_t[23]++, 1): (ctc_f[23]++, 0)))
{
r = a % b;
a = b;
b = r;
}
结果=一个；

对于服务器或 PC 应用程序，这种影响可以忽略不计。另一方面，对于嵌入式设备，仪器开销可能会带来挑战，因为出于成本原因，硬件资源的计算通常非常严格。在这里，必须注意使用具有相对较低检测开销的代码覆盖分析器，否则计数器将很快超过可用内存的限制。当需要非常苛刻的测试覆盖级别（例如 MC/DC）时尤其如此。针对嵌入式系统优化的特殊分析仪，例如 Verifysoft Technology 的 Testwell CTC++，是正确的选择。

部分仪器

If the code coverage tool has a too high instrumentation overhead, this hurdle can be circumvented in RAM with partial instrumentation. With partial instrumentation, only small sections of the program under test are instrumented and tested. The test is repeated one after the other with all program parts, and the resulting data is combined to form an overall picture. This allows to determine the test coverage for the complete program.

测量小目标上的代码覆盖率的另一种可能的解决方案是限制计数器的大小。通常，代码覆盖工具使用 32 位计数器。这些计数器可以减少到 16 或 8 位。但是，这里应该小心，因为在某些情况下，计数器可能会溢出。因此，必须非常小心地解释获得的数据。在极端情况下，计数器也可以降低到单个位。此位覆盖（由 Testwell CTC++ 提供）可能很有用，例如，如果与程序部分运行的频率无关。

不幸的是，ROM 中所需的额外空间几乎是有限的。需要一个小型库来捕获代码覆盖率，除其他外，它负责将计数器读数传输到主机。

不要忘记：除了内存之外，检测还会给目标中的处理器带来负担。因此，可能会发生不再遵守定义的时间安排的情况。特别是如果 CPU 已经接近极限工作，可能会出现错误的进程。总线通信对此特别敏感。在这里，测试人员应该仔细监控过程并仔细检查结果。然而，强大的代码覆盖工具可以使检测内存需求和运行时行为变化保持相对较低。

结论

安全和安保在物联网计划的长期成功中发挥着重要作用。除了工业应用外，还必须以可控制用户和制造商风险的方式开发和测试私营部门的物联网程序。虽然 MC/DC 覆盖对于汽车和飞机中的安全关键型应用是强制性的，但至少分支覆盖应该是所有其他领域的标准。目前，只有少数标准要求证明对非安全关键软件的测试覆盖率，但标准化机构和行业协会在安全关键应用程序之外增加要求只是时间和市场渗透的问题。更好的测试也符合制造商本身的利益，因为有缺陷的产品会导致高昂的后续成本，并会严重损害公司的声誉。嵌入式领域的客户几乎不会接受以 PC 闻名的“香蕉软件”，交付后才成熟。