CN112198861A - 车载终端的应用程序测试方法 - Google Patents

Abstract

本申请涉及一种车载终端的应用程序测试方法，该方法包括：在需要对车载终端内置的待测应用程序进行测试的情况下，车载终端获取模拟数据通路切换消息，其中，车载终端配置有用于与车身数据模拟器通讯的模拟数据通路；车载终端根据模拟数据通路切换消息，将获取车身数据的数据通路切换为模拟数据通路，并通过模拟数据通路获取模拟的车身数据，其中，模拟的车身数据由车身数据模拟器通过模拟方式生成；车载终端根据模拟的车身数据测试车载终端内置的待测应用程序；根据车载终端内置的待测应用程序的运行结果，生成测试报告。通过本申请，解决了相关技术中应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低的问题，提高了开发效率。

Description

车载终端的应用程序测试方法

技术领域

本申请涉及车辆控制领域，特别是涉及车载终端的应用程序测试方法。

背景技术

车载终端上可以运行有空调应用程序、倒车影像应用程序等。车载终端通常通过车辆的微控制单元(Microcontroller Unit，简称为MCU)解析实测车辆的车身数据来获取与车辆或者车辆的内置设备有关的数据，这些车身数据可以被提供给车载终端上运行的应用程序以实现相应功能或者进行相应的控制。因此，这些应用程序在开发过程中的功能调试需要在实际车辆环境中进行，并且调试过程中获取车身数据依赖于车辆的MCU。

MCU与车载终端以及其他传感器设备之间的通讯通常采用标准的通讯协议，例如控制器局域网络(Controller Area Network，简称为CAN)总线协议，但即使是标准的通讯协议，在不同车辆中CAN总线的信号(例如波特率)等也会存在差别，因此，在实际车辆环境中对应用程序进行功能调试之前，仍需要对MCU进行适配调试，以使得MCU与车载终端的通讯协议适配，这就使得车载终端的应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低。

目前针对相关技术中应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低的问题，尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种车载终端的应用程序测试方法，以至少解决相关技术中应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低的问题。

第一方面，本申请实施例提供了一种车载终端的应用程序测试方法，包括：在需要对车载终端内置的待测应用程序进行测试的情况下，所述车载终端获取模拟数据通路切换消息，其中，所述车载终端配置有用于与车身数据模拟器通讯的模拟数据通路；所述车载终端根据所述模拟数据通路切换消息，将获取车身数据的数据通路切换为模拟数据通路，并通过所述模拟数据通路获取模拟的车身数据，其中，所述模拟的车身数据由所述车身数据模拟器通过模拟方式生成；所述车载终端根据所述模拟的车身数据测试所述车载终端内置的待测应用程序；根据所述车载终端内置的待测应用程序的运行结果，生成测试报告。

在其中一些实施例中，所述车载终端还配置有用于与车辆的微控制单元通讯的MCU数据通路；在所述车载终端获取所述模拟数据通路切换消息之前，所述方法还包括：所述车载终端通过所述MCU数据通路获取实测的车身数据，其中，所述实测的车身数据是由所述微控制单元通过解析所述车辆的传感器数据获取的；所述车载终端根据所述实测的车身数据，运行所述车载终端内置的所述待测应用程序。

在其中一些实施例中，所述车载终端还配置有用于与车辆的微控制单元通讯的MCU数据通路；在根据所述车载终端内置的待测应用程序的运行结果，生成测试报告之后，所述方法还包括：所述车载终端获取MCU数据通路切换消息；所述车载终端根据所述MCU数据通路切换消息，将获取车身数据的数据通路切换为所述MCU数据通路，并通过所述MCU数据通路获取实测的车身数据，其中，所述实测的车身数据是由所述微控制单元通过解析所述车辆的传感器数据获取的；所述车载终端根据所述实测的车身数据，运行所述车载终端内置的所述待测应用程序。

在其中一些实施例中，所述车载终端获取模拟数据通路切换消息包括：所述车载终端通过安卓操作***调试工具与所述车身数据模拟器连接；所述车载终端建立用于与所述车身数据模拟器进行双向数据通信的通信连接，并获取由所述车身数据模拟器生成的所述模拟数据通路切换消息。

在其中一些实施例中，所述模拟数据通路采用的通讯协议是由所述车身数据模拟器与所述车载终端预先约定的标准协议或者私有协议，和/或所述MCU数据通路采用的通讯协议为标准协议。

在其中一些实施例中，所述模拟的车身数据和所述实测的车身数据具有相同的数据格式，所述数据格式是与所述车载终端内置的待测应用程序预先约定的。

在其中一些实施例中，所述车身数据包括车辆内置设备的控制数据及状态数据，和/或车辆的控制数据及状态数据。

在其中一些实施例中，所述模拟数据通路切换消息包括：所述模拟数据通路的标识信息及校验码；所述车载终端根据所述模拟数据通路切换消息，将获取车身数据的数据通路切换为所述模拟数据通路包括：所述车载终端根据所述校验码校验所述模拟数据通路切换消息是否完整，并在校验到所述模拟数据通路切换消息完整的情况下，根据所述模拟数据通路的标识信息，确定将获取车身数据的数据通路切换为所述模拟数据通路。

在其中一些实施例中，所述MCU数据通路切换消息包括：所述MCU数据通路的标识信息及校验码；所述车载终端根据所述MCU数据通路切换消息，将获取车身数据的数据通路切换为所述MCU数据通路，并通过所述MCU数据通路获取实测的车身数据包括：所述车载终端根据所述校验码校验所述MCU数据通路切换消息是否完整，并在校验到所述MCU数据通路切换消息完整的情况下，根据所述MCU数据通路的标识信息，确定将获取车身数据的数据通路切换为所述MCU数据通路。

在其中一些实施例中，在根据所述车载终端内置的待测应用程序的运行结果，生成测试报告之后，所述方法还包括：所述车载终端通过所述模拟数据通路将所述测试报告发送给所述车身数据模拟器。

在其中一些实施例中，所述方法还包括：所述车载终端根据所述车载终端的性能数据生成所述车载终端的压力测试报告，并通过所述模拟数据通路将所述压力测试报告发送给所述车身数据模拟器。

相比于相关技术，本申请实施例提供的车载终端的应用程序测试方法，解决了相关技术中应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低的问题，提高了应用程序的开发效率。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的车载终端的硬件结构框图；

图2是根据本申请实施例的车载终端的应用程序测试方法的流程图；

图3是根据本申请优选实施例的车载终端的应用程序测试方法的流程图；

图4是根据本申请实施例的PC端模拟器工具的图形用户界面的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指大于或者等于两个。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本实施例提供的方法实施例可以在车载终端中执行。图1是本发明实施例的车载终端的硬件结构框图。如图1所示，该车载终端可以包括一个或多个处理器102(图1中仅示出一个)和用于存储数据的存储器104。其中，处理器102可以包括但不限于微控制单元(Microcontroller Unit，简称为MCU)或可编程逻辑器件(Field Programmable GateArray，简称为FPGA)等的处理装置。

可选地，上述车载终端还可以包括用于通信功能的传输设备106以及输入输出设备108。其中，输入输出设备108例如可以包括但不限于以下至少之一的输入设备：键盘、鼠标、触控板、麦克风、传感器等。输入输出设备108还可以包括但不限于以下至少之一的输出设备：显示器、喇叭、灯、振动反馈装置等。

本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述车载终端的结构造成限定。例如，车载终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的车载终端的应用程序测试方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至车载终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括车载终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

本实施例提供了一种车载终端的应用程序测试方法，图2是根据本申请实施例的车载终端的应用程序测试方法的流程图，如图2所示，该流程包括如下步骤：

步骤S201，在需要对车载终端内置的待测应用程序进行测试的情况下，车载终端获取模拟数据通路切换消息，其中，车载终端配置有用于与车身数据模拟器通讯的模拟数据通路。

上述的模拟数据通路用于获取模拟的车身数据，应用于车载终端的应用程序测试。为了让车载终端能够在实际车辆场景中根据实测的车身数据来运行应用程序，在车载终端上还可以配置有用于与车辆的微控制单元通讯的MCU数据通路。在车载终端获取模拟数据通路切换消息之前，车载终端处于非测试场景下，此时车载终端通过MCU数据通路获取实测的车身数据，这些实测的车身数据是由微控制单元通过解析车辆的相关传感器数据获取的；车载终端根据这些实测的车身数据，运行车载终端内置的待测应用程序。

在其中一些实施例中，上述的模拟数据通路切换消息可以是由车载终端的输入设备获取的。车载终端可以通过诸如触摸屏、键盘等输入设备接收用户的输入信息，并判断用户的输入信息是否是用于指示进行模拟数据通路切换，若是，则确定接收到模拟数据通路切换消息。通过该方式，用户可以通过车载终端提供的输入设备获取模拟数据通路切换消息。

在另一些实施例中，车载终端并不必需提供输入设备来获取模拟数据通路切换消息，或者模拟数据通路切换消息不能够从车载终端的输入设备获取。如此设置的目的，是避免在车辆实际使用场景下，直接从车载终端的输入设备能够获取模拟数据通路切换消息而导致的获取车身数据的数据通路被错误切换。作为替代地，为了获取模拟数据通路切换消息，可以将车载终端与测试用设备建立连接，并通过隐式或者显式的方式获取模拟数据通路切换消息。

其中，显式的方式获取模拟数据通路切换消息例如可以是：通过测试用设备向车载终端发送模拟数据通路切换消息。其中，该模拟数据通路切换消息中可以携带有用于表示切换到模拟数据通路的预设标识信息，或者携带有模拟数据通路的标识信息；车载终端根据模拟数据通路中携带的预设标识信息或者模拟数据通路的标识信息，来判断该消息为模拟数据通路切换消息。

为了进一步简化操作，测试人员也可以不显式地输入表示该模拟数据通路切换消息的信号，或者接收由车身数据模拟器发送的模拟数据通路切换消息，而是采用隐式的方式获取模拟数据通路切换消息。

例如，在车身数据模拟器与车载终端成功建立通信连接的情况下，车载终端识别车身数据模拟器的身份信息，在识别到车身数据模拟器的身份信息时，确定当前场景为测试场景，从而确定获取到模拟数据通路切换消息。

又例如，由车载终端根据与车身数据模拟器之间的通信连接状态。当测试人员成功建立车载终端与车身数据模拟器之间的通信连接时，车载终端隐式地获取到模拟数据通路切换消息。

再例如，根据通信连接状态及车身数据模拟器上相关应用程序的运行或开启状态来获取模拟数据通路切换消息。在车载终端与车身数据模拟器之间建立通信连接后，当车身数据模拟器上与车身数据模拟相关的应用程序被开启时，车载终端根据该应用程序的开启状态隐式地获取到模拟数据通路切换消息。

在本实施例中，车载终端可以是与车辆一体的电子装置，例如，该车载终端可以是车辆的中控台设备。车载终端也可以是与车辆分体的电子装置，例如通过车载底座安装于车辆中的移动终端设备或者其他的智能终端设备。车载终端的操作***不限于特定的操作***，例如其操作***可以是安卓操作***、iOS操作***、视窗(Windows)操作***或者Linux操作***等。

步骤S202，车载终端根据模拟数据通路切换消息，将获取车身数据的数据通路切换为模拟数据通路，并通过模拟数据通路获取模拟的车身数据，其中，模拟的车身数据由车身数据模拟器通过模拟方式生成。

在步骤S202中，车载终端根据校验码校验模拟数据通路切换消息是否完整，并在校验到模拟数据通路切换消息完整的情况下，根据模拟数据通路的标识信息，确定将获取车身数据的数据通路切换为模拟数据通路。

在上述步骤S201中通过显式的方式获取模拟数据通路切换消息时，为了避免模拟数据通路切换消息在传输过程中受到干扰等因素导致车载终端接收到的模拟数据通路切换消息不完整，在模拟数据通路切换消息的预设位置还携带有用于校验数据完整性的校验码。

例如，该校验码可以是循环冗余校验(Cyclic Redundancy Check，简称为CRC)校验码。在测试用设备对模拟数据通路切换消息中的有效数据部分(该部分包括模拟数据通路的标识信息)进行循环冗余计算，得到一个CRC校验值，并将该值附在模拟数据通路切换消息中发送给车载终端，车载终端在接收到模拟数据通路切换消息后，使用与测试用设备所使用的相同算法进行循环冗余计算，得到一个CRC校验值。如果计算得到的CRC校验值与模拟数据通路切换消息中携带的CRC校验值一致，则表明接收到的模拟数据通路切换消息中有效数据部分(模拟数据通路的标识信息)是正确数据，在此情况下，则可以根据模拟数据通路切换消息中携带的模拟数据通路的标识信息，确定将获取车身数据的数据通路切换为模拟数据通路。如果不一致则表明接收到的模拟数据通路切换消息中有效数据部分不正确，此时将会丢弃该模拟数据通路切换消息，等待测试用设备重传或者通知测试用设备重传模拟数据通路切换消息。通过在模拟数据通路切换消息中携带校验值，提高了模拟数据通路切换消息传输的可靠性。上述的测试用设备可以是车身数据模拟器。

在本实施例中，车身数据模拟器通过计算机模拟的方式生成模拟的车身数据。车身数据模拟器可以是具有输入设备的电子装置，该车身数据模拟器通过将测试人员从输入设备输入的信号或者数据转换为模拟的车身数据。在一些实施例中，车身数据模拟器优选地还包括显示器，或者车身数据模拟器的输入设备为触摸显示屏。车身数据模拟器可以通过其上运行的应用程序将测试人员从输入设备输入的信号或者数据转换为模拟的车身数据，该应用程序可以提供图形用户界面来接收及显示测试人员输入的信号或者数据。车身数据模拟器的操作***也不限于特定的操作***，例如其操作***可以是安卓操作***、iOS操作***、视窗操作***或者Linux操作***等。

在其中一些实施例中，车载终端的操作***为开源的安卓操作***、车身数据模拟器的操作***为视窗操作***。其中，安卓操作***具有良好的应用程序开发平台，并且基于其开源的特点方便了车载终端的功能扩展，尤其适用于车载终端。在车载终端获取模拟数据通路切换消息之前，车载终端与车身数据模拟器建立单向或者双向的通信连接。

以车载终端为安卓操作***为例，在步骤S201中，车载终端可以通过安卓操作***调试工具(安卓调试桥工具，简称为ADB)与车身数据模拟器连接，然后车载终端建立用于车载终端与车身数据模拟器之间进行双向数据通信的通信连接(例如socket通信连接)。其中，ADB用于与运行安卓操作***的设备进行通信，并提供功能多样的命令行工具。而socket(套接字)通信连接则通过套接字建立车载终端与车身数据模拟器之间的双向通信。通过上述的socket通信连接获取由车身数据模拟器生成的模拟数据通路切换消息。

在车载终端与车身数据模拟器之间建立通信连接后，车载终端则使用其配置的用于与车身数据模拟器通讯的模拟数据通路从车身数据模拟器获取模拟的车身数据。

本实施例中的车身数据包括但不限于车辆的内置设备的控制数据及状态数据，和/或车辆的控制数据及状态数据。其中，车辆的内置设备是指车辆的附加的设备，例如车载空调、行车记录仪、倒车影像等设备。车辆的控制数据及状态数据则包括车辆自身的运行相关的数据，例如车辆的控制数据及状态数据包括但不限于以下至少之一：车辆仪表数据(车速、油量、车速、档位等)、车辆电池状态数据等。

在其中一些实施例中，模拟数据通路采用的通讯协议是由车身数据模拟器与车载终端预先约定的通讯协议，该通讯协议可以是诸如控制器局域网络(Controller AreaNetwork，简称为CAN)总线协议等标准协议，也可以是私有协议，在本实施例中并不限定。并且，对于不同的车载终端而言，可以分别与车身数据模拟器预先约定相同的通讯协议，从而保证对不同的车载终端的测试过程使用统一的通讯协议，避免了通讯协议不统一而导致的在车载终端的应用程序的调试测试之前需要进行通讯协议适配的问题。

步骤S203，车载终端根据模拟的车身数据测试车载终端内置的待测应用程序。

在本实施例中，在获得由车身数据模拟器模拟得到的模拟的车身数据之后，车载终端内置的待测应用程序根据实现其相应功能而预先设定的逻辑运行，并产生运行结果，实现对车载终端内置的待测应用程序的功能的验证和测试。

步骤S204，根据车载终端内置的待测应用程序的运行结果，生成测试报告。

通过上述步骤S201至步骤S204，根据车身数据模拟器模拟得到的模拟的车身数据运行车载终端内置的待测应用程序，使得车载终端的调试过程与MCU的适配调试过程解耦，解决了相关技术中应用程序的开发调试受制于MCU的适配调试，导致应用程序的开发效率低的问题，提高了应用程序的开发效率。

本实施例提供的车载终端的应用程序测试方法可以用于验证车载终端内置的待测应用程序的功能，还可以用于车载终端的压力测试。例如，在其中一些实施例中，在车载终端切换到模拟数据通路且车载终端根据模拟的车身数据测试车载终端内置的待测应用程序，产生了待测应用程序的运行结果以后，车载终端还可以生成测试报告，并通过模拟数据通路将生成的测试报告发送给车身数据模拟器。其中，测试报告包括诸如应用程序的运行状态数据和/或运行结果数据等。

在另一些实施例中，还可以对车载终端进行其他的测试，例如车载终端的压力测试。在进行车载终端的压力测试时，可以通过在车载终端内同时运行多个待测应用程序，然后收集车载终端的性能数据，根据车载终端的性能数据生成车载终端的压力测试报告，并在数据通路切换到模拟数据通路的情况下，通过模拟数据通路将压力测试报告发送给车身数据模拟器。上述的性能数据包括但不限于以下至少之一：响应时间、CPU利用率、内存利用率等。压力测试报告可以用于评估车载终端的压力测试结果。

在其中一些实施例中，车载终端还配置有用于与车辆的微控制单元(MCU)通讯的MCU数据通路；车载终端在非测试场景下，通过MCU数据通路获取实测的车身数据。其中，实测的车身数据是由MCU通过解析车辆的传感器数据获取的。在车辆上配置有各种传感器用来测量车辆的车身数据，这些车身数据被称为实测的车身数据。车辆的MCU与车辆中安装的各种传感器通讯，分别获取这些传感器的传感器数据。车载终端则通过车载终端与MCU之间的MCU数据通路获取这些实测的车身数据。

本实施例中的车身数据包括但不限于车辆的内置设备的控制数据及状态数据，和/或车辆的控制数据及状态数据。其中，车辆的内置设备是指车辆的附加的设备，例如车载空调、行车记录仪、倒车影像等设备。车辆的控制数据及状态数据则包括车辆自身的运行相关的数据，例如车辆的控制数据及状态数据包括但不限于以下至少之一：车辆仪表数据(车速、油量、车速、档位等)、车辆电池状态数据等。

在非测试场景下，车载终端根据实测的车身数据，运行车载终端内置的待测应用程序。其中，非测试场景包括车载终端获取模拟数据通路切换消息之前对应的场景，也包括车载终端获取到MCU数据通路切换消息之后对应的场景。

例如，在车载终端获取模拟数据通路切换消息之前，车载终端通过MCU数据通路获取实测的车身数据，其中，实测的车身数据是由微控制单元通过解析车辆的传感器数据获取的；车载终端根据实测的车身数据，运行车载终端内置的待测应用程序。

又例如，在根据车载终端内置的待测应用程序的运行结果，生成测试报告之后，车载终端获取MCU数据通路切换消息；车载终端根据MCU数据通路切换消息，将获取车身数据的数据通路切换为MCU数据通路，并通过MCU数据通路获取实测的车身数据，其中，实测的车身数据是由微控制单元通过解析车辆的传感器数据获取的；车载终端根据实测的车身数据，运行车载终端内置的待测应用程序。

其中，MCU数据通路切换消息用于指示车载终端通过MCU数据通路获取实测的车身数据。该MCU数据通路切换消息可以是由车载终端的输入设备获取的。

类似地，在上述实施例中，MCU数据通路切换消息也可以是显式的方式获取的或者隐式的方式获取的。

其中，显式的方式获取MCU数据通路切换消息例如可以是：通过测试用设备向车载终端发送MCU数据通路切换消息。其中，该MCU数据通路切换消息中可以携带有用于表示切换到MCU数据通路的预设标识信息，或者携带有MCU数据通路的标识信息；车载终端根据MCU数据通路中携带的预设标识信息或者MCU数据通路的标识信息，来判断该消息为MCU数据通路切换消息。

在上述通过显式的方式获取MCU数据通路切换消息时，为了避免MCU数据通路切换消息在传输过程中受到干扰等因素导致车载终端接收到的MCU数据通路切换消息不完整，在MCU数据通路切换消息的预设位置还携带有用于校验数据完整性的校验码。

例如，该校验码可以是循环冗余校验(Cyclic Redundancy Check，简称为CRC)校验码。在测试用设备对MCU数据通路切换消息中的有效数据部分(该部分包括MCU数据通路的标识信息)进行循环冗余计算，得到一个CRC校验值，并将该值附在MCU数据通路切换消息中发送给车载终端，车载终端在接收到MCU数据通路切换消息后，使用与测试用设备所使用的相同算法进行循环冗余计算，得到一个CRC校验值。如果计算得到的CRC校验值与MCU数据通路切换消息中携带的CRC校验值一致，则表明接收到的MCU数据通路切换消息中有效数据部分(MCU数据通路的标识信息)是正确数据，在此情况下，则可以根据MCU数据通路切换消息中携带的MCU数据通路的标识信息，确定将获取车身数据的数据通路切换为MCU数据通路。如果不一致则表明接收到的MCU数据通路切换消息中有效数据部分不正确，此时将会丢弃该MCU数据通路切换消息，等待测试用设备重传或者通知测试用设备重传MCU数据通路切换消息。通过在MCU数据通路切换消息中携带校验值，提高了MCU数据通路切换消息传输的可靠性。上述的测试用设备可以是车身数据模拟器。

为了进一步简化操作，测试人员也可以不显式地输入表示该MCU数据通路切换消息的信号，或者接收由车身数据模拟器发送的MCU数据通路切换消息，而是采用隐式的方式获取MCU数据通路切换消息。

例如，在车身数据模拟器与车载终端断开通信连接的情况下，车载终端确定当前场景为非测试场景，从而确定获取到MCU数据通路切换消息。

为了保证兼容性，MCU数据通路采用的通讯协议为标准协议。模拟的车身数据和实测的车身数据具有相同的数据格式，并且该数据格式是与车载终端内置的待测应用程序预先约定的。

下面通过优选实施例对本申请进行描述和说明。

在相关技术中，车载终端的测试依赖于MCU，并且测试人员验证车载终端的应用程序的功能都是实车验证，实车验证需要搭建相关测试环境，比较费时且流程麻烦，实车操作测试效率也低。并且，实车信号都是触发上报，测试人员无法进行压力测试以及特殊场景极限测试，导致不能测试上层应用稳定性以及性能。

为了解决上述问题，本优选实施例提供了一种车载终端的应用程序测试方法。该车载终端的应用程序测试方法通过PC端模拟器工具(相当于上述的车身数据模拟器)运行时，发送通路切换加密协议数据通知车载终端由MCU数据通路切换到模拟器数据通路。模拟器工具提供一套标准平台化的车身数据协议供上层应用使用，从而不需要车载终端的应用程序再根据不同车辆适配，可以脱离MCU和实车环境，实现开发时间可控和便捷。模拟器工具还可以提供压力测试和特殊场景极限测试，方便测试人员压测应用程序及车载终端的稳定性。模拟器工具退出时，发送通路切换加密协议数据通知车载终端由模拟器数据通路切换到MCU数据通路。通过加密协议可以实现MCU数据通路和模拟器数据通路自由切换，也可以确保数据通路安全性。

在本优选实施例中，当PC端模拟器工具运行时，发送加密协议数据通知车载终端，车载终端接收到协议数据并解析，把数据通路从MCU数据通路切换到模拟器数据通路，此时开发人员和测试人员可通过模拟器工具模拟车身数据的收发，实现应用程序的开发和测试，退出PC端模拟器工具时，发送切换到MCU数据通路加密协议数据到车载终端，通知车载终端从模拟器数据通路切换到MCU数据通路。

图3是根据本申请优选实施例的车载终端的应用程序测试方法的流程图，如图3所示，该流程包括如下步骤：

步骤S301，车载终端启动时同时创建模拟器数据通路和MCU数据通路，默认使用MCU数据通路来获取车身数据。

模拟器数据通路提供一套用于车速、档位等车身数据模拟的信号协议，该信号协议与CAN协议可以是不同协议，是模拟器应用与车载终端预先约定的，专用于接收模拟器应用的数据的协议。该协议中数据格式可以根据车身数据的类型和类型中功能确定。例如，数据格式包括：信号类型和信号类型的功能项。数据格式可以用若干位表示，以10000001为例，前4位表示信号类型(例如空调信号为1000，车速可能为2000)，后四位表示功能项(例如，空调开关为0001、空调风速为0002)。

车载终端通过读取MCU解析的实车CAN信号获取的车身数据，用于提供实车CAN信号的数据通路即为MCU数据通路。该MCU数据通路的数据格式可以基于CAN协议，为现有协议。

在本实施例中，车载终端启动时默认通过MCU数据通路获取车身数据；若模拟器应用启动运行时，会通过下述的S302发送通路切换指令，执行后续的步骤。

在本实施例中，车身数据包括但不限于：车辆空调的控制信号，车辆仪表数据、车身电源状态、车辆中的传感器数据，比如车速、档位、车轮转向角等。在图4中示出了PC端模拟器工具的图形用户界面的示意图，如图4所示，该图形用户界面包括多个选项卡，例如“电源状态”、“360环视”、“雷达”、“车辆设置”、“空调”等，每个选项卡用于显示和设置相应的车身数据。在图4中示出的电源状态选项卡中包括发动机状态：停止(STOP)、曲轴启动(CRANK)和运行(RUNNING)；还包括自适应巡航控制电源(Adaptive Cruise Control简称为ACC)状态：ACC关闭(ACC OFF)、ACC、曲轴启动(CRANK)和开启(START)。

步骤S302，PC端模拟器工具与车载终端连接ADB后，通过socket(软接口)进行通信，当PC端模拟器工具运行时发送切换到模拟器数据通路加密协议数据到车载终端，加密协议数据可以由数据通路标识值和CRC8校验码。

ADB是指集成在车载终端的安卓***中的调试工具。

PC端模拟器工具运行时发生切换指令，切换指令携带有数据通路加密协议数据，该数据包括数据通路标识值和CRC8校验码。

步骤S303，车载终端接收到PC端发送的加密协议按照CRC8校验码进行解析，解析协议判定是由PC端发送的切换到模拟器数据通路指令，则把当前数据通路由MCU数据通路切换到模拟器数据通路。

解析后获取数据通路标识值，根据数据通路标识值(指示是当前待切换数据通路是模拟器数据通路还是MCU数据通路)车载终端将MCU数据通路切换到模拟器数据通路。

步骤S304，车载终端将数据通路切换到模拟器数据通路，PC端模拟器工具与车载终端建立通信之后，使用PC端模拟器工具可以模拟发送车速、电源状态、档位等车身信息供应用开发调试，还可以提供信号周期上报以便测试人员进行压力测试。

其中，车速、电源状态、档位等车身信息是通过PC端模拟器工具的用户界面输入的信息得到的模拟车辆的相关信息，并非车辆当前实际的车身数据。

其中，压力测试内容包括：车载终端的***稳定性(例如，车载终端的电源管理进程、车身数据解析上报进程)和内存资源(车载终端的CPU占用率、内存占用空间大小)消耗。

步骤S305，退出PC端模拟器工具时发送切换到MCU数据通路加密协议数据到车载终端，加密协议数据由数据通路标识值和CRC8校验码组成。

步骤S306，车载终端接收到PC端发送的加密协议数据，按照CRC8校验码进行解析，解析协议判定是由PC端发送的切换到MCU数据通路请求，则把当前数据通路由模拟器数据通路切换到MCU数据通路。

本实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，在需要对车载终端内置的待测应用程序进行测试的情况下，车载终端获取模拟数据通路切换消息，其中，车载终端配置有用于与车身数据模拟器通讯的模拟数据通路。

S2，车载终端根据模拟数据通路切换消息，将获取车身数据的数据通路切换为模拟数据通路，并通过模拟数据通路获取模拟的车身数据，其中，模拟的车身数据由车身数据模拟器通过模拟方式生成。

S3，车载终端根据模拟的车身数据测试车载终端内置的待测应用程序。

S4，根据车载终端内置的待测应用程序的运行结果，生成测试报告。

需要说明的是，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

本领域的技术人员应该明白，以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种车载终端的应用程序测试方法，其特征在于包括：

在需要对车载终端内置的待测应用程序进行测试的情况下，所述车载终端获取模拟数据通路切换消息，其中，所述车载终端配置有用于与车身数据模拟器通讯的模拟数据通路；

所述车载终端根据所述模拟数据通路切换消息，将获取车身数据的数据通路切换为模拟数据通路，并通过所述模拟数据通路获取模拟的车身数据，其中，所述模拟的车身数据由所述车身数据模拟器通过模拟方式生成；

所述车载终端根据所述模拟的车身数据测试所述车载终端内置的待测应用程序；

根据所述车载终端内置的待测应用程序的运行结果，生成测试报告。

2.根据权利要求1所述的车载终端的应用程序测试方法，其特征在于，所述车载终端还配置有用于与车辆的微控制单元通讯的MCU数据通路；在所述车载终端获取所述模拟数据通路切换消息之前，所述方法还包括：

所述车载终端通过所述MCU数据通路获取实测的车身数据，其中，所述实测的车身数据是由所述微控制单元通过解析所述车辆的传感器数据获取的；

所述车载终端根据所述实测的车身数据，运行所述车载终端内置的所述待测应用程序。

3.根据权利要求1所述的车载终端的应用程序测试方法，其特征在于，所述车载终端还配置有用于与车辆的微控制单元通讯的MCU数据通路；在根据所述车载终端内置的待测应用程序的运行结果，生成测试报告之后，所述方法还包括：

所述车载终端获取MCU数据通路切换消息；

所述车载终端根据所述MCU数据通路切换消息，将获取车身数据的数据通路切换为所述MCU数据通路，并通过所述MCU数据通路获取实测的车身数据，其中，所述实测的车身数据是由所述微控制单元通过解析所述车辆的传感器数据获取的；

所述车载终端根据所述实测的车身数据，运行所述车载终端内置的所述待测应用程序。

4.根据权利要求1所述的车载终端的应用程序测试方法，其特征在于，所述车载终端获取模拟数据通路切换消息包括：

所述车载终端通过安卓操作***调试工具与所述车身数据模拟器连接；

所述车载终端建立用于与所述车身数据模拟器进行双向数据通信的通信连接，并获取由所述车身数据模拟器生成的所述模拟数据通路切换消息。

5.根据权利要求2所述的车载终端的应用程序测试方法，其特征在于，所述模拟数据通路采用的通讯协议是由所述车身数据模拟器与所述车载终端预先约定的标准协议或者私有协议，和/或所述MCU数据通路采用的通讯协议为标准协议。

6.根据权利要求2所述的车载终端的应用程序测试方法，其特征在于，所述模拟的车身数据和所述实测的车身数据具有相同的数据格式，所述数据格式是与所述车载终端内置的待测应用程序预先约定的。

7.根据权利要求1至6中任一项所述的车载终端的应用程序测试方法，其特征在于，所述车身数据包括车辆内置设备的控制数据及状态数据，和/或车辆的控制数据及状态数据。

8.根据权利要求1至6中任一项所述的车载终端的应用程序测试方法，其特征在于，所述模拟数据通路切换消息包括：所述模拟数据通路的标识信息及校验码；所述车载终端根据所述模拟数据通路切换消息，将获取车身数据的数据通路切换为所述模拟数据通路包括：

所述车载终端根据所述校验码校验所述模拟数据通路切换消息是否完整，并在校验到所述模拟数据通路切换消息完整的情况下，根据所述模拟数据通路的标识信息，确定将获取车身数据的数据通路切换为所述模拟数据通路。

9.根据权利要求3所述的车载终端的应用程序测试方法，其特征在于，所述MCU数据通路切换消息包括：所述MCU数据通路的标识信息及校验码；所述车载终端根据所述MCU数据通路切换消息，将获取车身数据的数据通路切换为所述MCU数据通路，并通过所述MCU数据通路获取实测的车身数据包括：

所述车载终端根据所述校验码校验所述MCU数据通路切换消息是否完整，并在校验到所述MCU数据通路切换消息完整的情况下，根据所述MCU数据通路的标识信息，确定将获取车身数据的数据通路切换为所述MCU数据通路。

10.根据权利要求1至6中任一项所述的车载终端的应用程序测试方法，其特征在于，在根据所述车载终端内置的待测应用程序的运行结果，生成测试报告之后，所述方法还包括：

所述车载终端通过所述模拟数据通路将所述测试报告发送给所述车身数据模拟器。

Images