网络诊断 0x3E 服务用例设计从需求拆解到 testbuddy 自动化落地做网络诊断和 UDS 测试的同学对 0x3E 服务应该都不陌生。这个服务负责会话切换是整个诊断流程里被调用次数最多的服务之一。很多刚入门的测试工程师会问0x3E 服务不就是一个切换会话的指令吗能有多少测试点实际上0x3E 会话控制服务牵扯到会话状态机、会话切换时序、P2/P2* 定时参数、非默认会话访问权限、网络异常恢复等多个维度单靠“发一条指令看响应”这种粗放式验证根本覆盖不了实车场景里的各种问题。这次我们就从需求拆解出发把 0x3E 服务的测试用例完整设计一遍再结合 testbuddy 这类用例生成和管理工具把手工编写的用例转成可维护、可回溯的自动化用例资产。文章内容分为三块第一0x3E 服务的协议逻辑和测试需求分析第二按功能、时序、异常、安全四个维度设计用例第三如何用 testbuddy 辅助生成用例、组织测试步骤并与诊断自动化工具链打通。1. 0x3E 服务核心能力速览能力项说明服务名称Session Control诊断会话控制SID0x3E子功能0x01 默认会话0x02 编程会话0x03 扩展会话0x04 安全扩展会话按项目定义主要作用切换 ECU 诊断会话控制会话超时与访问权限响应方式正响应 0x7E负响应 0x7F关键时序P2、P2* 定时参数非默认会话 S3 超时回到默认会话测试重点会话状态机、子功能有效性、切换时序、权限隔离、异常恢复常用工具CANoe、CANalyzer、PCAN、迪卡侬诊断仪、testbuddy、Vector vTESTstudio是否支持自动化支持可编程实现全流程自动化验证适合场景ECU 开发测试、诊断协议一致性测试、产线诊断、售后诊断流程验证0x3E 服务的核心逻辑不复杂但测试覆盖点非常多。下面按“需求拆解 - 场景提取 - 用例设计 - 自动化执行”的顺序展开读者可以把它当作一套可直接复用的测试用例设计模板。2. 0x3E 服务协议逻辑与测试需求拆解在设计用例之前先确认 0x3E 服务在 UDS 协议里怎么工作。UDSISO 14229定义 0x3E 服务用于客户端请求切换 ECU 的诊断会话。ECU 上电后默认进入默认会话通过 0x3E 子功能可以切换到编程会话或扩展会话非默认会话通常有 S3 超时时间超过时间没有收到后续请求ECU 会回到默认会话。从测试需求拆解角度0x3E 服务可以按五个层面展开功能需求会话切换是否正确子功能是否有效正响应/负响应是否符合协议。时序需求S3 超时、P2/P2* 定时器、切换响应时间。状态需求默认会话、编程会话、扩展会话之间的状态迁移是否合法。安全需求非默认会话下对 0x27 安全解锁、0x22 读取、0x2E 写入等服务的访问控制是否正确。异常需求通信中断、总线休眠、非法子功能、连续切换、重复切换时的行为。真实项目中0x3E 服务最容易出问题的点包括非默认会话超时后未回到默认会话、扩展会话下无法执行 0x2E 写入、编程会话切换失败、P2* 延长响应时序超过诊断仪等待时间。这些都应该作为重点用例覆盖。结合最新热词中提到的 testbuddy 用例生成工具层面需要考虑的是需求条目不完整时通过平台现有的 UDS 服务模板生成基础用例再用迁移图或状态机补充分支场景最后把补充用例固化到测试规范中。3. 0x3E 服务用例设计方法3.1 基于需求分类的用例框架0x3E 服务用例建议按三级目录管理0x3E_SessionControl/ ├── 01_DefaultSession/ │ ├── TC_3E_001_默认会话下切换默认会话 │ ├── TC_3E_002_默认会话下切换扩展会话 │ └── TC_3E_003_默认会话下切换编程会话 ├── 02_ExtendedSession/ │ ├── TC_3E_010_扩展会话身份切换 │ ├── TC_3E_011_扩展会话S3超时回退 │ └── TC_3E_012_扩展会话访问0x2E写入 ├── 03_ProgrammingSession/ │ ├── TC_3E_020_编程会话身份切换 │ └── TC_3E_021_编程会话下刷写前置条件 ├── 04_AbnormalSequence/ │ ├── TC_3E_030_非法子功能 │ ├── TC_3E_031_连续切换会话 │ └── TC_3E_032_通信中断后会话状态 └── 05_SecurityAccess/ ├── TC_3E_040_扩展会话与安全解锁 └── TC_3E_041_不同会话下安全状态保留这种目录结构的好处是用例编号清晰后续追踪需求覆盖率和失败用例分布时可以按目录聚合统计也可以直接在 testbuddy 里按模块导入。3.2 用例设计要素每个 0x3E 用例至少包含以下字段字段说明用例编号TC_3E_XXX唯一标识测试目的说明验证的协议行为前置条件ECU 上电状态、会话状态、总线条件测试步骤按顺序发送的诊断请求和等待时间预期结果正响应/负响应、状态切换、时间参数实际结果执行后自动或手动填写判定标准Pass/Fail 的明确条件关联需求关联到系统需求条目 ID风险等级高/中/低决定测试优先级testbuddy 之类的用例管理平台通常支持自定义字段这组字段建议直接映射到平台的用例模板里后续生成测试报告和追溯矩阵很方便。3.3 状态迁移法生成用例0x3E 服务本质是一个状态机默认、扩展、编程三个会话之间不是任意切换都合法。各 ECU 对编程会话的进入条件定义不同很多控制器要求先进入扩展会话并完成安全解锁之后才能进入编程会话。通过状态迁移图可以补充出以下边界用例默认会话直接进入编程会话按 ECU 设计决定是否允许。扩展会话进入编程会话常规合法路径。编程会话进入扩展会话通常允许但要注意退出编程会话后是否保留安全解锁状态。非默认会话下重复进入同一会话应返回正响应但部分 ECU 会返回 0x22 条件不满足。状态迁移法尤其适合用 testbuddy 生成因为 testbuddy 支持步骤组合和分支逻辑。把每个会话状态定义成一个前置条件把 0x3E 子功能定义成动作自动展开后就能得到覆盖矩阵。4. 0x3E 服务功能测试用例明细4.1 默认会话切换测试TC_3E_001默认会话下切换到默认会话测试目的验证重复进入当前会话是否正常处理。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 01。预期结果正响应 0x7E 01ECU 保持默认会话。判定标准响应 SID 正确无负响应。TC_3E_002默认会话下切换到扩展会话测试目的验证默认会话到扩展会话基础切换路径。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 03。预期结果正响应 0x7E 03ECU 进入扩展会话。判定标准后续发送 0x22 读取扩展会话下才允许访问的 DID 能成功。TC_3E_003默认会话下切换到编程会话测试目的验证不同 ECU 对编程会话进入条件。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 02。预期结果按 ECU 设计可能正响应或负响应。若设计允许ECU 进入编程会话若不允许负响应 NRC 0x22。判定标准必须与诊断规范一致。4.2 非默认会话切换测试TC_3E_010扩展会话保持与超时回退测试目的验证 S3 超时后是否回到默认会话。前置条件ECU 处于扩展会话。测试步骤发送 0x3E 03 进入扩展会话等待超过 S3 时间以 AUTOSAR 配置为准常见 5s 或 10s再发送 0x22 读取扩展会话 DID。预期结果超时后 ECU 自动回到默认会话0x22 返回负响应 0x7F 22 0x7E 或 0x51。判定标准状态切换时间和回退行为符合设计要求。TC_3E_011非默认会话下发送 0x3E 保持会话测试目的验证周期性发送 0x3E 01 能否防止非默认会话超时。前置条件ECU 处于扩展会话。测试步骤进入扩展会话后在 S3 超时时间内周期性发送 0x3E 01例如每 2s 发送一次持续超过 S3 时间。预期结果ECU 保持在扩展会话不会回到默认会话。判定标准整个保持期间 0x22 扩展 DID 可正常读取。TC_3E_012非默认会话下写入访问控制测试目的验证扩展会话下 0x2E 写入权限。前置条件ECU 处于扩展会话且未安全解锁。测试步骤发送 0x2E 写入一个需要扩展会话权限的 DID。预期结果若该 DID 仅要求扩展会话写入成功若还要求安全访问负响应 0x33 安全访问拒绝。判定标准NRC 值与 DID 权限定义一致。4.3 编程会话刷写前置条件测试TC_3E_020进入编程会话测试目的验证完整刷写流程的会话切换部分。前置条件ECU 处于默认会话。测试步骤0x10 03 进入扩展会话 - 0x27 01/02 安全解锁 - 0x3E 02 进入编程会话。预期结果每一步正响应最终进入编程会话。判定标准刷写前置流程完整执行。TC_3E_021编程会话下重启保持测试目的验证编程会话下 ECU 重启后的会话状态。前置条件ECU 处于编程会话。测试步骤发送 0x3E 02 进入编程会话执行 ECU 复位等待重启完成后发送 0x22 读取会话状态。预期结果ECU 重启后回到默认会话。判定标准重启后无法直接执行编程会话专属功能。5. 0x3E 服务异常与安全用例设计5.1 异常用例TC_3E_030非法子功能测试目的验证错误子功能处理。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 00 或 0x3E FF。预期结果负响应 0x7F 3E 12子功能不支持。判定标准NRC 必须为 0x12SNS。TC_3E_031连续快速切换会话测试目的验证 ECU 对高频率会话切换的稳定性。前置条件ECU 上电。测试步骤循环发送 0x3E 01、0x3E 03、0x3E 02每两条之间间隔 10ms持续 100 次。预期结果无总线错误响应正确最终会话状态符合最后一次切换。判定标准无错误帧ECU 不死机不进入 Bus Off。TC_3E_032通信中断后会话保持测试目的验证总线断开后非默认会话是否按 S3 超时回退。前置条件ECU 处于扩展会话。测试步骤进入扩展会话后断开总线或关闭诊断仪等待超过 S3 时间后重新连接。预期结果重新连接后 ECU 处于默认会话。判定标准回退行为正确重新进入扩展会话需要重新发送 0x3E 03。TC_3E_0330x3E 请求和 0x10 请求交叉测试目的验证 0x3E 与 0x10 诊断会话控制之间的关系。前置条件ECU 处于扩展会话。测试步骤发送 0x10 01 切换到默认会话再发送 0x3E 03 切换扩展会话再发送 0x10 03 切换扩展会话。预期结果所有切换按请求顺序执行正响应正常。判定标准最终状态与最后一次请求一致。5.2 安全用例TC_3E_040不同会话下安全解锁状态测试目的验证会话切换后安全解锁状态是否保留。前置条件ECU 处于扩展会话。测试步骤0x27 01/02 完成安全解锁切换默认会话再切换回扩展会话发送需要安全解锁的 0x2E 写入请求。预期结果按 ECU 设计决定多数 ECU 在离开扩展会话后取消安全解锁状态。判定标准与安全规范一致。TC_3E_041编程会话下安全解锁失败测试目的验证安全解锁失败是否阻止编程会话操作。前置条件ECU 处于扩展会话。测试步骤发送错误密钥的 0x27 05接着发送 0x3E 02 进入编程会话。预期结果若进入编程会话需要安全解锁应负响应 0x22 或 0x33。判定标准非授权刷写被阻止。6. 测试执行与 testbuddy 自动化用例生成6.1 手工执行流程0x3E 服务手工测试常用 CANoe 或 PCAN操作流程加载 DBC。建立诊断通道配置物理寻址请求 ID 和响应 ID。使用诊断控制台或 CAPL 脚本发送 0x3E 请求。监听响应记录响应时间和状态。以 CANoe 为例发送 0x3E 01 的 CAPL 代码片段如下// 发送 0x3E 01 默认会话请求 diagRequest SessionControl_Default req; req.SessionType 1; diagSendRequest(req);如果需要自定义 0x3E 原始帧也可以直接用 CAN 报文发送但要注意请求 ID 和发送类型// 物理请求 0x7E00x3E 01 canTx 0x7E0 0x02 0x3E 0x01 0x00 0x00 0x00 0x00 0x00 0x006.2 testbuddy 用例生成思路testbuddy 这类工具的价值不只是管理用例更重要的是把需求、设计、用例、执行结果、缺陷串联起来。针对 0x3E 服务用 testbuddy 辅助用例生成可以按下面的步骤做第一步在 testbuddy 中创建 UDS 诊断测试模板第二步通过 SID/子功能参数化生成基础用例矩阵。例如定义“会话切换”模板参数为初始会话和目的会话自动展开出默认到扩展、默认到编程、扩展到默认等组合。第三步结合状态机配置补充异常分支。比如 testbuddy 的策略模式允许针对每个正响应路径增加负响应分支不会重复描述步骤。第四步导出用例到自动化执行平台或者通过脚本批量导入。6.3 用 Python 扩展自动化用例如果测试环境本身有诊断自动化框架可以用 Python 编写 0x3E 服务用例脚本。以下是一个逻辑示意实际底层通信需要替换为 CAN 库接口import time class SessionControlTester: def __init__(self, can_channel, request_id0x7E0, response_id0x7E8): self.can_channel can_channel self.request_id request_id self.response_id response_id def send_3e(self, sub_function): # 构造 0x3E 请求帧 request [0x02, 0x3E, sub_function] # 通过 can_channel 发送 CAN 报文 # self.can_channel.send(self.request_id, request) print(fSend 0x3E {sub_function:02X}) def switch_to_default(self): resp self.send_3e(0x01) return resp 0x7E def switch_to_extension(self): resp self.send_3e(0x03) return resp 0x7E def run_s3_timeout_test(self, s3_time5.0): self.switch_to_extension() time.sleep(s3_time 1) # 发送非默认会话下的 DID 读取请求验证是否回到默认会话 # read_did(0xF190) print(S3 timeout test done)这段代码展示的是用例脚本的结构思路。实际执行时需要把can_channel替换成 CANoe COM 接口、python-can 库或诊断仪 SDK响应 ID 和 DBC 解析也需要按项目配置。7. 0x3E 服务用例执行结果判定7.1 判定正向响应0x3E 正响应为 0x7E 子功能比如发送 0x3E 03正响应是 0x7E 03。接收到的第一个字节如果等于响应 SID说明 ECU 已接受会话切换。这里要注意正响应不代表 ECU 立即切换成功有些实现会先返回正响应再执行内部状态切换最稳妥的方式是在正响应后继续发送一个会话相关 DID 读取请求来验证状态。7.2 判定负响应0x3E 负响应格式为0x7F [0x3E] [NRC]常见 NRCNRC含义典型场景0x12子功能不支持发送非法子功能0x22条件不满足直接进入编程会话被禁止0x31请求超出范围子功能值在范围外0x33安全访问拒绝需要安全解锁才能切换如果负响应值为 0x22重点检查前置条件是否满足。比如是否先进入了扩展会话是否完成了安全解锁。7.3 判定时序指标0x3E 服务还有几个默认时间参数需要关注P2服务器响应时间常见 50ms 以内。P2*延长响应时间一般 5000ms仅用于下载/上传请求或长操作。S3非默认会话超时时间常见 5000ms部分 ECU 会定义 3s。测试时通过 CANoe 的 Trace 窗口统计请求发送到响应接收的时间间隔。0x3E 服务属于短请求若响应时间超过 P2 但未超过 P2*服务端应发送 0x7F 0x3E 0x78 先行响应然后才给出最终结果。8. 0x3E 服务测试常见问题与排查方法问题现象可能原因排查方式解决方案发送 0x3E 03 无响应请求 ID 错误、ECU 不在线、波特率不匹配检查 CAN 通信状态查看总线是否有错误帧确认 DBC 中的节点地址和诊断请求 ID0x3E 正响应后 0x22 读取仍失败会话切换未真正完成或 DID 权限不匹配增加延时后再读取 DID在正响应后加 200ms 等待再发送后续请求非默认会话超时未回退S3 超时时间配置过长或功能未激活查看 DTC/事件日志确认 S3 定时器按设计文档确认 S3 时间必要时用诊断仪读取会话状态编程会话切换返回 0x22前置条件未满足检查是否先进入扩展会话是否完成安全解锁按规范执行完整前置流程大量连续切换后 ECU Bus Off高频率请求导致总线负载过高查看 CANoe 总线统计增加请求间隔避免 10ms 内连续请求testbuddy 导入用例失败用例字段与模板不匹配检查自定义字段名称查看导入日志统一字段映射重新导入实际项目里0x3E 服务测试最常见的“坑”是时序问题。尤其是扩展会话下的 S3 超时如果测试代码在发送 0x3E 03 后没有周期性发送 0x3E 01 保持会话那么测试过程中非默认会话可能已经悄悄回到默认会话导致后续所有用例全部失败。更稳妥的方式是每执行一个用例前都先检查当前会话状态再按测试目的切换。9. 0x3E 服务测试环境与资源占用0x3E 服务测试对硬件要求不高常用环境包括组件推荐配置总线工具CANoe、CANalyzer、PCAN-USB、ValueCAN软件CANoe 12.0 及以上、vTESTstudio、testbuddy诊断协议ISO 14229-1、ISO 15765-2DoCAN数据库DBC、CDD、ODX操作系统Windows 10/11 x64最低资源4G 内存、20G 磁盘空间如果只做 0x3E 服务单一功能验证用 PCAN 加 python-can 也可以成本更低。大量用例批量执行时建议用 CANoe CAPL 或 vTESTstudio能直接生成测试报告。批量执行时注意每个测试用例之间要清空诊断仪会话状态避免上一个用例的非默认会话状态影响下一个用例。以 testbuddy 批量执行模式为例建议每条用例前增加“复位 ECU 或等待回默认会话”的前置动作。如果 ECU 支持功能寻址复位则可在整批用例开始前统一复位。10. testbuddy 与诊断测试用例资产管理10.1 用例模板化testbuddy 支持用例模板和参数化扩展。0x3E 服务的所有用例可以抽象成一个模板参数取值初始会话defaultSession, extendedSession, programmingSession目标会话defaultSession, extendedSession, programmingSession子功能0x01, 0x02, 0x03是否需要安全解锁true, false是否检查 S3 超时true, false通过模板参数化能自动展开出全组合的用例矩阵。凡是项目中实际不支持的组合可以通过过滤规则排除最终落地成为稳定用例集。10.2 用例与需求追溯0x3E 服务的每条用例都应该关联系统需求。比如需求 ID: SYS_DIAG_SESSION_001描述“ECU 上电进入默认会话”。需求 ID: SYS_DIAG_SESSION_005描述“非默认会话应支持 S3 超时回退”。在 testbuddy 里建立需求与用例的关联关系后执行结果可以自动生成需求覆盖率报告。这个能力对 A-SPICE 和功能安全流程审计很有价值。10.3 自动化执行闭环0x3E 服务用例自动化的完整闭环包括从 testbuddy 导出用例集。通过脚本转换成 CAPL 测试工程或 Python 脚本。执行测试并采集 Trace 和响应数据。将结果回填到 testbuddy。生成测试报告和缺陷单。具体接口取决于测试平台和 testbuddy 版本但整体思路都是用例定义和执行结果分离避免在自动化工程里重复开发用例描述。11. 0x3E 服务测试最佳实践第一先把会话状态检查做成公共函数。无论在 CANoe 还是 Python 脚本里都要有一个get_current_session()函数每次测试开始前调用避免用例之间状态串扰。第二区分物理请求和功能请求。0x3E 服务通常使用物理寻址功能寻址时响应可能不回复或者延迟回复按诊断规范确定。第三非默认会话测试一定要关注 S3 超时时间。测试报告里必须记录测试开始时间、最后请求时间、回退时间以便精确定位 S3 参数是否满足设计。第四批量执行时把用例间隔设置为大于 S3 超时时间或者每个用例后主动发送 0x3E 01 回到默认会话。这两种方式中主动回默认会话更可靠等待超时会让批量执行时间拉长。第五关于版权、安全和数据合规。0x3E 服务测试涉及 ECU 数据和诊断访问权限控制测试过程中可能读取到车辆 VIN、标定数据、软硬件版本等信息。这些数据只能用于开发测试和售后诊断不能用于未授权场景。涉及安全访问时所有密钥和绕过操作必须经过整车厂授权测试报告中也应避免明文记录敏感安全信息。12. 总结与后续方向0x3E 服务虽然协议简单但从需求拆解到用例落地的完整过程并不简单。真正值得验证的功能点是默认、扩展、编程会话之间所有合法与非法迁移路径非默认会话下的访问权限S3 超时回退以及安全解锁与会话切换的组合场景。建议首次测试时先跑 TC_3E_001、TC_3E_002、TC_3E_010、TC_3E_030 这四类用例能快速判断 ECU 的 0x3E 基础实现是否符合协议。最容易踩的坑是会话状态串扰和 S3 超时设置。测试框架没有状态检查、用例之间不重置会话会导致批量执行结果完全失真。后续扩展方向可以包括把 0x3E 服务用例接入完整 UDS 自动化测试套件结合 vTESTstudio 生成一致性测试报告在 testbuddy 里按需求维度统计 0x3E 服务覆盖率 UDS 0x3E服务用例设计与testbuddy自动化测试落地
网络诊断 0x3E 服务用例设计从需求拆解到 testbuddy 自动化落地做网络诊断和 UDS 测试的同学对 0x3E 服务应该都不陌生。这个服务负责会话切换是整个诊断流程里被调用次数最多的服务之一。很多刚入门的测试工程师会问0x3E 服务不就是一个切换会话的指令吗能有多少测试点实际上0x3E 会话控制服务牵扯到会话状态机、会话切换时序、P2/P2* 定时参数、非默认会话访问权限、网络异常恢复等多个维度单靠“发一条指令看响应”这种粗放式验证根本覆盖不了实车场景里的各种问题。这次我们就从需求拆解出发把 0x3E 服务的测试用例完整设计一遍再结合 testbuddy 这类用例生成和管理工具把手工编写的用例转成可维护、可回溯的自动化用例资产。文章内容分为三块第一0x3E 服务的协议逻辑和测试需求分析第二按功能、时序、异常、安全四个维度设计用例第三如何用 testbuddy 辅助生成用例、组织测试步骤并与诊断自动化工具链打通。1. 0x3E 服务核心能力速览能力项说明服务名称Session Control诊断会话控制SID0x3E子功能0x01 默认会话0x02 编程会话0x03 扩展会话0x04 安全扩展会话按项目定义主要作用切换 ECU 诊断会话控制会话超时与访问权限响应方式正响应 0x7E负响应 0x7F关键时序P2、P2* 定时参数非默认会话 S3 超时回到默认会话测试重点会话状态机、子功能有效性、切换时序、权限隔离、异常恢复常用工具CANoe、CANalyzer、PCAN、迪卡侬诊断仪、testbuddy、Vector vTESTstudio是否支持自动化支持可编程实现全流程自动化验证适合场景ECU 开发测试、诊断协议一致性测试、产线诊断、售后诊断流程验证0x3E 服务的核心逻辑不复杂但测试覆盖点非常多。下面按“需求拆解 - 场景提取 - 用例设计 - 自动化执行”的顺序展开读者可以把它当作一套可直接复用的测试用例设计模板。2. 0x3E 服务协议逻辑与测试需求拆解在设计用例之前先确认 0x3E 服务在 UDS 协议里怎么工作。UDSISO 14229定义 0x3E 服务用于客户端请求切换 ECU 的诊断会话。ECU 上电后默认进入默认会话通过 0x3E 子功能可以切换到编程会话或扩展会话非默认会话通常有 S3 超时时间超过时间没有收到后续请求ECU 会回到默认会话。从测试需求拆解角度0x3E 服务可以按五个层面展开功能需求会话切换是否正确子功能是否有效正响应/负响应是否符合协议。时序需求S3 超时、P2/P2* 定时器、切换响应时间。状态需求默认会话、编程会话、扩展会话之间的状态迁移是否合法。安全需求非默认会话下对 0x27 安全解锁、0x22 读取、0x2E 写入等服务的访问控制是否正确。异常需求通信中断、总线休眠、非法子功能、连续切换、重复切换时的行为。真实项目中0x3E 服务最容易出问题的点包括非默认会话超时后未回到默认会话、扩展会话下无法执行 0x2E 写入、编程会话切换失败、P2* 延长响应时序超过诊断仪等待时间。这些都应该作为重点用例覆盖。结合最新热词中提到的 testbuddy 用例生成工具层面需要考虑的是需求条目不完整时通过平台现有的 UDS 服务模板生成基础用例再用迁移图或状态机补充分支场景最后把补充用例固化到测试规范中。3. 0x3E 服务用例设计方法3.1 基于需求分类的用例框架0x3E 服务用例建议按三级目录管理0x3E_SessionControl/ ├── 01_DefaultSession/ │ ├── TC_3E_001_默认会话下切换默认会话 │ ├── TC_3E_002_默认会话下切换扩展会话 │ └── TC_3E_003_默认会话下切换编程会话 ├── 02_ExtendedSession/ │ ├── TC_3E_010_扩展会话身份切换 │ ├── TC_3E_011_扩展会话S3超时回退 │ └── TC_3E_012_扩展会话访问0x2E写入 ├── 03_ProgrammingSession/ │ ├── TC_3E_020_编程会话身份切换 │ └── TC_3E_021_编程会话下刷写前置条件 ├── 04_AbnormalSequence/ │ ├── TC_3E_030_非法子功能 │ ├── TC_3E_031_连续切换会话 │ └── TC_3E_032_通信中断后会话状态 └── 05_SecurityAccess/ ├── TC_3E_040_扩展会话与安全解锁 └── TC_3E_041_不同会话下安全状态保留这种目录结构的好处是用例编号清晰后续追踪需求覆盖率和失败用例分布时可以按目录聚合统计也可以直接在 testbuddy 里按模块导入。3.2 用例设计要素每个 0x3E 用例至少包含以下字段字段说明用例编号TC_3E_XXX唯一标识测试目的说明验证的协议行为前置条件ECU 上电状态、会话状态、总线条件测试步骤按顺序发送的诊断请求和等待时间预期结果正响应/负响应、状态切换、时间参数实际结果执行后自动或手动填写判定标准Pass/Fail 的明确条件关联需求关联到系统需求条目 ID风险等级高/中/低决定测试优先级testbuddy 之类的用例管理平台通常支持自定义字段这组字段建议直接映射到平台的用例模板里后续生成测试报告和追溯矩阵很方便。3.3 状态迁移法生成用例0x3E 服务本质是一个状态机默认、扩展、编程三个会话之间不是任意切换都合法。各 ECU 对编程会话的进入条件定义不同很多控制器要求先进入扩展会话并完成安全解锁之后才能进入编程会话。通过状态迁移图可以补充出以下边界用例默认会话直接进入编程会话按 ECU 设计决定是否允许。扩展会话进入编程会话常规合法路径。编程会话进入扩展会话通常允许但要注意退出编程会话后是否保留安全解锁状态。非默认会话下重复进入同一会话应返回正响应但部分 ECU 会返回 0x22 条件不满足。状态迁移法尤其适合用 testbuddy 生成因为 testbuddy 支持步骤组合和分支逻辑。把每个会话状态定义成一个前置条件把 0x3E 子功能定义成动作自动展开后就能得到覆盖矩阵。4. 0x3E 服务功能测试用例明细4.1 默认会话切换测试TC_3E_001默认会话下切换到默认会话测试目的验证重复进入当前会话是否正常处理。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 01。预期结果正响应 0x7E 01ECU 保持默认会话。判定标准响应 SID 正确无负响应。TC_3E_002默认会话下切换到扩展会话测试目的验证默认会话到扩展会话基础切换路径。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 03。预期结果正响应 0x7E 03ECU 进入扩展会话。判定标准后续发送 0x22 读取扩展会话下才允许访问的 DID 能成功。TC_3E_003默认会话下切换到编程会话测试目的验证不同 ECU 对编程会话进入条件。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 02。预期结果按 ECU 设计可能正响应或负响应。若设计允许ECU 进入编程会话若不允许负响应 NRC 0x22。判定标准必须与诊断规范一致。4.2 非默认会话切换测试TC_3E_010扩展会话保持与超时回退测试目的验证 S3 超时后是否回到默认会话。前置条件ECU 处于扩展会话。测试步骤发送 0x3E 03 进入扩展会话等待超过 S3 时间以 AUTOSAR 配置为准常见 5s 或 10s再发送 0x22 读取扩展会话 DID。预期结果超时后 ECU 自动回到默认会话0x22 返回负响应 0x7F 22 0x7E 或 0x51。判定标准状态切换时间和回退行为符合设计要求。TC_3E_011非默认会话下发送 0x3E 保持会话测试目的验证周期性发送 0x3E 01 能否防止非默认会话超时。前置条件ECU 处于扩展会话。测试步骤进入扩展会话后在 S3 超时时间内周期性发送 0x3E 01例如每 2s 发送一次持续超过 S3 时间。预期结果ECU 保持在扩展会话不会回到默认会话。判定标准整个保持期间 0x22 扩展 DID 可正常读取。TC_3E_012非默认会话下写入访问控制测试目的验证扩展会话下 0x2E 写入权限。前置条件ECU 处于扩展会话且未安全解锁。测试步骤发送 0x2E 写入一个需要扩展会话权限的 DID。预期结果若该 DID 仅要求扩展会话写入成功若还要求安全访问负响应 0x33 安全访问拒绝。判定标准NRC 值与 DID 权限定义一致。4.3 编程会话刷写前置条件测试TC_3E_020进入编程会话测试目的验证完整刷写流程的会话切换部分。前置条件ECU 处于默认会话。测试步骤0x10 03 进入扩展会话 - 0x27 01/02 安全解锁 - 0x3E 02 进入编程会话。预期结果每一步正响应最终进入编程会话。判定标准刷写前置流程完整执行。TC_3E_021编程会话下重启保持测试目的验证编程会话下 ECU 重启后的会话状态。前置条件ECU 处于编程会话。测试步骤发送 0x3E 02 进入编程会话执行 ECU 复位等待重启完成后发送 0x22 读取会话状态。预期结果ECU 重启后回到默认会话。判定标准重启后无法直接执行编程会话专属功能。5. 0x3E 服务异常与安全用例设计5.1 异常用例TC_3E_030非法子功能测试目的验证错误子功能处理。前置条件ECU 上电处于默认会话。测试步骤发送 0x3E 00 或 0x3E FF。预期结果负响应 0x7F 3E 12子功能不支持。判定标准NRC 必须为 0x12SNS。TC_3E_031连续快速切换会话测试目的验证 ECU 对高频率会话切换的稳定性。前置条件ECU 上电。测试步骤循环发送 0x3E 01、0x3E 03、0x3E 02每两条之间间隔 10ms持续 100 次。预期结果无总线错误响应正确最终会话状态符合最后一次切换。判定标准无错误帧ECU 不死机不进入 Bus Off。TC_3E_032通信中断后会话保持测试目的验证总线断开后非默认会话是否按 S3 超时回退。前置条件ECU 处于扩展会话。测试步骤进入扩展会话后断开总线或关闭诊断仪等待超过 S3 时间后重新连接。预期结果重新连接后 ECU 处于默认会话。判定标准回退行为正确重新进入扩展会话需要重新发送 0x3E 03。TC_3E_0330x3E 请求和 0x10 请求交叉测试目的验证 0x3E 与 0x10 诊断会话控制之间的关系。前置条件ECU 处于扩展会话。测试步骤发送 0x10 01 切换到默认会话再发送 0x3E 03 切换扩展会话再发送 0x10 03 切换扩展会话。预期结果所有切换按请求顺序执行正响应正常。判定标准最终状态与最后一次请求一致。5.2 安全用例TC_3E_040不同会话下安全解锁状态测试目的验证会话切换后安全解锁状态是否保留。前置条件ECU 处于扩展会话。测试步骤0x27 01/02 完成安全解锁切换默认会话再切换回扩展会话发送需要安全解锁的 0x2E 写入请求。预期结果按 ECU 设计决定多数 ECU 在离开扩展会话后取消安全解锁状态。判定标准与安全规范一致。TC_3E_041编程会话下安全解锁失败测试目的验证安全解锁失败是否阻止编程会话操作。前置条件ECU 处于扩展会话。测试步骤发送错误密钥的 0x27 05接着发送 0x3E 02 进入编程会话。预期结果若进入编程会话需要安全解锁应负响应 0x22 或 0x33。判定标准非授权刷写被阻止。6. 测试执行与 testbuddy 自动化用例生成6.1 手工执行流程0x3E 服务手工测试常用 CANoe 或 PCAN操作流程加载 DBC。建立诊断通道配置物理寻址请求 ID 和响应 ID。使用诊断控制台或 CAPL 脚本发送 0x3E 请求。监听响应记录响应时间和状态。以 CANoe 为例发送 0x3E 01 的 CAPL 代码片段如下// 发送 0x3E 01 默认会话请求 diagRequest SessionControl_Default req; req.SessionType 1; diagSendRequest(req);如果需要自定义 0x3E 原始帧也可以直接用 CAN 报文发送但要注意请求 ID 和发送类型// 物理请求 0x7E00x3E 01 canTx 0x7E0 0x02 0x3E 0x01 0x00 0x00 0x00 0x00 0x00 0x006.2 testbuddy 用例生成思路testbuddy 这类工具的价值不只是管理用例更重要的是把需求、设计、用例、执行结果、缺陷串联起来。针对 0x3E 服务用 testbuddy 辅助用例生成可以按下面的步骤做第一步在 testbuddy 中创建 UDS 诊断测试模板第二步通过 SID/子功能参数化生成基础用例矩阵。例如定义“会话切换”模板参数为初始会话和目的会话自动展开出默认到扩展、默认到编程、扩展到默认等组合。第三步结合状态机配置补充异常分支。比如 testbuddy 的策略模式允许针对每个正响应路径增加负响应分支不会重复描述步骤。第四步导出用例到自动化执行平台或者通过脚本批量导入。6.3 用 Python 扩展自动化用例如果测试环境本身有诊断自动化框架可以用 Python 编写 0x3E 服务用例脚本。以下是一个逻辑示意实际底层通信需要替换为 CAN 库接口import time class SessionControlTester: def __init__(self, can_channel, request_id0x7E0, response_id0x7E8): self.can_channel can_channel self.request_id request_id self.response_id response_id def send_3e(self, sub_function): # 构造 0x3E 请求帧 request [0x02, 0x3E, sub_function] # 通过 can_channel 发送 CAN 报文 # self.can_channel.send(self.request_id, request) print(fSend 0x3E {sub_function:02X}) def switch_to_default(self): resp self.send_3e(0x01) return resp 0x7E def switch_to_extension(self): resp self.send_3e(0x03) return resp 0x7E def run_s3_timeout_test(self, s3_time5.0): self.switch_to_extension() time.sleep(s3_time 1) # 发送非默认会话下的 DID 读取请求验证是否回到默认会话 # read_did(0xF190) print(S3 timeout test done)这段代码展示的是用例脚本的结构思路。实际执行时需要把can_channel替换成 CANoe COM 接口、python-can 库或诊断仪 SDK响应 ID 和 DBC 解析也需要按项目配置。7. 0x3E 服务用例执行结果判定7.1 判定正向响应0x3E 正响应为 0x7E 子功能比如发送 0x3E 03正响应是 0x7E 03。接收到的第一个字节如果等于响应 SID说明 ECU 已接受会话切换。这里要注意正响应不代表 ECU 立即切换成功有些实现会先返回正响应再执行内部状态切换最稳妥的方式是在正响应后继续发送一个会话相关 DID 读取请求来验证状态。7.2 判定负响应0x3E 负响应格式为0x7F [0x3E] [NRC]常见 NRCNRC含义典型场景0x12子功能不支持发送非法子功能0x22条件不满足直接进入编程会话被禁止0x31请求超出范围子功能值在范围外0x33安全访问拒绝需要安全解锁才能切换如果负响应值为 0x22重点检查前置条件是否满足。比如是否先进入了扩展会话是否完成了安全解锁。7.3 判定时序指标0x3E 服务还有几个默认时间参数需要关注P2服务器响应时间常见 50ms 以内。P2*延长响应时间一般 5000ms仅用于下载/上传请求或长操作。S3非默认会话超时时间常见 5000ms部分 ECU 会定义 3s。测试时通过 CANoe 的 Trace 窗口统计请求发送到响应接收的时间间隔。0x3E 服务属于短请求若响应时间超过 P2 但未超过 P2*服务端应发送 0x7F 0x3E 0x78 先行响应然后才给出最终结果。8. 0x3E 服务测试常见问题与排查方法问题现象可能原因排查方式解决方案发送 0x3E 03 无响应请求 ID 错误、ECU 不在线、波特率不匹配检查 CAN 通信状态查看总线是否有错误帧确认 DBC 中的节点地址和诊断请求 ID0x3E 正响应后 0x22 读取仍失败会话切换未真正完成或 DID 权限不匹配增加延时后再读取 DID在正响应后加 200ms 等待再发送后续请求非默认会话超时未回退S3 超时时间配置过长或功能未激活查看 DTC/事件日志确认 S3 定时器按设计文档确认 S3 时间必要时用诊断仪读取会话状态编程会话切换返回 0x22前置条件未满足检查是否先进入扩展会话是否完成安全解锁按规范执行完整前置流程大量连续切换后 ECU Bus Off高频率请求导致总线负载过高查看 CANoe 总线统计增加请求间隔避免 10ms 内连续请求testbuddy 导入用例失败用例字段与模板不匹配检查自定义字段名称查看导入日志统一字段映射重新导入实际项目里0x3E 服务测试最常见的“坑”是时序问题。尤其是扩展会话下的 S3 超时如果测试代码在发送 0x3E 03 后没有周期性发送 0x3E 01 保持会话那么测试过程中非默认会话可能已经悄悄回到默认会话导致后续所有用例全部失败。更稳妥的方式是每执行一个用例前都先检查当前会话状态再按测试目的切换。9. 0x3E 服务测试环境与资源占用0x3E 服务测试对硬件要求不高常用环境包括组件推荐配置总线工具CANoe、CANalyzer、PCAN-USB、ValueCAN软件CANoe 12.0 及以上、vTESTstudio、testbuddy诊断协议ISO 14229-1、ISO 15765-2DoCAN数据库DBC、CDD、ODX操作系统Windows 10/11 x64最低资源4G 内存、20G 磁盘空间如果只做 0x3E 服务单一功能验证用 PCAN 加 python-can 也可以成本更低。大量用例批量执行时建议用 CANoe CAPL 或 vTESTstudio能直接生成测试报告。批量执行时注意每个测试用例之间要清空诊断仪会话状态避免上一个用例的非默认会话状态影响下一个用例。以 testbuddy 批量执行模式为例建议每条用例前增加“复位 ECU 或等待回默认会话”的前置动作。如果 ECU 支持功能寻址复位则可在整批用例开始前统一复位。10. testbuddy 与诊断测试用例资产管理10.1 用例模板化testbuddy 支持用例模板和参数化扩展。0x3E 服务的所有用例可以抽象成一个模板参数取值初始会话defaultSession, extendedSession, programmingSession目标会话defaultSession, extendedSession, programmingSession子功能0x01, 0x02, 0x03是否需要安全解锁true, false是否检查 S3 超时true, false通过模板参数化能自动展开出全组合的用例矩阵。凡是项目中实际不支持的组合可以通过过滤规则排除最终落地成为稳定用例集。10.2 用例与需求追溯0x3E 服务的每条用例都应该关联系统需求。比如需求 ID: SYS_DIAG_SESSION_001描述“ECU 上电进入默认会话”。需求 ID: SYS_DIAG_SESSION_005描述“非默认会话应支持 S3 超时回退”。在 testbuddy 里建立需求与用例的关联关系后执行结果可以自动生成需求覆盖率报告。这个能力对 A-SPICE 和功能安全流程审计很有价值。10.3 自动化执行闭环0x3E 服务用例自动化的完整闭环包括从 testbuddy 导出用例集。通过脚本转换成 CAPL 测试工程或 Python 脚本。执行测试并采集 Trace 和响应数据。将结果回填到 testbuddy。生成测试报告和缺陷单。具体接口取决于测试平台和 testbuddy 版本但整体思路都是用例定义和执行结果分离避免在自动化工程里重复开发用例描述。11. 0x3E 服务测试最佳实践第一先把会话状态检查做成公共函数。无论在 CANoe 还是 Python 脚本里都要有一个get_current_session()函数每次测试开始前调用避免用例之间状态串扰。第二区分物理请求和功能请求。0x3E 服务通常使用物理寻址功能寻址时响应可能不回复或者延迟回复按诊断规范确定。第三非默认会话测试一定要关注 S3 超时时间。测试报告里必须记录测试开始时间、最后请求时间、回退时间以便精确定位 S3 参数是否满足设计。第四批量执行时把用例间隔设置为大于 S3 超时时间或者每个用例后主动发送 0x3E 01 回到默认会话。这两种方式中主动回默认会话更可靠等待超时会让批量执行时间拉长。第五关于版权、安全和数据合规。0x3E 服务测试涉及 ECU 数据和诊断访问权限控制测试过程中可能读取到车辆 VIN、标定数据、软硬件版本等信息。这些数据只能用于开发测试和售后诊断不能用于未授权场景。涉及安全访问时所有密钥和绕过操作必须经过整车厂授权测试报告中也应避免明文记录敏感安全信息。12. 总结与后续方向0x3E 服务虽然协议简单但从需求拆解到用例落地的完整过程并不简单。真正值得验证的功能点是默认、扩展、编程会话之间所有合法与非法迁移路径非默认会话下的访问权限S3 超时回退以及安全解锁与会话切换的组合场景。建议首次测试时先跑 TC_3E_001、TC_3E_002、TC_3E_010、TC_3E_030 这四类用例能快速判断 ECU 的 0x3E 基础实现是否符合协议。最容易踩的坑是会话状态串扰和 S3 超时设置。测试框架没有状态检查、用例之间不重置会话会导致批量执行结果完全失真。后续扩展方向可以包括把 0x3E 服务用例接入完整 UDS 自动化测试套件结合 vTESTstudio 生成一致性测试报告在 testbuddy 里按需求维度统计 0x3E 服务覆盖率