4、测试需求分析：从系统需求提取HIL测试用例

做HIL测试这么多年，我见过太多团队一上来就搭机柜、连线、刷模型。结果呢？测了半天，发现关键场景根本没覆盖到。说白了，测试需求分析才是HIL环境搭建的起点。这一步做不好，后面全是白忙活。

这一章，我们就聊聊怎么从系统需求里，把HIL测试用例给“榨”出来。

4.1 需求分析的“三层过滤”法

系统需求文档往往又厚又杂。直接读，很容易迷失。我个人习惯用“三层过滤”法，把需求一层层筛成可执行的测试项。

举个例子。需求里写“系统应能在1秒内响应油门踏板信号”。第一层过滤后，我们得到“响应时间≤1s”这个指标。第二层过滤时，你会发现这个测试必须用真实的踏板传感器信号（模拟量输入），不能用CAN报文模拟。第三层，就要细化成：踏板开度从0%阶跃到50%，记录ECU输出扭矩的变化时间。

4.2 从需求到用例：一个实战案例

我记得有一次做BMS（电池管理系统）的HIL测试。需求里有一条：“当单体电池电压低于2.8V时，系统应在100ms内发出欠压报警，并限制放电功率。”

我们来看看怎么拆解：

1. 识别触发条件： 单体电压 < 2.8V。这里要注意，是“任一单体”还是“所有单体”？需求写得不清楚，必须找系统工程师确认。
2. 识别动作： 发出报警（CAN报文？硬线信号？）+ 限制功率（通过CAN指令还是PWM输出？）。
3. 识别时序： 100ms内。这个时序在HIL上怎么测？需要用示波器或高速采集卡抓取电压跳变沿和报警信号输出沿的时间差。
4. 识别边界： 2.8V是阈值。那2.79V呢？2.81V呢？电压缓慢下降和快速跌落，响应时间一样吗？

最终，我们从这个需求里提取了6个测试用例：

• 用例1：单体电压从3.0V阶跃至2.79V，验证报警和功率限制。
• 用例2：单体电压从3.0V以0.1V/s速率下降，验证报警阈值精度。
• 用例3：单体电压从2.79V恢复至3.0V，验证报警撤销和功率恢复。
• 用例4：多单体同时欠压，验证系统处理优先级。
• 用例5：电压在2.8V附近抖动（±0.05V），验证防抖逻辑。
• 用例6：在极限温度（-40℃ / 85℃）下重复用例1，验证温度补偿。

4.3 测试覆盖度分析：别漏了“暗礁”

覆盖度分析，说白了就是回答一个问题：我们测全了吗？

HIL测试的覆盖度，不能只看功能覆盖。我一般会从四个维度去评估：

功能覆盖是最基础的。每个系统需求，至少对应一个正向用例和一个反向用例。比如“门锁上锁”功能，正向是“收到闭锁信号→门锁动作”，反向是“收到闭锁信号但车门未关→门锁不动作并报警”。

边界覆盖是HIL测试的强项。为什么？因为HIL可以精确控制模拟量信号。电压的0.1V、电流的1mA、时间的1ms，都能精准复现。我建议把每个模拟量输入信号的“正常工作范围”、“警告范围”、“故障范围”都列出来，然后在每个范围的边界上布点测试。

时序覆盖容易被忽略。很多系统需求里都有“应在XX时间内”的描述。但实际测试时，你会发现：ECU的响应时间不是固定的。它和系统负载、总线负载、甚至温度都有关。所以，时序覆盖不能只测一个点，要测一个范围。

故障覆盖是HIL的看家本领。你想想看，实车上有多少故障是偶发的、不可复现的？在HIL上，我们可以通过故障注入单元（FIU），精确地制造短路、开路、信号漂移、CAN总线断线等故障。而且，可以反复复现。

4.4 测试优先级划分：先测什么，后测什么

资源总是有限的。机柜通道数有限、项目周期有限、测试工程师的精力也有限。所以，我们必须给测试用例排个优先级。

我常用的方法是“风险-影响”矩阵。每个用例从两个维度打分：

• 风险等级（1-5）： 这个功能失效后，会导致什么后果？是车辆失控（5分），还是只是舒适性下降（1分）？
• 影响范围（1-5）： 这个功能失效，会影响多少其他功能？是核心控制逻辑（5分），还是独立的人机交互界面（1分）？

然后，优先级 = 风险等级 × 影响范围。得分最高的用例，优先执行。

嗯，这里还要注意一点：优先级不是一成不变的。随着测试的进行，你会发现一些P2的用例，实际执行时暴露了严重问题。这时候，就要把它升级到P1甚至P0。反过来，如果某个P0的用例跑了100次都没问题，也可以适当降低它的执行频率，把资源让给新发现的“雷区”。

最后，总结一下这一章的核心：从需求到用例，不是简单的“翻译”，而是“提炼”和“重构”。你要把系统工程师写的“人话”，转化成HIL设备能执行的“机器语言”。覆盖度分析帮你查漏补缺，优先级划分帮你把好钢用在刀刃上。这三步走扎实了，你的HIL环境搭建才算是有了“灵魂”。