基于车载SOA的测试方法、装置及电子设备

技术领域

本申请属于车辆领域、软件测试技术领域，具体涉及一种基于车载SOA的测试方法、装置及电子设备。

背景技术

目前，基于开放式的汽车软件架构标准(AUTomotive Open SystemARchitecture，AutoSar)的面向服务架构(Service-Oriented Architecture，SOA)的服务主要通过汽车通信网络开发和测试工具CANOE和便捷的嵌入式系统自动化测试序列和用例设计工具vTestStudio结合起来进行测试。但是，现有的测试方案中存在如下问题：

在测试过程中，测试用例是通过导入通信数据文件后，使用vTestStudio工具基于导入的数据文件人工通过跨平台的计算机程序设计语言python或者高级脚本语言(Communication Access Programming Language，CAPL)脚本编写测试用例，手工编写测试用例需要测试人员具有编码能力，而且测试效率低。

发明内容

本申请实施例的目的是提供一种基于车载SOA的测试方法、装置及电子设备，能够解决现有的测试方案导致测试效率低的问题。

为了解决上述技术问题，本申请是这样实现的：

第一方面，本申请实施例提供了一种基于车载SOA的测试方法，包括：

获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件；

根据所述服务数据文件以及所述模板文件，生成上位机的测试用例；

根据所述服务数据文件，生成下位机的测试脚本；

通过所述测试脚本执行所述测试用例，得到测试结果。

第二方面，本申请实施例提供了一种基于车载SOA的测试装置，包括：

第一获取模块，用于获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件；

第一生成模块，用于根据所述服务数据文件以及所述模板文件，生成上位机的测试用例；

第二生成模块，用于根据所述服务数据文件，生成下位机的测试脚本；

第一执行模块，用于通过所述测试脚本执行所述测试用例，得到测试结果。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

在本申请实施例中，通过获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件，根据所述服务数据文件以及所述模板文件，自动生成上位机的测试用例，根据所述服务数据文件，自动生成下位机的测试脚本，通过所述测试脚本执行所述测试用例，得到测试结果。相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，自动生成的测试用例框架和测试脚本具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

附图说明

图1是本申请实施例提供的基于车载SOA的测试方法的流程示意图；

图2是本申请实施例提供的Poseidon与DWAutoTest的通信关系示意图；

图3是本申请实施例提供的Poseidon与DWAutoTest的时序关系示意图；

图4是本申请实施例提供的基于车载SOA的测试方法的具体流程示意图；

图5是本申请实施例提供的一种基于车载SOA的测试装置的结构示意图；

图6是本申请实施例提供的一种电子设备的结构框图；

图7是本申请实施例提供的另一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

目前，在车载平台中，SOA服务测试非常重要，因为它可以确保服务的质量和稳定性。SOA服务测试可以验证服务的功能、性能、可靠性和安全性，帮助开发人员和测试人员发现和纠正潜在的问题，以便在服务部署到生产环境之前修复它们。测试SOA服务的难点主要有以下几点：

第一点：SOA服务通常由多个组件、服务和系统组成，这些组件之间的交互非常复杂。测试用例需要模拟整体架构和各个组件之间的交互方式跑在不同的设备上，以便设计和执行有效的测试；

第二点：SOA架构中涉及的数据包括服务描述文件、服务通信矩阵等，这些数据文件中的数据量一般都很大，手动创建测试用例将非常耗时和困难；

第三点：SOA服务的测试用例涉及底层通信相关的逻辑代码，测试人员开发门槛高。

由此，本发明提供了一种基于车载SOA的测试方法、装置及电子设备，能够根据输入的服务数据文件，自动生成测试用例和测试脚本，不仅提升了测试效率，还减少了测试人员在测试用例编写方面的工作量和出错率。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的基于车载SOA的测试方法进行详细地说明。

如图1所示，本申请实施例提供了一种基于车载SOA的测试方法，具体可以包括如下步骤：

步骤101，获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件。

具体的，获取车载SOA的服务数据文件，并获取与服务数据文件对应的模板文件。其中，服务数据文件包括：符合AutoSar定义的ARXML格式的文件和/或符合GENIVI Franca接口定义的FIDL的文件。

步骤102，根据所述服务数据文件以及所述模板文件，生成上位机的测试用例。

具体的，根据服务数据文件以及与服务数据文件对应的模板文件，自动生成上位机的测试用例，相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，自动生成的测试用例具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

步骤103，根据所述服务数据文件，生成下位机的测试脚本。

具体的，根据所述服务数据文件，自动生成下位机的测试脚本，提升了测试效率，减少了测试人员的工作量。其中，下位机的测试脚本是测试用例的具体实现，可以运行在实际的车载设备中，也可以运行在个人计算机(personal computer，PC)端等，在此不做具体限定。

步骤104，通过所述测试脚本执行所述测试用例，得到测试结果。

具体的，基于车载SOA架构，为了实现既可以运行在PC上仿真测试，也可以运行在车载的设备中模拟实际的环境的目的，通过表格Excel测试用例，实现业务数据相关的测试逻辑，测试脚本为通信协议等相关通用的功能代码，通过测试脚本执行测试用例，得到测试结果，整个过程自动执行，提升了测试效率。

在本申请上述实施例中，通过获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件，根据所述服务数据文件以及所述模板文件，自动生成上位机的测试用例，根据所述服务数据文件，自动生成下位机的测试脚本，通过所述测试脚本执行所述测试用例，得到测试结果。相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，自动生成的测试用例框架和测试脚本具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

作为步骤101的一具体的实现方式，所述获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件的步骤，具体可以包括：

获取所述面向服务架构SOA的服务数据文件；

确定所述服务数据文件的文件类型；

根据所述文件类型，获取与所述服务数据文件对应的模板文件。

具体的，获取车载SOA的服务数据文件，并判断该服务数据文件的文件类型，不同类型的服务数据文件对应有不同的模板文件。由于不同类型的服务数据文件的测试内容不同，不同类型的服务数据文件采用不同的模板文件生成测试用例，由此可以兼容多种类型的服务数据文件进行测试。

作为步骤102的一具体的实现方式，所述根据所述服务数据文件以及所述模板文件，生成上位机的测试用例的步骤，具体可以包括：

解析所述服务数据文件，得到第一测试数据；

将所述第一测试数据添加至所述模板文件中，得到上位机的测试用例框架；

根据所述测试用例框架，生成所述测试用例。

具体的，通过解析SOA架构的服务数据文件中的服务通信信息、服务接口信息等，获取测试用例需要的数据信息，即第一测试数据。将第一测试数据添加到预先设置的模板文件中，从而自动生成上位机的测试用例框架，再通过测试用例框架自动生成上位机的测试用例，相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率。

其中，测试用例框架中包括基于IP网络的汽车通信协议(Scalable service-Oriented MiddlewarE over IP，SOMEIP)协议的通讯接口实例等。

进一步的，上述解析所述服务数据文件，得到第一测试数据的步骤，具体可以包括：

在所述服务数据文件的文件类型为描述汽车电子系统的XML格式ARXML的文件的情况下，解析所述ARXML的文件，得到第一测试数据；

在所述服务数据文件的文件类型为接口定义语言FIDL的文件的情况下，通过通用应用程序编程接口(Application Programming Interface，API)生成器解析所述FIDL的文件，得到第一测试数据。

具体的，由于服务数据文件的文件类型包括ARXML的文件和FIDL的文件，两种类型的文件内容格式差距较大，无法通用，需要实现两套逻辑，由此通过两种不同的方式进行测试。

如果确定服务数据文件的文件类型为ARXML的文件，则直接解析该ARXML的文件中的服务信息、通信接口内容等，得到第一测试数据，将该第一测试数据填充至ARXML的文件对应的模板文件中，生成测试用例框架。

如果确定服务数据文件的文件类型为FIDL的文件，则需要通过通用应用程序编程接口生成器CommonAPI Generator解析FIDL的文件中的服务信息、通信接口内容等，得到第一测试数据。

需要说明的是，用户可以根据需要选择服务数据文件对应的模板文件，如果模板文件是网络客户端client模板，则生成对应的client测试用例；如果模板文件是服务器server模板，则生成对应的server测试用例；也可以选择性生成某个服务或者全量服务的测试用例，一个服务对应一个测试用例和测试脚本。

作为一可选的具体实施例，所述方法还包括：获取第二测试数据，在获取第二测试数据之后，所述根据所述测试用例框架，生成所述测试用例的步骤，具体可以包括：

根据获取的第二测试数据和所述测试用例框架，生成所述测试用例。

具体的，获取第二测试数据，将第二测试数据与测试用例框架结合，共同生成测试用例，相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，通过测试用例框架自动生成的测试用例具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

其中，第二测试数据是通过上游的服务设计文档经过数据分析得到的第一测试数据的补充测试数据。

需要说明的是，第二测试数据的获取时间在生成测试用例之前，具体获取时间可以在获取服务数据文件之前，也可以在获取服务数据文件之后，也可以在获取服务数据文件的同时，具体时间并不限定。

作为步骤103的一具体的实现方式，所述根据所述服务数据文件，生成下位机的测试脚本的步骤，具体可以包括：

通过所述通用应用程序编程接口生成器生成通用应用程序编程接口接口；

根据所述FIDL的文件以及所述通用应用程序编程接口接口，生成所述测试脚本。

具体的，如果确定服务数据文件的文件类型为FIDL的文件，则需要通过通用应用程序编程接口生成器CommonAPI Generator解析FIDL的文件中的服务信息、通信接口内容等，得到第一测试数据。并且，通过通用应用程序编程接口生成器生成通用应用程序编程接口接口Common API接口，再基于Common API接口，将FIDL的文件封装成适配当前测试系统的测试脚本。

进一步的，为模拟实际的车载环境，测试脚本需要支持在至少两种主流车载操作系统上运行，即测试脚本至少支持两种不同的操作系统，如：开源的操作系统内核Linux、安卓Android、嵌入式实时操作系统(QuickUnix，QNX)等。

需要说明的是，基于车载SOA的测试系统架构中包括人机界面(Human MachineInterface，HMI)层和服务测试单元，HMI层中的用例即为上位机的测试用例，服务测试单元中的服务单元ServiceUnit1、ServiceUnit2等是下位机的测试脚本，上位机驱动下位机执行测试用例的内容，下位机可运行在不同系统的设备中，实现SOA的真正意义上的跨域通信。上述系统架构将上层测试用例逻辑和底层通信逻辑分开生成，将业务数据放到上位机Excel格式的测试用例中，测试人员可直接编辑Excel中数据内容实现具体的测试用例内容，大大降低了对测试人员的要求。

作为步骤104的一具体的实现方式，所述通过所述测试脚本执行所述测试用例，得到测试结果的步骤，具体可以包括：

将所述测试用例导入至测试工具Poseidon中；

通过导入测试用例的测试工具Poseidon向所述测试脚本下发测试指令；

控制所述测试脚本根据所述测试指令执行所述测试用例，得到测试结果。

具体的，测试系统包括上位机的测试工具Poseidon以及下位机的测试程序DWAutoTest，测试工具Poseidon和测试程序DWAutoTest之间通过套接字socket进行通信。将测试用例导入至Poseidon中，通过导入测试用例的测试工具Poseidon向测试脚本下发测试指令，测试脚本在接收到测试指令之后，根据测试指令自动执行测试用例，得到测试结果。

需要说明的是，以上Poseidon可以同时与多个DWAutoTest进行通信，DWAutoTest既可以运行在PC端，又可以运行在车载设备中。Poseidon包括：加载测试用例、解析测试用例，下发测试用例数据到测试脚本以及接收来自测试脚本的回馈数据、展示测试过程和测试结果、导出测试报告等功能。

下面通过一具体实施例对上述测试过程进行说明：

如图2所示，测试工具Poseidon实现测试用例的加载、测试指令的下发和测试结果的接收，测试程序DWAutoTest负责接收测试指令，测试工具Poseidon与测试程序DWAutoTest之间通信。测试工具Poseidon与测试程序DWAutoTest可以共同运行在PC端，测试工具Poseidon还可以与运行在Linux、Android、QNX的测试程序DWAutoTest通信。

测试工具Poseidon与其中一个测试程序DWAutoTest的通信过程为：DWAutoTest将测试指令传给测试脚本执行相应的测试用例，并且将执行后得到的测试结果返回至Poseidon。另外DWAutoTest中包括有多个测试脚本，每一个测试脚本需要至少两种操作系统，上述方案可以通过增加、修改、删除测试脚本的方式直接替换测试，不需要进行编译。

下面通过一时序图对上述测试过程进行详细阐述：

如图3所示，步骤a1：测试用例导入至测试工具Poseidon中；

步骤a2：导入测试用例的测试工具Poseidon向测试程序DWAutoTest下发测试指令；

步骤a3：测试程序DWAutoTest在接收到测试指令之后，根据测试指令自动执行测试用例，得到测试结果；

步骤a4：测试程序DWAutoTest将执行后得到的测试结果返回至测试工具Poseidon。

需要说明的是，DWAutoTest与测试脚本之间通过动态加载的方式实现，即将测试脚本以库文件的形式放到预设目录下，DWAutoTest启动时读取预设目录，根据预设目录下动态链接库so库的文件名实现动态加载。

下面通过一具体实施例对上述生成测试报告的过程进行说明：

如图4所示，步骤301：获取服务数据文件；

步骤302：解析服务数据文件得到第一测试数据，并结合模板文件生成测试用例框架；

步骤303：获取第二测试数据；

步骤304：测试用例框架结合第二测试数据，生成上位机的测试用例；

步骤305：根据服务数据文件，自动生成测试脚本；

步骤306：将测试用例导入至Poseidon工具中，通过Poseidon工具测试指令下发到测试脚本执行自动化测试，得到测试结果。

作为一可选的实施例，编写模板文件需要先确定模板文件的要素、内容、规范等。Excel模板文件的要素包括但不限于：电子数据表Scrip sheet页和钥匙触发表KeyTriggersheet页；其中，Scrip sheet页包括：测试用例ID、测试用例的优先级、测试用例的名称、测试用例的步骤等。KeyTrigger sheet页包括：步骤ID、步骤key、步骤ID对应的详细步骤内容、步骤的循环测试次数关键字、步骤等待时间关键字等。

其中，步骤ID对应的详细步骤内容可以包括：测试指令下发的测试程序端ID、测试指令下发的测试程序ID中的测试脚本ID、所述测试用例的内容、是否执行所述测试脚本中对应关键字的逻辑内容、所述测试脚本执行对应关键字的逻辑内容的第二测试数据等。

为了方便测试人员进行测试用例的开发，测试用例通过Excel按照规定的模板文件内容编写，下面通过一具体实施例说明按照模板文件内容编写的内容：

测试步骤：

key＝FindService_key

wait＝1

key＝CoastRegenStrengthSet_key

key＝OffroadModeSet_key

loop_times＝2

其中，Key表示步骤的索引，通过“FindService_key”、“CoastRegenStrengthSet_key”、“OffroadModeSet_key”可以查找对应的详细步骤内容；

Wait表示步骤等待时间关键字，wait＝1代表执行完上面一行的步骤后等待1s执行下一步骤；

loop_times表示压力测试的关键字，即代表整个步骤的循环测试次数关键字。

详细步骤内容如下：

其中，"ClientType"：用于区分测试指令下发至哪个DWAutoTest端；

"BDCM"表示测试指令下发至BDCM端；

"Feature"：用于区分测试指令下发到DWAutoTest端的哪个测试脚本中；

"TEST_2005"表示测试指令下发至BDCM端的TEST_2005测试脚本中；

"Content"：详细的下发内容；

"TargetVehicleModeSet"：true表示执行测试脚本中对应关键字下面的逻辑内容；

"par"：测试脚本执行以上关键字逻辑内容接收的的第二测试数据；

"00 00 00 03 01 03 01"是第二测试数据的内容。

测试脚本以代码形式生成，包括：如下内容：

Excel关键字内容的测试逻辑

测试结果的返回。

综上所述，在本申请上述实施例中，通过服务数据文件和模板文件自动生成测试用例和测试脚本，相比纯手工编写测试用例，不仅降低了对测试人员在测试用例编写方面的要求，还降低了测试用例生成的时间，提升了测试效率。同时，自动生成的测试用例和测试脚本可以保证一定的一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

并且，多个Poseidon工具端和多个DWAutoTest端可以同时进行测试，还可以模拟1个或多个电子控制单元(Electronic Control Unit，ECU)、驱动控制单元(Drive ControlUnit，DCU)节点，满足多个测试端同时进行测试，测试用例部署环境更加灵活。由于测试用例和测试脚本是自动生成的，因此可以很容易地进行部署和管理，同时可以根据需要进行的修改和调整，提高测试效率。另外，通过仿真车内交互场景，可以更好地模拟实际使用场景，增加测试的真实性和可信度。

本申请实施例提供的基于车载SOA的测试方法，执行主体可以为基于车载SOA的测试装置。本申请实施例中以基于车载SOA的测试装置执行基于车载SOA的测试方法为例，说明本申请实施例提供的基于车载SOA的测试装置。

如图5所示，本申请实施例还提供了一种基于车载SOA的测试装置400，包括：

第一获取模块401，用于获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件；

第一生成模块402，用于根据所述服务数据文件以及所述模板文件，生成上位机的测试用例；

第二生成模块403，用于根据所述服务数据文件，生成下位机的测试脚本；

第一执行模块404，用于通过所述测试脚本执行所述测试用例，得到测试结果。

在本申请上述实施例中，通过获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件，根据所述服务数据文件以及所述模板文件，自动生成上位机的测试用例，根据所述服务数据文件，自动生成下位机的测试脚本，通过所述测试脚本执行所述测试用例，得到测试结果。相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，自动生成的测试用例框架和测试脚本具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

可选的，所述第一获取模块401，具体用于：

获取所述面向服务架构SOA的服务数据文件；

确定所述服务数据文件的文件类型；

根据所述文件类型，获取与所述服务数据文件对应的模板文件。

可选的，所述第一生成模块402，具体用于：

解析所述服务数据文件，得到第一测试数据；

将所述第一测试数据添加至所述模板文件中，得到上位机的测试用例框架；

根据所述测试用例框架，生成所述测试用例。

可选的，所述第一生成模块402在解析所述服务数据文件，得到第一测试数据时，具体用于：

在所述服务数据文件的文件类型为描述汽车电子系统的XML格式ARXML的文件的情况下，解析所述ARXML的文件，得到第一测试数据；

在所述服务数据文件的文件类型为接口定义语言FIDL的文件的情况下，通过通用应用程序编程接口生成器解析所述FIDL的文件，得到第一测试数据。

可选的，所述第二生成模块403，具体用于：

通过所述通用应用程序编程接口生成器生成通用应用程序编程接口接口；

根据所述FIDL的文件以及所述通用应用程序编程接口接口，生成所述测试脚本。

可选的，所述装置还包括：

第二获取模块，用于获取第二测试数据；

所述第一生成模块402在根据所述测试用例框架，生成所述测试用例时，具体用于：

根据所述第二测试数据和所述测试用例框架，生成所述测试用例。

可选的，所述第一执行模块404，具体用于：

将所述测试用例导入至测试工具Poseidon中；

通过导入测试用例的测试工具Poseidon向所述测试脚本下发测试指令；

控制所述测试脚本根据所述测试指令执行所述测试用例，得到测试结果。

可选的，所述测试脚本至少支持两种不同的操作系统。

综上所述，在本申请上述实施例中，通过服务数据文件和模板文件自动生成测试用例和测试脚本，相比纯手工编写测试用例，不仅降低了对测试人员在测试用例编写方面的要求，还降低了测试用例生成的时间，提升了测试效率。同时，自动生成的测试用例和测试脚本可以保证一定的一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

并且，多个Poseidon工具端和多个DWAutoTest端可以同时进行测试，还可以模拟1个或多个电子控制单元(Electronic Control Unit，ECU)、驱动控制单元(Drive ControlUnit，DCU)节点，满足多个测试端同时进行测试，测试用例部署环境更加灵活。由于测试用例和测试脚本是自动生成的，因此可以很容易地进行部署和管理，同时可以根据需要进行的修改和调整，提高测试效率。另外，通过仿真车内交互场景，可以更好地模拟实际使用场景，增加测试的真实性和可信度。

本申请实施例中的基于车载SOA的测试装置可以是电子设备，也可以是电子设备中的部件，例如集成电路或芯片。该电子设备可以是终端，也可以为除终端之外的其他设备。示例性的，电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、移动上网装置(Mobile Internet Device，MID)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、机器人、可穿戴设备、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，还可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的基于车载SOA的测试装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的基于车载SOA的测试装置能够实现图1至图4的方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图6所示，本申请实施例还提供一种电子设备500，包括处理器501和存储器502，存储器502上存储有可在所述处理器501上运行的程序或指令，该程序或指令被处理器501执行时实现上述基于车载SOA的测试方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图7为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备1000包括但不限于：射频单元1001、网络模块1002、音频输出单元1003、输入单元1004、传感器1005、显示单元1006、用户输入单元1007、接口单元1008、存储器1009、以及处理器1010等部件。

本领域技术人员可以理解，电子设备1000还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1010逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图7中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

其中，所述处理器1010，用于获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件；

根据所述服务数据文件以及所述模板文件，生成上位机的测试用例；

根据所述服务数据文件，生成下位机的测试脚本；

通过所述测试脚本执行所述测试用例，得到测试结果。

在本申请上述实施例中，通过获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件，根据所述服务数据文件以及所述模板文件，自动生成上位机的测试用例，根据所述服务数据文件，自动生成下位机的测试脚本，通过所述测试脚本执行所述测试用例，得到测试结果。相比纯手工编写测试用例，降低了测试用例生成的时间，提升了测试效率；并且，自动生成的测试用例框架和测试脚本具有一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

可选的，所述处理器1010在获取面向服务架构SOA的服务数据文件以及所述服务数据文件对应的模板文件时，具体用于：

获取所述面向服务架构SOA的服务数据文件；

确定所述服务数据文件的文件类型；

根据所述文件类型，获取与所述服务数据文件对应的模板文件。

可选的，所述处理器1010在根据所述服务数据文件以及所述模板文件，生成上位机的测试用例时，具体用于：

解析所述服务数据文件，得到第一测试数据；

将所述第一测试数据添加至所述模板文件中，得到上位机的测试用例框架；

根据所述测试用例框架，生成所述测试用例。

可选的，所述处理器1010在解析所述服务数据文件，得到第一测试数据时，具体用于：

在所述服务数据文件的文件类型为描述汽车电子系统的XML格式ARXML的文件的情况下，解析所述ARXML的文件，得到第一测试数据；

在所述服务数据文件的文件类型为接口定义语言FIDL的文件的情况下，通过通用应用程序编程接口生成器解析所述FIDL的文件，得到第一测试数据。

可选的，所述处理器1010在根据所述服务数据文件，生成下位机的测试脚本时，具体用于：

通过所述通用应用程序编程接口生成器生成通用应用程序编程接口接口；

根据所述FIDL的文件以及所述通用应用程序编程接口接口，生成所述测试脚本。

可选的，所述处理器1010还用于：

获取第二测试数据；

所述处理器1010在根据所述测试用例框架，生成所述测试用例时，具体用于：

根据所述第二测试数据和所述测试用例框架，生成所述测试用例。

可选的，所述处理器1010在通过所述测试脚本执行所述测试用例，得到测试结果时，具体用于：

将所述测试用例导入至测试工具Poseidon中；

通过导入测试用例的测试工具Poseidon向所述测试脚本下发测试指令；

控制所述测试脚本根据所述测试指令执行所述测试用例，得到测试结果。

可选的，所述测试脚本至少支持两种不同的操作系统。

综上所述，在本申请上述实施例中，通过服务数据文件和模板文件自动生成测试用例和测试脚本，相比纯手工编写测试用例，不仅降低了对测试人员在测试用例编写方面的要求，还降低了测试用例生成的时间，提升了测试效率。同时，自动生成的测试用例和测试脚本可以保证一定的一致性和规范性，减少了测试人员在测试用例编写方面的工作量和出错率。

并且，多个Poseidon工具端和多个DWAutoTest端可以同时进行测试，还可以模拟1个或多个电子控制单元(Electronic Control Unit，ECU)、驱动控制单元(Drive ControlUnit，DCU)节点，满足多个测试端同时进行测试，测试用例部署环境更加灵活。由于测试用例和测试脚本是自动生成的，因此可以很容易地进行部署和管理，同时可以根据需要进行的修改和调整，提高测试效率。另外，通过仿真车内交互场景，可以更好地模拟实际使用场景，增加测试的真实性和可信度。

应理解的是，本申请实施例中，输入单元1004可以包括图形处理器(GraphicsProcessing Unit，GPU)10041和麦克风10042，图形处理器10041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元1006可包括显示面板10061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板10061。用户输入单元1007包括触控面板10071以及其他输入设备10072中的至少一种。触控面板10071，也称为触摸屏。触控面板10071可包括触摸检测装置和触摸控制器两个部分。其他输入设备10072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

存储器1009可用于存储软件程序以及各种数据。存储器1009可主要包括存储程序或指令的第一存储区和存储数据的第二存储区，其中，第一存储区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器1009可以包括易失性存储器或非易失性存储器，或者，存储器1009可以包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请实施例中的存储器1009包括但不限于这些和任意其它适合类型的存储器。

处理器1010可包括一个或多个处理单元；可选的，处理器1010集成应用处理器和调制解调处理器，其中，应用处理器主要处理涉及操作系统、用户界面和应用程序等的操作，调制解调处理器主要处理无线通信信号，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器1010中。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述基于车载SOA的测试方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器ROM、随机存取存储器RAM、磁碟或者光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述基于车载SOA的测试方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述基于车载SOA的测试方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。