CN114880220A - 车辆自动驾驶软件的开发***和方法 - Google Patents

Abstract

本申请涉及一种车辆自动驾驶软件的开发***和方法。所述***包括：代码管理服务器，用于接收通过开发机终端上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器；持续集成服务器，用于根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，将测试通过的可执行文件发送至持续部署服务器；持续部署服务器，用于根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备和目标车辆；仿真测试设备，用于根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果。采用本***能够提高软件的开发效率。

Description

车辆自动驾驶软件的开发***和方法

技术领域

本申请涉及车辆自动驾驶技术领域，特别是涉及一种车辆自动驾驶软件的开发***和方法。

背景技术

随着车辆智能化和网联化的发展，出现了商用车领域的自动驾驶技术，采用自动驾驶技术的***能够执行动态驾驶任务，在有驾驶员的情况下实现辅助驾驶，在无驾驶员的情况下实现完全自动驾驶。

在传统的针对车辆自动驾驶的软件开发流程中，由各个软件模块开发完成后，需要集成工程师手动把开发完成的软件包集成到整体软件工程中，随着软件复杂度的提升，需要手动完成大量的集成、编译与测试工作。而且，在将整个软件包全部构建完成后，需要通过工程师手动刷写至车辆的特定控制器中进行联调和测试。

然而，传统的车辆自动驾驶软件的开发流程，对人工操作的依赖程度较高，存在效率低的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高软件开发效率的车辆自动驾驶软件的开发***和方法。

第一方面，本申请提供了一种车辆自动驾驶软件的开发***。所述***包括：

代码管理服务器，用于接收通过开发机终端上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器；

持续集成服务器，用于根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，将测试通过的可执行文件发送至持续部署服务器；

持续部署服务器，用于根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备和目标车辆；

仿真测试设备，用于在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果；

目标车辆，用于在满足实车测试条件的情况下，根据目标可执行文件，对目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果；

开发机终端，用于根据软件测试结果，以迭代的方式更新功能代码，直至软件测试结果满足预设条件，软件测试结果包括仿真测试结果和实车测试结果中的至少一种。

在其中一个实施例中，持续部署服务器中存储有多个历史可执行文件和多个历史可执行文件的历史版本信息，持续部署服务器还用于对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

在其中一个实施例中，仿真测试设备还用于进行模型在环测试，进行软件在环测试；根据目标可执行文件，进行硬件在环测试。

在其中一个实施例中，仿真测试设备还用于根据目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于目标硬件仿真测试环境，根据目标测试需求对整车进行功能测试，以完成硬件在环测试。

在其中一个实施例中，持续集成服务器，还用于：对功能代码进行编码规范检测和静态检测，生成第一问题清单；若对可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；若对可执行文件进行测试时，测试不通过，则生成第三问题清单。

第二方面，本申请还提供了一种车辆自动驾驶软件的开发方法。所述方法包括：

通过代码管理服务器，接收通过开发机终端上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器；

通过持续集成服务器，根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，并将测试通过的可执行文件发送至持续部署服务器；

通过持续部署服务器，根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备和目标车辆；

通过仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果；

通过目标车辆，在满足实车测试条件的情况下，根据标可执行文件，对目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果；

通过开发机终端，根据软件测试结果，以迭代的方式更新功能代码，直至软件测试结果满足预设条件，软件测试结果包括仿真测试结果和实车测试结果中的至少一种。

在其中一个实施例中，持续部署服务器中存储有多个历史可执行文件和多个历史可执行文件的历史版本信息，通过持续部署服务器，根据接收到的可执行文件确定目标可执行文件，包括：通过持续部署服务器，对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

在其中一个实施例中，通过仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，包括：通过仿真测试设备，在满足仿真测试条件的情况下，进行模型在环测试，进行软件在环测试；根据接收到的目标可执行文件，进行硬件在环测试。

在其中一个实施例中，根据接收到的目标可执行文件，进行硬件在环测试，包括：根据目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于目标硬件仿真测试环境，根据目标测试需求对整车进行功能测试，以完成硬件在环测试。

在其中一个实施例中，所述方法还包括：通过持续集成服务器，对功能代码进行编码规范检测和静态检测，生成第一问题清单；若对可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；若对可执行文件进行测试时，测试不通过，则生成第三问题清单。

上述车辆自动驾驶软件的开发***和方法，通过代码管理服务器，实现了功能代码的托管和归档；通过持续集成服务器，实现了将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，并对可执行文件进行测试；通过持续部署服务器，实现了可执行的版本控制和推送，减少了传统的软件开发流程中集成、编译、测试、刷写等需要人工操作的工作，从而减少了由于人工操作带来的低效率和可靠性差的问题，能够达到提高车辆自动驾驶软件的开发效率的目的；通过仿真测试设备和目标设备，实现了仿真测试和实车测试，形成了软件开发流程中从开发代码到代码测试的闭环，能够得到更准确、更全面的软件测试结果；通过开发机终端，根据软件测试结果，迭代更新功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件，满足车辆自动驾驶软件开发流程对于快速测试和验证的需求，从而进一步地提高了车辆自动驾驶软件的开发效率。

附图说明

图1为一个实施例中车辆自动驾驶软件的开发***的结构框图；

图2为一个实施例中车辆自动驾驶软件的开发方法的流程示意图；

图3为另一个实施例中车辆自动驾驶软件的开发***的结构框图；

图4为另一个实施例中车辆自动驾驶软件的开发方法的流程示意图；

图5为一个实施例中车辆自动驾驶软件的开发装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供一种车辆自动驾驶软件的开发***，如图1所示，***包括开发机终端102、代码管理服务器104、持续集成服务器106、持续部署服务器108、仿真测试设备110、目标车辆112。其中，开发机终端102、代码管理服务器104、持续集成服务器106、持续部署服务器108和仿真测试设备110均通过以太网连接，代码管理服务器104、持续集成服务器106和持续部署服务器108通过分布式技术部署于服务器集群上，目标车辆112和持续部署服务器108通过无线通信网络连接，例如LTE(Long Term Evolution，长期演进)网络。

代码管理服务器104，用于接收通过开发机终端102上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器106。

其中，开发者根据开发任务，在开发机终端102上进行车辆自动驾驶软件相关功能的开发，每完成一个功能模块的开发后，将具备试验条件的功能代码推送给代码管理服务器104，以将具备试验条件的功能代码合并到车辆自动驾驶工程中，尽早地与整体软件工程的其他功能模块集成。具备试验条件的功能代码是与功能模块对应的代码，并且该代码需要通过自动化测试和人工测试，即开发者在推送功能代码之前会先进行自动化测试和人工测试中的至少一种，以保证功能代码的正确性。触发信息是指用于触发持续集成服务器的信息，触发信息与功能代码是否符合持续集成服务器的触发条件有关，当功能代码符合持续集成服务器的触发条件时，触发信息用于发送至持续集成服务器，以触发持续集成服务器进行集成等相关操作；当功能代码不符合持续集成服务器的触发条件时，触发信息将不能被发送至持续集成服务器，而是返回至开发机终端。

具体地，在开发者进行软件开发之前，代码管理服务器104用于将软件相关代码拉取至开发者使用的开发机终端，实现多个开发者之间的代码分发和协同开发。在开发者完成软件开发之后，将开发机终端中的功能代码上传至代码管理服务器104托管。对于要提交至持续集成服务器的功能代码，代码管理服务器104首先对功能代码进行预评审，判断功能代码的实现逻辑、数据结构和复杂度，然后对通过预评审的功能代码进行检测，如果功能代码符合触发条件，则产生触发信息，将触发信息发送至持续集成服务器，以触发持续集成服务器进行集成等相关操作。如果功能代码不符合触发条件，则产生错误触发信息，将错误触发信息返回至开发机终端。

持续集成服务器106，用于根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，将测试通过的可执行文件发送至持续部署服务器108。

其中，持续集成(Continuous integration，CI)是指根据开发情况，随时将开发完成的功能集成到整个项目中。车辆自动驾驶工程属于开发者已经开发完成的软件工程，包括与车辆自动驾驶相关功能的功能代码，车辆自动驾驶工程托管在持续集成服务器本地。

具体地，在代码管理服务器104发送触发信息至持续集成服务器106之后，持续集成服务器106接收触发信息，根据触发信息启动自动集成流程，将功能代码与车辆自动驾驶工程进行集成，得到基于车辆自动驾驶工程的可编译代码，对可编译代码进行编译，编译成功后，得到可执行文件，对可执行文件进行测试，并将测试通过的可执行文件发送至持续部署服务器108。

持续部署服务器108，用于根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备110和目标车辆112。

其中，持续部署(Continuous Deployment，CD)是指根据功能集成情况，将发布版本的产品自动提供给用户使用的过程，以在小周期内形成交付、快速迭代，让用户尽快体验到新功能。目标可执行文件是根据测试需求确定的特定版本的可执行文件。由于本实施例中集成和部署都是持续进行的，因此虽然能够集成新功能的代码并提供更新版本的可执行文件，但是由于测试需求不同，对应的可执行文件的版本也不同，尤其是对于想要测试已知的稳定版本的开发者来说，其只需要对已知的稳定版本的可执行文件进行测试，而不需要对最新版本的可执行文件进行测试。仿真测试设备是仿真环境下的测试设备，用于模拟实际环境下的车辆测试；目标车辆是实际环境下用于测试的车辆，主要是商用车，也可以是乘用车。

具体地，在持续集成服务器106将可执行文件发送至持续部署服务器108之后，持续部署服务器108将可执行文件拉取至服务器本地，从服务器本地的可执行文件中确定目标可执行文件，以实现对可执行文件的版本控制，并将目标可执行文件推送至仿真测试设备110和OTA(Over-the-Air Technology，空中下载技术)平台，通过OTA平台将目标可执行文件传输至目标车辆112。

仿真测试设备110，用于在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果。

其中，仿真测试条件是指目标可执行文件能够在仿真环境下进行测试的条件，由于不同的测试需求需要采用不同的测试用例，而不同的测试用例中，有些需要同时在仿真环境和实际环境下进行测试，有些只需要在仿真环境下进行测试，还有些只需要在实际环境中进行测试，因此，对于测试用例只需要在仿真环境下进行测试、和需要同时在仿真环境和实际环境下进行测试的情况，目标可执行文件需要满足仿真测试条件。仿真测试是基于自动驾驶仿真软件实现的，常用的自动驾驶仿真软件包括Prescan、Carsim、Tracksim等。仿真测试设备可以是安装有仿真软件的计算机设备或终端。仿真测试结果表示仿真测试通过或不通过。

具体地，在目标可执行文件推送至仿真测试设备110之后，仿真测试设备110接收目标可执行文件，判断目标可执行文件是否能够进行仿真测试，如果能，根据目标可执行文件进行仿真测试，得到仿真测试结果，并将仿真测试结果反馈至开发机终端102；如果不能，则不启动仿真测试流程。

目标车辆112，用于在满足实车测试条件的情况下，根据目标可执行文件，对目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果。

其中，实车测试条件是指目标可执行文件能够在实际环境下进行测试的条件，包括目标可执行文件只能够在实际环境下进行测试的条件、和目标可执行文件能够同时在仿真环境和实际环境下进行测试的条件。实车测试是对整个目标车辆进行软件功能测试，这里的软件既包括车辆自动驾驶软件，也包括其他功能的软件，例如车联网、辅助驾驶。实车测试依赖于提前部署好的实车测试环境，通过自动化手段完成软件刷写，然后由实车测试人员完成相关测试工作，并得到实车测试结果。实车测试结果表示实车测试通过或不通过。

控制器包括域控制器(DCU，Domain Control Unit)，例如智能驾驶域控制器，还包括支持OTA平台的、用于实现不同功能的多个电子控制单元(ECU，Electronic ControlUnit)。其中，域控制器是汽车每一个功能域的核心，由域主控处理器、操作***和应用软件等组成，用于将原本需要很多个ECU实现的核心功能集成。

具体地，在目标可执行文件通过OTA平台传输至目标车辆112之后，目标车辆112接收目标可执行文件，判断目标可执行文件是否能够进行实车测试，如果能，则通过目标车辆112的车载Tbox(Telematics-box，简称Tbox)根据CAN总线的文件刷写协议将目标可执行文件刷写到目标车辆的控制器中，以便后续实车测试人员对整车进行功能测试，得到实车测试结果，并通过实车测试人员将仿真测试结果反馈至开发机终端102。

开发机终端102，用于根据软件测试结果，以迭代的方式更新功能代码，直至软件测试结果满足预设条件，软件测试结果包括仿真测试结果和实车测试结果中的至少一种。

其中，在目标可执行文件同时满足仿真测试条件和实车测试条件的情况下，软件测试结果为仿真测试结果和实车测试结果，预设条件是仿真测试和实车测试均通过的条件；在目标可执行文件仅满足仿真测试条件的情况下，软件测试结果为仿真测试结果，预设条件是仿真测试通过的条件；在目标可执行文件仅满足实车测试条件的情况下，软件测试结果为实车测试结果，预设条件是实车测试通过的条件。

预设条件可以是测试人员根据特定测试需求确定的，不同测试需求对应的预设条件不一样，也可以是所有测试需求下均需满足的预设条件，例如，仿真测试结果和实车测试结果中的问题数量减少到预设值，或者，仿真测试结果的问题数量和实车测试结果中的问题数量的差值满足预设范围。

具体地，开发机终端102接收仿真测试设备110反馈的仿真测试结果和目标车辆112反馈的实车测试结果中的至少一种，以使得开发者对软件测试结果进行分析，并朝不断减少软件测试结果中的问题的方向，通过迭代的方式更新功能代码，将更新后的功能代码通过开发机终端102推送给代码管理服务器104，代码管理服务器104接收更新后的功能代码并对更新后的功能代码进行归档，确定更新后的功能代码的版本信息，基于更新后的功能代码触发持续集成服务器，直到软件测试结果满足预设条件时停止更新功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件。

上述车辆自动驾驶软件的开发***中，通过代码管理服务器，实现了功能代码的托管和归档；通过持续集成服务器，实现了将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，并对可执行文件进行测试；通过持续部署服务器，实现了可执行的版本控制和推送，减少了传统的软件开发流程中集成、编译、测试、刷写等需要人工操作的工作，从而减少了由于人工操作带来的低效率和可靠性差的问题，能够达到提高车辆自动驾驶软件的开发效率的目的；通过仿真测试设备和目标设备，实现了仿真测试和实车测试，形成了软件开发流程中从开发代码到代码测试的闭环，能够得到更准确、更全面的软件测试结果；通过开发机终端，根据软件测试结果，迭代更新功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件，满足车辆自动驾驶软件开发流程对于快速测试和验证的需求，从而进一步地提高了车辆自动驾驶软件的开发效率。

在一个实施例中，持续部署服务器中存储有多个历史可执行文件和多个历史可执行文件的历史版本信息，持续部署服务器还用于：对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

由于本实施例中集成和部署都是持续进行的，因此对于同一个功能，代码管理服务器中托管有很多版本的功能代码，相应地，持续部署服务器中存储有很多版本的可执行文件。历史可执行文件是指在对通过开发机终端上传的功能代码进行集成之前，持续部署服务器中已存储的不同版本的可执行文件，版本信息包括版本号、版本更新日期和版本更新内容等。

具体地，持续部署服务器在将可执行文件拉取至服务器本地之后，对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

本实施例中，通过对接收到的可执行文件进行归档，得到可执行文件的版本信息，通过版本信息匹配确定目标版本信息，从而确定目标可执行文件，能够达到对可执行文件的版本控制的目的。

在一个实施例中，仿真测试设备还用于：进行模型在环测试，进行软件在环测试；根据目标可执行文件，进行硬件在环测试。

其中，模型在环(Model in the loop，MIL)测试主要针对基于软件算法模型的软件开发，主要目的是验证软件算法模型的逻辑。软件在环(Model in the loop，MIL)测试的主要目的是验证代码和软件算法模型的一致性，即基于软件算法模型生成的或手写的代码功能与软件算法模型功能是否一致。硬件在环(Hardware in the loop，HIL)测试的主要目的是验证基于控制器的代码功能，即将代码下载到实际车辆的控制器中，对控制器进行功能测试。

模型在环测试和软件在环测试可以直接在自动驾驶仿真软件提供的仿真场景下进行，模型在环测试的仿真场景与软件在环测试的仿真场景相同，因此仿真测试设备可以在接收到目标可执行文件之前，依次进行模型在环测试和软件在环测试，也可以在接收到目标可执行文件之后，依次进行模型在环测试、软件在环测试和硬件在环测试。而硬件在环测试依赖于提前部署好的硬件仿真测试环境，硬件仿真测试环境包括与模型在环测试、软件在环测试相同的仿真场景，还包括实际车辆的控制器，控制器包括智能驾驶域控制器等域控制器，还包括支持OTA平台的、用于实现不同功能的多个ECU，例如辅助驾驶相关功能、车联网相关功能，控制器的选择取决于测试需求。

具体地，仿真测试结果包括模型在环测试结果、软件在环测试结果和硬件在环测试结果，仿真测试设备在接收到目标可执行文件之前，依次进行模型在环测试和软件在环测试，其中仿真测试设备进行模型在环测试的步骤包括：在仿真场景下，仿真测试设备对软件算法模型进行测试，得到模型在环测试结果，以便于后续开发者根据模型在环测试结果，不断优化软件算法模型，得到优化后的软件算法模型。在完成模型在环测试后，仿真测试设备进行软件在环测试的步骤包括：在与模型在环测试相同的仿真场景下，仿真测试设备对优化后的软件算法模型进行代码转化，得到模型代码，对模型代码进行测试，得到软件在环测试结果，以便于后续开发者根据软件在环测试结果，不断优化模型代码，得到优化后的模型代码。仿真测试设备在接收到目标可执行文件之后，进行硬件在环测试的步骤包括：在与目标可执行文件对应的硬件仿真测试环境下，仿真测试设备将目标可执行文件刷写到控制器，对整车的软件功能进行测试，得到硬件在环测试结果，以便于后续开发者根据硬件在环测试结果，迭代更新与目标可执行文件对应的功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件。

在一个实施例中，仿真测试结果包括模型在环测试结果、软件在环测试结果和硬件在环测试结果，仿真测试设备在接收到目标可执行文件之后，依次进行模型在环测试、软件在环测试和硬件在环测试。其中，仿真测试设备进行模型在环测试的步骤包括：在仿真场景下，仿真测试设备对软件算法模型进行测试，得到模型在环测试结果，以便于后续开发者根据模型在环测试结果，不断优化软件算法模型，得到优化后的软件算法模型。在完成模型在环测试后，仿真测试设备进行软件在环测试的步骤包括：在与模型在环测试相同的仿真场景下，仿真测试设备对优化后的软件算法模型进行代码转化，得到模型代码，对模型代码进行测试，得到软件在环测试结果，以便于后续开发者根据软件在环测试结果，不断优化模型代码，得到优化后的模型代码。在完成软件在环测试后，仿真测试设备进行硬件在环测试的步骤包括：在与目标可执行文件对应的硬件仿真测试环境下，仿真测试设备将目标可执行文件刷写到控制器，对整车的软件功能进行测试，得到硬件在环测试结果，以便于后续开发者根据硬件在环测试结果，迭代更新与目标可执行文件对应的功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件。

本实施例中，通过仿真测试设备进行模型在环测试、软件在环测试和硬件在环测试，在仿真场景下，从软件算法模型测试、代码测试和硬件仿真测试三个层面进行仿真测试，使得仿真测试结果更加接近实际车辆行驶过程中的测试结果，能够达到提高车辆自动驾驶软件的开发效率的目的。

在一个实施例中，仿真测试设备还用于：根据目标可执行文件，对硬件仿真测试环境中的控制器进行刷写，并基于硬件仿真测试环境，根据目标测试需求对整车进行功能测试，以完成硬件在环测试。

其中，目标测试需求是与目标可执行文件对应的测试需求。目标硬件仿真测试环境是与目标可执行文件对应的硬件仿真测试环境。

具体地，在接收到目标可执行文件之前，仿真测试设备基于不同的测试需求确定不同的硬件仿真测试环境，包括确定不同的控制器；并部署各硬件仿真测试环境，包括将各控制器接入仿真测试设备。在接收到目标可执行文件之后，仿真测试设备根据目标可执行文件确定目标硬件仿真测试环境，在目标硬件仿真测试环境下，将目标可执行文件刷写到控制器，根据与目标可执行文件对应的目标测试需求对整车的软件功能进行测试，整车的软件功能包括自动驾驶相关功能、辅助驾驶相关功能、车联网相关功能等，得到硬件在环测试结果，以便于后续开发者根据硬件在环测试结果，迭代更新与目标可执行文件对应的功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件。

本实施例中，通过基于目标可执行文件确定目标硬件仿真测试环境，将目标可执行文件刷写到目标硬件仿真测试环境的控制器，对整车进行功能测试，能够达到在目标硬件仿真测试环境下，通过仿真测试设备进行硬件在环测试的目的。

在一个实施例中，持续集成服务器，还用于：对功能代码进行编码规范检测和静态检测，生成第一问题清单；若对可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；若对可执行文件进行测试时，测试不通过，则生成第三问题清单。

其中，第一问题清单为检测不通过的功能代码的检测结果，第二问题清单为编译失败的可编译代码的编译结果，第三问题清单为测试不通过的可执行文件的测试结果。

具体地，在代码管理服务器发送触发信息至持续集成服务器之后，持续集成服务器接收触发信息，并从代码管理服务器中拉取功能代码至持续集成服务器本地，根据触发信息启动自动集成流程，对功能代码进行编码规范检测、静态检查等检测，若检测不通过，则自动生成第一问题清单，并将第一问题清单反馈至开发机终端。开发者根据第一问题清单对功能代码进行修改，并通过开发机终端重新上传至代码管理服务器，直至检测通过。

持续集成服务器将检测通过的功能代码与车辆自动驾驶工程进行集成，得到基于车辆自动驾驶工程的可编译代码。持续集成服务器对可编译代码进行编译，若无法得到可执行文件，则表示编译失败，自动生成第二问题清单，并将第二问题清单反馈至开发机终端。开发者根据第二问题清单对功能代码进行修改，并通过开发机终端重新上传至代码管理服务器，直至编译成功。持续集成服务器对可编译代码编译成功后，得到可执行文件。

持续集成服务器对可执行文件进行测试，包括单元测试、覆盖率测试和集成测试，若测试不通过，则自动生成第三问题清单，并将第三问题清单反馈至开发机终端。开发者根据第三问题清单对功能代码进行修改，并通过开发机终端重新上传至代码管理服务器，直至测试通过。

其中，单元测试是对软件中的最小可测试单元，例如函数，进行检查和验证；覆盖率测试是对测试完成程度的度量，用于根据某种覆盖准则来对测试用例执行情况进行衡量，以判断测试执行得是否充分，例如对代码运行过程中运行代码的行数覆盖率进行测试，指示测试了多少代码；集成测试，也叫组装测试或联合测试，是在单元测试的基础上，将所有通过单元测试的单元按照设计要求组装成子***或***进行的测试。

本实施例中，通过持续集成服务器将功能代码检测、可编译代码编译、可执行文件测试过程中的问题清单反馈至开发机终端，能够达到帮助开发者快速发现功能代码的问题、并快速完善功能代码的目的，有助于提高车辆自动驾驶软件的开发效率。

基于同样的发明构思，本申请实施例还提供了一种应用于上述所涉及的车辆自动驾驶软件的开发***的车辆自动驾驶软件的开发方法，该方法所提供的解决问题的实现方案与上述***中所记载的实现方案相似，故下面所提供的一个或多个车辆自动驾驶软件的开发方法实施例中的具体限定可以参见上文中对于车辆自动驾驶软件的开发***的限定，在此不再赘述。

在一个实施例中，如图2所示，提供了一种车辆自动驾驶软件的开发方法，包括以下步骤：

步骤202，通过代码管理服务器，接收通过开发机终端上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器。

步骤204，通过持续集成服务器，根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，并将测试通过的可执行文件发送至持续部署服务器。

步骤206，通过持续部署服务器，根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备和目标车辆。

步骤208，通过仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果。

步骤210，通过目标车辆，在满足实车测试条件的情况下，根据标可执行文件，对目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果。

步骤212，通过开发机终端，根据软件测试结果，以迭代的方式更新功能代码，直至软件测试结果满足预设条件，软件测试结果包括仿真测试结果和实车测试结果中的至少一种。

上述车辆自动驾驶软件的开发方法中，通过代码管理服务器，实现了功能代码的托管和归档；通过持续集成服务器，实现了将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，并对可执行文件进行测试；通过持续部署服务器，实现了可执行的版本控制和推送，减少了传统的软件开发流程中集成、编译、测试、刷写等需要人工操作的工作，从而减少了由于人工操作带来的低效率和可靠性差的问题，能够达到提高车辆自动驾驶软件的开发效率的目的；通过仿真测试设备和目标设备，实现了仿真测试和实车测试，形成了软件开发流程中从开发代码到代码测试的闭环，能够得到更准确、更全面的软件测试结果；通过开发机终端，根据软件测试结果，迭代更新功能代码，得到功能更完善、可靠性更高的车辆自动驾驶软件，满足车辆自动驾驶软件开发流程对于快速测试和验证的需求，从而进一步地提高了车辆自动驾驶软件的开发效率。

在一个实施例中，持续部署服务器中存储有多个历史可执行文件和多个历史可执行文件的历史版本信息，通过持续部署服务器，根据接收到的可执行文件确定目标可执行文件，包括：通过持续部署服务器，对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

在一个实施例中，通过仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，包括：通过仿真测试设备，在满足仿真测试条件的情况下，进行模型在环测试，进行软件在环测试；根据接收到的目标可执行文件，进行硬件在环测试。

在一个实施例中，根据接收到的目标可执行文件，进行硬件在环测试，包括：根据目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于目标硬件仿真测试环境，根据目标测试需求对整车进行功能测试，以完成硬件在环测试。

在一个实施例中，车辆自动驾驶软件的开发方法还包括：通过持续集成服务器，对功能代码进行编码规范检测和静态检测，生成第一问题清单；若对可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；若对可执行文件进行测试时，测试不通过，则生成第三问题清单。

在一个实施例中，如图3所示，提供了一种车辆自动驾驶软件的开发***的结构框图。车辆自动驾驶软件的开发***包括：开发者的开发机终端、代码管理服务器、CI服务器(持续集成服务器)、CD服务器(持续部署服务器)、仿真测试设备(本实施例中也称作仿真环境)、目标车辆(本实施例中也称为实车测试)。

其中，开发者的开发机终端、代码管理服务器、CI服务器、CD服务器、仿真环境均通过以太网连接，实车测试与CD服务器通过LTE无线数据网络连接，形成自动化软件持续集成及自动部署测试***的信号回路。

开发者通过开发机终端提交代码给代码管理服务器，并接收代码管理服务器、CI服务器、仿真环境、实车测试反馈的消息；代码管理服务器用于项目代码仓库管理、代码合并管理、权限管理，并反馈结果通知至开发者的开发机终端；CI服务器用于代码拉取、代码检查、自动化编译、自动化集成、自动化测试、配置管理，并反馈问题至开发者的开发机终端；CD服务器用于内容拉取、内容归档、并通过OTA平台实现远程推送；仿真环境用于模型在环测试、软件在环测试和硬件在环测试，并反馈问题至开发者的开发机终端；实车测试用于远程拉取、部署刷写和实车验证，并反馈问题至开发者的开发机终端。

图4为应用于上述车辆自动驾驶软件的开发***的车辆自动驾驶软件的开发方法的流程示意图。参考图4，车辆自动驾驶软件的开发方法包括以下步骤：

1、开发者根据开发团队定义的相关功能和开发任务，进行相关软件功能开发，通过开发机终端将具备试验条件的软件代码手动提交至代码管理服务器中。在整个开发过程中，开发者接收CI服务器、仿真环境、实车测试反馈的测试问题。开发者结合代码集成、仿真测试、实车测试环节中发现的问题，完善相关软件代码。

2、通过代码管理服务器，将代码管理服务器中的项目相关代码拉取至开发者使用的开发机终端中，以实现多个开发者之间的代码分发和协同开发；在开发者完成相关软件开发后，将开发机终端中的相关代码上传至服务器中托管；当需要功能集成时，对预计要提交至CI服务器的代码进行预评审，评审内容包括软件实现逻辑、数据结构、复杂度等；对通过预评审的代码状态进行检测，如符合触发条件，则提供CI服务器的触发信号，触发相关集成操作。

3、通过CI服务器，进行代码拉取：通过接收代码管理服务器提交的触发信息，启动自动集成流程；进行代码检查：对触发自动集成的代码进行编码规范、静态检查等编译前检查，对于检查不通过的代码，自动生成相关问题单，并反馈失败消息至开发者使用的开发机终端；进行自动化集成：将提交的代码与实际工程进行集成，形成基于整体软件工程可编译的代码，用于下一步自动化编译及测试；进行自动化编译：对集成的软件工程进行编译，编译成功后，对编译后产生的可执行文件进行自动化测试，并生成自动集成报告，便于后续开发者在维护软件代码时能够获取到代码集成的相关信息；对于编译失败的工程，自动生成相关问题单，并反馈失败消息至开发者使用的开发机终端；其中，自动化测试包括对编译成功后产生的可执行文件进行单元测试、覆盖率测试和集成测试，并将测试通过的可执行文件发送至CD服务器进行自动部署和仿真环境进行仿真测试；对于执行自动化测试失败的软件代码，自动生成相关问题单，并反馈失败消息至开发者使用的开发机终端。配置管理员根据各项目需求不同，可以通过对CI服务器的相关功能进行部署，并根据实际流程进行相关功能裁剪，例如对于只能在实车环境下进行测试的测试需求或者在仿真环境未搭建好的情况下，与测试需求对应的可执行文件可以不经过仿真环境下的仿真测试，又例如某些测试需求只能在仿真环境下进行测试，此时，与测试需求对应的可执行文件可以不经过实车环境下的实车测试，以实现软件开发过程中的配置管理。

4、通过CD服务器中，进行可执行文件拉取：根据CI服务器自动集成完成情况，将自动集成后的可执行文件拉取至服务器本地，用于后续文件归档及推送；进行可执行文件归档：将拉取至服务器的可执行文件进行文件归档，以实现对可执行文件的版本控制，便于后续推送及刷写；进行远程推送：基于测试需求，确定刷写至控制器的可执行文件的特定版本，将特定版本的可执行文件推送至OTA平台，由OTA平台分发至实际进行测试的车辆，完成相关控制器的软件更新。

5、通过仿真环境，接收从CI服务器中推送的软件代码及相关模型，并进行模型在环测试、软件在环测试、和硬件在环测试，以在软件开发前期解决相关问题。其中，模型在环测试主要针对基于模型的软件开发，测试对象为软件算法模型，主要验证软件算法逻辑；软件在环测试主要用于验证代码与模型一致性，此外，软件在环测试还验证手写代码相关的逻辑及功能；硬件在环测试主要用于控制器的代码功能测试，此项依赖于已经布置完毕的硬件仿真测试环境，硬件仿真测试环境包括与模型在环测试和软件在环测试相同的仿真环境，还包括实际车辆的控制器，通过自动化手段完成刷写及使用测试。在模型在环测试、软件在环测试、硬件在环测试过程中，如果存在仿真测试失败的情况，则自动生成相关问题单，并反馈失败消息至开发者使用的开发机终端。

6、通过实车测试，进行远程拉取：通过车载终端连接至OTA平台，从OTA平台以无线通信的网络传输协议完成数据拉取，存放在车辆终端本地，用于后续数据刷写；进行部署刷写：基于车辆本地(通常是车辆的车载Tbox)的CAN总线的文件刷写协议进行刷写，将特定版本的可执行文件刷写到车辆的控制器中，控制器可以是域控制器，也可以是其他功能的ECU，本实施例支持多ECU刷写，并对刷写程序进行校验，以完成整车软件功能的自动升级。

实车测试是针对整车的软件功能测试，依赖于已经部署完毕的实车测试环境，在通过自动化手段完成刷写后，需要由实车测试人员手动完成相关测试工作，在实车测试阶段，如果存在测试失败的情况，则由实车测试人员填写相关问题单，反馈失败信息至开发者的开发机终端。

本实施例中，通过将软件开发过程中的自动持续集成和自动持续部署与控制器验证和测试技术结合，将软件开发过程中产生的代码通过自动化手段，实现软件开发过程中从开发到集成、测试的自动化部署及测试。基于代码管理及版本控制技术，在代码管理服务器中实现了软件代码管理和版本控制；基于持续集成和持续部署技术，在CI服务器和4CD服务器中实现了代码持续集成及持续部署工作，显著提升集成效率，为开发团队提供更好的软件开发支持功能；基于持续部署及自动化测试技术，在仿真环境和实车测试中实现了软件的自动化推送刷写和自动化仿真测试，减少了在软件部署过程中由于人工带来的低效率和可靠性差的问题。并且，通过在整个开发流程中对相关问题进行自动化问题反馈和人工问题反馈，形成闭环，能够满足商用车自动驾驶软件开发对于敏捷和快速测试验证的需求，节省产品开发成本。

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

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的车辆自动驾驶软件的开发方法的车辆自动驾驶软件的开发装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个车辆自动驾驶软件的开发装置实施例中的具体限定可以参见上文中对于车辆自动驾驶软件的开发方法的限定，在此不再赘述。

在一个实施例中，如图5所示，提供了一种车辆自动驾驶软件的开发装置500，包括：代码管理模块502、持续集成模块504、持续部署模块506、仿真测试模块508、实车测试模块510和代码开发模块512，其中：

代码管理模块502，用于接收通过开发机终端上传的功能代码，产生与功能代码对应的触发信息，并发送触发信息至持续集成服务器。

持续集成模块504，用于根据触发信息，将功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对可执行文件进行测试，将测试通过的可执行文件发送至持续部署服务器。

持续部署模块506，用于根据接收到的可执行文件确定目标可执行文件，将目标可执行文件传输至仿真测试设备和目标车辆。

仿真测试模块508，用于在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果。

实车测试模块510，用于在满足实车测试条件的情况下，根据目标可执行文件，对目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果。

代码开发模块512，用于根据软件测试结果，以迭代的方式更新功能代码，直至软件测试结果满足预设条件，软件测试结果包括仿真测试结果和实车测试结果中的至少一种。

在一个实施例中，持续集成模块504中存储有多个历史可执行文件和多个历史可执行文件的历史版本信息，持续集成模块504还用于对接收到的可执行文件进行归档，得到接收到的可执行文件的版本信息；根据与目标测试需求对应的版本信息，从接收到的可执行文件的版本信息和历史版本信息中，确定目标版本信息；根据目标版本信息，确定目标可执行文件。

在一个实施例中，仿真测试模块508还用于进行模型在环测试，进行软件在环测试；根据目标可执行文件，进行硬件在环测试。

在一个实施例中，仿真测试模块508还用于根据目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于目标硬件仿真测试环境，根据目标测试需求对整车进行功能测试，以完成硬件在环测试。

在一个实施例中，持续集成模块504还用于对软件代码进行编码规范检测和静态检测，生成第一问题清单；若对可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；若对可执行文件进行测试时，测试不通过，则生成第三问题清单。

上述车辆自动驾驶软件的开发装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是上述实施例中提及的代码管理服务器、持续集成服务器、持续部署服务器中的任一服务器，其内部结构图可以如图6所示。该计算机设备包括通过***总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储功能代码、触发信息、车辆自动驾驶工程、可编译代码、可执行文件、仿真测试结果、实车测试结果等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种车辆自动驾驶软件的开发方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

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

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

Claims (10)

1.一种车辆自动驾驶软件的开发***，其特征在于，所述***包括：

代码管理服务器，用于接收通过开发机终端上传的功能代码，产生与所述功能代码对应的触发信息，并发送所述触发信息至持续集成服务器；

所述持续集成服务器，用于根据所述触发信息，将所述功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对所述可执行文件进行测试，将测试通过的可执行文件发送至持续部署服务器；

所述持续部署服务器，用于根据接收到的可执行文件确定目标可执行文件，将所述目标可执行文件传输至仿真测试设备和目标车辆；

所述仿真测试设备，用于在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果；

所述目标车辆，用于在满足实车测试条件的情况下，根据所述目标可执行文件，对所述目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果；

所述开发机终端，用于根据软件测试结果，以迭代的方式更新所述功能代码，直至所述软件测试结果满足预设条件，所述软件测试结果包括所述仿真测试结果和所述实车测试结果中的至少一种。

2.根据权利要求1所述的***，其特征在于，所述持续部署服务器中存储有多个历史可执行文件和所述多个历史可执行文件的历史版本信息，所述持续部署服务器还用于：

对接收到的可执行文件进行归档，得到所述接收到的可执行文件的版本信息；

根据与目标测试需求对应的版本信息，从所述接收到的可执行文件的版本信息和所述历史版本信息中，确定目标版本信息；

根据所述目标版本信息，确定目标可执行文件。

3.根据权利要求1所述的***，其特征在于，所述仿真测试设备还用于：

进行模型在环测试，进行软件在环测试；

根据所述目标可执行文件，进行硬件在环测试。

4.根据权利要求3所述的***，其特征在于，所述仿真测试设备还用于：

根据所述目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于所述目标硬件仿真测试环境，根据所述目标测试需求对整车进行功能测试，以完成所述硬件在环测试。

5.根据权利要求1所述的***，其特征在于，所述持续集成服务器，还用于：

对所述功能代码进行编码规范检测和静态检测，生成第一问题清单；

若对所述可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；

若对所述可执行文件进行测试时，测试不通过，则生成第三问题清单。

6.一种车辆自动驾驶软件的开发方法，其特征在于，所述方法包括：

通过代码管理服务器，接收通过开发机终端上传的功能代码，产生与所述功能代码对应的触发信息，并发送所述触发信息至持续集成服务器；

通过所述持续集成服务器，根据所述触发信息，将所述功能代码与车辆自动驾驶工程进行集成得到可编译代码，对可编译代码进行编译得到可执行文件，对所述可执行文件进行测试，并将测试通过的可执行文件发送至持续部署服务器；

通过所述持续部署服务器，根据接收到的可执行文件确定目标可执行文件，将所述目标可执行文件传输至仿真测试设备和目标车辆；

通过所述仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，得到仿真测试结果；

通过所述目标车辆，在满足实车测试条件的情况下，根据所述目标可执行文件，对所述目标车辆的控制器进行刷写，以对整车进行功能测试，得到实车测试结果；

通过所述开发机终端，根据软件测试结果，以迭代的方式更新所述功能代码，直至所述软件测试结果满足预设条件，所述软件测试结果包括所述仿真测试结果和所述实车测试结果中的至少一种。

7.根据权利要求6所述的方法，其特征在于，所述持续部署服务器中存储有多个历史可执行文件和所述多个历史可执行文件的历史版本信息，所述通过所述持续部署服务器，根据接收到的可执行文件确定目标可执行文件，包括：

通过所述持续部署服务器，对接收到的可执行文件进行归档，得到所述接收到的可执行文件的版本信息；

根据与目标测试需求对应的版本信息，从所述接收到的可执行文件的版本信息和所述历史版本信息中，确定目标版本信息；

根据所述目标版本信息，确定目标可执行文件。

8.根据权利要求6所述的方法，其特征在于，所述通过所述仿真测试设备，在满足仿真测试条件的情况下，根据接收到的目标可执行文件进行仿真测试，包括：

通过所述仿真测试设备，在满足仿真测试条件的情况下，进行模型在环测试，进行软件在环测试；

根据接收到的目标可执行文件，进行硬件在环测试。

9.根据权利要求8所述的方法，其特征在于，所述根据接收到的目标可执行文件，进行硬件在环测试，包括：

根据所述目标可执行文件，对目标硬件仿真测试环境中的控制器进行刷写，并基于所述目标硬件仿真测试环境，根据所述目标测试需求对整车进行功能测试，以完成所述硬件在环测试。

10.根据权利要求6所述的方法，其特征在于，所述方法还包括：

通过所述持续集成服务器，对所述功能代码进行编码规范检测和静态检测，生成第一问题清单；

若对所述可编译代码进行编译时，无法得到可执行文件，则生成第二问题清单；

若对所述可执行文件进行测试时，测试不通过，则生成第三问题清单。

Images