用于嵌入式开发的单元测试最佳实践

Question

我正在寻找一些为嵌入式系统编写的单元测试代码的最佳实践策略。所谓嵌入式系统，我指的是代码，如设备驱动程序、ISR处理程序等，它们非常接近于金属。

如果不借助ICE在硬件上进行测试，大多数单元测试都是不可能的。有时，嵌入式单元也需要连接到其他刺激，如机械开关，步进电机和灯泡。这通常发生在手动方式，自动化将是伟大的，但难以实现和昂贵的。

更新

我遇到了一个C测试框架，它在测试嵌入式项目方面似乎相当成功。它使用了模拟硬件的思想。看看统一，CMock，可能还有塞德林。

更新2016年7月6日

偶然发现克明卡 -似乎是更积极的工作。

Answer 1

我将尽可能早地从硬件依赖项中抽象化，并在软件仿真/测试工具上构建系统，从而启用各种测试框架。我开发的个人电脑经常被用来测试多达95%或更多的完整系统。额外开销(另一层抽象)的成本很容易通过抽象生成的更干净的代码来收回。

对嵌入式系统中真正的裸金属部件的测试通常是一个独立的应用程序(单元测试？)这使得固件远远超出了应用程序所希望达到的目标。自动化是可以做到的--付出代价，但并不是典型的。

除非，也就是说，你有预算来构建一个单元测试硬件线束，包括完整的ICE。这是绝对好的，因为一般的功能测试是小的。

Answer 2

编辑:我的答案接近mattnz，我想.

我想将这个问题与其他测试联系起来，所有这些测试都依赖于代码外部的某些内容(比如系统时钟、持久文件系统或数据库，与外部web服务联系.)。我建议对所有这些代码都使用相同的策略，将这两个级别隔离在两层代码中。

测试单个外部操作

您可能需要对每个操作进行物理测试。检查系统时钟是否给出了正确的时间，检查一个文件实际上记住了所写的内容，检查一个设备接收到了一个操作.

这些测试：

• 应该尽可能简单:没有任何算法，没有条件或循环。
• 可能依赖于订单，也可能依赖于机器:因此，您需要严格执行命令，并在每个硬件上重复。
• 在您的项目过程中大部分是稳定的，所以您不需要经常运行它们
• 因此，手动运行它们是一种选择；自动化甚至更好，即使不是过于复杂。
• 请注意，正在测试的不是您的代码，而是您的代码需要的工具.所以测试这对你来说可能是可选的，可能是由另一个团队做的.

测试将外部操作

连接在一起的逻辑(代码、算法)

通过拥有一层代码来进行实际的外部操作，通过隐藏它们作为一个您可以轻松模拟的接口，您的逻辑不再依赖于实际的物理设备.

您可以简单地进行测试，就像任何常规项目一样，您不再处于嵌入的难以测试的代码中。

Answer 3

嵌入式CPU模拟器一般也可以编程来模拟硬件。除Xen之外的所有虚拟化技术都是这样做的。但是，您需要编写一些代码，这些代码假装在某个物理地址上有一些寄存器，或者在x86上在I/O总线上有一个地址，然后您需要响应对这些地址的读写，就好像您的软件是一个物理芯片，其控制和状态寄存器正在被访问一样。

如果您想这样做，我建议修改QEMU。但这并不容易。这类事情通常只有在您设计带有微控制器的定制芯片和I/O的其他核心时才能完成。

ARM控股出售的开发系统为此提供了条件，并且可能比黑客攻击QEMU更容易使用，但非常昂贵。

有几个开放源码ARM模拟器运行一个子程序，它本身可以调用其他子程序，您可以使用这些子程序来调试不依赖于硬件访问的子程序的性能。我使用其中之一成功地优化了ARM7TDMI的AES加密器。

您可以用C或C++编写一个简单的单元测试工具，将测试中的类或子程序链接到它，然后在模拟器中运行它。

多年来，我一直在思考一个类似的问题，如何对Linux或Mac内核代码进行单元测试。这应该是可能的，但我从来没有试过。一种可能是构建完整的内核，而不是孤立地测试代码，将单元测试框架直接链接到内核中。然后，您将从某种外部接口启动单元测试。

也许使用代码覆盖工具会更有效率，然后通过外部接口测试您的固件作为一个完整的包。覆盖率工具将找到尚未测试的代码路径，因此您可以添加额外的外部测试以获得更多的覆盖率。