在嵌入式环境中或在自动化测试的可能性非常有限的其他情况下运行回归测试有哪些好的实践和策略。
根据我的经验，许多测试必须手动执行，即测试人员需要按下一系列按钮并验证机器是否正常运行。作为开发人员，很难保证您的更改不会破坏其他内容。
如果没有适当的回归测试，在大型重构等过程中情况会变得更糟。
有没有人认识到这个问题？您是否找到了处理此类问题的良好解决方案或流程？
问问题
6761 次
9 回答
11
就个人而言，我非常喜欢在目标硬件和我自己的计算机上编译我的嵌入式代码。例如，在针对 8086 时，我同时包含了一个映射到 8086 硬件上的重置的入口点和一个 DOS 入口点。硬件的设计使所有 IO 都是内存映射的。然后我有条件地在硬件模拟器中编译，并有条件地将硬件内存位置更改为模拟的硬件内存。
如果我要在非 x86 平台上工作，我可能会编写一个模拟器。
另一种方法是创建一个测试台，其中硬件的所有输入和输出都通过软件控制。我们在工厂测试中经常使用它。
有一次我们在 IO 硬件中构建了一个模拟器。这样，系统的其余部分就可以通过通过 CAN 发送一些命令将硬件置于模拟模式来进行测试。类似地，精心设计的软件可以具有“模拟模式”，其中 IO 被模拟以响应软件命令。
于 2009-04-09T11:26:37.643 回答
4
对于嵌入式测试，我建议您在开发过程的早期就设计出解决方法。将您的嵌入式代码沙箱化以在 PC 平台上运行有很大帮助，然后再进行模拟 :)
这将确保大部分内容的完整性，但您稍后仍需要手动进行系统和验收测试。
于 2009-04-09T11:24:52.390 回答
2
有没有人认识到这个问题？
明确地。
您是否找到了处理此类问题的良好解决方案或流程？
技术组合：
- 自动化测试；
- 蛮力测试，即没有自动化测试那么智能，但是在很长一段时间（数小时或数天）内重复测试一个特性，并且可以在没有人为干预的情况下运行；
- 手动测试（通常难以避免）；
- 在 PC 上的软件模拟器上进行测试（或者作为最后的手段，硬件模拟器）。
关于在 PC 编译器上编译：这对于高级模块和具有适合测试工具的低级模块肯定是有意义的。
例如，当涉及到必须处理来自多个源的实时信号的部分代码时，仿真是一个很好的起点，但我认为这还不够。在尽可能真实的环境中，在实际硬件上测试代码通常是无可替代的。
于 2009-04-09T16:39:16.073 回答
2
与迄今为止的大多数响应者不同，我使用的嵌入式环境根本不像桌面系统，因此无法在桌面上模拟嵌入式系统。
为了编写好的测试系统，你需要你的测试系统有前馈和反馈。JTAG 是控制器件的最常见的前馈方式。您可以设置设备的完整状态（如果幸运的话，甚至可以设置整个电路板），然后将测试代码设置为运行。在这一点上你得到你的反馈。JTAG 也可以用作反馈设备。然而，在这种情况下，带有软件 API 的逻辑分析仪是最好的。您可以在引脚上查找特定电平、计数脉冲，甚至解析来自流外设的数据流。
于 2009-04-13T02:36:32.837 回答
1
除了迄今为止关于确保您的应用程序可以在普通 PC 上构建和至少部分测试的建议（这对于使用 Valgrind 等工具也很有用），我会考虑您的软件设计。
我参与的一个项目有一个用于驱动硬件的组件，一个用于处理管理任务，另一个用于网络管理。网络管理由 SNMP 处理，因此很容易编写远程运行的脚本来驱动硬件做某事。
为了运行低级硬件测试，我编写了一个简单的脚本阅读器，它解析测试脚本并将命令注入我的驱动程序的 IPC。由于输出是基于视频的，因此除了肉眼之外很难自动验证处理，但它确实为我节省了 RSI。它在生成脚本以进行压力测试或模拟已知故障条件以确保错误不会再次发生时也非常有用。
如果我在哪里重新做一遍，我可能会实现一个共享库，供测试工具和发送核心消息的真实代码使用。然后我会用python（或类似的东西）包装lib，这样我的测试可能会稍微“可编写脚本”。
于 2009-04-10T04:03:31.373 回答
1
我同意每个人都说自动化硬件是必须的——我们正在使用这种方法来测试我们的一些单元的嵌入式软件。我们已经建立了充满硬件模拟器的大型两机架测试站，我们使用 NI TestStand 和 Labview VI、C# 代码、供应商 DLL 等来管理所有这些。我们必须测试很多硬件——这就是为什么我们有那么多废话。如果您只是在测试软件，那么您可以将其缩小到最基本的要求。测试串行接口？只需构建一个设备来模拟串行流量并运行所有消息（以及一些无效消息）以确保软件正确响应。测试 DIO？这很容易——有很多 USB 外围设备或嵌入式设备可以模拟 DIO。如果时机很重要，你'
重要的部分是始终知道你在测试什么，而不是测试除此之外的任何东西。如果是软件，请确保测试尽可能独立于硬件。如果您正在测试波形生成或使用 D/A 的东西，请将任务分开 - 在嵌入式设备上使用特殊构建的软件测试 D/A 硬件，除了吐出预先安排的序列电压水平。然后您可以查看您的参考是否关闭，您的滤波器是否设置为错误的频率等。然后您应该能够独立于硬件测试软件 - 使用开发板测试软件并验证处理器的行为针脚是正确的。
于 2009-04-11T14:38:26.220 回答
1
我工作的一个解决方案是自动化的夜间构建和测试程序。
- 从源代码管理中查看主干头代码。
- 构建项目并加载到目标上。
- 运行 PC 控制的自动化测试脚本。
如果您使用某种通信协议，测试脚本很容易运行。这对内部单元测试有好处。使情况更有趣（和彻底）的是制作插入电路板以模拟外部 IO 的线束。
仿真有利于开发和基本的初始测试，但真实的物理运行时间是系统验证的唯一可靠方法。物理操作可以找出非代码问题（由编码方法引起），例如电压骤降、噪声、毛刺、去抖动问题、竞争条件等。
长时间的系统测试也很重要。设置一个自动化测试以连续数天/数周连续滥用系统是一种很好的方法来排除可能直到几个月后在该领域才会出现的问题。告诉客户只要事情开始变得有趣就循环供电并不是所有行业都可以接受的奢侈品。
于 2009-04-13T15:49:08.857 回答
1
为单个子系统和整个项目提供模拟目标环境的测试工具/沙箱/模型。
这并没有消除在真实环境中进行测试的需要，但会大大减少它们的数量，因为模拟会捕捉到大多数问题，所以当它们都通过并且您执行昂贵的人工驱动测试时，您有理由相信您会首先通过该测试时间。
于 2009-04-09T11:26:08.863 回答
0
In my experience, automated hardware testing has been critical. -- Investing in dual compilation in both PC & target is a "nice to have" feature but given the choice, I'd much rather invest in automated hardware testing. It'll be a more cost-effective solution in the end since the manufacturing arms will want/need the capability anyways for failure analysis.
于 2009-04-10T19:15:42.210 回答