基于嵌入式硬件的自动化测试

Question

是否有人成功地直接在嵌入式硬件上自动测试？？？

具体来说，我正在考虑为硬件层模块自动化一组单元测试。我们需要对硬件层代码有更大的信心。我们的许多项目使用中断驱动定时器，ADC，串行io，串行SPI设备(闪存)等。

，这值得付出努力吗？

我们通常的目标是：

处理器:8或16位微控制器(一些DSP )

语言:C(有时是c++)。

Answer 1

好的。在汽车行业，我们为每种新产品使用价值10万美元的定制测试器来验证硬件和软件是否正确运行。

然而，开发人员还构建了一个更便宜(低于1,000美元)的测试器，其中包括一堆USB /O、A/D、PWM输入/输出等，或者在工作站上使用脚本，或者使用像MxVDev这样的目的构建的HIL/SIL测试软件。

硬件在循环(HIL)测试可能是什么意思，它只是涉及一些USB硬件I/O连接到您的设备的I/O，软件在计算机上运行对它的测试。

这是否值得取决于。

在高可靠性工业(飞机，汽车等)，客户指定非常广泛的硬件测试，所以你必须有它只是为了获得投标。

在消费行业，非复杂的项目通常不值得这样做。

但是，对于任何涉及到不止几个程序员的项目，在硬件上运行一个夜间回归测试真的很好--很难正确地模拟硬件以满足自己的需要，即软件测试已经足够了。

然后，测试将在问题进入构建时立即显示。

通常，您同时执行黑匣子和白盒测试--在设备上运行诊断代码，可以监视硬件中的信号和内存(例如，它可能只是调试器，也可能是对总线上的消息作出反应的代码)。这将是白盒测试，在这里您可以看到内部正在发生的事情(甚至导致一些事情发生，例如不引入错误就无法测试的关键内存错误)。

我们还运行了大量的“黑匣子”测试，在这些测试中，诊断路径被忽略，只有I/O被刺激/读取。

对于更便宜的设置，您可以获得100美元的带有USB和/或以太网的微控制器板(如Atmel UC3系列)，您可以连接到设备并运行基本测试。

它对于产品维护特别有用--当项目完成后，在CD上存储几块工作板、测试器和一整套软件。当您需要修改或调试问题时，很容易设置所有备份，并在测试后了解到主要功能不受更改的影响。

-Adam

Answer 2

是。我已经取得了成功，但这不是一个需要解决的问题.简而言之，这就是我的团队所做的：

1. 使用自制的C单元测试框架定义了各种单元测试。基本上，只有很多宏，其中大多数被命名为TEST_EQUAL、TEST_BITSET、TEST_BITVLR等。
2. 编写了一个引导代码生成器，它将这些编译的测试进行编排，并将它们编排到一个执行环境中。它只是一个小驱动程序，执行我们的正常启动例程-但它没有进入控制循环，它执行一个测试套件。完成后，它存储在闪存中运行的最后一个套件，然后重置CPU。然后，它将运行然后下一个套房。这是为了在套房死亡时提供隔离。(但是，您可能希望禁用此功能，以确保模块之间的协作。但是这是一个集成测试，而不是单元test.)
3. Individual测试会使用串口记录它们的输出。这对我们的设计是可以的，因为串口是免费的。如果所有的IO都被消耗了，您就必须找到一种存储结果的方法。

啊，真灵!很高兴有。使用我们的自定义数据表，您可以点击"Test“按钮，几分钟后，您将得到所有的结果。我强烈推荐它。

更新了以澄清测试驱动程序是如何工作的。

Answer 3

是。

困难取决于您试图测试的硬件类型。正如其他人早些时候所说，问题将是你需要实施的外部刺激的复杂性。外部刺激可能最好是通过一些外部试验台来实现(正如亚当·戴维斯所描述的)。

不过，有一件事需要考虑，那就是你想要验证的是什么。

很容易假设要验证硬件和固件之间的交互，那么您真的别无选择，只能直接应用外部刺激(即。将DACs应用于所有ADC输入，等等)。然而，在这些情况下，你真正想要测试的角落案例往往会受到时间问题的影响(例如。当您执行函数foo()时，中断会到达，这将非常难以一种有意义的方式进行测试，甚至更难获得有意义的结果。(即)第一次我们进行了100 K的测试-很好。上次我们运行的时候失败了。为什么？！？)

但是硬件的验证应该分开进行。一旦完成，除非它是定期变化(通过可下载的fpga图像等)，那么您应该能够假设硬件工作，并纯粹测试您的固件。

因此，在这种情况下，您可以集中精力验证用于处理外部stimulii的算法。例如，用固定值调用ADC转换例程，就好像它们直接来自ADC一样。这些测试是可重复的，因此是有益的。不过，它们需要特殊的测试构建。

测试设备的通信路径将是相对简单的，不需要特殊的代码构建。