📚 课程目录第2章电驱系统基础

2. 电驱系统基础

做HIL测试这么多年，我见过不少团队一上来就盯着“覆盖率”这个数字猛追。结果呢？数字很好看，车在路上跑着跑着就出问题了。说白了，覆盖度不是单一指标，它是个体系。你得分清楚你在测什么，才能知道你的覆盖度到底有没有意义。

这一章，我们就来掰扯清楚四种最核心的覆盖度概念。我个人习惯把它们分成两类：一类是“测没测到代码”，另一类是“测没测到功能”。前者是代码覆盖度，后者是需求、功能、接口覆盖度。方向完全不同，但缺一不可。

  核心观点： 覆盖度不是越高越好，而是“该覆盖的地方都覆盖了”。盲目追求100%代码覆盖度，反而可能让你漏掉真正的功能缺陷。

代码覆盖度，说白了就是看你的测试用例把被测代码“踩”了多少。它是最底层的覆盖度指标，也是很多开发团队最熟悉的。

常见的代码覆盖度指标有这几个：

注意： 在HIL测试中，代码覆盖度通常不是直接目标。HIL测的是“系统行为”，不是“代码行”。但如果你在做安全关键系统（比如ISO 26262要求的ASIL C/D），MC/DC覆盖度就是硬性要求。我曾经在一个EPS项目中，就因为MC/DC覆盖度差2%，被审核员卡了整整两周。

需求覆盖度，这是HIL测试里我最看重的指标。它回答一个简单的问题：需求文档里写的每一条，你都有对应的测试用例吗？

我建议把需求覆盖度分成两个层次：

举个例子，我之前做BMS（电池管理系统）项目时，需求里有一条：“当SOC低于10%时，系统发出低电量警告”。对应的测试用例就是：模拟SOC从15%下降到5%，检查CAN总线上是否发出警告信号。这就是正向覆盖。

我的习惯： 每次写测试用例前，先把需求清单拉出来，逐条打勾。没打勾的，要么是需求冗余，要么是测试遗漏。这两种情况，我都遇到过。

功能覆盖度比需求覆盖度更“粗”一些，但也更贴近用户视角。它关注的是：这个功能的所有使用场景，你都测了吗？

需求覆盖度是“点对点”，功能覆盖度是“面对面”。你想想看，一个功能可能对应多条需求，也可能对应多个使用场景。

功能覆盖度通常用功能矩阵来管理：

这里要注意，功能覆盖度不是简单的“功能有就行”。你得把功能的状态机走通。比如ACC功能，从“待机”到“激活”到“退出”，每个状态转换都要覆盖到。

接口覆盖度，这是HIL测试的“独门绝技”。纯软件测试不太关注这个，但在HIL里，接口覆盖度直接决定了你的测试环境是否真实。

接口覆盖度关注的是：ECU与外界交互的所有信号通道，你都测了吗？

常见的接口类型包括：

我建议用接口覆盖度矩阵来管理：

接口类型	信号名称	方向	正常值覆盖	边界值覆盖	故障注入覆盖
CAN	车速信号(0x100)	输入	0~250 km/h	0, 250, 255	信号超时/校验错误
硬线	刹车开关	输入	高/低电平	抖动/毛刺	对地短路/对电源短路
PWM	油门位置	输出	5%~95%占空比	0%, 100%	频率偏移/占空比超限

避坑指南： 我曾经在一个项目中，接口覆盖度做到了95%，但漏掉了一个“传感器供电电压”的硬线信号。结果台架上跑得好好的，装车后传感器供电不稳，系统直接死机。从那以后，我要求每个接口信号必须覆盖：正常值、边界值、故障注入三种场景。

说了这么多，我们来总结一下这四种覆盖度的核心区别。我习惯用一个表格来对比：

维度	代码覆盖度	需求覆盖度	功能覆盖度	接口覆盖度
关注对象	代码语句/分支	需求条目	功能场景	信号通道
测试视角	白盒	黑盒	灰盒	集成
粒度	细	中	粗	中
HIL适用性	低（安全关键除外）	高	高	极高
常用工具	Polyspace, Cantata	DOORS, Polarion	Test Manager, ECU-TEST	CANoe, vTESTstudio
典型指标	MC/DC ≥ 100%	需求-用例追溯率 ≥ 100%	功能场景覆盖率 ≥ 90%	信号通道覆盖率 ≥ 95%

它们之间的关系，我打个比方你就明白了：

在HIL测试中，我个人的优先级排序是：接口覆盖度 > 功能覆盖度 > 需求覆盖度 > 代码覆盖度。为什么？因为HIL的核心价值在于“真实环境下的系统验证”，接口和功能是直接反映系统行为的，而代码覆盖度更多是开发阶段的事。

  一句话总结： 代码覆盖度告诉你“代码跑了多少”，需求覆盖度告诉你“需求测了多少”，功能覆盖度告诉你“场景覆盖了多少”，接口覆盖度告诉你“信号验证了多少”。四者缺一不可，但HIL测试的重心，永远在接口和功能上。