4. 诊断测试基础
诊断测试自动化不是“把手工点击录制成脚本”这么简单。它需要先把诊断需求翻译成可验证的测试目标，再选择合适的测试类型、设计可复用的测试用例、搭建稳定的测试环境，并管理好测试数据。本章围绕这五个基础环节展开，帮助建立可落地、可维护的诊断测试工程框架。
一、诊断测试类型：先分清“测什么”
ECU诊断测试通常按验证目标分为以下几类，不同测试类型对应不同的执行时机和自动化策略：
- 协议一致性测试：验证ECU是否满足ISO 14229（UDS）、ISO 15765（DoCAN）等标准要求，例如服务寻址、会话切换、响应码格式。
- 诊断服务功能测试：验证具体服务的行为，如0x22读数据、0x2E写数据、0x31例程控制、0x27安全访问。
- 故障码与快照测试：验证DTC置位/清除条件、冻结帧数据、扩展数据记录是否正确。
- 刷写与引导测试：验证Bootloader刷写流程、校验、回滚和断电恢复能力。
- 网络与通信测试：验证多帧传输、流控、超时、总线负载下的诊断稳定性。
- 回归测试：在软件版本迭代后，快速验证已有诊断功能未被破坏。
二、需求分析：把自然语言变成可测条件
诊断需求通常来自诊断规范、诊断调查表（Diagnostic Specification）和ECU软件需求。需求分析的核心是识别出“可观测的输入、输出和约束”。例如一条需求写“安全访问失败后应延迟10秒再允许重试”，需要拆解为：
- 输入：发送0x27 01，返回错误种子或错误密钥；
- 输出：后续0x27请求返回NRC 0x37（requiredTimeDelayNotExpired）；
- 约束：延迟时间10秒，容差范围需确认；
- 前置条件：ECU处于扩展会话，安全等级未解锁。
需求分析输出应形成“需求—测试项—用例”的追溯矩阵，避免遗漏和重复。对于模糊需求，必须回到系统工程师确认，而不是在脚本里“猜”。
三、测试用例设计：从等价类到状态迁移
诊断测试用例设计常用方法包括等价类划分、边界值分析、状态迁移测试和错误猜测。以0x27安全访问为例：
用例ID: DIAG-SEC-001
测试项: 安全访问错误密钥重试延迟
前置条件: 10ms物理寻址, ECU上电, 默认会话
步骤:
1. 发送 10 03 (进入扩展会话)
2. 发送 27 01 (请求种子)
3. 发送 27 02 + 错误密钥
4. 立即再次发送 27 01
预期:
步骤3返回 NRC 0x35 (invalidKey)
步骤4返回 NRC 0x37 (requiredTimeDelayNotExpired)
等待10s后再次发送27 01, 返回种子好的用例应具备：唯一ID、明确前置条件、可执行步骤、可判定预期结果、可追溯需求。自动化脚本只是用例的“执行载体”，用例设计质量决定自动化价值。
四、测试环境搭建：信号链与工具链
诊断测试环境通常由被测ECU、电源、总线接口、诊断工具、自动化脚本和测试管理平台组成。下图展示了一个典型的台架测试环境信号链与工具链关系：
环境搭建的关键是“可控”和“可重复”：电源时序可控、总线负载可控、诊断报文时间戳可记录。台架环境还应支持故障注入，例如模拟总线短路、电压跌落、ECU掉电重启，以验证诊断鲁棒性。
五、测试数据管理：种子、密钥与DTC数据
诊断测试数据包括安全访问种子/密钥、DTC故障码表、例程控制参数、刷写文件、标定数据等。数据管理不当会导致用例不可重复、结果不可信。建议按以下清单管理：
| 数据类别 | 典型内容 | 管理要求 |
|---|---|---|
| 安全访问数据 | 种子、密钥、算法DLL | 版本绑定，禁止硬编码在脚本中 |
| DTC数据 | 故障码、快照、扩展数据 | 与诊断规范版本一致，可追溯 |
| 刷写数据 | S19、HEX、签名文件 | 校验和验证，区分开发/量产 |
| 环境配置 | 通道、波特率、寻址方式 | 参数化配置，环境隔离 |
| 测试结果 | 日志、报文、断言结果 | 自动归档，支持失败复现 |
六、案例与复盘：一次安全访问回归失败
某项目在软件升级后，安全访问用例批量失败。排查发现：新版本ECU的种子长度从4字节变为8字节，而测试脚本仍按4字节解析。问题不在ECU，而在测试数据与需求分析没有同步更新。复盘结论：
- 需求变更必须触发测试用例评审，不能只改代码；
- 种子/密钥解析应参数化，长度从配置读取；
- 回归测试应包含协议格式断言，而不仅是功能结果断言；
- 测试数据仓库应记录与软件版本的对应关系。
诊断测试基础工作的价值在于：让自动化脚本建立在清晰的需求、规范的用例、稳定的环境和可控的数据之上。只有这样，后续的持续集成和 nightly 回归才有意义。