在嵌入式环境或自动化测试的可能性非常有限的其他情况下运行回归测试有哪些好的做法和策略。
根据我的经验，许多测试必须手动执行，即测试人员需要按下一系列按钮并验证机器是否正常运行。作为开发人员，很难保证您的更改不会破坏其他内容。
如果没有适当的回归测试，在大型重构等过程中情况会变得更糟。
有人知道这个问题吗？有没有找到好的解决方案或流程来处理这类问题？
【问题讨论】：
标签： testing embedded regression-testing automated-tests
就个人而言，我非常喜欢在目标硬件和我自己的计算机上编译我的嵌入式代码。例如，在针对 8086 时，我同时包含了一个映射到 8086 硬件上的重置的入口点和一个 DOS 入口点。硬件的设计使所有 IO 都是内存映射的。然后我有条件地在硬件模拟器中编译，并有条件地将硬件内存位置更改为模拟的硬件内存。
如果我要在非 x86 平台上工作，我可能会编写一个模拟器。
另一种方法是创建一个测试台，其中硬件的所有输入和输出都通过软件控制。我们在工厂测试中经常使用它。
有一次我们在 IO 硬件中构建了一个模拟器。这样，系统的其余部分就可以通过通过 CAN 发送一些命令将硬件置于模拟模式来进行测试。同样，精心设计的软件可能具有“模拟模式”，其中 IO 被模拟以响应软件命令。
【讨论】：
对于嵌入式测试，我建议您在开发过程的早期就设计出解决方法。将您的嵌入式代码沙箱化以在 PC 平台上运行有很大帮助，然后再进行模拟 :)
这将确保大部分内容的完整性，但您稍后仍需要手动进行系统和验收测试。
【讨论】：
有人知道这个问题吗？
绝对是。
您是否找到了好的解决方案或 处理这种情况的过程 有问题吗？
技术组合：
关于在 PC 编译器上进行编译：这对于高级模块以及具有适合测试工具的低级模块肯定是有意义的。
例如，当涉及到必须处理来自多个来源的实时信号的部分代码时，仿真是一个很好的起点，但我认为这还不够。在尽可能真实的环境中，在实际硬件上测试代码通常是无可替代的。
【讨论】：
与迄今为止的大多数响应者不同，我使用的嵌入式环境根本不像桌面系统，因此无法在桌面上模拟嵌入式系统。
为了编写好的测试系统，您的测试系统需要前馈和反馈。 JTAG 是控制器件的最常见的前馈方式。您可以设置设备的完整状态（如果幸运的话，甚至可以设置整个电路板），然后将测试代码设置为运行。在这一点上你得到你的反馈。 JTAG 也可以用作反馈设备。然而，在这种情况下，带有软件 API 的逻辑分析仪是最好的。您可以在引脚上查找特定电平、计数脉冲，甚至解析来自流外设的数据流。
【讨论】：
为单个子系统和整个项目提供模拟目标环境的测试工具/沙盒/模型。
这并没有消除在真实环境中进行测试的需要，但会大大减少它们的数量，因为模拟会发现大多数问题，所以当它们全部通过并且您执行昂贵的人工驱动测试时，您有理由相信自己会第一次通过。
【讨论】：
除了迄今为止关于确保您的应用可以构建的建议之外 并至少在普通 PC 上进行部分测试（这也适用于 使用 Valgrind 等工具）我会考虑您的软件设计。
我参与的一个项目有一个用于驱动硬件的组件，一个 用于处理管理任务和另一个网络管理。 网络管理由SNMP处理，因此易于编写 远程运行以驱动硬件执行某些操作的脚本。
为了运行底层硬件测试，我编写了一个简单的脚本阅读器 解析测试脚本并将命令注入我的 IPC 司机。由于输出是基于视频的，因此很难自动化 除了肉眼之外的处理验证，但它确实保存了 我RSI。它在生成压力脚本时也非常有用 测试或模拟已知的故障情况，以确保没有错误 再次发生。
如果我从头再来，我可能会实现一个共享 测试工具使用的库和发送核心的真实代码 消息。然后我会用python（或其他东西）包装lib 类似），所以我的测试可能会更“可编写脚本”。
【讨论】：
我同意每个人所说的自动化硬件是必须的 - 我们正在使用这种方法来测试我们的一些单元的嵌入式软件。我们已经建立了充满硬件模拟器的大型两机架测试站，我们使用 NI TestStand 和 Labview VI、C# 代码、供应商 DLL 等来管理所有这些。我们必须测试很多硬件——这就是为什么我们有那么多废话。如果您只是在测试软件，那么您可以将其缩小到最基本的要求。测试串行接口？只需构建一个设备来模拟串行流量并运行所有消息（以及一些无效消息）以确保软件正确响应。测试 DIO？这很容易——有很多 USB 外围设备或嵌入式设备可以模拟 DIO。如果时间很重要，您将不得不使用另一个嵌入式设备来获得您正在寻找的严格公差，否则 PC 就可以了。
重要的是要始终了解您要测试的内容，而不是测试除此之外的任何内容。如果是软件，请确保测试尽可能独立于硬件。如果您正在测试波形生成或使用 D/A 的东西，请将任务分开 - 在嵌入式设备上使用特殊构建的软件测试 D/A 硬件，除了吐出预先安排的序列电压电平。然后您可以查看您的参考是否关闭，您的滤波器是否设置为错误的频率等。然后您应该能够独立于硬件测试软件 - 使用开发板测试软件并验证处理器的行为针脚是正确的。
【讨论】：
我工作的一个解决方案是自动化的夜间构建和测试程序。
如果您使用某种通信协议，测试脚本很容易运行。这对内部单元测试有好处。使情况更有趣（和彻底）的是制作一个插入电路板以模拟外部 IO 的线束。
仿真有利于开发和基本的初始测试，但真实的物理运行时间是系统验证的唯一可靠方法。物理操作可以找出非代码问题（由编码方法引起），例如电压骤降、噪声、毛刺、去抖问题、竞争条件等。
长时间的系统测试也很重要。设置自动化测试以连续数天/数周连续滥用系统是一种很好的方法，可以排除可能直到几个月后才出现的问题。告诉客户只要事情开始变得有趣就循环供电并不是所有行业都可以接受的奢侈品。
【讨论】：
根据我的经验，自动化硬件测试至关重要。 -- 在 PC 和目标机上投资双重编译是一个“不错的”功能，但如果可以选择，我更愿意投资于自动化硬件测试。最终，这将是一个更具成本效益的解决方案，因为制造部门无论如何都需要/需要这种能力来进行故障分析。
【讨论】：