2. 需求工程基础与HIL测试衔接

HIL（Hardware-in-the-Loop）测试的价值，取决于它所验证的需求是否被正确理解、正确分解，并正确映射到测试用例。如果需求本身模糊、不可测，或者测试用例与需求之间没有可追溯的链路，那么再精密的HIL台架也只能产出“看起来通过、实际上无意义”的结论。本节从需求分类、可测试性准则、需求到HIL测试用例的映射关系三个层面，建立后续覆盖率与追溯体系的共同基础。

一、需求分类：功能、性能、安全

在汽车电子与嵌入式控制领域，需求通常按“功能—性能—安全”三条主线分类，它们对HIL测试的诉求差异明显。

功能需求描述系统“做什么”，即输入到输出的行为逻辑。例如：“当车速大于30 km/h且驾驶员按下巡航激活按钮时，巡航控制器应进入待激活状态。”功能需求是HIL测试中最直接的对象，通常通过激励信号注入、总线报文模拟和输出观测来验证。

性能需求描述“做到什么程度”，包括响应时间、精度、吞吐量、抖动、超调量等。例如：“从制动踏板位置传感器信号变化到制动灯输出置位，延迟应不超过50 ms。”性能需求在HIL中需要精确的时间基准和可重复的激励序列，往往依赖实时仿真步长、I/O延迟补偿和测量点定义。

安全需求描述“异常或故障条件下如何保证安全”，通常来自ISO 26262的功能安全概念或系统FMEA。例如：“当轮速传感器信号丢失时，ESC应在100 ms内进入降级模式并点亮故障指示灯。”安全需求在HIL中需要故障注入能力，包括信号开路、短路、超范围、报文丢失、校验错误等。

三类需求并非彼此独立。一条完整的需求条目往往同时包含功能行为、性能指标和安全约束。在需求管理工具中，建议用属性字段显式标注需求类别，便于后续按类别统计HIL覆盖率。

二、需求可测试性准则

需求可测试性，是指一条需求能否在给定测试环境下被客观、可重复地判定为通过或失败。可测试性不足的需求，是HIL测试中最常见的返工来源。以下准则可作为需求评审时的检查依据。

• 可观测：需求所描述的输出必须能在HIL台架上被测量，例如总线信号、硬线电压、执行器电流或内部标定量。
• 可激励：需求所依赖的输入必须能被HIL系统产生或模拟，包括传感器信号、总线报文、故障注入条件。
• 可判定：通过/失败判据必须量化，避免“正常”“合理”“尽快”等主观词。应给出阈值、容差和时间窗口。
• 边界明确：需求应说明适用工况、前置条件和状态约束，避免测试用例无法确定初始状态。
• 无歧义：同一术语在全文中含义一致，单位、坐标系、正负号方向必须明确。
• 可追溯：每条需求有唯一标识，且能向上追溯到系统需求或安全目标，向下追溯到测试用例。

三、需求与HIL测试用例的映射关系

需求到HIL测试用例的映射，不是简单的一对一。实际工程中常见四种关系：一对一、一对多、多对一、多对多。理解这些关系，是后续计算需求覆盖率和追溯完整性的前提。

一对一：一条需求对应一个测试用例，适用于逻辑简单、边界清晰的功能需求。一对多：一条需求需要多个测试用例覆盖正常、边界、异常等不同场景，性能和安全需求通常属于此类。多对一：一个测试用例同时验证多条相关需求，常见于同一工况下的组合功能。多对多：复杂安全需求与多个测试用例交叉覆盖，需要借助追溯矩阵管理。

建立映射时，建议在需求管理工具与测试管理工具之间使用唯一标识进行双向链接。每条测试用例至少关联一条需求，每条需求至少被一条测试用例覆盖。对于安全需求，还应额外关联故障注入用例和降级行为验证用例。

四、从需求到HIL用例的实操要点

在实际项目中，需求到HIL用例的映射通常按以下顺序落地。首先，从需求管理工具导出需求清单，确认每条需求已标注类别、优先级和验证方法。其次，为每条需求分配测试用例编号，建立追溯矩阵的初始版本。然后，针对性能需求补充测量点定义和采样率设置，针对安全需求补充故障注入类型和注入时刻。最后，在HIL测试执行后，将实际结果回写到追溯矩阵，标记通过、失败或阻塞状态。

以“制动灯延迟不超过50 ms”为例，HIL用例需要明确：激励为制动踏板位置传感器信号从0%阶跃到50%，测量点为制动灯硬线输出，采样率不低于1 kHz，判据为从信号变化到输出置位的时间差≤50 ms。若测试结果在48 ms至52 ms之间波动，应检查台架I/O延迟补偿是否已启用，而不是直接判定需求失败。