SOA架构/测试阶段接口描述语言转换方案

作者： Polelink北汇信息

1356 次浏览

19 次

2022-11-23

编辑推荐:

本文主要介绍了SOA架构/测试阶段接口描述语言转换方案。希望对你的学习有帮助。
本文来自于CSDN，由火龙果软件Linda编辑、推荐。

SOA架构盛行

随着汽车新四化的推进，汽车整车厂在实现车辆网联、自动驾驶和数据驱动的同时，更要在满足用户体验和基本服务的基础上快速响应客户的个性化需求，为更好地解决这些新的挑战，整车厂引入了高性能的芯片、突破性的技术产品，同时传统的EE架构也需要变革，SOA（面向服务的架构）成为大多整车厂响应市场需求的首选架构。

SOA架构的主要优势是可以在很大程度上实现分布式系统软件模块间的解耦，通过软件升级OTA可以更方便灵活地将服务实体部署在任意的域控制器上，服务之间只需通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。而且对于ECU的版本更新、信号库更新、代码修改等过程更加简便和灵活。简化了注册服务与调用API，节约了时间成本，提高系统的健壮性和扩展性。

SOA开发和部署步骤

设计和部署一个SOA汽车软件大概可分为以下几个步骤:图1: SOA开发部署步骤

服务接口开发阶段往往需要挑选有固定规则、逻辑性强，又有大量高度重复的场景进行测试验证，为了快速进行验证，架构工程师通常会以IDL(接口描述语言)来做服务定义描述，作为开发链路上后续工作开展的输入，业务逻辑开发阶段以统一的标准进行服务实现。

市面上的IDL语言非常多，例如FIDL、Protobuf、vCDL、ARXML、OMG IDL、C++、CANoe FDX等。测试人员对于各种IDL的语法规则需要零基础开始学习，在转换过程中相应的操作也比较复杂、繁琐，同时出错率也很高。

如果软件的架构采用了SOA，对系统中的功能进行了服务化，在前期技术选型，清单定义、架构设计以及中期的业务逻辑开发阶段都会碰到诸如以下的几种场景。

场景一

架构人员在使用PREEvision Adaptive AUTOSAR进行系统建模、定义服务相关SWC后，通常会导出不同类型的ARXML，该文件定义了各服务接口、数据类型、参数引用等，这些AP ARXML可导入到CANoe中进行节点仿真和监控以太网通信，也支持导入DaVinci IDE生成代码，配合DaVinci进行开发。但是这个建模过程短期内无法完成，需要不停地沟通协调，考虑便捷性，在沟通过程中相关方会以Excel作为沟通输入，最终会将这些Excel中的配置信息再转换为ARXML导入到相关的工具中进行验证。

图2-1: 接口和数据类型定义Excel

图2-2: 接口和数据类型定义Excel

如上图简单示例，其中结构体引用，数据类型等信息容易出错，时常需要反复修改后再重新转换为ARXML，这个过程费时费力，从效率角度来说也影响了软件的开发进度。

场景二

以太网测试（以SOME/IP为例）时，开发人员输出的是Excel，测试人员需要再把Excel转成测试软件可以支持的文件格式，如vCDL，此环节工作量极大，正确率也无法保证。

图3-1: 以太网测试接口定义Excel

图3-2: 以太网测试接口定义Excel

场景三

开发人员在使用DaVinci做架构设计时，为了加快开发周期，通常情况下会先使用Excel做模板，在Excel中填入接口信息、数据类型、SWC定义、SWC与接口关系等信息，然后再由模块责任人把Excel中的数据在DaVinci Developer中做相应的节点配置和连线关联，整个过程出错概率高并且重复性高，需要有工具能依据Excel模板文件自动生成ARXML文件，实现SWC的转换及接口与SWC结合工作，用以提高设计效率。

场景四

在SOA架构中，中间件技术的应用使得应用软件与底层的操作系统和硬件实现了解耦，我们可以使用 SIL （Software in loop）技术在系统开发早期对系统进行功能验证。SIL 测试的一个重要环节是 SIL Adapter 开发。SIL Adapter 实现了测试系统对被测服务实现的调用。针对各个服务接口的 SIL Adapter代码结构是相同的，只是接口参数数量、名称、类型方面有少量代码差异，整个过程重复性也较高，需要有工具能自动将架构设计产出的FIDL、XML、ARXML等文件自动转化为C++等代码，同时能根据文件中的描述/备注等内容自动生成插桩代码，这将缩短验证周期。

场景五

SOA架构设计、测试验证等阶段，工程师在使用相关工具软件时，会使用许多配置文件作为输入或输出文件，但是鉴于使用的工具众多，且文件格式之间的标准并不统一，所使用的各个开发工具及测试工具也并不能支持所有的格式，所以各个工具间的串联并不流畅，影响工程师的工作效率，需要有工具能自动将这些不同格式的文件进行互相转换以实现工具的高效串联。

场景六

测试用例通常是在Doors或Polarion中管理，测试用例中的测试步骤或测试标准正常是以自然语言的方式描述，在测试执行过程中软件无法识别这些描述性语言，测试人员需要先将这些自然语言转换为脚本文件，再把测试脚本放到测试工程中执行，在测试用例较多的时候这个工作量将会非常庞大，需要有工具能集成相关用例管理软件，将测试用例能自动转换为相应的测试软件的脚本文件，在提高效率的同时减少出错机率。

场景七

SOA测试开发过程大体上需要进行以下几个步骤：

测试规范开发：基于需求规范和测试经验及对实现方案的理解，完成测试规范的开发。

SOA-HIL 测试系统需求分析和测试系统开发：被测对象的引脚和资源定义，HIL硬件及测试软件运行环境搭建。

测试工程开发：开发测试工程，实现测试规范所定义的测试内容的自动化/半自动化测试。

仿真模型开发：开发仿真模型，与待测节点建立接口交互。

测试环境集成调试与测试执行：针对某一具体被测对象进行测试环境搭建、工程集成调试与测试执行。

以上各个步骤中所需的输入物类型较多，如：SOA功能的需求规范、服务接口规范，资源定义文件，测试范围定义，ARXML 等类型数据库文件，测试系统第三方编程脚本，测试规范，通信数据库，通信矩阵文件，被测节点交互数据格式定义等，需要有工具能够按测试项目进行统一分类管理，同时能够支持相关输入物间进行格式转换，转换后的结果能够便捷地加载到相关的测试软件中或能够通过网络自动上传到配置库的对应位置下方便后续操作。

场景八

目前SOA架构软件普遍采用敏捷开发方式进行管理，软件版本的高频迭代极大考验了测试人员工作量和自动化测试能力，目前大多整车厂和零部件供应商基本上已在进行或正在研案持续集成测试方案来解决这一问题。

如下图所示，随着SOA架构的盛行，输入物或规范文件已经出现了多样化，但是持续集成测试推进的前提条件是需要预先将这些测试软件不可识别的接口文件或用例文件转换为符合测试软件定义的规范脚本，并且能够与相关的工具进行集成自动转换。

图4: 持续集成测试文件转换需求示意图

为什么需要接口描述语言转换

以上几个场景都需要测试人员手动录入或转换后才能继续推动项目进度，此环节尤为关键，但往往转换周期较长，且该工作耗时又费力，出错率也较高，导致经常返工，这些问题一直困扰着的开发/测试人员。

PAVELINK.SOA-Converter介绍

针对以上问题，开发出了接口描述语言转换工具——PAVELINK.SOA-Converter。

PAVELINK.SOA-Converter是一个基于Eclipse开发的IDL转换工具。可实现对常用IDL语言的批量转换（FIDL、OMG IDL、C++、Protobuf、vCDL、CANoe FDX、ARXML等），例如FIDL转CANoe FDX，FIDL与Protobuf互转，同时也支持直接通过Protobuf转换CANoe FDX等便捷的转换功能，转换前可根据用户需求自定义输出目录、是否忽略注释信息、是否批量转换、是否转换为多个文件等配置。

PAVELINK.SOA-Converter结合测试代理引擎进行自动化回归测试，可以解决整个链路的沟通问题并缩短测试验证的时间。

用户通用使用PAVELINK.SOA-Converter实现对文件的快速转换，相较于人工转换，不但很大程度上节约了时间成本，而且保障了转换的正确率，提高了开发测试的进度，同时有效降低了维护的成本。