DDS测试策略探讨与协议测试工具介绍

作者 | 梵高先生

小编 | 吃不饱

01

软件定义汽车对测试的影响

OEM作为集成方，需要对来自不同供应商的模块进行“验收测试”，其目的是确认该模块是否按照需求进行实现。根据需求类型可以将验收测试划分为三个部分：针对行业标准的验收测试，针对OEM企业标准的验收测试，以及针对车型项目需求的验收测试。其中每个部分又根据测试方法的不同而分成两种类型，分别是静态审查和动态测试。

02

DDS中间件的测试策略

DDS中间件即是上述新模式下的一个典型例子，那么如何对这种产品进行测试呢？

对于成熟的标准的软件产品，比如Linux，QNX等，我们其实并不需要对其核心功能进行太多测试，因为软件厂商或开发者会在产品开发过程中进行大量测试，市场和时间也能充分证明其质量的可靠性，这也是我们选择成熟软件模块的意义所在。然而，当我们把来自不同供应商的标准产品放到同一个系统或网络中协同工作时，必须考虑到它们之间是否兼容，也就是互操作问题。

那么对DDS来说，会出现互操作问题吗？这需要分情况讨论。

如果参与DDS通信的节点均是基于高性能SoC实现，并且运行标准操作系统（如Linux，QNX等），得益于DDS良好的可移植性和OS无关的特性，OEM可以采用成熟的商业产品或开源产品，然后部署在每个节点中。此时，若所有节点运行着相同的来源和版本的DDS中间件，显然这种模式下我们可以忽略互操作的问题。

然而，目前也有不少厂商正在尝试或已经实现向MCU中集成DDS中间件。受限于MCU性能和资源，DDS软件必须经过适当裁剪和优化才能在MCU的环境下运行。同时，MCU软硬件高度耦合，软件移植、复用和维护并不容易，这种情况下我们可能不能再将其视为成熟的软件模块，厂商因此需要对DDS软件进行大量的测试来保证DDS系统的质量。这种情况下，为了避免与其他DDS软件互通时产生交互问题，互操作测试是必不可少的。除了上述情况，如果DDS中间件来源或版本存在差别，互操作性测试也将是十分必要的。

除了互操作测试，另一个更重要的关注点是系统测试，具体来说是DDS中间件集成至目标平台后，会不会出现系统性问题。因为车载电子电器系统的计算平台五花八门，不同车型平台，不同项目，其搭载的系统平台（包括芯片架构，操作系统等）可能都有不同，甚至还有像基于MCU的DDS这种嵌入式软件，这些不同的平台相互的组合情况，DDS QoS配置组合情况，以及复杂的网络配置情况（如DDS-TSN），更难以计数。尽管DDS协议栈厂商可能会验证DDS产品与常见平台的兼容性，但是这很难覆盖所有可能的系统配置。所以我们认为在上述情况下对DDS中间件进行功能和性能测试是有必要的。

03

DDS协议测试工具介绍

南京臻融软件科技有限公司多年来专注于DDS产品与相关工具链的自主研发。其产品ZRDDS是我国首个100%自主研制并被OMG组织官方认证的DDS产品。

图1：DDS协议测试的测试框架示意

图1显示了DDS协议测试的测试框架示意。上位机中运行的DDS Test Frame软件能够提供图形化的用户界面，具备测试用例管理，测试用例执行监控，测试报告生成，测试系统配置等功能。DDS Tester是专门为测试而开发的应用程序，在开始测试之前需要将此应用植入被测系统的每个节点内部。测试执行过程中，上位机将指令下发至DDS Tester，DDS Tester按照指令内容执行操作，比如调用某个应用程序接口，并将结果返回至上位机。其角色类似于TC8 TCP/IP测试中的Upper Tester。得益于DDS标准化的应用程序接口，理论上DDS Tester可在不同供应商的DDS产品之间轻松移植。

当然，DDS节点并不一定只通过以太网进行通信，其它还包括板载交换机的介质无关接口，共享内存，或者本地环回网络等等，测试环境可以根据系统的实际情况进行搭建。

DDS协议测试规范/用例完全自主设计开发，并且在多年的项目实践中不断进行迭代和优化，目前可以覆盖OMG DDS 1.4所定义的DCPS的核心功能，包括DDS应用程序接口的行为，QoS行为，以及性能测试，共计400余条测试用例，通过所开发的测试脚本套件，全部可实现自动化执行。

04

DDS协议测试实践

如下示例展示了DDS测试的执行过程。

图2：测试环境

图3：DDS Tester 运行界面

测试环境如图2所示，为便于展示，被测系统为Windows主机中运行的两台Ubuntu虚拟机，两台虚拟机中均运行DDS Tester。被测DDS为某DDS中间件产品，目前在汽车行业内已经得到较广应用。

在上位机软件DDS Test Frame中选择并执行测试用例，如图4所示。

图4：在DDS Test Frame中执行测试用例

我们以DisposeWTimeStamp_WrongHandle这条失败的测试用例来说明一下测试问题的分析步骤。测试步骤如下表所示。

在这条测试用例中，DDS Test Frame发送指令，使DDS Tester创建同一个Topic的两个数据，分别为Data1和Data2，Topic中指定“key”为键，不同键值的两个数据应视为同一个Topic的两个不同的实例。之后创建对应的DDS实体，包括DomainParticipant，Topic，Publisher，以及DataWriter，并使用Data1和Data2分别在DataWriter中进行注册，获得两个句柄Handle1和Handle2，分别指向key为1和2的两个Topic实例，Data1和Data2。当取消注册时，DDS Tester使用了错误的句柄，即使用Data1和Handle2来取消注册，按照OMG DDS标准的描述，这时DDS应向应用程序返回“PRECONDITION_NOT_MET”，但实际返回为“OK”。

通过以上示例我们可以看到，被测DDS并没有完全按照OMG DDS标准进行实现。在实际项目中，这样的偏离可能导致系统不能达到设计预期的功能或者性能。DDS作为支撑起整车分布式系统的重要的框架性软件，我们需要谨慎的评估每一个对需求的实现偏离，因为其影响的范围可能并不局限于某个应用程序或某个应用场景，它可能影响的是整个分布式系统。

DDS协议测试套件中的测试用例能够在实际系统环境下遍历几乎所有应用程序接口，以及所有可能出现的调用接口的参数组合情况，并且能够评估整个系统在不同场景下的性能表现，实现了对DDS中间件的全面和深入的测试和评估。

05

总结

本篇文章探讨了DDS中间件的测试策略，并介绍了北汇信息与臻融软件科技推出的测试套件，然后通过一个示例展示了测试执行和分析问题的过程。如果想了解更多关于DDS协议测试套件的信息，欢迎联系我们。

往

期

推

荐

DDS协议解读及测试开发实践

SOME/IP与DDS对比及DDS测试策略和方案探讨

“汽车人”眼中的网络安全-聊聊网络安全的5W1H

SOME/IP概述及TC8-SOME/IP 测试实践