有没有人能够直接在嵌入式硬件上自动化测试？
具体来说，我正在考虑为硬件层模块自动化一系列单元测试。我们需要对硬件层代码更有信心。我们的很多项目都使用中断驱动的定时器，ADC，串行io，串行SPI器件（闪存）等。
这是值得的吗？
我们通常定位：
处理器：8位或16位微控制器（某些DSP产品）
语言：C（有时是c ++）。
答案 0 :(得分：19)
不确定。在汽车行业，我们为每种新产品使用100,000美元的定制测试仪，以验证硬件和软件是否正常运行。
然而，开发人员还构建了一个更便宜（低于1,000美元）的测试仪，其中包括一堆USB I / O，A / D，PWM输入/输出等，并且要么在工作站上使用脚本，要么使用专用的HIL / SIL测试软件，如MxVDev。硬件在环（HIL）测试可能就是您的意思，它只是涉及一些USB硬件I / O连接到您设备的I / O，计算机上的软件正在运行测试。
是否值得，取决于。
在高可靠性行业（飞机，汽车等）中，客户指定了非常广泛的硬件测试，因此您只需获得出价即可。
在消费行业，对于非复杂的项目，通常不值得。
但是，对于涉及多个程序员的任何项目，在硬件上运行夜间回归测试是非常好的 - 很难正确地模拟硬件到所需的程度确保软件测试足够了。
然后，测试会在问题进入构建时立即显示。
通常你执行黑盒子和白盒子测试 - 你在设备上运行的诊断代码允许你监视硬件中的信号和内存（可能只是一个调试器，或者你写的代码可能是例如，总线上的消息。这将是白盒测试，您可以在其中查看内部发生的情况（甚至导致某些事情发生，例如关键内存错误，如果不自行引入错误则无法测试）。
我们还运行了一系列“黑盒子”测试，其中忽略了诊断路径，只激发/读取了I / O.
对于更便宜的设置，您可以获得100美元的带有USB和/或以太网的微控制器板（例如Atmel UC3系列），您可以将其连接到您的设备并运行基本测试。
它对产品维护特别有用 - 项目完成后，在CD上存储一些工作板，测试仪和一整套软件。当您需要进行修改或调试问题时，可以很容易地将其全部备份并使用一些知识（经过测试）处理它，主要功能不受您的更改的影响。
- 亚当
答案 1 :(得分：14)
是。我取得了成功，但这并不是一个需要解决的问题。简而言之，我的团队就是这样做的：
使用自制的C单元测试框架定义了各种单元测试。基本上，只有很多宏，其中大多数被命名为TEST_EQUAL，TEST_BITSET，TEST_BITVLR等。
编写了一个启动代码生成器，它接受了这些编译过的测试并将它们编排到执行环境中。它只是一个执行我们正常启动例程的小驱动程序 - 但它不是进入控制循环，而是执行测试套件。完成后，它会存储最后一个在闪存中运行的套件，然后重置CPU。然后它将运行下一个套件。这是为了在套件死亡时提供隔离。 （但是，你可能想要禁用它以确保你的模块合作。但这是一个集成测试，而不是单元测试。）
单个测试将使用串行端口记录其输出。这对我们的设计来说没问题，因为串口是免费的。如果消耗了所有IO，则必须找到存储结果的方法。
有效！这很棒。使用我们的自定义数据记录器，您可以点击“测试”按钮，几分钟后，您将获得所有结果。我强烈推荐它。
更新以阐明测试驱动程序的工作原理。
答案 2 :(得分：6)
是
难度取决于您尝试测试的硬件类型。正如其他人之前所说的，问题将是您需要应用的外部刺激的复杂性。外部刺激可能最好通过一些外部测试装备实现（正如Adam Davis所描述的那样）。
但要考虑的一件事是完全您正在尝试验证的内容。
很有可能假设要验证硬件和固件的相互作用，那么你真的别无选择，只能直接应用外部激励（即将DAC应用于所有ADC输入等）。但是，在这些情况下，您真正想要测试的极端情况通常会受到时序问题的影响（例如，当您执行函数foo（）时到达的中断）将会非常难以测试一种有意义的方式 - 甚至更难从中获得有意义的结果。 （也就是说。我们运行这个测试的前100K次很好。我们最后一次运行它失败了。为什么？！？）
但是硬件的验证应该单独完成。一旦完成，除非它经常更改（通过可下载的fpga图像等），否则你应该能够假设硬件工作并纯粹测试你的固件。
因此，在这种情况下，您可以专注于验证用于处理外部刺激的算法。例如，使用固定值调用ADC转换例程，就好像它们直接来自ADC一样。这些测试是可重复的，因此是有益的。他们需要特殊的测试版本。
测试设备的通信路径将相对简单，不需要特殊的代码构建。
答案 3 :(得分：5)
我们的嵌入式系统自动化测试取得了良好的效果。我们使用在专用测试机器上运行的高级（易于编程和调试）语言编写测试。这些测试通常会进行健全性检查或生成随机输入到设备中，然后检查是否有正确的行为。生成和维护这些测试有很多工作要做。我们设计了一个框架，然后让实习生自己处理测试。
这不是一个完美的解决方案，测试肯定容易出错，但最重要的部分是改善现有的覆盖漏洞。找到最大的洞并设计一些以自动化的方式覆盖它，即使它不完美或不能覆盖整个功能。稍后当你所有的东西都被覆盖时，你可以回来解决最糟糕的覆盖范围或最关键的功能。
需要考虑的一些事项：
答案 4 :(得分：3)
如果你的目标是测试你的低级驱动程序代码，你可能需要使用环回电缆或多个互连单元来创建某种测试夹具，以便让你锻炼每个驱动程序。将具有已知良好软件的电路板与运行开发构建的电路板配对将允许您测试通信协议中的回归等。
具体的测试策略取决于您要测试的硬件。例如，可以通过呈现已知波形并转换一系列样本，然后检查适当的范围，频率，平均值等来测试ADC。
我发现这种类型的测试在过去非常有价值，让我可以自信地修改和改进驱动程序代码，而不用担心破坏现有的应用程序。
答案 5 :(得分：2)
是的，我这样做，虽然我总是有一个可用于测试I / O的串口。
通常很难让完全未经修改。某些测试需要注释掉一行或添加一个电话，例如处理看门狗。
恕我直言，这比没有单元测试好。当然，您也需要进行完整的集成/系统测试。答案 6 :(得分：1)
单元测试嵌入式项目非常困难，因为它通常需要外部刺激和外部测量。
我们已经成功开发了一个外部串行协议（rs232或udp或tcpip消息），其中包含基本命令，用于在低级别驱动程序中调试日志，以查找错误条件甚至是轻微异常情况（特别是限制条件）检查）
但是一旦开发出来，我们就可以在每次构建后运行测试。它绝对会让您提供更优质的产品。
答案 7 :(得分：1)
我知道现在已经老了，但也许会有所帮助。是的，你可以做到，但这取决于你想要投资多少你想要的解决方案。两年多来，我一直在为AUTOSAR的MCAL层进行测试和验证。这是软件测试中最低的一种。这是一种组件级别的测试。有些人可能将其称为单位级别，但略高于此级别，因为我们正在测试MCAL组件的API。例如：ADC，SPI，ICU，DIO等。
使用的解决方案包括： - 在目标微型上运行的测试框架 - dSPACE盒，用于在需要时向目标提供信号和从目标读取信号 - 通过Vector CANape访问XCP以触发测试执行和结果收集 - 用于执行测试控制和结果验证的python框架
测试用例用C语言编写，然后将它们与被测软件一起闪存在目标上。这是一个黑盒子测试，因为我们没有以任何方式改变MCAL的实施。而且我认为即使启动序列也没有被触及。空闲任务用于连续检查作为开始执行测试的信号的标志的状态。使用10毫秒的任务来实际运行测试。测试用例实际上是一个切换案例。此开关中的每个案例都是一个测试步骤。 Python在测试步骤级别触发测试执行。这种方法的一个好处是重用不同参数的步骤。这个测试控件，执行什么以及如何执行，是由Python通过在测试实现与测试触发和评估机制之间充当API的测试控制数据结构完成的。这就是CANape的用途。设置要执行的测试并读取测试结果。通过测试步骤获得的每个值都存储在数据结构的数组部分中。测试步骤本身并不涉及任何验证，因为目标被认为是测试环境中不可信任的组件。验证是由Python根据测试规范完成的。 Python正在解析这些规范，并能够自动创建测试触发脚本，包括每个测试步骤的验证标准。每个测试用例的规范是一系列测试步骤描述及其验证标准。其中一些步骤是与dSPACE相关的步骤。举个例子，一步是初始化某些东西，并且要求在已经配置的通道上捕获一些边缘，下一步是通过命令dSPACE设备在该通道上应用信号。
更便宜的解决方案是使用内部板而不是dSPACE设备。在某种程度上，甚至可以使用可编程信号发生器，但如果您需要验证目标输出的信号，这将无济于事。
答案 8 :(得分：0)
如果你的目标是制造测试（确保模块正确组装，没有无意的短路/打开/等），你应该首先关注测试电缆和连接器，然后是插座和焊接连接，然后是PCB本身。这些物品都可以进行短裤和短裤测试。通过查找驱动每个单独行高而其邻居低的访问模式打开，反之亦然，然后读回行的值。
如果不了解硬件的更多细节，则很难更具体，但大多数嵌入式处理器都可以将I / O引脚设置为GPIO模式，从而简化此类测试。
如果您没有在PCA上进行钉床测试，则应将此测试视为新制造的电路板的必备第一步。