单元测试嵌入式软件 [英] Unit Testing Embedded Software

问题描述

解决方案

嵌入式软件可能有在过去十年中，我们通常做了以下工作：

• 不依赖于目标硬件的算法，我们只是在非嵌入式平台上构建和测试单元测试。


• 对于需要硬件的内容，单元测试有条件地编译成代码以使用任何可用的硬件。在我们的例子中，这是目标上的一个串行端口，将结果推送到另一个更有能力的机器上，检查测试是否正确。


• 根据硬件，你有时可能会在非嵌入式平台上创建虚拟设备。这通常包括改变程序所使用的存储器的另一个执行线程（或信号功能）。对于内存映射的I / O而不是IRQ等等，有用。


• 通常，您一次只能对整个代码的一小部分进行单元测试（由于内存限制） li>
  
• 用于测试时间敏感的东西，我们没有。干净利落。我们使用的硬件（8051和68302）如果运行得太慢，并不总是有效。这种调试必须首先使用CRO（示波器）和（当我们有更多的钱）一个ICE（在线仿真器）时。

希望自从我上次做以来情况有所改善。我不希望我最大的敌人痛苦。

What best practices have you used in unit testing embedded software that are peculiar to embedded systems?

解决方案

Embedded software may have come a long way in the last 10 years but we generally did the following:

• for algorithms that didn't depend on the target hardware, we simply had unit tests that were built and tested on a non-embedded platform.
• for stuff that did require the hardware, unit tests were conditionally compiled into the code to use whatever hardware was available. In our case, it was a serial port on the target pushing the results to another, more capable, machine where the tests were checked for correctness.
• Depending on the hardware, you could sometimes dummy up a "virtual" device on a non-embedded platform. This usually consisted of having another thread of execution (or signal function) changing memory used by the program. Useful for memory mapped I/O but not IRQs and such.
• typically, you could only unit test a small subset of the complete code at a time (due to memory constraints).
• for testing of time-sensitive things, we didn't. Plain and simple. The hardware we used (8051 and 68302) was not always functional if it ran too slow. That sort of debugging had to be done initially with a CRO (oscilloscope) and (when we had some more money) an ICE (in-circuit emulator).

Hopefully the situation has improved since I last did it. I wouldn't wish that pain on my worst enemy.

这篇关于单元测试嵌入式软件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！