车载系统的测试方法、装置、系统、设备、介质及产品

技术领域

本申请涉及车载系统测试控制技术领域，尤其涉及一种车载系统的测试方法、装置、系统、设备、介质及产品。

背景技术

随着汽车科技的发展，智能座舱逐渐成为汽车智能化发展的重点，智能座舱可以实现更加全面的人机交互，在此背景下，作为智能座舱重要系统之一的车载信息娱乐(In-Vehicle Infotainment，IVI)系统显得尤为重要，现如今，市场上已经有各种车载IVI系统测试控制设备，例如模拟鼠标、键盘、测试仪器等的测试控制设备，然而，这些测试控制设备通常需要专业的软件和硬件支持，而且难以掌握，对于研发，尤其对开发或测试人员来说不太友好。

现有技术中，可以基于安卓Android系统提供各种应用程序和硬件接口，如触摸屏、蓝牙、无线保真(Wireless Fidelity，Wi-Fi)、全球定位系统(Global PositioningSystem，GPS)等实现车载IVI系统的交互控制。

但是，上述Android系统的材料和实现的成本较高，且功能有限，导致系统的稳定性和响应速度较差。

发明内容

本申请提供一种车载系统的测试方法、装置、系统、设备、介质及产品，用于解决现有车载系统测试，所需的材料和实现的成本较高，且功能有限，导致系统的稳定性和响应速度较差的问题。

第一方面，本申请提供一种车载系统的测试方法，所述方法包括：

获取测试执行脚本；所述测试执行脚本为控制任意一种被控制设备进行测试操作的编程语言；

基于微控制器板的至少一个输入接口，传输所述测试执行脚本，以使所述微控制器板对所述测试执行脚本进行信号转换，得到模拟信号；所述微控制器板用于提供多种功能类型的接口，以实现与任意一种被控制设备的通信和交互控制；

基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，以使所述被控制设备执行所述模拟信号进行测试；

接收所述被控制设备反馈的响应信息，基于所述响应信息确定车载系统的测试是否发生异常；所述响应信息为所述被控制设备执行所述模拟信号后生成的结果信息。

可选的，所述测试执行脚本包括第一测试执行脚本和/或第二测试执行脚本；获取测试执行脚本，包括：

获取用户输入的第一测试执行脚本；所述第一测试执行脚本基于用户的编写操作进行设置；

和/或，获取用户输入的用户需求和/或应用环境，基于所述用户需求和/或应用环境调用对应的第二测试执行脚本；所述第二测试执行脚本与所述用户需求和/或应用环境存在映射关系，提前存储于数据库中。

可选的，基于微控制器板的至少一个输入接口，传输所述测试执行脚本，包括：

获取所述测试执行脚本的应用场景和/或数据类型；

基于所述应用场景和/或数据类型，确定传输所述测试执行脚本的至少一个输入接口；

基于所述至少一个输入接口传输所述测试执行脚本。

可选的，基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，包括：

对所述模拟信号进行解析，得到所述模拟信号的发送次数和/发送形式；所述发送形式包括：连续发送和间隔预设时间发送；

基于所述发送次数和/发送形式，将所述模拟信号发送至被控制设备。

可选的，接收所述被控制设备反馈的响应信息，包括：

基于所述微控制器板的接收接口接收所述被控制设备反馈的响应信息；所述被控制设备包括至少一种类型的车载主机。

可选的，所述方法还包括：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备；

获取所述异常设备在车载系统中的位置信息，基于所述位置信息生成提示信息；

将所述提示信息和所述异常设备的位置进行可视化显示，以提示用户对所述异常设备进行检修。

可选的，所述方法还包括：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备的异常等级；

当所述异常等级不满足预设条件时，生成预警信息；所述预警信息包括语音信息和/或文字信息。

第二方面，本申请提供一种车载系统的测试装置，所述装置包括：

获取模块，用于获取测试执行脚本；所述测试执行脚本为控制任意一种被控制设备进行测试操作的编程语言；

传输模块，用于基于微控制器板的至少一个输入接口，传输所述测试执行脚本，以使所述微控制器板对所述测试执行脚本进行信号转换，得到模拟信号；所述微控制器板用于提供多种功能类型的接口，以实现与任意一种被控制设备的通信和交互控制；

发送模块，用于基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，以使所述被控制设备执行所述模拟信号进行测试；

确定模块，用于接收所述被控制设备反馈的响应信息，基于所述响应信息确定车载系统的测试是否发生异常；所述响应信息为所述被控制设备执行所述模拟信号后生成的结果信息。

第三方面，本申请还提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面中任一项所述的方法。

第四方面，本申请还提供一种车载系统的测试系统，所述系统包括：

微控制器板、车载信息娱乐IVI系统、电源模块、至少一种被控制设备和如第三方面所述的电子设备；

所述微控制器板用于控制所述车载IVI系统、所述电源模块和所述至少一种被控制设备的工作；

所述电源模块用于为所述车载IVI系统、所述微控制器板和所述至少一种被控制设备供电；

所述至少一种被控制设备用于执行模拟信号以模拟用户的触控操作和/或被控制设备的应用场景进行测试。

第五方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面中任一项所述的方法。

第六方面，本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如第一方面中任一项所述的方法。

综上所述，本申请提供一种车载系统的测试方法、装置、系统、设备、介质及产品，可以通过将车载系统连接微控制器板，如开源Arduino Leonardo，以使Arduino Leonardo发送模拟信号控制车载系统的各种被控制设备进行测试，如兼容性测试、功能测试等，进而判断被控制设备是否发生异常；其中，该模拟信号为用户使用简单的编程语言，模拟用户的操作和环境编写的代码，并将代码上传到Arduino Leonardo微控制器板中进行信号转换得到的；由于Arduino Leonardo具有多种类型的应用接口，以进行可靠的数据传输和通信，因此，本申请基于Arduino Leonardo的应用接口进行测试执行脚本和模型信号的传输。这样，由于微控制器板的丰富功能和应用接口，以及提供的可靠的数据传输和通信，且支持传输编写的各种类型的控制程序，可以实现高效的交互控制，提高系统的响应速度，进而提高整个车载系统研发过程的效率和性能。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的一种车载系统的测试方法的流程示意图；

图3为本申请实施例提供的一种可选的车载系统的测试系统的结构示意图；

图4为本申请实施例提供的一种车载系统的测试装置的结构示意图；

图5为本申请实施例提供的一种电子设备的结构示意图；

图6为本申请实施例提供的另一种可选的车载系统的测试系统的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一设备和第二设备仅仅是为了区分不同的设备，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

车载IVI系统是一种集成了多种功能的车载娱乐和信息系统，包括音频、视频、导航、通信等。为了确保车载IVI系统的稳定性和可靠性，需要对其进行各种测试，例如兼容性测试、功能测试等。在测试过程中，需要使用各种控制控制设备来模拟开发或测试对于操作和环境控制。

目前，市场上已经有各种车载IVI系统测试控制设备，例如模拟鼠标、键盘、测试仪器等测试控制设备。然而，这些测试控制设备通常需要专业的软件和硬件支持，而且难以掌握，对于研发，尤其对开发或测试人员来说不太友好。因此，如何设计一种简单易用的车载IVI系统测试控制设备，以提高研发整体的效率和准确性，也是当前亟待解决的问题。

一种可能的实现方式中，可以基于Android系统提供各种应用程序和硬件接口，如触摸屏、蓝牙、Wi-Fi、GPS等实现车载IVI系统的交互控制。

但是，上述Android系统的材料和实现的成本较高，且功能有限，导致系统的稳定性和响应速度较差。

另一种可能的实现方式中，可以基于一种信用卡大小的微型电脑提供的Linux操作系统以及各种应用程序和硬件接口，如通用串行总线(Universal Serial Bus，USB)、高清晰度多媒体接口(High Definition Multimedia Interface，HDMI)、Wi-Fi、蓝牙等控制车载IVI系统，以实现车载IVI系统的交互控制。

但是，使用微型电脑进行车载IVI系统的交互控制，成本较高，难以实现低成本的车载IVI系统交互控制。

再一种可能的实现方式中，可以基于个人(Personal Computer，PC)终端使用Windows系统或Linux操作系统，在应用和硬件接口方面提供的丰富功能和选项实现车载IVI系统的交互控制。

但是，使用PC终端进行车载IVI系统的交互控制，PC终端难以提供多样化的应用和硬件接口，导致功能受限，且PC终端难以保证车载IVI系统的稳定性和响应速度，导致性能不足。

又一种可能的实现方式中，可以直接使用传统的控制器和传感器，如人工操作按钮、控制杆和模拟仪表等，以实现基本的车载IVI系统控制功能。

但是，在车载IVI相关系统和应用的研发过程中，大面积的人为操作会出现错误，从而无法达到研发和验证的效果，与此同时，在人工反复操作相关应用的过程中，人为作业可能出现大量性的重复操作内容，导致整体效率较低，以及增加了过多的人力成本，尤其是在大量外设的使用中，会出现了大量的浪费。

需要说明的是，相关车载IVI操作系统和相关应用在没有相关配套硬件的场景下，只能通过仿真或者模拟器实现相关作业，难以获取与实际操作的设备的反馈和效果；针对有相关联系的车载IVI操作系统和应用，仅能通过人工的方式实现相关的作业内容。

针对上述问题，本申请提供一种车载系统的测试方法，可以通过将车载系统连接微控制器板，如开源Arduino Leonardo，以使Arduino Leonardo发送模拟信号控制车载系统的各种被控制设备进行测试，如兼容性测试、功能测试等，进而判断被控制设备是否发生异常；其中，该模拟信号为用户使用简单的编程语言，模拟用户的操作和环境编写的代码，并将代码上传到Arduino Leonardo微控制器板中进行信号转换得到的；由于ArduinoLeonardo具有多种类型的应用接口，以进行可靠的数据传输和通信，因此，本申请基于Arduino Leonardo的应用接口进行测试执行脚本和模型信号的传输。

这样，由于微控制器板的丰富功能和应用接口，以及提供的可靠的数据传输和通信，且支持传输编写的各种类型的控制程序，可以实现高效的交互控制，提高系统的响应速度，进而提高整个车载系统研发过程的效率和性能。

需要说明的是，微控制器板是一个价格实惠，多功能的外部平台，在进行车载系统的测试时，可以节省车载系统内部的资源占用，具有较高的性能和稳定性，并支持传输灵活的控制程序，容易用户学习和使用，因此该微控制器板可以实现车载IVI系统的交互控制。

示例性的，图1为本申请实施例提供的一种应用场景示意图，如图1所示，该应用场景可以应用到车载IVI系统中，该应用场景包括：汽车101、测试系统102和用户的终端设备103；其中，汽车101中部署有车载IVI系统，该车载IVI系统可以为车载座舱主机1011，和/或，车载域控主机；测试系统102中部署有微控制器板；本申请实施例对车载IVI系统对应的具体系统以及微控制器板的类型不作限定。

以微控制器板为Arduino Leonardo为例，通过Arduino Leonardo车载IVI系统测试控制设备，用户可以基于终端设备103使用简单的编程语言来编写控制汽车101中各种被控制设备的测试执行脚本，如基于Arduino开发环境来编写代码，以模拟开发环境的各种操作和应用场景，如自动驾驶的应用场景，点击触摸屏按钮的触控操作等，本申请实施例对此不作具体限定。

进一步的，用户基于终端设备103将代码上传到Arduino Leonardo中，ArduinoLeonardo基于应用接口接收用户编写的代码，且Arduino Leonardo可以识别和执行该代码，即将代码进行信号转换，得到模拟信号，该模拟信号可以控制各种被控制设备工作。

进一步的，测试系统102基于Arduino Leonardo的应用接口向被控制设备输出模拟信号，在被控制设备执行完该模拟信号后，测试系统102还可以基于Arduino Leonardo的应用接口接收各个被控制设备反馈的测试执行结果，以确定被控制设备是否发生异常。

可选的，测试系统102可以将测试执行结果和/或发生异常的被控制设备的信息发送到用户的终端设备103上进行可视化显示，以提醒用户查看测试结果。

需要说明的是，Arduino Leonardo具有多种类型的应用接口，不同类型的应用接口对应不同数据类型的传输数据，本申请实施例对应用接口的类型以及每一类型对应的传输数据不作具体限定。

可选的，上述终端设备103可以指的是具有显示屏幕的电子设备，可以为平板电脑、手机、智能手表等电子设备，也可以是测试系统102对应的显示设备，本申请实施例对此不作具体限定。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的一种车载系统的测试方法的流程示意图，如图2所示，所述车载系统的测试方法的执行主体为测试系统中的主机，所述车载系统的测试方法包括如下步骤：

S201、获取测试执行脚本；所述测试执行脚本为控制任意一种被控制设备进行测试操作的编程语言。

本申请实施例中，测试执行脚本可以是用户编写好的代码，也可以提前编写好的存储于数据库中的代码，在使用时基于标识、用户需求、应用环境等直接调用，本申请实施例对代码的来源和存储位置不作具体限定，以上仅是示例说明。

其中，该测试执行脚本用于实现汽车内部控制，如车载系统和内部程序、模拟外部设备等，也可以控制车辆的某些零部件的操作，如点击、按压、滑动、外部硬件信号输入等。

在本步骤中，测试系统可以获取研发人员和测试人员可以通过编写的程序，以对车载系统进行交互控制，该车载系统可以为车载IVI系统和相关外部设备等，本申请实施例对车载系统对应的具体系统不作限定。

可选的，测试系统还可以获取用户输入的用户需求和/或应用环境，进而测试系统可以基于用户需求和/或应用环境从数据库中直接调用提前编写好的程序。

可选的，用户可以根据项目和场景的对应的用户需求，灵活设置和修改程序的控制逻辑，以实现更个性化的车载系统交互控制，本申请实施例对程序的内容以及形式不作具体限定，其可以为Java语言的编程，也可以为C++语言的编程；其可以对自动驾驶进行模拟编程，也可以对触控操作进行模拟编程。

S202、基于微控制器板的至少一个输入接口，传输所述测试执行脚本，以使所述微控制器板对所述测试执行脚本进行信号转换，得到模拟信号；所述微控制器板用于提供多种功能类型的接口，以实现与任意一种被控制设备的通信和交互控制。

本申请实施例中，微控制器板为具有多种功能的扩展接口、可靠的数据传输和通信、支持自定义化控制程序转换以及可以进行高效的交互控制的外部设备，该微控制器板可以为Arduino Leonardo，也可以是具有上述功能的任意一种类型的设备，本申请实施例对此不作具体限定。

其中，测试系统在进行车载系统的测试时，该微控制器板不占用系统内部资源，节省内部资源占用，进而可以提高响应速率。

可选的，微控制器板具有多种功能的扩展接口(应用接口)，如数字输入输出口、模拟输入输出口、串口、内部集成电路总线(Inter－Integrated Circuit，I2C)、串行外围接口(Serial Peripheral interface，SPI)等接口，可以提供更多可选的硬件功能和应用，满足车载系统的不同数据的传输需求。

需要说明的是，不同类型的应用接口对应不同数据类型的传输数据，如以Arduino设备为例，Arduino设备具有20个数字输入/输出引脚，其中7个可用于脉冲宽度调制(PulseWidth Modulation，PWM)输出、12个可用于模拟输入；还有一个16MHz的晶体振荡器，一个Micro USB接口，一个直流电源(Direct Current，DC)接口，一个在线串行编程(In-CircuitSerial Programming，ICSP)接口，一个复位按钮，以Micro USB接口为例，用于传输串口信号，以DC接口为例，用于传输电信号等。

可选的，微控制器板可以提供可靠的数据传输和通信技术，使得车载系统与微控制器板之间的信息交互稳定可靠，减少数据丢失和通信中断的问题，提高了车载系统的操作稳定性和实用性。

可选的，微控制器板可以通过串口指令等方式实现高效的交互控制，提高了开发人员和测试人员的操作便捷性和体验；该串口指令为基于应用接口接收测试执行脚本的接口指令。

在本步骤中，微控制器板以Arduino Leonardo为例，需要将Arduino Leonardo与车载系统连接起来，通过确定所需的硬件接口类型，来确定Arduino Leonardo与车载系统的连接方式，以实现与车载系统的物理连接，该硬件接口类型包括串口、触摸屏、蓝牙、Wifi等外部设备的接口类型。

例如，将车辆的控制主机通过串口连接Arduino Leonardo，可以对于串口信号进行编程，得到测试执行脚本，进而将该测试执行脚本基于Arduino Leonardo的至少一个输入接口传输至Arduino Leonardo，以使Arduino Leonardo将该测试执行脚本进行信号转换，得到模拟信号，进而测试系统可以控制Arduino Leonardo进行模拟信号的发送。

其中，至少一个输入接口为符合测试执行脚本传输类型的应用接口，本申请实施例对至少一个输入接口对应的应用接口的类型和数量不作具体限定。

S203、基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，以使所述被控制设备执行所述模拟信号进行测试。

本申请实施例中，被控制设备可以指的是模拟用户在车端中进行相应执行操作以及使用环境的各种控制设备，例如模拟键盘、鼠标、摄像头等各种控制设备，车载座舱主机和车载域控主机也是被控制设备，本申请实施例对被控制设备对应的设备类型不作具体限定。

示例性的，测试系统可以控制微控制器板的至少一个输出接口，将模拟信号发送至被控制设备，如将模拟信号发送至车载座舱主机和/或车载域控主机，以通过模拟车辆上可以被车载系统识别的信号对车载系统进行控制，其中包括模拟各类鼠标、键盘、测试仪器等的测试控制，相应的，也可以接收到车载座舱主机和/或车载域控主机执行该模拟信号后的相关内容和数据。

在一些实施例中，以微控制器板为Arduino Leonardo为例，Arduino Leonardo可以基于模拟信号控制车载IVI系统和相关外部设备的各种动作和任务，如点击屏幕的动作、自动驾驶的任务等，这样，研发人员和测试人员可以通过自己编写的程序来控制ArduinoLeonardo发送模拟信号完成自己规划的任务。

可选的，通过使用Arduino Leonardo对车载系统进行交互控制，可以拓展多种应用场景，以及发掘更多可能性，如可以适用于涉及车辆行驶、车辆多媒体应用等的各种场景，本申请实施例对使用Arduino Leonardo对车载系统进行交互控制的应用场景不作具体限定。

需要说明的是，针对车载系统所依赖的相应操作系统和特殊连接方式，通过对连接输入和控制进行有效的优化和增强相应的交互控制方法，如在车载的连接方式中，对连接的接口对应的特殊协议，通过设置在指定的协议范围内进行传输，或者增加相应的连接传输的方式，可以更好的实现相应的内容。

其中，本申请实施例对连接的接口对应的协议、协议范围以及增加的连接传输的方式不作具体限定，其可以基于用户需求和/或应用场景进行设定，也可以参照现有的方式进行设定。

S204、接收所述被控制设备反馈的响应信息，基于所述响应信息确定车载系统的测试是否发生异常；所述响应信息为所述被控制设备执行所述模拟信号后生成的结果信息。

被控制设备在执行完模拟信号的测试后，可以生成包括测试结果的响应信息，进而被控制设备可以将响应信息回传到测试系统的控制主机中，以使控制主机基于响应信息，判断车载系统是否发生异常。

可选的，被控制设备可以基于微控制器板的应用接口将响应信息回传到测试系统的控制主机中。

需要说明的是，本申请实施例对基于响应信息判断车载系统是否发生异常的方法不作具体限定，其可以参照现有的测试异常的判断方法，也可以重新定义新的判断方法。

因此，本申请实施例提供一种车载系统的测试方法，通过微控制器板实现对车载系统的交互控制，基于微控制器板具有的高效的交互控制、支持自定义化控制程序转换、提供多功能的扩展接口以及可靠的数据传输和通信等的功能，使得开发人员和测试人员可以自定义和编写控制程序，进而基于简单程序便可以实现对被控设备的测试，节省成本，由于微控制器板是外部设备，在进行车载系统的测试，不占用系统内部资源，提高了系统的稳定性和响应速度，进而大大提高了交互控制的效率。

示例性的，图3为本申请实施例提供的一种可选的车载系统的测试系统的结构示意图，如图3所示，测试系统包括控制主机、微控制器板、车载座舱主机和车载域控主机；其中，车载座舱主机和车载域控主机是被控制设备，微控制器板连接控制主机的相关的数据发生接口(应用接口)，用于发送编程后的模拟数据以及输出模拟信号，相应的，还可以在相关的数据发生接口中返回相应的测试结果对应的数据和信息。

示例性的，以微控制器板为Arduino设备为例，控制主机通过串口连接Arduino设备，通过提前对串口信号进行编程，得到测试执行脚本，进而测试系统在获取测试执行脚本后，将测试执行脚本发送至Arduino设备，以控制Arduino设备转换为模型信号，并控制模拟信号的发送。

进一步的，Arduino设备通过发送模拟信号，以模拟车辆上可以被车载系统识别的信号，进而对车载系统中的车载座舱主机和车载域控主机进行控制测试，同时，控制主机也可以收到车载座舱主机和车载域控主机返回的控制测试结果的相关内容和数据。

其中，车载座舱主机和车载域控主机基于车载内部网络连接，包括通过T1网络百兆或者千兆的网络通信的内容，该车载座舱主机为图1所示的车载座舱主机1011，车载域控主机为车辆自动驾驶中涉及的车载系统中各域的主机。

需要说明的是，上述不仅车载座舱主机和车载域控主机保持了连接，车载系统中其他车载主机，也会建立相应的连接，本申请实施例对车载系统中涉及到的车载主机的类型和数量不作具体限定。

可以理解的是，Arduino Leonardo是Arduino设备的一种，本申请实施例中，微控制器板可以是不同种类的Arduino设备。

这样，车载系统通过连接开源Arduino设备的硬件模拟输入，即多个应用接口，以通过Arduino Leonardo控制车载系统的被控制设备，进而测试人员可以使用简单的编程语言来控制各种被控制设备，以及模拟用户的操作和应用环境，以实现对车载系统的各种测试，如兼容性测试、功能测试等。

可选的，所述测试执行脚本包括第一测试执行脚本和/或第二测试执行脚本；获取测试执行脚本，包括：

获取用户输入的第一测试执行脚本；所述第一测试执行脚本基于用户的编写操作进行设置；

和/或，获取用户输入的用户需求和/或应用环境，基于所述用户需求和/或应用环境调用对应的第二测试执行脚本；所述第二测试执行脚本与所述用户需求和/或应用环境存在映射关系，提前存储于数据库中。

本申请实施例中，第一测试执行脚本可以基于用户需求和/或应用环境，进行人为的修改以及编写操作，形成适用各种用户需求和/或应用环境的代码。

可选的，也可以将不同用户需求和/或应用环境对应的第二测试执行脚本提前编写好，并建立用户需求和/或应用环境与第二测试执行脚本的映射关系，将存在映射关系的用户需求和/或应用环境与第二测试执行脚本存储于数据库或数据表中，在进行车载系统的测试，可以直接基于用户需求和/或应用环境调用对应的第二测试执行脚本，不需要用户再次进行编写，节省时间，方便不了解编程用户的使用。

可选的，也可以将存在映射关系的用户需求和/或应用环境与第二测试执行脚本进行标识信息的标注并存储，这样，也可以基于标识信息调用对应的第二测试执行脚本。

需要说明的是，本申请实施例对存在映射关系的用户需求和/或应用环境与第二测试执行脚本存储位置不作具体限定，以上仅是示例说明。

可选的，当基于用户需求和/或应用环境无法查找到对应的第二测试执行脚本，可以获取用户输入的第一测试执行脚本，进行后续的车载系统的测试。

可选的，也可以分别获取用户输入的第一测试执行脚本以及基于用户需求和/或应用环境对应的二测试执行脚本，分别进行后续的车载系统的测试。

可选的，用户可以对第二测试执行脚本进行修改以及更新，并将修改以及更新后的第二测试执行脚本与其对应的用户需求和/或应用环境进行存储，以便于后续使用。

其中，第一测试执行脚本和第二测试执行脚本为不同的用户需求和/或应用环境对应的进行交互控制的软件编程代码，即根据所需的交互需求和功能，编写的用于测试的相应代码。

在本步骤中，可以通过调用各种库和工具中的测试执行脚本，实现与车载系统的信息交互和控制；在本申请中，开发人员和测试人员还可以根据用户需求和/或应用环境，灵活设置和修改测试执行脚本的控制逻辑，实现更个性化的车载系统交互控制。

这样，本申请实施例可以根据用户需求/或应用环境，定义和编写控制程序，实现更高效和精确的控制逻辑，使得交互控制更加智能化和个性化，提升了整个车载系统的灵活性和实用性，以及提供了更好的开发人员和测试人员体验。

可选的，基于微控制器板的至少一个输入接口，传输所述测试执行脚本，包括：

获取所述测试执行脚本的应用场景和/或数据类型；

基于所述应用场景和/或数据类型，确定传输所述测试执行脚本的至少一个输入接口；

基于所述至少一个输入接口传输所述测试执行脚本。

其中，应用场景可以指的是用于进行哪种被控制设备或哪种功能的测试场景，该应用场景与应用环境的定义类似，本申请实施例对应用场景和应用环境不作具体限定。

本申请实施例中，需要设计一个为车载系统定制的连接方法，可以通过调研硬件和软件系统的功能和参数，以及交互控制的需要，确定使用微控制器板的硬件配置和相关软件库，进而确定微控制器板对应的应用接口与车载系统的连接关系。

在本步骤中，由于不同的数据类型的传输数据对应不同的应用接口，因此，可以基于应用场景和/或数据类型，确定传输测试执行脚本的至少一个输入接口，如可以通过串口指令的方式传输测试执行脚本。

需要说明的是，至少一个输入接口是微控制器板对应的应用接口中的一种类型或多种类型，本申请实施例对此不作具体限定。

因此，本申请实施例可以基于应用场景和/或数据类型，确定传输测试执行脚本的至少一个输入接口，以实现高效的交互控制，提高了开发人员和测试人员的操作便捷性和体验。

可选的，基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，包括：

对所述模拟信号进行解析，得到所述模拟信号的发送次数和/发送形式；所述发送形式包括：连续发送和间隔预设时间发送；

基于所述发送次数和/发送形式，将所述模拟信号发送至被控制设备。

本申请实施例中，预设时间可以指的是以前预设的发送模拟信号至被控制设备的间隔时间，本申请实施例对预设时间对应的数值不作具体限定。

可选的，可以对模拟信号进行解析，得到该模拟信号的发送形式，如以间隔预设时间循环发送或者间隔预设时间单次发送模拟信号至被控制设备。

可选的，可以对模拟信号进行解析，得到该模拟信号的发送形式，如在一段时间内将模拟信号连续的发送至被控制设备。

可选的，可以对模拟信号进行解析，得到该模拟信号的发送次数，如5次，则微控制器板可以在一段时间内分别发送5次模拟信号至被控制设备。

可选的，可以对模拟信号进行解析，得到该模拟信号的发送次数和发送形式，进而在一段时间内基于发送次数和发送形式将模拟信号发送至被控制设备。

需要说明的是，本申请实施例对模拟信号的发送次数和/发送形式的不作具体限定，其可以基于用户需求和/或应用场景确定，如某个点击操作需要执行5次，则需要在分别发送5次模拟信号至被控制设备进行测试。

相应的，测试系统可以基于模拟信号的发送次数和/发送形式，接收被控制设备反馈的相关的内容和数据，并收集相关内容和数据保存至控制主机内。

因此，本申请实施例可以基于不同的发送次数和/发送形式，将模拟信号发送至被控制设备，以满足不同的用户需求和/或应用场景，提高测试的灵活性以及适用范围。

可选的，接收所述被控制设备反馈的响应信息，包括：

基于所述微控制器板的接收接口接收所述被控制设备反馈的响应信息；所述被控制设备包括至少一种类型的车载主机。

本申请实施例中，车载主机可以指的是车载系统中涉及到的各种类型的主机，如车载座舱主机和车载域控主机，本申请实施例对车载主机的类型不作具体限定。

在一些实施例中，需要对整个车载系统进行综合测试和优化，即在车载系统的测试过程中需要检查车载系统的稳定性、相应速度等，并进行软硬件优化，以确保与车载系统的交互控制稳定可靠，并满足开发和测试的需求。

需要说明的是，接收接口也是微控制器板对应的一种或多种类型应用接口，该接收接口可以与上述实施例中的输入接口和输出接口的类型一致，也可以不同，本申请实施例对此不作具体限定。

可选的，微控制器板对应的应用接口为多功能的扩展接口，可以用于扩展与多种传感器和执行器连接的接口，使车载系统具备更多功能和应用。

可选的，也可以通过控制主机的定义的接口接收被控制设备反馈的响应信息，本申请实施例对此不作具体限定。

在另一些实施例中，基于Arduino Leonardo的接收接口接收被控制设备反馈的响应信息，通过使用Arduino Leonardo的可靠数据传输和通信技术，可以确保与车载系统之间的稳定和可靠的信息交互，减少数据丢失和通信中断的问题。

因此，本申请实施例可以基于微控制器板的丰富功能和应用接口，实现了高效的交互控制，提高了车载系统在研发过程的效率和安全性能。

可选的，所述方法还包括：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备；

获取所述异常设备在车载系统中的位置信息，基于所述位置信息生成提示信息；

将所述提示信息和所述异常设备的位置进行可视化显示，以提示用户对所述异常设备进行检修。

本申请实施例中，位置信息用于指示异常设备在整个车载系统中的位置，提示信息为描述该位置的文字信息或图片信息，如以整个车辆为结构图，标注异常设备的位置，本申请实施例对提示信息对应的具体内容不作限定。

在一些实施例中，当确定车载系统的测试发生异常后，基于响应信息，利用预定义的识别方法确定异常设备，进而确定该异常设备在车载系统中的位置信息，进一步的，测试系统将提示信息和异常设备的位置进行可视化显示，以提示用户对异常设备进行检修。

需要说明的是，本申请实施例对确定异常设备的预定义的识别方法不作具体限定，其可以参照现有的方法，也可以重新定义新的方法。

可选的，测试系统将提示信息和异常设备的位置以短信或显示框的形式发送到用户的终端设备上进行可视化显示，本申请实施例对可视化显示的方式以及发送形式不作具体限定。

可选的，在用户对异常设备进行检修后，测试系统可以再次执行S201-S204，以对车载系统进行测试，并验证异常设备是否修复。

因此，本申请可以监测车载系统的测试过程，当确定车载系统的测试发生异常后，可以生成提示信息以及查找异常设备的位置提醒用户检修，以提升车载系统的功能和性能，并提供更好的安全性能。

可选的，所述方法还包括：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备的异常等级；

当所述异常等级不满足预设条件时，生成预警信息；所述预警信息包括语音信息和/或文字信息。

其中，语音信息包括声音信息、语音播报信息和音乐信息等，如当异常等级不满足预设条件时，可以播放特制的音乐，也可以语音提示“异常设备1的异常等级过高，请检修车辆”等，本申请实施例对语音信息的具体表现形式不作限定。

本申请实施例中，预设条件可以为小于预设阈值，即当异常等级大于或等于预设阈值时，可以生成预警信息，该预设阈值为提前预设的用于确定异常等级较高的数值，本申请实施例对预设阈值对应的大小不作具体限定。

可选的，预设条件也可以提前预设的固定的异常等级，如预设条件为异常等级为1级-3级，即当异常设备的异常等级不是1级-3级时，可以生成预警信息。

需要说明的是，本申请实施例对预设条件不作具体限定，其可以确定异常等级过高即可，该异常等级的表现形式，可以是文字、数字、字母中的一种多种组合，本申请实施例对此不作具体限定，如1级、2级，高级、低级等。

可选的，预警信息还可以包括警示灯信息，当异常等级不满足预设条件时，可以警示灯常亮、变红等。

在一些实施例中，当确定车载系统的测试发生异常后，基于响应信息，利用预设的方法确定异常设备的异常等级，以及当异常等级不满足预设条件时，生成文字信息，如显示“异常设备1的异常等级过高，请检修车辆”等内容，如果车载系统在运行过程中，还可以控制车载系统停止运行。

可选的，本申请实施例可以通过微控制器板对车辆的控制能力，如响应信息基于微控制器板的应用接口接收，预警信息以模拟信号的形式进行发送，可以实现对车辆设备的智能化监控和安全预警功能，并且可以自定义车辆的控制程序，如控制车辆停止运行等操作，从而提高车辆的安全性能。

其中，该控制程序基于微控制器板进行信号转换，并将转换后的信号基于微控制器板的应用接口发送至被控制设备。

需要说明的是，本申请实施例对预警信息的具体内容不作限定，如其还可以语音信息和文字信息同时显示。

因此，本申请实施例还可以实现对车辆设备的智能化监控和安全预警功能，并且可以自定义车辆的控制程序，从而提高车辆的安全性能。

在前述实施例中，对本申请实施例提供的车载系统的测试方法进行了介绍，而为了实现上述本申请实施例提供的方法中的各功能，作为执行主体的电子设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

例如，图4为本申请实施例提供的一种车载系统的测试装置的结构示意图，如图4所示，所述装置400包括：获取模块401，传输模块402，发送模块403和确定模块404，其中，所述获取模块401，用于获取测试执行脚本；所述测试执行脚本为控制任意一种被控制设备进行测试操作的编程语言；

所述传输模块402，用于基于微控制器板的至少一个输入接口，传输所述测试执行脚本，以使所述微控制器板对所述测试执行脚本进行信号转换，得到模拟信号；所述微控制器板用于提供多种功能类型的接口，以实现与任意一种被控制设备的通信和交互控制；

所述发送模块403，用于基于所述微控制器板的至少一个输出接口，将所述模拟信号发送至被控制设备，以使所述被控制设备执行所述模拟信号进行测试；

所述确定模块404，用于接收所述被控制设备反馈的响应信息，基于所述响应信息确定车载系统的测试是否发生异常；所述响应信息为所述被控制设备执行所述模拟信号后生成的结果信息。

可选的，所述测试执行脚本包括第一测试执行脚本和/或第二测试执行脚本；所述获取模块401，具体用于：

获取用户输入的第一测试执行脚本；所述第一测试执行脚本基于用户的编写操作进行设置；

和/或，获取用户输入的用户需求和/或应用环境，基于所述用户需求和/或应用环境调用对应的第二测试执行脚本；所述第二测试执行脚本与所述用户需求和/或应用环境存在映射关系，提前存储于数据库中。

可选的，所述传输模块402，具体用于：

获取所述测试执行脚本的应用场景和/或数据类型；

基于所述应用场景和/或数据类型，确定传输所述测试执行脚本的至少一个输入接口；

基于所述至少一个输入接口传输所述测试执行脚本。

可选的，所述发送模块403，具体用于：

对所述模拟信号进行解析，得到所述模拟信号的发送次数和/发送形式；所述发送形式包括：连续发送和间隔预设时间发送；

基于所述发送次数和/发送形式，将所述模拟信号发送至被控制设备。

可选的，所述确定模块404，具体用于：

基于所述微控制器板的接收接口接收所述被控制设备反馈的响应信息；所述被控制设备包括至少一种类型的车载主机。

可选的，所述装置400还包括监测模块，所述监测模块，用于：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备；

获取所述异常设备在车载系统中的位置信息，基于所述位置信息生成提示信息；

将所述提示信息和所述异常设备的位置进行可视化显示，以提示用户对所述异常设备进行检修。

可选的，所述装置400还包括预警模块，所述预警模块，用于：

当确定所述车载系统的测试发生异常后，基于所述响应信息确定异常设备的异常等级；

当所述异常等级不满足预设条件时，生成预警信息；所述预警信息包括语音信息和/或文字信息。

本申请实施例提供的一种车载系统的测试装置的具体实现原理和效果可以参见上述实施例对应的相关描述和效果，此处不做过多赘述。

本申请实施例还提供了一种电子设备的结构示意图，图5为本申请实施例提供的一种电子设备的结构示意图，如图5所示，该电子设备可以包括：处理器501以及与所述处理器通信连接的存储器502；该存储器502存储计算机程序；该处理器501执行该存储器502存储的计算机程序，使得该处理器501执行上述任一实施例所述的方法。

其中，存储器502和处理器501可以通过总线503连接。

可选的，本申请还提供一种车载系统的测试系统，图6为本申请实施例提供的另一种可选的车载系统的测试系统的结构示意图，如图6所示，该车载系统的测试系统600包括：

微控制器板、车载信息娱乐IVI系统、电源模块、至少一种被控制设备和如图5所述的电子设备；

所述微控制器板用于控制所述车载IVI系统、所述电源模块和所述至少一种被控制设备的工作；

所述电源模块用于为所述车载IVI系统、所述微控制器板和所述至少一种被控制设备供电；

所述至少一种被控制设备用于执行模拟信号以模拟用户的触控操作和/或被控制设备的应用场景进行测试。

本申请实施例中，微控制器板以Arduino Leonardo为例，Arduino Leonardo用于车载IVI系统的交互控制，可以强化车载IVI系统连接控制的安全性，通过ArduinoLeonardo发送模拟信号对车辆的控制能力，可以对用户的触控操作和/或被控制设备的应用场景进行测试。

示例性的，车载系统的测试系统包括Arduino Leonardo微控制器板、车载IVI系统、电源模块和各种被控制设备；其中，Arduino Leonardo微控制器用于控制和管理车载IVI系统、电源模块和各种被控制设备的工作；车载IVI系统包括各种车载娱乐和信息系统，例如音频、视频、导航、通信等；电源模块用于为整个车载系统提供电源；各种被控制设备用于模拟用户的操作和应用环境，例如模拟键盘、鼠标、摄像头等测试控制设备。

这样，将Arduino Leonardo用于车载IVI系统的交互控制，可以实现以下技术效果：

通过使用Arduino Leonardo，用户可以自定义控制车载IVI系统，实现更灵活、便捷、智能的操作经验，从而提高整个系统的用户友好性和实用性。

用户可以通过Arduino Leonardo实现车载软件研发系统的各种功能操作。

Arduino Leonardo用于车载IVI系统的交互控制，可以强化车载IVI系统连接控制的安全性，通过Arduino Leonardo对车辆的控制能力，用户还可以实现对车辆设备的智能化监控和安全预警功能，并且可以自定义车辆的控制程序，从而提高车辆的安全性能。

综上所述，利用Arduino Leonardo进行车载IVI系统的交互控制，可以带来自定义控制、车内软件研发体验升级、满足研发人员和测试人员的需求，并为车载系统的研发和测试过程提升了效率，满足了开发人员和测试人员在整体车载交互控制的需求，并大幅提升了车载IVI系统的开发效率。

这样，通过具有Arduino Leonardo的车载系统的测试系统，测试人员可以使用简单的编程语言来控制各种被控制设备，提高了测试人员的效率和准确性。此外，由于具有Arduino Leonardo的车载系统的测试系统的设计简单，易于掌握和使用，测试人员可以快速上手，无需专业的软件和硬件支持。进而可以减少测试成本，提高测试效率，为车载IVI系统的开发和测试提供了更好的支持。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序执行指令，计算机执行指令被处理器执行时用于实现如本申请前述任一实施例中的所述的方法。

本申请实施例还提供了一种运行指令的芯片，该芯片用于执行如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

本申请实施例还提供了一种计算机程序产品，该程序产品包括计算机程序，该计算机程序被处理器执行时可实现如本申请前述任一实施例中由电子设备所执行的前述任一实施例中所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(Central Processing Unit，简称CPU)，还可以是其它通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速随机存取存储器(Random Access memory，简称RAM)，也可能还包括非不稳定的存储器(Non-volatile Memory，简称NVM)，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，简称ISA)总线、外部设备互连(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random-Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-OnlyMemory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

进一步需要说明的是，虽然流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。上述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求书指出。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。