对嵌入式系统的任何小改动都可能产生最恶毒的影响。 此外，如果您发现并修复问题的时间太晚，修复成本会非常高。 因此，应该可以在几分钟内测试嵌入式系统的每个更改。 这是确保您可以快速检测并修复问题的唯一方法。

对于纯软件项目，通过持续集成 (CI) 实现测试的完全自动化会有所帮助。在这里，每次代码更改都会自动触发完整软件的构建和测试。这允许完整的回归测试在几分钟内检测现有代码和新代码中的错误。 这也适用于嵌入式系统吗？

用于测试自动化的持续集成

首先，让我们看看持续集成是如何工作的。

1. 每个开发人员通过提交中央源代码管理系统（例如 GIT）来更新他的软件更改。

2. 每次提交都会通知持续集成服务器应用程序（CI 服务器）。

3. CI 服务器检查刚刚所做的更改并完全重建软件项目，包括测试。

4. 现在所有测试都自动为新的软件版本执行。

A. 如果测试失败，只有最后一次更改的开发人员会收到通知——例如，通过电子邮件。

B.如果所有测试运行没有问题，则不会通知任何人。 但测试结果将被记录。

5.在许多情况下，构建了带有文档和发行说明的完整版本。 这始终确保项目随时准备好自动交付。

用于测试自动化的持续集成

嵌入式系统有什么不同？

持续集成的目标应该是在每次软件更改后尽快运行测试。对于通常是纯软件测试的单元测试，这很容易。但是对于嵌入式系统的系统或集成测试如何实现呢？

为此所需的硬件在环测试（HIL 测试）或手动系统测试通常难以自动化。

测试设置中的真实硬件部分阻碍了自动化和可重复性。

通常只能测试“快乐路径”，而不能测试失败行为。

测试台通常过于昂贵，无法在每个项目的每个时间都实现自动化。

油泵测试的实际案例

让我们看一个真实项目的例子。这是对安全相关油泵的系统测试。 测试设置的目标：测试所有相关系统状态的温度关闭。

之前的设置：整个系统在一个大型气候室中运行。

缺点：

由于人工气候室的惯性，一个完整的测试序列大约需要 30 天。 这使得该测试对于早期项目阶段的软件测试几乎毫无价值。

由于系统设计复杂，测试只能部分自动化。

只能测试温度误差。 对于其他故障情况，必须手动操作电机、泵或液压系统。

昂贵的资源气候室通常无法用于其他重要且频繁的系统测试。

硬件在环测试

新设置：我们只测试微控制器、驱动程序和应用软件，并模拟完整的环境。该测试通过微控制器引脚上的信号作为黑盒测试完成。

优点：

您测试最常更改的内容：软件

不仅可以测试温度关机，还可以测试所有其他潜在的错误情况。

除了好的案例之外，所有的坏案例都可以通过模拟和错误注入来测试。

测试执行可以完全自动化。

对每个代码更改执行完整的回归测试。

执行仅需 50 分钟而不是 30 天。

硬件设置明显更便宜且更小。

硬件测试设置

而不是完整的系统，只有带有完整未更改软件的微控制器被测试。

被测系统的引脚和所需信号连接到测试系统。 在测试系统上运行环境模拟和自动化测试用例。

硬件测试设置

由于完整的环境模拟，SUT 可以设置为任何需要的状态，因此测试可以完全自动化。 如果您有多个项目，或者多个开发人员在一个项目上工作，建议将 SUT 安装在 19 英寸机柜中。 该示例显示了齐腰高的橱柜中的 8 个不同项目。 它们通过 USB 集线器连接到 CI 服务器。

环境模拟

软件开发环境

为了能够尽可能高效地创建环境模拟和测试用例，我们使用了模型驱动的方法。 测试系统的软件结构和环境模拟是使用ROOM语言和开源工具eTrice开发的。 测试用例也是用语言开发的模型驱动的CeGe（案例生成器）。 C 代码从模型中生成、编译并传输到测试系统。 测试执行期间记录的结果被转换为各种图表和标准格式。 这使开发人员、项目经理和审阅者更容易解释结果、学习并开始开发过程中的下一次迭代。

软件开发环境

总结

通过使用完整的软件将硬件在环测试减少到微控制器，可以实现测试设置的完全自动化。 由于持续集成的使用，测试执行的响应时间在几分钟内，而不是几天、几周甚至几个月。 因此，开发人员可以非常快速地消除发生的错误，并且不依赖于其他更改。 这是快速、迭代项目开发的重要先决条件。