谈谈汽车ECU测试

01

系统与软件测试的区别

在ECU开发测试中，通常会把二者区分开来，我们从以下几个角度来看差异点：

• 测试对象： 软件测试是面向集成在芯片上的软件；系统测试是针对包含软件、硬件与标定的ECU。

• 测试目的： 软件测试是来寻找软件中的错误，证明软件本身符合软件需求；系统测试是寻找软件、硬件与标定以及结构件共同组成的ECU中的错误，证明系统符合系统需求。

• 测试环境： 软件测试要尽量独立于硬件，要通过诸如CANoe发送信号的模拟方式进行，尽量模拟；系统测试要尽量真实，真实的线束，真实的负载等。

02

测试的次序

最好呢，从V模型的最底层按次序逐层测上来，但最好的东西一般不容易得到，我们基本没有那么多时间来进行这样的瀑布式开发。

所以得考虑一些大的原则，然后，适当地并行。

• 单元级测试这种非典型测试，最好首先完成 ，甚至要通过工具链和代码生成进行绑定，即不达到一定的条件无法生成代码，早期一些代码逻辑的覆盖测试会极大地减少后期痛苦的返工。

• 冒烟或基本功能测试是第二优先级的测试 ，基本可用也是开发人员基本素养的要求。

• 软件功能、系统集成、系统测试 可以在架构变化、接口历史问题等现实项目情况的考虑下，进行 适当的并行 。

03

测试准入条件

测试并不是想测就能测的，需要达到一定的条件才能交给测试团队，这就是测试准入条件。这些规则对于大团队协作非常重要。

• 首先要看前面讲的必要测试次序及测试结果是不是满足进行更高层级测试要求。

• 硬件设备 已就位，比如，ECU工程样件、线束、外围传感器、对手件等。

• 测试台架 可用，并已经过校准。

• 测试信息输入 完成，比如，软硬件版本、配置参数、测试计划、交付信息等。

• 标定 已到位。

• 文档 （需求、测试规范等）完成 review与基线化 。

• 软件交付 按流程完成 评审 。

04

测试准出条件

测试不是想来就来，也不是想走就走的，我们还需要准出条件。

准出其实是有两层含义的，第一层是正常结束，第二层是异常终止。

4.1 正常结束

一般，我们要同时满足以下条件，才可进行正常结束。

• 所有计划的测试均已按计划执行。

• 测试结果的异常项完成了分析与评审。

• 发现的bug录入相应ALM工具。

4.2 异常终止

除了流程强制外，终止的大部分原因是考虑到成本与时间，有些情况下，测试没必要继续进行。

• 软件或ECU 质量太差 ，不足以支撑测试。

• 测试开始后，发现 没有满足准入条件 。

• 如果发现的bug会 影响到某些测试的有效性 ，则这些测试要停下来。

• 如果修复某些bug后还 需要重测某些case ，则这些case在修复后再进行。

• 如果 新的硬件或软件很快就可用 （很快是多快要具体定义了），所有的测试就可停下来，等待新的软硬件。

05

测试用例的选择

开始测试之前，我们多数会有一个测试用例库，每版本都全测自然是带来高成本和长周期，因此，用例是需要被选择的，也就是我们总说的Delta测试。

• 产品本身的风险 高低，对于ASIL等级较高的产品，要强制做一些关键功能测试。

• feature的实现 情况。

• 已知的 软硬件变化 。

• 工作量 评估。

• 前序版本、相关版本的测试状态 。

• 变更对未更改部分的影响 。

• 不同项目 变体之间的调度策略 。

• 对于这类主观及经验属性较大的决策， 每个未执行的测试用例最好都有一个 的记录下来的理由。

除了Delta测试， 全功能测试的策略也应被制定出来，比如，一年至少一次全功能，SOP前完成一次全功能，平台软件升级后进行一次全功能，发版超过5版之后进行一次全功能，硬件有变化时要进行一次全功能 ......

06

测试管理

测试是一项复杂冗长的工作，必要的管理是必要的。

6.1 测试管理

测试管理的目标是，根据测试计划获取相应的测试交付物 （例如，测试规范、测试执行、测试报告、测试评审、缺陷提交等) ，并且要保证交付能满足项目进度中定义的里程碑。

6.2  测试资源

交付物能够及时获取的一个大前提是测试资源能够得到满足，而测试资源包括人员的能力、测试设备、测试样件等。

6.3 测试调度

为了尽早确定可能的退出条件，必须首先执行失败概率更高的测试 ，比如，依次按照以下次序进行。

• bug重新测试

• 测试 新功能

• 测试 修改或优化的功能

• 未改变feature的测试（ 回归测试 ）

6.4 测试计划和监控

基于项目进度要求以及“测试评估”和“测试调度”的结果，我们就能够给出测试阶段完成的截止日期，从而得出详细的计划。

计划所需的详细程度取决于项目的复杂性和所涉及的测试人员的数量。

07

双向追溯性和测试覆盖率

每一条系统或软件的可测试需求都需要被至少一个测试用例强制覆盖。 为了检查测试覆盖率，测试报告、测试规范和相应需求之间的可追溯性可借助相应的需求覆盖率工具，如Reqtify。

如果测试覆盖不完整，则需要将信息暴露给项目层面，并完成风险评估与偏差许可。

08

写在最后

测试是个非常庞杂的课题，值得反复研究，限于精力与时间，本文简单总结，点到为止。