汽车ECU测试中的几个共性问题

最近的工作需要经常和测试打交道，但我并非这个细分领域的行家，看着几千条测试用例和五花八门的测试设备与工具，以及工程师展示的繁复曲线与图表，着实有些眼花缭乱，没太看懂，不由得陷入了深深的思索......

1

T型人才与焦利氏称

陷入思索有两个原因：一是确实没跟上节奏，只能佯装沉思，以掩饰尴尬，保持风度；二是汽车领域的知识太多了，没能力是一说，但也实在没必要事事跟上节奏，守好自己碗里的饭就不错了。

可是，我们不是要构建T型知识结构，成为综合性人才嘛。那怎么办呢？

写到这里，想到多年前的大学物理实验课，绝大多数课意料之内地忘得干干净净，但倒是记住了一堂——焦利氏称，原因是老师说的一句话，“话我照讲，实验你们照做，但你们多年后肯定记不住我们今天做了什么，只要记住一点，焦利氏称是测微小力的......”老师的反向操作倒也是6，不肖弟子把老师是谁都忘了，还记着这句话。

这堂课的这部分，于我，是最有价值的内容，但凡我遇到测微小力的场景，我就可以快速收集整理焦利氏称的信息......否则，这么冷门的东西有几个人晓得呢？

回到我们的T型人才，这涉及一个知识结构搭建的问题，我们得把T这一横里的那些原则性、策略性、共性的东西提炼出来，完善自己的知识和认知框架，细节嘛，择需而取。

下面开始正题，概要讲几个ECU测试的小点。

2

系统与软件测试的区别

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

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

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

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

3

测试的次序

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

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

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

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

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

4

测试准入条件

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

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

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

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

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

• 标定已到位。

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

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

5

测试准出条件

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

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

5.1 正常结束

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

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

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

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

5.2 异常终止

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

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

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

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

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

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

6

测试用例的选择

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

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

• feature的实现情况。
  

• 已知的软硬件变化。
  

• 工作量评估。
  

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

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

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

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

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

7

测试管理

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

7.1 测试管理

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

7.2 测试资源

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

7.3 测试调度

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

• bug重新测试

• 测试新功能
  

• 测试修改或优化的功能

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

7.4 测试计划和监控

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

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

8

双向追溯性和测试覆盖率

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

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

9

写在最后

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

另外，以前也写过一篇测试相关的文章——《汽车电子软件测试的“脉络”》，有兴趣的读者，也可以结合着看。

关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。

完