嵌入式软件单元测试

Question

在对嵌入式系统特有的嵌入式软件进行单元测试时，您使用了哪些最佳实践？

Answer 1

嵌入式软件可能在过去10年中取得了长足的进步，但我们通常做了以下几点：

• 对于不依赖于目标硬件的算法，我们只是在非嵌入式平台上构建和测试单元测试。
• 对于确实需要硬件的东西，单元测试被有条件地编译到代码中，以使用任何可用的硬件。在我们的例子中，它是目标上的一个串行端口，将结果推送到另一台功能更强的机器上，在那里测试在硬件上检查correctness.
• Depending，有时你可以在非嵌入式平台上虚拟一个“虚拟”设备。这通常包括让另一个执行线程(或信号函数)改变程序使用的内存。对于内存映射的I/O很有用，但IRQ和such.
• typically，没有用，你一次只能对完整代码的一小部分进行单元测试(由于对时间敏感的东西进行内存constraints).
• for测试，我们没有这样做。简单明了。如果运行速度太慢，我们使用的硬件(8051and 68302)并不总是起作用。这种调试最初必须使用CRO (示波器)和(当我们有更多的钱时) ICE (在线仿真器)来完成。

希望自从我上次这样做后，情况已经有所改善。我可不希望我最大的敌人也承受这样的痛苦。

Answer 2

在PC环境中进行单元测试(使用PC C编译器编译您的代码，并在PC单元测试框架中运行您的代码)可以获得很多好处，但有几个条件：

1. 这不适用于测试低级代码，包括启动代码、内存测试、硬件驱动程序。你将不得不使用更直接的单元测试。
2. 你的嵌入式系统的编译器必须是值得信任的，所以你不会寻找由编译器产生的bug。
3. 你的代码必须是分层的体系结构，具有硬件抽象。您可能需要为您的PC单元测试框架编写硬件驱动程序模拟器。
4. 您应该始终使用stdint.h类型，如uint16_t，而不是纯unsigned int等。

我们遵循了这些规则，并发现在PC单元测试框架中对应用层代码进行单元测试后，我们可以很有把握地认为它工作得很好。

在PC平台进行单元测试的优势：

在PC平台上，由于增加了单元测试framework.

• The编译-链接-运行周期通常更快、更简单(并且避免了可能是几个minutes).

• You的‘/

1. ’步骤)，具有更多的选项来可视化进度(一些嵌入式应用程序具有有限的I/O外围设备)，存储输入/输出数据以供分析，运行更耗时的测试。
2. 您可以使用现成的基于PC的单元测试框架，这些框架不适用于嵌入式平台。

Answer 3

嵌入式系统是一个广泛的话题，但总的来说，让我们把它看作是一种结合了硬件和软件的专用产品。我的嵌入式背景来自移动电话，它只是所有嵌入式系统中的一小部分。我将尽量把以下几点放在抽象的方面：

• 尽可能抽象出硬件依赖关系。通过这种方式，您可以在模拟的“硬件”上运行单元测试，还可以测试在目标上难以测试的各种罕见/异常情况。为了避免抽象成本，你可以根据硬件尽可能少地使用条件compilation.
• Have。在仿真器或交叉编译器环境上运行的
• 单元测试仍然不能保证代码在目标硬件上工作。您还必须在目标上进行测试。尽早在目标上进行测试。