很长一段时间以来，嵌入式软件一直用于安全性非常重要的关键应用。在嵌入式开发中，由于嵌入式设备通常是与物联网(IoT)上的其他设备相连接的客户端，因此还需要考虑安全性问题。这意味着，无论是从安全角度还是从功能安全角度来看，嵌入式设备的质量都极其重要。

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

最重要的代码覆盖率是：

报表覆盖范围确定测试执行了哪些指令。可以检测死代码以及还没有为其创建合适测试的指令。

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

MC/DC(修改的条件/决策范围)是标准要求的最高级别，相当复杂。为了最小化测试工作，使用了复合条件的所有原子条件。在嵌入式开发中，对于每一个原子条件，测试用例对被测试，导致复合条件的整体结果的改变，但是只有考虑中的原子条件的真值改变。这里，其他原子条件的真值必须保持不变。

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

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

这个过程如图1所示。代码覆盖率分析器Testwell CTC++向源代码添加计数器(“插装”)。关于计数器的信息存储在名为“符号数据”的文件中。在测试期间(图的右侧),执行的次数被计数并存储在“数据文件”中。在过程的最后，Testwell CTC++的“报告生成器”将来自“符号数据”和“数据文件”的信息结合起来，生成一个“覆盖报告”。在嵌入式开发中，覆盖率分析的副作用是更高的内存消耗(通过比较使用和不使用工具时所需的内存显示在底部)。

即使用C编写的While条件很小，也能以这种方式显著增长。

初始结构

通过使用代码覆盖率分析器Testwell CTC++，变成了以下代码：

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

部分仪器

如果代码覆盖工具的插装开销太高，那么可以在RAM中使用部分插装来绕过这个障碍。使用部分插装，只有被测程序的一小部分被插装和测试。对所有程序部分一个接一个地重复测试，并将结果数据组合在一起，形成一个整体图。这允许确定整个程序的测试覆盖率。

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

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

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

结论

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