ECU-TEST自动化从一条用例跑通开始

自动化测试不应该从“把几百条 Excel 一次导入”开始，而应当从一条能够在台架上稳定复现的用例开始。

第一条用例选最有代表性的最小闭环：一个前置条件、一次信号写入、一个可观测响应、一个明确断言和一次清理。先在人工状态下手动跑通，确认台架连接、工程版本、映射和测试数据。只有这样，自动化失败时才有可靠基线。

用例结构建议固定为 Setup、Test Body 和 Teardown。Setup 建立模型连接、加载参数、初始化接触器和故障注入状态；Test Body 只包含本用例要验证的动作；Teardown 撤销写入、清除故障、恢复基础工况。把大量初始化塞进 Test Body，会让结果难以复用；完全不做清理，则会让失败像传染病一样进入后续用例。

等待条件要写上超时和采样周期。看到期望值就继续，超时则给出“实际值、期望值、持续时间、信号路径”四类信息。无意义的固定等待会让套件变慢，也会在慢机器上产生偶发失败。读值前的变量命名、单位、比较精度和结果类型必须在套件内保持一致。

信号映射要锁定一个版本。测试脚本中的短名通过映射文件落到台架长名，映射变化后脚本即使语法正确也可能控制错对象。执行前做映射完整性检查，执行后保存映射版本和台架工程版本。

一次通过不等于自动化成立。至少连续运行三次，并覆盖冷启动、重新下载工程和一次故意失败。人为把期望值改错，确认报告能显示失败而不是被异常吞掉；人为中断连接，确认超时和清理行为符合预期。

当单条用例稳定后，再按功能分组扩展。每条用例只验证一个主要意图，公共步骤封装成可维护关键字。自动化的目标不是减少几次点击，而是让同一测试意图在不同时间、不同人员和不同台架状态下得到同样可解释的结果。