0x11服务是UDS统一诊断服务里的EcuReset服务核心作用是诊断仪向ECU发送复位请求让ECU按指定方式重启恢复。很多测试工程师接到“根据需求设计用例”这个任务时习惯性直接套模板结果漏掉子功能支持范围、会话限制、安全等级、功能寻址行为和复位后恢复时间这些关键点。下面就把0x11服务按需求设计用例的完整流程拆一遍包括需求拆解、覆盖矩阵、正常异常用例、时序与并发边界以及执行判定标准。如果你刚开始接触诊断测试或者准备从手动测试转向用例设计这套方法可以直接用。另外最近常有人搜“网络诊断显示dns”这里先给结论DNS和0x11服务不在同一层诊断界面上出现DNS提示通常是上位机网络解析问题不是ECU复位服务问题后面会单独拆开讲。1. 0x11服务到底是什么先搞清楚它属于哪一层1.1 UDS诊断服务框架中的0x11UDS也就是统一诊断服务是汽车诊断里常用的应用层协议。0x11服务是这个协议里的ECU复位服务服务名是EcuReset。它的功能很直接就是让诊断仪向ECU发送一个带复位类型的请求ECU收到后执行对应的复位动作并在条件允许时返回应答。这里要特别注意0x11不是一个物理按键操作。它通过总线报文下发常见承载网络是CAN、CAN FD在支持以太网诊断时会走DoIP。ECU收到请求后会按照请求里的子功能选择复位方式。这个动作属于应用层和DNS、IP地址解析没有直接关系。诊断仪能不能找到ECU取决于总线配置和网络层0x11服务能不能被正确执行取决于ECU的应用层实现。所以设计用例之前别急着写测试步骤。先把0x11服务放在整条链路上看诊断仪发报文传输层保证报文到达应用层解析SID和子功能ECU执行复位再恢复通信。中间任何一层有问题用例表现出来的现象都会不一样。1.2 0x11服务常见的子功能0x11服务必须带子功能字节。常见子功能包括0x01硬复位相当于ECU直接重新上电或重启主控复位最彻底。0x02钥匙开关复位模拟点火开关断开再闭合常用于需要电源状态切换的场景。0x03软复位不切断电源只重启应用软件或部分逻辑。部分项目和厂商还会定义快速复位、休眠唤醒复位或者自定义子功能具体以诊断规范为准。子功能字节里的最高位是抑制肯定响应位。比如0x01表示硬复位且需要返回肯定响应0x81表示硬复位但不要返回肯定响应。设计用例时这个位很容易被漏掉后面我会单独展开。1.3 设计用例之前要先明确哪些需求要素一份合格的0x11服务需求至少应该包含下面这些信息支持的子功能列表以及每个子功能对应的复位效果。支持的会话列表比如只在默认会话或扩展会话下支持。是否要求安全解锁解锁等级是什么。支持物理寻址还是功能寻址还是两者都不允许。是否支持抑制肯定响应。复位完成后ECU恢复到哪个会话是否需要重新发送诊断会话控制请求。复位执行时间、最大响应时间、恢复时间。复位期间重复收到请求时应该怎么处理。如果需求文档里没有写清楚这些内容用例很难设计完整。我的经验是先把需求要素列成一张表再对照表格逐项补用例。否则很容易出现“正常复位能通过但功能寻址或者安全访问的异常用例漏掉”的情况。2. 根据需求提取用例点比直接写测试步骤更重要2.1 需求拆解从一句描述拆出可测条件拿到需求后不要直接写“发送11 01返回51 01”。那只是正常路径。真正的用例设计要从一句需求描述里拆出多个可测条件。例如这样一条需求支持硬复位复位后回到默认会话安全等级要求低仅支持物理寻址。拆出来的可测条件包括发送0x11 0x01后能否收到肯定响应。ECU是否真的发生复位复位后是否回到默认会话。默认会话中是否可以执行硬复位。扩展会话中是否可以执行硬复位。在安全锁定状态下执行是否会被拒绝。使用功能寻址发送0x11 0x01ECU是否不响应或者按规范返回否定响应。发送不支持的子功能是否返回对应否定响应码。请求长度错误是否返回否定响应码0x13。复位期间发送会话控制请求响应顺序是否正确。复位后多长时间内可以重新通信重新进入诊断会话。这些条件有的属于正常用例有的属于异常用例有的是时序有的是总线行为。把它们列出来才算完成了需求分析。只盯着正常路径写用例评审的时候大概率会被打回来。2.2 用需求覆盖矩阵把功能、异常、时序、总线行为串起来用例设计过程中我习惯用覆盖矩阵检查漏洞。矩阵的每一行是一条需求或功能点每一列是一种测试类型。功能测试请求和响应的正确性复位动作是否真实发生。异常测试子功能不支持、长度错误、会话错误、安全访问失败。边界测试子功能边界值、抑制位开关、超时阈值。时序测试复位执行时间、恢复时间、重复请求、并发请求。总线行为测试物理寻址、功能寻址、总线负载下的表现。状态恢复测试复位后默认会话、DTC状态、安全状态、通信状态。覆盖矩阵不需要写得很复杂在Excel里列出需求项和测试类型每有一个交叉点就补一条用例。这样能避免漏测也能让评审人一眼看出用例的覆盖逻辑。2.3 具体用例点示例下面是一个简化例子假设某ECU支持0x11的0x01子功能物理寻址支持在默认会话和扩展会话中执行需要安全解锁后才允许。这个条件下最少要覆盖这些用例用例点请求内容预期结果正常硬复位11 01返回51 01ECU重启未解锁发送复位11 01返回7F 11 33扩展会话中复位先进入扩展会话再发送11 01允许复位或按需求处理不支持的子功能11 05返回7F 11 12请求长度错误11 01 00返回7F 11 13功能寻址发送功能寻址11 01无响应或按需求处理这只是一个示例真实项目的需求不同预期结果也会不同。重点是先把用例点列出来再转化为标准用例。用例点列不全后面写得再规范也没用。3. 用例设计实操从正常流程到边界异常逐层展开3.1 正常请求响应用例第一层是正常流程。最基础的用例是发送有效的0x11请求收到肯定响应并确认实际复位动作发生。用硬复位举例步骤大概是确认ECU处于支持的诊断会话。确认安全解锁状态满足要求。用物理寻址发送0x11 0x01。在超时时间内接收响应。检查响应SID是否为0x51子功能是否为0x01。检查ECU是否真的发生复位例如通过供电电流变化、重新上线报文、应用日志确认。等待复位完成检查ECU是否回到预期会话。这里有一个容易犯错的地方很多测试员看到收到0x51就认为通过。但0x51只代表ECU接受了请求不代表复位动作一定成功。比如ECU内部有一个复位标志没有清掉或者复位流程在等待某个状态可能过一段时间才复位甚至复位失败。所以必须有“复位结果确认”这一步不能只看响应。注意收到0x51只代表ECU接受请求不等于复位动作一定成功。用例预期结果里必须包含可观察的复位动作。3.2 子功能参数与长度校验用例第二层是参数校验。UDS对长度有严格校验0x11服务请求长度通常是SID加子功能共2字节。超过或少于这个长度通常返回NRC 0x13也就是incorrectMessageLengthOrInvalidFormat。需要覆盖的输入包括只发送0x11缺少子功能字节。发送0x11 0x01 0x00多了一个字节。子功能取0x00看是否为保留值。子功能取边界值比如保留区间的值。子功能设置为0x81验证抑制肯定响应位。子功能设置为0xFF通常视为不支持。设计这些用例时不要贪多。关键先确认需求里定义了哪些子功能然后把不支持的枚举值、保留值、边界值各选一两个覆盖即可。重点是验证ECU对非法输入的处理是否一致不能出现有些异常返回NRC 0x12有些异常直接无响应的情况。3.3 会话、安全等级和权限控制用例第三层是权限控制。0x11服务在很多ECU上不是无条件可用的。常见限制有仅支持扩展会话中的复位默认会话返回NRC 0x7F。需要安全解锁未解锁返回NRC 0x33。需要满足整车上电状态条件不满足时返回NRC 0x22。需要先进入编程会话或工厂模式否则返回NRC 0x7F或0x22。用例设计时要覆盖“授权前”和“授权后”两种状态。授权前发送复位请求期待否定响应授权后发送复位请求期待肯定响应。还要覆盖安全等级不对的场景例如解锁了普通安全访问等级但复位需要更高等级。这类用例很容易被手动测试漏掉因为手动测试一般会先做解锁再复位很少专门验证“不解锁就复位”。但实际上这是诊断工具最容易踩到的场景。如果权限控制用例没覆盖后续功能寻址、异常场景全部会受影响。3.4 时序、并发与状态恢复用例第四层是时序和状态恢复。0x11服务最大的特点就是会导致ECU暂时离线所以时序类用例非常重要。建议覆盖这些场景复位请求发出后ECU在多长时间内开始执行复位。复位期间ECU是否停止响应停止响应时间是否在需求范围内。复位完成后ECU重新上线重新进入诊断会话所需的时间。在复位过程中诊断仪连续发送会话控制请求ECU是否能正确恢复。在复位过程中再次收到0x11请求ECU是按顺序执行还是返回NRC 0x78还是直接丢弃。多个ECU同时在线时使用功能寻址发送0x11会不会出现多个ECU同时响应的冲突。最后一个场景很实际。0x11服务通常建议只使用物理寻址就是因为功能寻址会导致多个ECU同时复位响应帧会冲突测试也看不出到底哪个ECU执行了复位。所以用例设计时要单独标注寻址类型并在预期结果里写清楚。状态恢复还包含复位后安全解锁状态被清除DTC状态可能被清除或保留应用层状态、标定数据、非易失存储数据的保存情况。不要只测“能复位”要测“复位后状态对不对”。4. 把用例落到测试执行里前置条件、检查点和判定规则4.1 用例模板与字段说明用例设计最好统一模板方便评审和回归。一张比较完整的0x11服务用例表至少包含以下字段用例编号例如TC_ECUReset_001对应需求标识。需求描述点明被验证的需求点。前置条件ECU状态、会话、安全等级、总线配置。测试步骤按顺序写清发送什么请求等待什么响应。测试数据请求字节、子功能、寻址方式。预期结果响应字节、复位行为、恢复时间。实际结果执行后填写。优先级高、中、低。备注依赖项、风险说明。下面是一个简化的用例模板字段内容用例编号TC_ECUReset_001需求描述支持硬复位复位后回到默认会话前置条件ECU上电诊断仪连接正常处于扩展会话并完成安全解锁测试步骤1. 发送11 012. 等待响应3. 观察复位动作预期结果返回51 01ECU执行复位复位后进入默认会话优先级高这个模板可以扩展成自动化脚本也可以直接用于手工测试记录。关键是字段之间要有逻辑前置条件决定从哪里开始测试步骤决定做什么预期结果决定如何判断。4.2 前置条件和环境准备0x11服务的执行依赖整车和诊断环境前置条件不能含糊。执行用例前至少确认下面几项诊断仪和ECU之间的总线通信正常能正常进入诊断会话。ECU供电稳定复位动作不会导致诊断仪断电。复位前的会话状态和安全状态已经记录。如果测试真实复位动作需要能观察到ECU重新上线的报文或供电电流变化。日志采集开启包括总线报文、诊断响应、时间戳、错误帧。如果走DoIP或以太网诊断还要确认上位机网络配置正常避免把网络问题误判成ECU问题。很多现场问题都出在环境上。比如诊断仪只接了虚拟仿真节点没有真正连接ECU或者供电模块限流复位瞬间电流拉低导致通信不稳或者日志时间戳精度不够无法判断复位时间。这些不是0x11服务本身的缺陷但会影响用例执行结果。4.3 测试结果判定标准判定结果时不能只看有没有响应要看响应码和动作是否一起出现。我一般按这个顺序判断是否在预期时间内收到响应。响应是否为肯定响应SID和子功能是否匹配。如果是否定响应NRC是否符合需求预期。是否观察到实际复位动作包括重新上线、电源变化、应用日志变化。复位后是否回到预期会话安全状态是否被清除。整个过程中总线上是否有错误帧或异常报文。如果前几步通过但第4步没有观察到位我会把用例标记为“待确认”不会直接判通过。原因很简单有些需求只需要诊断仪发起复位请求但大多数0x11服务的真实目标是让ECU发生复位。没有观察到复位动作就不能证明服务真正生效。4.4 实际执行时常见的问题执行0x11服务用例时几个问题很常见。第一响应太快日志采样跟不上。有些ECU的复位几乎瞬时完成上位机还没记录到完整状态就掉线了。解决办法是增加固定等待时间并让日志记录连续的线上报文。第二复位后上位机没有重新建立诊断通信。这种情况下后续用例会全部失败。这通常不是ECU问题而是测试脚本没有等待恢复时间或者没有重新发送会话控制请求。第三NRC 0x78被当成失败。0x78表示请求收到但正在处理需要测试仪继续等待不要立即判定失败。注意收到0x78不是失败它表示ECU正在处理请求。测试脚本要等不要立即判失败。第四子功能0x81抑制肯定响应测试员以为ECU没有响应是异常。实际上如果需求支持抑制肯定响应无响应也是通过条件。关键在于ECU是否执行了复位动作。第五功能寻址测试时总线上多个ECU同时响应导致显示乱码或超时。这不是ECU异常而是寻址方式选择不当。设计用例时就要写明本次使用的是物理寻址还是功能寻址。如果遇到输出结果和预期不一致排查顺序我建议这样走先看响应是否存在再看NRC。NRC清楚了再查前置条件会话、安全等级、电源状态。前置条件没问题再看报文寻址类型、子功能字节、长度。报文没问题再看环境总线配置、上位机软件设置、供电。最后回到需求文档确认是不是需求里就没有定义这个子功能。5. 不要混淆“网络诊断”和“诊断显示DNS”5.1 0x11服务不依赖主机DNS0x11服务在应用层执行它不负责域名解析也不依赖主机上的DNS配置。只要ECU的总线地址和诊断会话建立正常发送11 01就能被ECU收到和DNS没有关系。很多测试人员看到“网络诊断显示dns”这类提示就很紧张以为是ECU服务出问题。实际上这个提示通常出现在诊断上位机或电脑网络环境里和0x11服务没有直接联系。比如诊断软件需要联网校验授权或者安装目录在局域网共享盘上电脑DNS解析失败界面就弹出了类似“网络诊断显示dns”的提示。这时ECU通信可能完全正常。所以做0x11服务用例时如果上位机弹DNS相关提示不要急着把用例改成失败。先确认诊断仪和ECU之间的总线通信是否正常再确认应用层请求是否发出。5.2 看到DNS相关提示时按这个顺序排查如果确实出现了DNS相关提示我建议按下面顺序排查先确认诊断仪和ECU是否还能正常进入诊断会话。如果能进入说明总线链路没问题。再确认上位机软件是否需要联网授权、升级或者在线校验。如果是优先检查电脑的网卡、代理、防火墙和DNS配置。如果诊断软件安装或日志路径在网络共享盘本地化到本机再试一次。如果走DoIP做诊断检查ECU的IP地址、端口、连接是否正常独立于DNS问题处理。最后才是看0x11服务用例本身这时通常会发现服务请求和响应都是正常的。这条排查链路的核心是分层隔离先把网络层问题排除掉再回到应用层看0x11服务。不要一看到DNS提示就怀疑ECU复位服务也不要在ECU复位失败时去改电脑DNS。5.3 网络诊断和诊断服务的协作关系在网络诊断这个范围里0x11服务是应用层用例它依赖底层传输但不等同于底层传输。“网络诊断”这个说法经常被模糊使用既可以指CAN网络里的诊断通信也可以指以太网DoIP诊断个别场景还会牵扯到上位机网络配置。设计0x11服务用例时要把“网络通信正常”作为前置条件而不是把它放进被测范围内。如果网络通信有问题优先单独建网络层测试用例比如检测总线连接、地址配置、会话建立、报文收发。等网络层稳定后再执行0x11服务用例定位问题会快很多。6. 用例评审和后续维护6.1 用例设计完成后先做这几个检查完成0x11服务用例初稿后我一般会按下面几个问题过一遍需求里写的每一个子功能是否有对应用例。不支持的子功能、保留位、长度错误是否有异常用例。会话限制、安全限制是否覆盖了授权前和授权后。抑制肯定响应位是否单独设计。功能寻址和物理寻址是否分开标注。复位后的默认会话、安全状态、DTC状态是否有检查点。是否设计时序用例比如响应超时、复位恢复时间、重复请求。用例是否能在自动化环境里稳定执行而不是只能手工点一遍。如果这八项都覆盖了用例基本完整。任何一项缺失评审的时候都应该被提出来。6.2 维护时机需求变更、软件版本和故障库更新0x11服务用例不是一次设计完就固定的。以下几种情况需要主动维护诊断需求变更比如新增子功能、修改安全等级。软件版本更新复位行为或恢复时间变化。故障库更新新增了实际测试中发现的NRC和时序问题。整车网络拓扑变化功能寻址的响应行为可能改变。工具链或诊断仪逻辑变化测试脚本需要同步调整。维护时建议保留历史版本不要直接覆盖。否则回归测试时无法对比新旧差异也无法确定某个用例的变化是需求导致的还是软件缺陷导致的。6.3 个人经验总结0x11服务看起来简单真正把用例设计完整并不容易。最容易遗漏的不是正常路径而是复位后的状态恢复、功能寻址行为、抑制肯定响应位、时序超时条件。如果只做手工测试建议不要一上来就连续复位先跑一条正常用例确认ECU复位动作和日志记录都正常再铺开异常用例。如果做自动化一定要把恢复时间做成可配置参数否则ECU换一个软件版本恢复时间变了整个脚本就会崩。最后提醒一句这类用例的价值不在于你写了多少条而在于每条用例能否稳定复现、能否快速定位问题。能复现、能定位才算真正可用的诊断用例。