Embedded System 自动化测试
-
date_range 30/01/2024 infosortEmbedded and Linux
1 概述/前言
作者最近工作关注在Embedded System DevOps上。 对Embedded System的DevOps来说, Automated Testing是比较不同的一个环节。
虽然之前也零零散散接触过不少”操作系统+硬件环境”的自动化测试方案,但是一直没有系统化整理过这些碎片知识, 所以借本文整理一遍。
2 背景概念
2.1 测试分类
下图我从网上找来的一些测试分类资料,可以用来基础的了解下Software Testing Types。
以上不是本文所关注的重点, 我们接下来关注的是Simulation-based testing这一个概念及其分类。
(GPT生成) Simulation-based testing 是指任何使用模拟环境来进行软件或硬件测试的方法。该方法通过创建一个控制的环境来模拟现实世界的运行条件和数据交互,以便于测试、验证和调试系统。在汽车和航天等领域尤其常见。常见的仿真基础测试类型包括:
- MIL (Model in the Loop) Testing:
- 测试中使用数学模型在仿真环境中验证系统设计的正确性。
- SIL (Software in the Loop) Testing:
- 在不包含硬件的情况下,在PC或服务器上模拟运行环境进行的测试。
- HIL (Hardware in the Loop) Testing:
- 测试在实际或仿真的硬件组件中集成嵌入式软件系统。
- VIL (Vehicle in the Loop) Testing:
- 真实车辆被嵌入到模拟的交通环境中的测试。
- …….
这些仿真基础测试可以提供强大的工具集,用于在安全的仿真环境中评估复杂系统的行为和性能,从而避免早期阶段成本高昂或危险的物理测试。通过这些方法可以在产品实际开发和生产之前发现潜在问题,并且加速迭代和改进的过程。
Embedded System的Automated Testing, 区别于Software System的测试, 主要在于Simulation方式的不同。
Software System一般使用SIL测试,包括虚拟出的单元测试环境/测试环境/预发环境等等。但是对于Embedded System来说, SIL测试有以下问题:
- Embedded System的Software有部分是OS Kernel/Driver, 不能脱离实际的硬件进行测试
- Embedded System包含Hardware/Software, SIL不能涵盖完整的功能和集成
- 很多Embedded System是用在Safety-Critical场景,不仅是要验证他的functioning, 也需要验证他failing gracefully, 在一个大系统里是否正确的失效。
所以,Embedded System的自动化测试,都倾向使用HIL(或者更高的硬件环境,比如VIL)(Hardware并不一定是真实硬件,也可以是simulator, 比如QEMU)作为Simulation方式。
2.2 测试对象
预先定义测试对象非常重要,明确了测试对象才能做测试计划, 定义测试边界。
下面我们用一个思维导图,列两个常见Embedded System的行业场景。
从上面这个导图可以做几个结论:
- 自动化测试其实在硬件行业的使用率不高,其他大部分测试还是手工触发的测试。 这是因为硬件行业使用的是V开发过程而不是DevOps敏捷开发。
- 汽车这样一个大的工程项目里,是通过不同团队/供应商交付不同的组件来完整组织的。 所以其实每个组件都需要一套DevOps/自动化测试的流程来保证自己的质量。
- 这里要注意的是,部分组件与外部耦合严重(比如说中间件), 自己单独测试无法保证质量。 这种组件就需要下游组件集成的时候一起测试。
3 方案对比
上面我们讲了Embedded System的自动化测试主要是HIL。 下面来看看HIL测试的具体Framework方案。
一个HIL的测试Framework方案,应该包含以下几个部分:
- build system
- test runner
- test report
- scheduler
- device manage
以这几个部分为划分,做一个表格统计可选方案
分步骤独立 | Lava | autotest | 商用特定行业解决方案 | |||
---|---|---|---|---|---|---|
功能 | build system | buildroot Yocto |
emerge | √ | ||
test runner | pytest custom scripts |
√ | √ | √ | ||
test report | allure | √ | √ | √ | ||
scheduler | Jenkins use from shell |
√ | custom tools | √ | ||
device manage | 硬件管理 | custom scripts labgrid 商用台架方案 |
√ | custom scripts | ||
仿真模拟 | 自研基础设施 | √ | ||||
行业场景 | 大部分场景都可以适配 | android设备 | Linux设备,比如说ChromeOS笔记本电脑 | 特定行业场景,比如说汽车的ECU | ||
文档资料 | Link | Link | Link |
对比以上方案, 大部分情况下自研特殊项目,都可以用 ”分步骤独立“的方式。
以下是网上找的以上方案的一些图片,可以看看
4 总结
本文只是整理了一些技术概念和细节,如何将这些知识点融入到具体的业务场景里,需要做另外的思考。