如何在嵌入式系统中执行回归测试

Question

在嵌入式环境中或在自动化测试的可能性非常有限的其他情况下运行回归测试有哪些良好实践和策略。

根据我的经验，许多测试必须手动执行，即测试人员需要按下一系列按钮并验证机器是否正常运行。作为开发人员，很难确保您的更改不会破坏其他内容。

如果没有适当的回归测试，在大型重构等过程中情况会变得更糟。

有人认出这个问题吗？您是否找到了解决此类问题的良好解决方案或流程？

Answer 1

就个人而言，我非常喜欢在目标硬件和我自己的计算机上编译嵌入式代码。例如，当定位8086时，我包括一个映射到8086硬件上的重置的入口点和一个DOS入口点。设计硬件使所有IO都进行内存映射。然后我在硬件模拟器中有条件地编译并有条件地将硬件存储器位置更改为模拟硬件存储器。

如果我要在非x86平台上工作，我可能会写一个模拟器。

另一种方法是创建一个测试装备，其中硬件的所有输入和输出都通过软件控制。我们在工厂测试中经常使用它。

有一次我们在IO硬件中构建了一个模拟器。这样，系统的其余部分可以通过在CAN上发送一些命令来测试，以使硬件进入模拟模式。类似地，良好分解的软件可以具有“模拟模式”，其中模拟IO以响应软件命令。

Answer 2

对于嵌入式测试，我建议您在开发过程的早期设计出自己的方法。将您的嵌入式代码沙盒化以在PC平台上运行有很大帮助，然后进行模拟:)

这将确保大部分内容的完整性，但您仍需要稍后手动进行系统和验收测试。

Answer 3

  

有人认出这个问题吗？

绝对是最好的。

  

你找到了一个好的解决方案吗？   处理这种问题的过程   问题

技术组合：

• 自动化测试;
• 强力测试，即那些不像自动测试那样聪明，但可以长时间（数小时或数天）反复测试功能的测试，可以在没有人为干预的情况下运行;
• 手动测试（通常很难避免）;
• 在PC上（或作为最后的手段，硬件模拟器）在软件模拟器上进行测试。

关于在PC编译器上进行编译：对于高级模块和具有测试合适线束的低级模块来说，这肯定是有意义的。

例如，当涉及到必须处理来自多个来源的实时信号的部分代码时，仿真是一个很好的起点，但我认为这还不够。在尽可能真实的环境中，通常无法替代在实际硬件上测试代码。

Answer 4

与大多数响应者不同，我使用的嵌入式环境根本不像桌面系统，因此无法模拟桌面上的嵌入式系统。

为了编写好的测试系统，您需要测试系统提供前馈和反馈。 JTAG是控制器件的最常见的前馈方式。您可以设置设备的完整状态（如果幸运的话，甚至可以设置整个电路板），然后设置测试代码以运行。此时您会收到反馈。 JTAG也可以作为反馈设备。但是，在这种情况下，带有软件API的逻辑分析仪是最好的。您可以在引脚上查找某些级别，计算脉冲，甚至从流式外设解析数据流。

Answer 5

为各个子系统以及模拟目标环境的整个项目提供测试工具/沙箱/模型。

这并没有消除在真实环境中进行测试的需要，但是大大减少了它们的数量，因为模拟将捕获大多数问题，所以当它们全部通过并执行昂贵的人为驱动测试时，你有理由相信你会第一次通过。

Answer 6

除了目前关于确保您的应用可以构建的建议 并且至少部分地测试普通PC（这也是有用的 使用像Valgrind这样的工具我会考虑你的软件设计。

我参与的一个项目有一个用于驱动硬件的组件，一个 用于处理管理任务和另一个网络管理。 网络管理由SNMP处理，因此很容易编写 远程运行以驱动硬件执行某些操作的脚本。

为了运行低级硬件测试，我编写了一个简单的脚本阅读器 解析测试脚本并将命令注入到我的IPC中 驱动程序。由于输出是基于视频的，因此很难实现自动化 除了用眼睛验证处理，但它肯定得救了 我RSI。它在生成压力的脚本时也非常有用 测试或模拟已知的故障条件，以确保错误没有 重新进行。

如果我重新做一遍，我可能会实现共享 测试工具使用的库和发送核心的真实代码 消息。然后我将在python中包装lib（或者其他东西 类似的）所以我的测试可能会更加“可编写脚本”。

Answer 7

我同意每个人都说自动硬件是必须的 - 我们正在使用这种方法来测试我们的一些单元的嵌入式软件。我们已经建立了大型双机架测试站，里面装满了硬件模拟器，我们使用NI TestStand混合使用Labview VI，C＃代码，供应商DLL等来管理所有这些。我们必须测试很多硬件 - 这就是我们拥有所有这些废话的原因。如果您只是测试软件，那么您可以将其扩展回最基本的功能。测试串行接口？只需构建一个设备来模拟串行流量并运行所有消息（以及一些无效消息）以确保软件正确响应。测试DIO？这很简单 - 有很多USB外设或嵌入式设备可以模拟DIO。如果时间很重要，你将不得不使用另一个嵌入式设备来获得你正在寻找的严格公差，否则PC就可以了。

重要的是要始终知道你在测试什么，而不是测试除此之外的任何东西。如果是软件，请确保测试尽可能独立于硬件。如果您正在测试波形生成或带有D / A的东西，请分离出任务 - 在嵌入式设备上使用特殊版本的软件测试D / A硬件，除了吐出预先安排的序列电压水平。然后，您可以查看您的参考是否已关闭，过滤器是否设置为错误的频率等。然后您应该能够独立于硬件测试软件 - 使用开发板测试软件并验证处理器的行为针是正确的。

Answer 8

我工作的解决方案是自动夜间构建和测试程序。

1. 从源代码管理中查看主干头代码。
2. 构建项目并加载到目标上。
3. 运行PC控制的自动化测试脚本。

如果您使用某种通信协议，测试脚本很容易运行。这对内部单元测试很有用。使情况变得更有趣（和彻底）的原因是制造一个插入电路板的线束，以模拟外部IO。

仿真适用于开发和基本的初始测试，但实际的物理操作时间是系统验证的唯一可靠方法。物理操作可以解决非编码问题（由编码方法引起），如电压骤降，噪声，毛刺，去抖问题，竞争条件等。

长时间的系统测试也很重要。建立一个连续数天/周连续滥用系统的自动化测试是一种很好的方法，可以解决几个月后在现场可能不会出现的问题。当事情开始变得有趣时，告诉客户只是循环供电并不是所有行业都能享受的奢侈品。

Answer 9

根据我的经验，自动硬件测试至关重要。 - 在PC和PC中投资双重编译目标是一个“很好的”功能，但如果有选择，我宁愿投资自动化硬件测试。它最终将成为一种更具成本效益的解决方案，因为制造部门无论如何都需要/需要能力进行故障分析。