3. 回归测试需求分析与用例建模
回归测试的核心矛盾在于：ECU功能需求以自然语言描述，测试规范以半结构化文档存在，而自动化回归用例必须能被测试执行器逐条解析、逐条判定。三者之间的鸿沟不是靠“多写脚本”填平的，而是靠一套可追溯的转化方法。本节围绕“需求→测试项→用例→自动化资产”这条主线，说明每一步该提取什么、如何判定可自动化、以及最终交付物长什么样。
一、从功能需求中提取可测项
ECU功能需求通常写成“当条件A满足且信号B处于范围R时，ECU应在时间T内将输出C置为状态S”。这句话里已经隐含了测试所需的全部要素：前置条件、输入激励、时间约束、期望输出。需求分析的第一步不是通读全文，而是逐条做“可测性拆解”，把每条需求拆成若干可独立判定的测试项。
拆解时重点识别三类信息。第一类是触发条件，例如点火状态KL15=ON、车速信号有效、档位处于D档；第二类是激励与边界，例如输入电压9V/12V/16V、温度-40℃/25℃/85℃、信号占空比0%/50%/100%；第三类是判定依据，包括输出电平、CAN报文周期、故障码状态、响应时间上限。凡是需求中出现“应”“必须”“在……内”“不得”等措辞的位置，都是判定依据的落点。
对于无法直接判定的需求，例如“ECU应具有良好的电磁兼容性”，不能强行转化为回归用例，而应标记为“需台架或专项试验验证”，避免把不可自动化的项混入回归集。这一步的产出是一张需求-测试项追溯表，每条测试项至少包含需求ID、测试项ID、激励类型、判定类型、可自动化标记。
二、测试规范到用例结构的映射
测试规范通常按功能域组织，包含测试目的、预置条件、测试步骤、期望结果。它与自动化用例之间不是一对一关系：一条测试规范可能展开为多条用例（不同边界值），多条测试规范也可能合并为一条用例（同一激励序列下的连续判定）。转化的关键是建立用例结构模型，把测试规范中的描述性步骤映射为可执行的结构化字段。
推荐采用“用例头 + 激励序列 + 判定点”三段式结构。用例头记录用例ID、关联需求ID、测试环境配置（如ECU软件版本、总线波特率、负载板卡通道映射）；激励序列记录每一步的通道、物理量、持续时间、变化方式（阶跃、斜坡、脉冲）；判定点记录判定信号、判定时刻、期望值、容差。这样一条用例在自动化平台中就是一组可参数化的数据，而不是一段硬编码脚本。
下面这张图展示了从需求条目到自动化用例资产的转化链路，以及每一步的输入、处理动作和输出物。图中同时标出了“可自动化判定”与“需人工/专项验证”的分支，帮助在建模阶段就完成筛选。
三、可自动化判定的筛选准则
并非所有测试项都适合进入回归集。筛选时用三条准则快速判断：激励能否由平台施加（电压、CAN、LIN、模拟量、数字IO是否覆盖）、响应能否由平台采集（总线报文、硬线电平、诊断响应是否可读）、判定能否由平台自动比较（期望值是确定量还是需要人工观察）。三条同时满足才标记为“可自动化”，否则进入专项验证清单。
实际项目中常见的灰色地带是“响应时间”类判定。例如需求写“ECU应在100ms内响应”，平台可以采集时间戳并自动比较，但前提是激励施加时刻与采集时刻使用同一时基。建模时必须在用例头中声明时基来源（如dSPACE实时系统的采样周期1ms），否则判定结果不可复现。
四、用例参数化与回归集组织
回归用例的价值在于“一次建模、多次执行”。因此建模阶段就要把变化量提取为参数，而不是写死在用例里。典型参数包括：电压等级、温度点、信号边界值、故障注入方式、软件版本。参数化后，一条用例模板可以生成多条回归实例，覆盖不同配置组合。
回归集的组织建议按“功能域 + 优先级 + 执行时长”三维划分。功能域保证覆盖完整，优先级保证冒烟集可在10分钟内跑完，执行时长用于排布夜间回归批次。每条用例必须携带需求ID，这样当需求变更时，可以通过追溯表快速定位受影响的用例，而不是全量重跑。
五、一个完整的转化示例
以“车速信号超范围时ECU应置车速有效位为0并记录DTC”为例。需求原文给出触发条件（车速信号超出0~300km/h范围）、响应（有效位置0、DTC置位）、时间约束（300ms内）。拆解后得到测试项：激励为车速信号从0斜坡至320km/h，判定为CAN报文有效位和DTC状态，时间约束300ms。
建模时，用例头声明ECU软件版本、CAN波特率、负载板卡通道映射；激励序列写为“CH1: 0→320km/h，斜坡2s，保持500ms”；判定点写为“激励后300ms，CAN_0x1A0.车速有效位==0，DTC_P0501==Active，容差±20ms”。这条用例进入回归集后，每次软件版本更新都可自动执行，判定结果直接与期望值比较，无需人工解读报文。
如果后续需求将时间约束从300ms改为200ms，只需修改判定点中的判定时刻参数，用例模板和激励序列不变。这正是结构化建模相对于硬编码脚本的优势：变更影响被限制在参数层，而不是扩散到脚本逻辑层。
六、交付物与检查要点
本节完成后应形成三份可直接使用的交付物：需求-测试项追溯表（含可自动化标记）、结构化用例数据表（用例头/激励序列/判定点三段式）、回归集清单（按功能域和优先级组织）。检查时重点确认：每条可自动化用例是否三要素闭环、参数是否已提取、需求ID是否可追溯、时基是否统一声明。这四点决定了后续自动化执行和回归分析能否顺利进行。