2. TC8测试中的Upper Tester（UT）是什么？一文讲清作用、架构与实现思路摘要

1. 为什么TC8测试需要Upper TesterTC8 Layer 3—7并不是单纯的外部抓包测试。很多测试用例不仅要求TESTER向ECU发送报文还要求ECU主动执行某个动作例如清除ARP缓存、发送UDP数据、建立TCP连接或者让应用读取接收到的数据。只从网络外部发送报文无法稳定完成这些动作也很难观察ECU应用层是否真正收到了数据。因此规范在“TCP/IP Protocol Family”的总前置条件中提出为了达到足够的测试深度需要在TESTER和ECU的TCP/IP协议栈之间引入Upper Tester接口。该接口用于配置、触发和结果评估。这里有两个容易误解的地方Upper Tester不是被测协议栈本身而是测试辅助接口规范给出了AUTOSAR Testability Protocol and Service Primitives作为实现示例但不等于所有项目必须采用完全相同的传输协议或物理接口。从工程角度看UT解决的是“如何让ECU可控、可观察”的问题。2. UT在测试系统中的位置TC8测试可以分成两个逻辑平面控制平面和被测网络平面。2.1 控制平面控制平面负责让DUT进入测试所需状态常见动作包括配置IP地址或网络接口清除、添加或查询ARP表项创建UDP接收端口触发UDP数据发送建立、监听或关闭TCP连接查询应用是否收到数据恢复测试初始状态。在TCP/IP测试范围内这类能力通常由Upper Tester接口提供。2.2 被测网络平面网络平面传输真正用于一致性判定的报文。TESTER会构造正常或异常的ARP、IPv4、UDP、TCP及DHCP报文监听DUT响应然后按照测试用例中的Pass Criteria判断结果。因此UT命令执行成功并不代表测试通过。最终仍然要看DUT在被测网络上的实际行为。3. UT是不是一个固定的软件模块不一定。规范定义的是测试所需能力并没有要求所有ECU使用同一种物理控制通道。项目中可能采用独立的以太网控制接口与测试网络复用的控制服务CAN或CAN FDUART或USB诊断服务测试脚本与ECU内部测试接口的组合。无论采用哪种方式都应满足三个基本要求能够稳定执行测试步骤中的DUT_CONFIGURE动作能够返回足够明确的结果或状态控制机制不能替代或篡改被测协议栈的行为。例如UT可以调用ECU正常使用的Socket接口触发UDP发送但不应该自行拼装完整UDP/IP报文并绕过被测协议栈否则测试对象就发生了变化。换句话说UT只负责控制和观察真正的协议行为仍然应该由被测协议栈完成。4. 哪些TCP/IP测试会使用UT4.1 ARP测试ARP测试经常需要UT完成以下动作清除动态ARP表项添加或删除静态ARP表项触发DUT向指定地址发送UDP数据查询或间接验证ARP缓存状态。例如TESTER先向DUT发送ARP Request使DUT学习对端地址然后通过UT触发DUT发送UDP数据。测试系统随后检查DUT是否直接使用已有ARP表项而不是再次发出ARP Request。如果没有UT或等效控制接口测试工具很难稳定地让ECU主动发送指定报文也无法在测试结束后可靠地清理ARP状态。4.2 UDP测试部分UDP用例需要在DUT侧创建接收端口或者确认应用层是否收到了指定数据。规范中的相关测试步骤会明确写出“使用Upper Tester验证应用层结果”。典型能力包括创建或关闭UDP端口绑定本地接口和端口发送UDP数据获取应用层接收数据清空接收缓冲区和接收状态。这里测试的不只是ECU能不能收到UDP报文还包括应用接口、端口处理、长度、校验和以及异常报文处理。4.3 TCP测试TCP测试对DUT控制能力的要求更高因为很多测试用例需要让TCP状态机进入指定状态例如LISTENSYN-SENTSYN-RECEIVEDESTABLISHEDFIN-WAITCLOSE-WAITLAST-ACK。UT可能需要完成主动建立TCP连接进入监听状态接受远端连接发送应用数据主动关闭连接中止连接查询连接状态验证应用层是否收到连接复位等事件。需要注意的是“命令已接收”和“TCP状态迁移完成”不是一回事。例如UT收到“建立TCP连接”命令后立即返回成功但此时三次握手可能还没有完成。如果TESTER马上执行下一步测试用例就可能失败。因此UT设计时最好区分命令已接收动作执行中动作执行完成动作执行失败。5. DHCP测试到底需不需要UT这个问题不能只回答“需要”或者“不需要”。DHCPv4 Client位于TC8的TCP/IP测试范围内因此受到该范围总前置条件中Upper Tester要求的覆盖。不过DHCP具体测试用例中经常使用下面这些表述外部配置DUT上的DHCP Client外部使指定接口上线或下线让DUT进入或等待特定DHCP状态由TESTER模拟一个或多个DHCP Server。这说明DHCP测试明确需要可重复的外部控制能力但规范并没有在每一个测试步骤中都规定必须调用某个固定名称、固定格式的UT命令。实际项目中可以这样理解如果现有UT能够配置DHCP Client、控制接口状态并配合自动化测试就可以使用UT如果项目通过诊断接口、配置脚本或其他等效机制完成相同动作也可以作为DUT_CONFIGURE的实现方式但需要与测试工具或测试机构确认。DHCP测试的重点仍然是DUT在网络上的实际行为例如是否正确发送DHCPDISCOVER是否正确发送DHCPREQUEST是否根据xid匹配服务器响应是否正确处理多个DHCP Server是否正确处理租约、T1和T2是否丢弃不应接受的DHCPOFFER是否丢弃不符合当前状态的DHCPACKDHCP报文字段和Option是否符合要求。不要把“能够启动DHCP客户端”误认为“DHCP测试已经通过”。启动DHCP Client只是测试准备DUT后续的协议行为才是判定对象。6. SOME/IP是否使用通用UTSOME/IP部分需要单独理解不能直接套用TCP/IP UT的说法。TC8 V3.0的Automotive Protocols范围包含SOME/IPSOME/IP Service Discovery。规范中又分别给出了SOME/IP Server测试用例SOME/IP TestStub Enhanced Testability ServiceETS测试用例。6.1 SOME/IP Server测试这组用例面向DUT中提供的SOME/IP Server检查内容包括SOME/IP报文格式Service ID和Method IDClient ID和Session IDProtocol VersionInterface VersionMessage TypeReturn CodeRPC行为SOME/IP Service Discovery发布订阅行为。部分用例可以由TESTER直接发送请求并检查DUT响应。部分用例仍需要通过DUT_CONFIGURE启动服务、停止服务或者触发事件。这个配置动作可以由项目已有的测试控制机制完成但不应该笼统地称为TCP/IP通用UT的固定功能。6.2 ETSETS全称Enhanced Testability Service是规范为SOME/IP测试定义的测试服务。其覆盖内容包括SOME/IP Service Discovery序列化Remote Procedure CallPublish/Subscribe正向测试异常报文测试负载测试回归测试。ETS提供了明确的方法和事件例如重置接口暂停接口触发事件激活或停止客户端服务订阅Eventgroup各类Echo方法读取事件的最后一个值。因此比较准确的说法是TCP/IP测试使用Upper Tester接口SOME/IP测试有自己的TestStub和ETS机制同时部分Server用例可以直接测试DUT已有服务。ETS承担了增强可测性的作用但它不是TCP/IP通用UT也不是所有SOME/IP Server测试的统一前置条件。实现了ETS并不代表已经具备ARP、UDP、TCP和DHCP测试需要的全部UT能力。7. 一条典型UT测试用例如何执行一个典型的TCP/IP UT测试过程通常包括以下几个阶段。7.1 初始化DUT测试开始前先清理上一个测试用例留下的状态例如ARP缓存TCP连接UDP SocketDHCP租约接收缓冲区测试状态标志。7.2 配置测试参数通过UT设置测试所需参数例如DUT接口本地IP地址目标IP地址本地端口目标端口发送数据TCP连接角色。7.3 触发协议动作通过UT触发DUT调用真实协议栈接口例如发送UDP数据建立TCP连接创建UDP接收端口清除ARP缓存。7.4 进行网络交互TESTER在被测网络上发送或接收协议报文并检查报文是否出现报文方向是否正确字段内容是否符合要求响应时间是否满足条件DUT是否发送了不应该出现的额外报文。7.5 查询内部结果部分测试用例需要通过UT确认应用层是否收到数据接收数据内容是否正确TCP连接是否进入预期状态协议栈是否报告指定错误。7.6 判定并清理TESTER按照Pass Criteria判断测试结果然后执行Cleanup。这里最容易忽略的是Cleanup。ARP缓存、TCP连接、DHCP租约和接收缓冲区都可能影响下一条测试用例。单条执行通过、连续回归失败时应优先检查状态是否真正清理完成。8. UT接口设计时需要注意什么8.1 返回状态要明确建议至少区分SUCCESSINVALID_PARAMETERNOT_SUPPORTEDBUSYTIMEOUTINTERNAL_ERROR。如果UT只返回一个笼统的FAIL很难判断问题位于控制协议、UT内部调用还是被测协议栈。8.2 支持异步操作TCP连接、DHCP状态迁移等操作不一定能在一条命令返回前完成。UT应该提供状态查询事件通知执行完成标志明确的超时机制。8.3 保持测试对象真实UT应调用量产软件正常使用的协议接口。如果UT为了方便测试而完全绕过协议栈自行生成最终报文测试结果就失去了意义。8.4 控制通道不能干扰测试结果如果UT控制通道与被测网络共用同一个接口需要评估控制通信是否会影响ECU的ARP表网络负载Socket资源报文发送时序TCP连接数量测试工具的抓包判断。8.5 保留可对齐的日志建议UT日志至少记录命令编号命令参数Sequence ID命令接收时间内部接口调用时间内部接口返回值返回给TESTER的状态。9. 用例失败时如何判断是不是UT问题定位时可以按照三个层级进行检查。第一层控制命令是否正确到达检查Command ID是否正确参数是否完整字节序是否一致Sequence ID是否匹配是否发生命令超时TESTER是否收到了对应响应。第二层UT是否真正调用了协议栈检查UT是否调用了正确的内部接口协议栈接口返回值是否正常Socket或缓存资源是否充足调用时间是否符合测试步骤动作是否尚未完成UT就提前返回成功。第三层网络行为是否符合预期检查PCAP中的实际报文报文方向时间顺序协议字段额外报文无响应情况。最好同时保存三类证据TESTER或控制通道日志ECU内部UT及协议栈日志被测网络PCAP。将三类日志按照时间戳对齐后通常可以判断失败属于测试控制问题、协议栈问题还是测试环境问题。10. 项目中什么时候开始准备UTUT最好在TCP/IP协议栈集成阶段同步准备而不是等到送检前再临时补充。如果开发过晚常见问题包括ECU内部缺少必要的测试接口无法查询应用层接收结果无法稳定触发指定报文无法控制TCP状态DHCP Client无法自动化启停测试状态无法可靠清理测试工具与UT联调时间不足出现Fail后无法判断是UT问题还是协议栈问题。比较合理的推进顺序是根据ECU功能确定适用的TC8测试范围从测试用例中整理DUT_CONFIGURE和结果读取需求区分TCP/IP UT、项目控制接口以及SOME/IP ETS定义控制协议和内部调用接口与测试工具完成基础联调按ARP、UDP、TCP、DHCP和SOME/IP逐项验证最后进行连续回归和资源泄漏检查。11. 总结Upper Tester的核心价值是让ECU在一致性测试中具备足够的可控性和可观察性。不过UT不是被测协议本身也不是一套所有项目都必须照搬的固定物理接口。几个关键结论可以归纳为TC8 V3.0在TCP/IP测试范围的总前置条件中要求引入Upper Tester接口ARP、UDP和TCP等测试会直接使用UT进行配置、触发或结果读取DHCP属于TCP/IP测试范围并且明确需要外部配置和状态控制DHCP的具体控制动作可以由UT或满足要求的等效机制完成SOME/IP部分单独定义了TestStub和ETS不能简单等同于TCP/IP通用UTSOME/IP Server测试和ETS测试是不同的测试内容ETS不是所有SOME/IP Server测试的统一前置条件最终Pass或Fail取决于DUT真实协议行为而不是UT命令是否返回成功。可以用一句话概括UT负责让ECU按照测试步骤进入指定状态TESTER负责检查ECU的真实协议行为是否正确。参考资料OPEN Alliance TC8官方介绍OPEN Alliance Automotive Ethernet SpecificationsOPEN Alliance Automotive Ethernet ECU Test Specification Layer 3—7 V3.0TC8 Test Process—ECU and Network Test说明不同测试工具和测试机构对控制接口的适配方式可能不同。正式送检前应以项目适用的规范版本、DUT Feature List以及测试机构要求为准。