嵌入式硬件测试自动化

有没有人成功地直接在嵌入式硬件上进行测试？

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

这甚至值得努力吗？

我们通常针对:

处理器:8位或16位微控制器(某些DSP的东西)
语言:C(有时是c ++).

当然.在汽车行业,我们为每种新产品使用100,000美元的定制测试仪,以验证硬件和软件是否正常运行.

然而,开发人员还构建了一个更便宜(低于1,000美元)的测试仪,其中包括一堆USB I/O,A/D,PWM输入/输出等,并使用工作站上的脚本或专用的HIL/SIL测试软件比如MxVDev.

硬件在环(HIL)测试可能就是您的意思,它只是涉及一些USB硬件I/O连接到您设备的I/O,计算机上的软件正在运行测试.

是否值得它取决于.

在高可靠性行业(飞机,汽车等)中,客户指定了非常广泛的硬件测试,因此您必须获得它才能获得出价.

在消费行业,对于非复杂的项目,通常不值得.

但是,对于涉及多个程序员的任何项目,在硬件上运行夜间回归测试真的很不错 - 很难正确地模拟硬件,以达到满足自己软件测试就足够的程度.

然后,测试会在问题进入构建时立即显示.

通常,您执行黑盒和白盒测试 - 您在设备上运行诊断代码,允许您监视硬件中的信号和内存(可能只是一个调试器,或者可能是您编写的对消息作出反应的代码)例如一辆公共汽车).这将是白盒测试,您可以在其中查看内部发生的情况(甚至导致某些事情发生,例如关键内存错误,如果不自行引入错误则无法测试).

我们还运行了一系列"黑盒子"测试,其中忽略了诊断路径,只激励/读取了I/O.

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

它对于产品维护特别有用 - 项目完成后,在CD上存储一些工作板,测试仪和一套完整的软件.当您需要进行修改或调试问题时,可以很容易地将其全部备份并使用一些知识(经过测试)处理它,主要功能不受您的更改的影响.

-亚当

是.我取得了成功,但这并不是一个需要解决的问题.简而言之,这是我的团队所做的:

使用自制的C单元测试框架定义了各种单元测试.基本上,只是很多宏,其中大部分被命名的TEST_EQUAL,TEST_BITSET,TEST_BITVLR,等.

编写了一个启动代码生成器,它使用这些编译的测试并将它们编排到执行环境中.它只是一个执行我们正常启动例程的小驱动程序 - 但它不是进入控制循环,而是执行测试套件.完成后,它会存储最后一个在闪存中运行的套件,然后重置CPU.然后它将运行下一个套件.这是为了在套件死亡时提供隔离.(但是,您可能希望禁用此功能以确保模块配合.但这是集成测试,而不是单元测试.)

单个测试将使用串行端口记录其输出.这对我们的设计来说没问题,因为串口是免费的.如果消耗了所有IO,则必须找到存储结果的方法.

有效!这很棒.使用我们的自定义数据记录器,您可以点击"测试"按钮,几分钟后,您将获得所有结果.我强烈推荐它.

更新以阐明测试驱动程序的工作原理.

是.

难度取决于您尝试测试的硬件类型.正如其他人之前所说的,问题将是您需要应用的外部刺激的复杂性.外部刺激可能最好通过一些外部测试装备实现(如Adam Davis所述).

但是,要考虑的一件事就是你要验证的确切内容.

很有可能假设要验证硬件和固件的相互作用,那么你真的别无选择,只能直接应用外部激励(即将DAC应用于所有ADC输入等).但是,在这些情况下,您真正​​想要测试的极端情况通常会受到时序问题的影响(例如,当您执行函数foo()时到达的中断)将会非常难以测试一种有意义的方式 - 甚至更难从中获得有意义的结果.(即.我们运行此测试的前100K次没问题.我们最后一次运行它失败了.为什么？!？)

但是硬件的验证应该单独进行.一旦完成,除非它定期更改(通过可下载的fpga图像等),否则您应该能够假设硬件正常工作并纯粹测试您的固件.

因此,在这种情况下,您可以专注于验证用于处理外部刺激的算法.例如,使用固定值调用ADC转换例程,就好像它们直接来自ADC一样.这些测试是可重复的,因此是有益的.但它们需要特殊的测试版本.

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

我们的嵌入式系统自动化测试取得了良好的效果.我们使用在专用测试机器上运行的高级(易于编程和调试)语言编写测试.这些测试通常会进行健全性检查或生成随机输入到设备中,然后检查是否有正确的行为.生成和维护这些测试有很多工作要做.我们设计了一个框架,然后让实习生自己处理测试.

这不是一个完美的解决方案,测试肯定容易出错,但最重要的部分是改善现有的覆盖漏洞.找到最大的洞并设计一些以自动化方式覆盖的洞,即使它不完美或不能覆盖整个功能.稍后当你所有的东西都被覆盖时,你可以回来解决最差的覆盖范围或最关键的功能.

有些事情需要考虑:

固件错误的代价是什么？在现场更新固件有多容易.

我的测试提供什么样的保险？这是一个简单的健全检查吗？它是否足够可配置,可以测试许多不同的场景？

一旦测试失败,您将如何重现该值以进行调试？您是否记录了所有设备和测试设置,以便尽可能多地消除变量？设备配置,固件版本,测试软件版本,所有外部输入,所有观察到的行为？

你在测试什么？规范是否足够清楚您正在测试的设备的预期行为,或者您是否根据您认为的代码应该进行验证？