CN116774679A - 一种自动驾驶车辆测试方法、系统、装置和存储介质 - Google Patents

Abstract

本申请实施例公开了一种自动驾驶车辆测试方法、系统、装置和存储介质。方法由处理器执行，包括：向待测试车辆发出执行初始测试方案的指令；通过通讯网络获取待测试车辆反馈的初始测试方案对应的测试数据；基于测试数据确定分析结果；响应于分析结果不满足预设条件，基于分析结果确定补充测试方案；生成并向补充测试车辆发送控制指令，以控制补充测试车辆执行补充测试方案。本说明书通过向待测试车辆远程发送指令，并基于待测试车辆返回的测试数据进行分析，在分析结果不满足预设条件时，控制其他自动驾驶车辆（即补充测试车辆）进行补充测试，从而可以实现自动驾驶车辆的自动化测试，节约人力的同时提高了测试的效率。

Description

一种自动驾驶车辆测试方法、系统、装置和存储介质

技术领域

本说明书涉及自动驾驶技术领域，特别涉及一种自动驾驶车辆测试方法、系统、装置和存储介质。

背景技术

随着自动驾驶技术的广泛运用，自动驾驶车辆测试也成为自动驾驶研发中的重要环节之一。在出厂前，会对自动驾驶车辆的性能进行测试，以确定车辆在实际行驶过程中的性能表现与设计的性能一致，保证自动驾驶车辆的正常工作。

针对自动驾驶车辆测试，CN114235442B提出了一种自动驾驶车辆性能测试方法，该申请重点通过控制自动驾驶车辆沿行驶路径行驶，得到车辆的功率的测试结果，但是该方法仍需要技术人员的大量介入才能完成，如需要技术人员申请测试车辆、修改车辆中执行测试的软件参数、从车辆端下载测试数据、分析测试数据等，导致自动驾驶车辆测试会耗费大量的人力物力，使得测试的效率较低。

因此，希望提供一种自动驾驶车辆测试方法、系统、装置和存储介质，以提高自动驾驶车辆测试的效率。

发明内容

本说明书实施例之一提供一种自动驾驶车辆测试方法。所述方法由处理器执行，所述方法包括：向待测试车辆发出执行初始测试方案的指令；通过通讯网络获取待测试车辆反馈的初始测试方案对应的测试数据；基于测试数据确定分析结果；响应于分析结果不满足预设条件，基于分析结果确定补充测试方案；生成并向补充测试车辆发送控制指令，以控制补充测试车辆执行补充测试方案。

本说明书实施例之一提供一种自动驾驶车辆测试系统。所述系统包括：初始测试模块，被配置为向待测试车辆发出执行初始测试方案的指令；数据获取模块，被配置为通过通讯网络获取所述待测试车辆反馈的所述初始测试方案对应的测试数据；数据分析模块，被配置为基于所述测试数据确定分析结果；方案生成模块，被配置为响应于所述分析结果不满足预设条件，基于所述分析结果确定补充测试方案；补充测试模块，被配置为生成并向补充测试车辆发送控制指令，以控制所述补充测试车辆执行所述补充测试方案。

本说明书实施例之一提供一种自动驾驶车辆测试装置，所述装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现任务跟踪管理方法。

本说明书实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行自动驾驶车辆测试方法。

附图说明

本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本说明书一些实施例所示的自动驾驶车辆测试系统的结构示意图；

图2是根据本说明书一些实施例所示的自动驾驶车辆测试方法的示例性流程图；

图3是根据本说明书一些实施例所示的确定车辆一致性结果的示例性流程图；

图4是根据本说明书一些实施例所示的确定补充测试方案的示例性流程图。

具体实施方式

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

对于如何进行自动驾驶车辆测试，目前的测试往往需要大量人工的介入才能完成，如替换车辆的测试软件、收集测试数据、分析测试数据等，导致自动驾驶车辆测试会耗费大量的人力物力，使得测试的效率较低。

因此，本说明书一些实施例通过向待测试车辆远程发送指令，并基于待测试车辆返回的测试数据进行分析，在分析结果不满足预设条件时，控制其他自动驾驶车辆（即补充测试车辆）进行补充测试，从而可以实现自动驾驶车辆的自动化测试，节约人力的同时提高了测试的效率。

图1是根据本说明书一些实施例所示的自动驾驶车辆测试系统的结构示意图。

在一些实施例中，如图1所示，所述自动驾驶车辆测试系统100可以包括初始测试模块110、数据获取模块120、数据分析模块130、方案生成模块140和补充测试模块150。

在一些实施例中，初始测试模块110可以用于向待测试车辆发出执行初始测试方案的指令。

在一些实施例中，数据获取模块120可以用于通过通讯网络获取所待测试车辆反馈的初始测试方案对应的测试数据。

在一些实施例中，数据分析模块130可以用于基于测试数据确定分析结果。

在一些实施例中，方案生成模块140可以响应于分析结果不满足预设条件，基于分析结果确定补充测试方案。

在一些实施例中，补充测试模块150可以用于生成并向补充测试车辆发送控制指令，以控制补充测试车辆执行补充测试方案。

在一些实施例中，自动驾驶车辆测试系统100还可以包括异常分析模块，其可以用于：基于多组测试数据，确定全局测试结果；基于全局测试结果，确定多辆待测试车辆中的异常车辆；基于异常车辆的异常程度，确定异常车辆的车辆性能一致性结果。

在一些实施例中，补充测试模块还可以用于：将异常车辆的车辆性能一致性结果与一致性条件进行比较；响应于比较结果不满足预设条件，基于异常车辆的测试路段、初始测试方案以及车辆性能一致性结果，为异常车辆的测试路段确定补充测试方案。

在一些实施例中，补充测试模块还可以用于基于异常车辆的车辆性能一致性结果，确定执行补充测试方案的补充测试车辆的数量。

在一些实施例中，自动驾驶车辆测试系统100还可以包括恢复数据模块，其可以用于执行完成初始测试方案后，指示待测试车辆将车辆状态恢复至测试前状态；和/或执行完成补充测试方案后，指示补充测试车辆将车辆状态恢复至测试前状态。

关于自动驾驶车辆测试系统100的更多细节参见图2-图4及其相关描述。

需要注意的是，以上对于初始测试模块、数据获取模块及其他模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。在一些实施例中，图1中披露的数据获取模块、数据分析模块和方案生成模块可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本说明书的保护范围之内。

图2是根据本说明书一些实施例所示的自动驾驶车辆测试方法的示例性流程图。如图2所示，流程200包括下述步骤。在一些实施例中，流程200可以由处理器执行。

步骤210，向待测试车辆发出执行初始测试方案的指令。

待测试车辆可以是等待基于测试数据进行测试的至少一辆自动驾驶车辆。在一些实施例中，待测试车辆可以至少包括处于空闲状态的自动驾驶车辆。其中，空闲状态可以是自动驾驶车辆未参与生产作业的状态。

在一些实施例中，处理器可以通过多种方式确定待测试车辆。例如，处理器可以基于用户上传的测试申请，根据测试申请确定待测试车辆。其中，申请内容可以包括待测试时间、待测试项、待测试模块、期望的待测试车辆、希望得到的测试反馈等。

其中，待测试时间可以为用户期望本次测试的发生时间，以便处理器调度车辆。待测试项可以为用户期望自动驾驶车辆在本次测试中需要执行的测试步骤。待测试模块可以为本次测试涉及到的车辆上的模块，如可以包括待测试模块需要满足的条件以及本次测试对这些模块的修改内容。期望的待测试车辆可以为本次测试涉及到的车辆，如可以包括待测试车辆需要满足的条件以及本次测试对这些车辆的修改内容。希望得到的测试反馈可以为用户希望得到的反馈内容，如希望采集到的指标、希望得到的传感器数据等。

在一些实施例中，处理器还可以通过多种方式确定待测试车辆。例如，处理器可以基于预先存储的自动驾驶车辆的信息，寻找满足测试申请中所有申请内容的驾驶车辆，将满足测试申请的所有的自动驾驶车辆，确定为待测试车辆。在一些实施例中，处理器还可以将测试申请进行记录，并在确定了待测试车辆之后，向用户显示申请结果。处理器还可以向用户展示分配的待测试车辆，以得到用户的确认。

在一些实施例中，初始测试方案可以用于指导自动驾驶车辆执行相对应的车辆性能测试。初始测试方案可以但不限于包括测试模块，测试车辆，测试时间，测试项，希望得到的测试反馈等。其中，测试项可以包括但不限于：自动驾驶能力测试、安全可靠能力测试、精确程度测试、软硬件集成性能测试、联网性能和数据安全测试以及用户体验测试。

其中，自动驾驶能力测试可以用于测试自动驾驶车辆的感知能力、决策能力、规划路线等能力。安全可靠能力测试可以用于测试车辆的应急制动、防碰撞能力、避障能力等。精确程度测试可以用于测试车辆的位置估计、路径规划和控制精度等方面的性能，其可以包括但不限于车辆对道路标识的识别准确度、车辆行驶轨迹准确度等。软硬件集成性能测试可以用于测试车辆中的传感器与控制系统的通信稳定性、匹配程度等。联网性能和数据安全测试可以用于测试自动驾驶车辆的网络连接性能、数据传输效率和数据安全性等能力。用户体验测试可以用于测试车辆的舒适性、操作界面的友好性、系统的可操作性等。

在一些实施例中，初始测试方案还可以包括但不限于待测试车辆的测试路段及测试路段对应的测试项。其中，测试路段可以为指定待测试车辆执行测试项的路段。

在一些实施例中，不同的待测试车辆的测试路段可以不同，不同的待测试车辆的测试项可以相同，以便分析待测试车辆在不同测试路段的车辆性能。

在一些实施例中，测试路段还可以包括多个测试子路段以及测试子路段对应的测试项。在一些实施例中，一个待测试车辆可以在多个测试子路段中执行测试项，并在不同的测试子路段中执行不同的测试项，从而实现对待测试车辆的多个性能的测试。

在一些实施例中，处理器可以根据申请内容，确定待测试车辆对应的初始测试方案。在一些实施例中，处理器也可以通过其他方式确定待测试车辆与初始测试方案的对应关系，如随机为待测试车辆分配初始测试方案。

在一些实施例中，指令用于驱使待测试车辆根据初始测试方案执行对应的车辆能力测试。在一些实施例中，指令还可以用于指示待测试车辆通过通讯网络下载对应的初始测试方案。在一些实施例中，指令可以包括初始测试方案的标识，以指示待测试车辆通过通讯网络下载对应的初始测试方案。在一些实施例中，指令也可以包括初始测试方案，以使接收到指令的待测试车辆可以直接获取初始测试方案。

在一些实施例中，处理器可以通过通讯网络与待测试车辆建立通信，通过通讯网络向待测试车辆发送对应的测试指令。在一些实施例中，处理器可以根据申请内容中的待测试时间，在预定时间向待测试车辆发送对应的测试指令。其中，预设时间可以早于或等于待测试时间。

步骤220，通过通讯网络获取待测试车辆反馈的初始测试方案对应的测试数据。

测试数据可以为与待测试车辆性能测试相关的数据，其可以用于反映待测试车辆的车辆性能。在一些实施例中，测试数据可以包括至少一个测试项的测试数据，如自动驾驶能力测试数据、安全可靠能力测试数据、精确程度测试数据等。测试项的更多细节可以参看上述相关描述。

在一些实施例中，测试数据可以包括预设上报数据和指定上报数据。其中，预设上报数据可以为预先设定的需要反馈给处理器的测试数据，如车辆底盘状态数据等。指定上报数据可以为此次测试用户指定的额外需要关注的测试数据。在一些实施例中，待测试车辆可以根据初始测试方案中希望得到的测试反馈，确定指定上报数据。

在一些实施例中，待测试车辆可以在预定测试开始时间执行测试项，并记录测试期间发生的事件。待测试车辆的测试执行模块可以在预定时间启动测试项，待测试车辆的本地记录模块可以持续监控测试期间发生的各种事件，得到测试项的测试数据。例如，在测试期间发生的各种事件可以包括：传感器时序状态、车辆时序行为、模块时序行为等。在一些实施例中，待测试车辆的本地记录模块还可以将监控到的各种事件进行存储。

在一些实施例中，在执行测试项之前，待测试车辆可以基于测试项准备测试环境。例如，待测试车辆可以将测试项相对应的修改下载至待测试车辆的车辆本地，还可以将测试模块相对应的修改下载至车辆本地。在一些实施例中，待测试车辆还可以对下载后的测试项进行本地校验，以确定待测试车辆是否能够执行该测试项。

在一些实施例中，待测试车辆可以在预定测试开始时间前保存当前状态，并准备执行测试项。其中，当前状态可以包括当前车辆状态和当前模块状态。待测试车辆可以将下载的测试项相对应的修改应用至车辆和模块，以完成执行测试项的准备。在一些实施例中，待测试车辆也可以在执行测试项之前进行自检操作，以检查修改后的车辆和模块是否能够达到执行测试项的要求。

在一些实施例中，处理器可以通过多种方式获取到至少一个待测试车辆反馈的测试数据。例如，处理器可以通过通讯网络与待测试车辆上设置的传感器建立通信，从而控制传感器在待测试车辆执行测试项时采集对应的测试数据。

相对应的，在一些实施例中，待测试车辆反馈测试数据的方式有多种。例如，待测试车辆可以在预设上传时间内将测试数据发送给处理器；也可以在收到处理器发送的请求反馈指令后，向处理器发送测试数据。

步骤230，基于测试数据确定分析结果。

分析结果是指对至少一个待测试车辆反馈的测试数据进行分析得到的结果。在一些实施例中，分析结果可以包括自动驾驶车辆执行测试项的评价指标值，其可以用于反映测试数据的表现是否良好。例如，测试数据在某一时间段内越稳定，该测试数据的表现越好，则处理器确定的测评值的评价指标值越高。

在一些实施例中，分析结果可以用于衡量该测试数据是否表现良好、是否能够准确地反映待测试车辆的该测试项能力。测试数据表现良好可以说明当前采集到的测试数据可以满足测试分析的需求，表现异常可以说明当前采集到的测试数据无法满足采集测试分析需求，可以进行补充测试以获取更多的测试数据。

在一些实施例中，处理器可以通过多种方式确定分析结果。例如，处理器可以基于测试数据，在分析结果对应表中查找与该测试数据相近的参考测试数据，并确定与参考测试数据对应的参考分析结果。其中，分析结果对应表可以待测试车辆的历史分析数据建立，也可以通过人工经验等其他方式建立。

在一些实施例中，处理器还可以对测试数据进行多种处理，以便进行分析。例如，处理器可以预先解析待测试车辆打包上传的测试数据。在一些实施例中，若接收到来自多个待测试车辆的测试数据，处理器可以提前合并测试数据（如，求多个测试数据的均值等），再对合并后的测试数据进行综合分析。在一些实施例中，处理器还可以将测试数据进行存储，以便后续进行数据分析。

在一些实施例中，响应于满足预设通知条件，处理器可以向发出测试申请的用户输出通知信息，以提示用户车辆已完成初始测试任务。其中，预设通知条件可以包括但不限于：处理器接收到预设数目的测试数据、达到预设时间点。其中，预设数据和预设时间点可以根据历史测试过程或人工经验等多种方式确定。

在一些实施例中，分析结果可以包括车辆性能一致性结果，一辆待测试车辆的车辆性能一致性结果，可以体现该辆待测试车辆对应的测试数据与全局测试数据的一致性程度。

全局测试数据是指多个正常的待测试车辆的车辆性能测试相关的数据，其可以用于反映自动驾驶车辆的正常车辆性能。如果待测试车辆均正常，则多个正常的待测试车辆在不同的测试子路段执行同一测试任务，得到的测试数据也应当保持一致。

在一些实施例中，处理器可以通过多种方式获取全局测试数据。例如，处理器可以对多个正常的待测试车辆的测试数据进行数学运算（如求平均值等），得到全局测试数据。全局测试数据的更多细节可以参看下述图3及其相关描述。

在一些实施例中，车辆性能一致性结果可以包括整体性能一致性结果和独立性能一致性结果。其中，独立性能一致性结果可以反映待测试车辆的某一个测试项的测试数据，与多个自动驾驶车辆的该测试项的测试数据的一致性程度。例如，车辆A的安全可靠能力测试的测试数据，与多个自动驾驶车辆在安全可靠能力测试（即，测试项中的一种）的测试数据的相似程度。整体性能一致性结果可以反映一个待测试车辆的所有测试数据，与多个自动驾驶车辆的测试数据的一致性程度。

在一些实施例中，一致性程度越高，说明该待测试车辆的测试数据与多个自动驾驶车辆的测试数据相似，待测试车辆对应的测试数据反映的车辆性能也就越准确。

在一些实施例中，处理器可以通过多种方式确定车辆性能一致性结果。例如，处理器可以基于该待测试车辆的测试数据与全局测试数据，构建车辆特征向量，在性能向量数据库中检索，检索到与车辆特征向量相似的参考车辆特征向量，将该参考车辆特征向量对应的参考车辆性能一致性结果，确定为车辆性能一致性结果。其中，性能向量数据库可以包括多个参考车辆特征向量及其各自对应的参考车辆性能一致性结果，参考车辆特征向量可以基于历史测试数据与历史全局测试数据建立，参考车辆性能一致性结果可以基于历史测试数据与历史全局测试数据的一致性程度建立。关于确定车辆性能一致性结果的更多细节，可以参看下述图3及其相关描述。

步骤240，响应于分析结果不满足预设条件，基于分析结果确定补充测试方案。

预设条件可以是测试数据达到符合车辆测试的需求的条件。在一些实施例中，当分析结果满足预设条件时，可以说明测试数据达到车辆测试的需求，能够准确地反映待测试车辆的车辆性能，则处理器无需再获取更多测试数据。反之，则处理器需要再获取更多的测试数据，如进行补充测试，以提高测试准确性。

在一些实施例中，预设条件可以包括多个测试数据的一致性程度高于一致性阈值。补充测试的更多细节参看下述相关描述。

在一些实施例中，处理器可以通过多种方式确定预设条件，如基于历史车辆测试的需求确定预设条件，或是基于人工经验确定。确定预设条件的更多细节，可以参看下述图4及其相关描述。

在一些实施例中，预设条件还可以包括一致性条件。

一致性条件是指待测试车辆的测试数据与全局测试数据的一致性程度，达到车辆测试的需求的条件。在一些实施例中，一致性条件可以包括待测试车辆的测试数据与全局测试数据的一致性程度，高于一致性阈值。其中，一致性阈值可以根据人工经验确定。

在一些实施例中，当一致性程度满足预设条件时，可以说明测试数据与全局测试数据的一致性程度，达到车辆测试的需求，能够准确地反映待测试车辆的车辆性能。

在一些实施例中，补充测试方案可以用于指导自动驾驶车辆再次执行的车辆性能测试，以获取测试数据进行补充。在一些实施例中，补充测试方案可以包括但不限于：补充测试车辆、补充测试车辆的测试路段及测试项。其中，补充测试车辆可以为新增的测试车辆。补充测试车辆的测试路段可以与前述初始测试方案中的测试路段相同，也可以不同。补充测试车辆的测试项可以与前述初始测试方案中的测试项相同，从而对同一测试项的测试数据进行补充。

例如，处理器在初始测试方案中控制待测试车辆进行软硬件集成性能测试，则处理器在补充测试方案中也可以控制补充测试车辆进行软硬件集成性能测试，以补充软硬件集成性能测试的测试数据。补充测试车辆的测试子路段及测试项的具体实现方式，与上述待测试车辆的测试子路段和测试项类似，更多细节可以参看上述步骤210及其相关描述。

在一些实施例中，处理器可以通过多种方式确定补充测试方案。例如，处理器可以基于不满足预设条件的测试数据，在补充任务对应表中查找与该测试数据相近的历史测试数据，并确定与历史测试数据对应的历史补充测试任务，作为该测试数据的补充测试任务。其中，补充任务对应表可以基于历史测试数据以及对应的历史补充测试任务建立，历史测试数据以及对应的历史补充测试任务均可以由处理器通过网络或人工输入等方式获得。确定补充测试方案的更多细节可以参看图4及其相关描述。

步骤250，生成并向补充测试车辆发送控制指令，以控制补充测试车辆执行补充测试方案。

在一些实施例中，处理器可以通过多种方式确定补充测试车辆。例如，处理器可以通过随机挑选的方式从多个自动驾驶车辆中选择出至少一个，作为补充测试车辆。

在一些实施例中，补充测试车辆可以包括当前时段的空闲车辆和/或未来时段的空闲车辆。

在一些实施例中，空闲车辆可以为处于空闲状态的自动驾驶车辆。空闲状态的更多细节可以参看上述相关描述。需要说明的是，空闲车辆也可以包括执行完初始测试方案、且处于空闲状态的待测试车辆。

在一些实施例中，处理器可以通过多种方式确定空闲车辆。例如，处理器可以通过通讯网络获取自动驾驶车辆的状态，基于空闲状态选择对应的空闲车辆。

在一些实施例中，处理器可以通过多种方式确定补充测试车辆。例如，处理器可以从当前时段的空闲车辆和/或未来时段的空闲车辆中随机选择至少一个，作为补充测试车辆。处理器也可以基于测试申请再次分配补充测试车辆。其中，分配补充测试车辆的具体实现方式，可以与上述分配待测试车辆的具体实现方式类似，更多细节可以参看上述相关描述。

在一些实施例中，处理器可以基于预设补充测试车辆数量，确定补充测试车辆。处理器可以优先调用当前时段的空闲车辆作为补充测试车辆，如果当前时段的空闲车辆数量小于预设补充测试车辆数量，则处理器可以调用未来时间段的空闲车辆作为补充测试车辆。其中，预设补充测试车辆数量可以根据历史测试数据或人工经验确定。补充测试车辆的数量的更多细节可以参看下述图4及其相关描述。

在一些实施例中，控制指令用于指示补充测试车辆执行补充测试方案。生成、控制指令的具体实现方式，与上述处理器发出的执行初始测方案的指令类似，更多细节可以参看前述相关描述。

在本说明书实施例中，通过向待测试车辆远程发送指令，并基于待测试车辆返回的测试数据进行分析，在分析结果不满足预设条件时，控制其他自动驾驶车辆（即补充测试车辆）进行补充测试，从而可以实现自动驾驶车辆的自动化测试，节约人力的同时提高了测试的效率。

在一些实施例中，处理器还可以在执行完成初始测试方案后，指示待测试车辆将车辆状态恢复至测试前状态；和/或执行完成补充测试方案后，指示补充测试车辆将车辆状态恢复至测试前状态。

车辆状态是指自动驾驶车辆（如待测试车辆、补充测试车辆等）的当前状态。在一些实施例中，测试前状态可以为自动驾驶车辆在执行测试方案之前的状态，如空闲状态或作业状态。

在一些实施例中，处理器可以向自动驾驶车辆发送指示，指示自动驾驶车辆在测试完成后自动删除测试方案（如初始测试方案、补充测试方案），并基于存储的车辆状态和模块状态进行恢复。其中，车辆状态和模块状态可以为待测试车辆在预定测试开始时间前保存的当前状态。车辆状态和模块状态的更多细节可以参看上述步骤210及其相关描述。

在一些实施例中，处理器还可以检查自动驾驶车辆是否满足预设生产作业条件。若满足，则处理器控制自动驾驶车辆继续参与生产作业，反之，则处理器控制自动驾驶车辆处于空闲状态。其中，预设生产作业条件可以基于历史生产作业数据确定，还可以基于人工经验等其他方式确定。

在本说明书实施例中，通过指示自动驾驶车辆恢复至测试前状态，可以使得车辆能够继续参与生产作业，从而实现对完成测试的自动驾驶车辆的生产管理。

图3是根据本说明书一些实施例所示的确定车辆一致性结果的示例性流程图。

在一些实施例中，待测试车辆可以包括多辆，测试数据301可以包括多组，每组测试数据301对应一辆待测试车辆。相对应的，在一些实施例中，处理器可以基于多组测试数据301，确定全局测试结果302；基于全局测试结果302，确定多辆待测试车辆中的异常车辆303；基于异常车辆303的异常程度304，确定异常车辆303的车辆性能一致性结果305。

也就是说，存在多个待测试车辆执行同一测试方案，且在每个待测试车辆在执行完测试方案后，均会向处理器反馈一组测试数据301。待测试车辆、多组测试数据301的更多细节参看上述图2及其相关描述。

全局测试结果302可以是多个待测试车辆的车辆性能测试相关的测试结果，其可以用于反映自动驾驶车辆的正常车辆性能。由于多个待测试车辆中的大部分均正常，即使出现部分处于异常状态的待测试车辆，而得到的全局测试结果302也可以趋向于一致，从而处理器可以利用全局测试结果302作为参考，以确定待测试车辆中的异常车辆303。

在一些实施例中，处理器可以基于多组测试数据301，通过多种方式确定全局测试结果302。在一些实施例中，每一组测试数据301可以包括多个测试参数。其中，一个测试参数是指一个待测试车辆执行一个测试项得到的测试数值。相对应的，处理器可以基于多组测试数据301，确定多组测试数据301中相同测试项的多个测试参数，并对相同测试项的多个测试参数进行数学运算，得到全局测试结果302中的相同测试项的测试参数。全局测试结果302中的相同测试项的测试参数可以反映该测试项的测试参数在多组测试数据301中的整体水平。

例如，第一组测试数据包括自动驾驶能力测试项的第一测试参数，第二组测试数据包括自动驾驶能力测试项的第二测试参数，则第一测试参数与第二测试参数可以为多组测试数据的相同测试项的测试参数。相对应的，处理器可以对多组测试数据的相同测试项的测试参数（如，第一测试参数和第二测试参数）进行求方差、求均值302-1等数学运算操作，得到全局测试结果302中的相同测试项的测试参数，其可以反映自动驾驶能力测试项的测试参数在多组测试数据301中的整体水平。

在一些实施例中，一组测试数据301可以包括多个子数据，该子数据可以为测试子路段对应的测试数据301。相对应的，在一些实施例中，处理器可以对多个子数据加权求和，得到一组测试数据301；加权求和的权重正相关于子数据对应的测试子路段的道路复杂度。

子数据可以为不同待测试车辆反馈的不同测试子路段的测试数据，其可以用于评估车辆在不同测试子路段上的车辆性能。例如，子数据1可以为车辆A在测试子路段1上的安全可靠能力测试数据，子数据2可以为车辆B在测试子路段2上的安全可靠能力测试数据。

在一些实施例中，处理器可以通过多种方式获取子数据，如通过待测试车辆上设置的传感器获取子数据。获取子数据的具体实现方式，与获取测试数据301的方式类似，可以参看上述相关描述。

在一些实施例中，不同子数据可以对应不同的权重。其中，权重可以用于反映某一子数据反映的待测试车辆的车辆性能的准确程度。例如，权重越高表明该子数据可以越准确地反映车辆性能。相对应的，在一些实施例中，处理器可以为不同的子数据设定不同的权重，以使加权求和的测试数据301可以更加准确地反映待测试车辆的车辆性能。

道路复杂度是指测试子路段中的路况、地形等的变化程度。在一些实施例中，道路复杂度可以影响不同子数据对应的权重。例如，道路复杂度越高，该测试子路段对车辆的考验难度越大，从而得到的子数据也就越具有代表性和参考性，越能够准确地反映车辆性能，从而处理器可以为该子数据设定越大的权重。

在一些实施例中，处理器可以通过多种方式获取道路复杂度。例如，处理器可以通过定位装置获取测试子路段的位置信息，再基于位置信息通过网络等多种渠道获取测试子路段的道路复杂度；也可以在待测试车辆执行测试项时，利用待测试车辆的传感器实时采集测试子路段的道路复杂度，再由待测试车辆将道路复杂度发送给处理器。

在一些实施例中，处理器可以基于道路复杂度，为同一测试项的多个测试子路段的子数据设定不同的权重，并对多个子数据进行加权求和，得到与该测试项对应的测试数据301。

在一些实施例中，可以基于道路复杂度为不同测试子路段的子数据设定权要，通过加权求和的方式确定的测试数据301，可以更加准确地反映车辆性能，从而可以提高自动驾驶车辆测试的准确性。

异常车辆303可以为测试数据301发生异常的测量。在一些实施例中，测试数据301发生异常的原因可以包括但不限于：车辆异常工作、车辆装置异常工作、传感器异常工作等。

在一些实施例中，处理器可以基于全局测试结果302，通过多种方式确定多辆待测试车辆中的异常车辆303。例如，处理器可以响应于待测试车辆的测试参数满足预设异常条件，将该待测试车辆确定为异常车辆303。其中，预设异常条件可以包括：待测试车辆的任一测试参数与全局测试结果302中相同测试项的测试参数的差异超过预设参数阈值。例如，待测试车辆的自动驾驶能力测试项的第一测试参数，与全局测试结果302中的自动驾驶能力测试项的测试参数的差异超过预设参数阈值，则处理器可以认为第一测试参数满足预设异常条件，该待测试车辆为异常车辆。预设参数阈值可以根据人工经验设定。

在一些实施例中，全局测试结果302可以包括多组测试数据301中相同测试项的测试参数的均值302-1。相对应的，处理器可以将多组测试参数分别与均值302-1比较确定差值，基于差值与参数阈值确定异常车辆303。

在一些实施例中，均值302-1可以为处理器对多组测试数据301中相同测试项的测试参数求取平均得到的数值。在一些实施例中，每一组测试参数与均值302-1的差值，可以反映每一组测试数据301中的相同测试项的测试参数与整体水平的差距。例如，差值越大，该测试参数与整体水平的差距越大，对应的待测试车辆异常的可能性也就越大。

在一些实施例中，不同测试参数的参数阈值可以不同，参数阈值可以与多组测试数据301中相同测试项的测试参数的方差正相关。测试参数的方差越小，该测试参数对应的参数阈值越小。其中，方差可以反映相同测试项的测试参数的参数整体波动情况。例如，方差越小，证明该测试参数的稳定性越好，而待测试车辆的测试参数与均值302-1的差异稍微大一些，该参数可能都是异常的，则处理器可以设置较小的参数阈值，以准确地确定异常车辆303。

在一些实施例中，处理器可以将差值大于参数阈值的待测试车辆确定为异常车辆303。

在本说明实施例中，通过为不同测试参数设定不同的参数阈值，并设置参数阈值与相同测试项的测试参数的方差正相关，使得基于参数阈值确定的异常车辆303更加准确，从而提高了自动驾驶车辆测试的准确性。

在一些实施例中，异常车辆303的异常程度304可以指该异常车辆303的测试参数与相同测试项的测试参数的整体水平的差异程度。例如，该异常车辆303的测试参数与相同测试项的测试参数的整体水平的差异程度越大，则异常车辆303的异常程度304也就越大。

在一些实施例中，处理器可以通过多种方式确定异常车辆303的异常程度304。例如，处理器可以将异常车辆303的每个测试参数的异常程度304相加，得到的总和确定为该异常车辆303的异常程度304。其中，每个测试参数的异常程度304可以为该测试参数的参数值与相同测试项的测试参数的均值302-1的差值的绝对值，与相同测试项的测试参数的均值302-1的比值，即测试参数i的异常程度=|测试参数i的参数值-相同测试项的测试参数i的均值|÷相同测试项的测试参数i的均值×100%。

在一些实施例中，异常车辆303的异常程度304可以用于衡量车辆性能的一致性。例如，异常程度304越高，说明异常车辆303的测试参数与全局测试结果302的相同测试项的测试参数相差越大，则异常车辆303的车辆性能一致性越低。

使用车辆性能的异常程度304来衡量车辆性能的一致性，车辆的异常程度304越大，车辆性能的一致性越小，可以预设异常程度304与车辆性能的一致性之间的对应关系。相对应的，处理器可以预设异常程度304与车辆性能一致性的对应关系，以便确定车辆性能一致性。

在一些实施例中，处理器可以基于异常车辆303的异常程度304，通过多种方式确定异常车辆303的车辆性能一致性结果305。例如，处理器可以基于异常车辆303的异常程度304，在一致性结果对应表中查找与该异常程度304相近的参考异常程度304，并确定与参考异常程度304对应的车辆性能一致性结果305。其中，一致性结果对应表可以基于异常程度304与车辆性能一致性的预设对应关系建立。

在本说明书实施例中，通过多组测试数据确定全局测试结果，从而确定异常车辆及其异常程度，可以更加快速地确定异常车辆的车辆性能一致性结果，从而提高自动驾驶车辆测试的效率。

图4是根据本说明书一些实施例所示的确定补充测试方案的示例性流程图。

在一些实施例中，处理器可以将异常车辆的车辆性能一致性结果305与一致性条件402进行比较；响应于比较结果403不满足预设条件，基于异常车辆的测试路段404、初始测试方案405以及车辆性能一致性结果305，为异常车辆的测试路段404确定补充测试方案406。其中，一致性条件402可以至少包括车辆性能一致性结果305小于一致性阈值异常。车辆的车辆性能一致性结果305、一致性条件402的更多细节，参看上述图2-图3及其相关描述。

在一些实施例中，处理器可以通过比较异常车辆的车辆性能一致性与一致性阈值，确定比较结果403，并在比较结果403不满足预设条件时，确定车辆的测试数据表现不好，处理器可以基于异常车辆的测试子路段，确定补充测试方案406，以补充相对应的测试数据。车辆性能一致性与一致性阈值的更多细节，可以参看上述图2及其相关描述。

在一些实施例中，不同异常车辆的一致性条件402可以不同，一致性条件402可以相关于异常车辆的关联测试结果407。

一致性阈值可以相关于异常车辆本身的车辆性能。比如某一车辆本身的车辆性能会略好于多个待测试车辆的整体性能，使得该车辆的测试数据中的部分测试参数会略高于全局测试结果中的数据，从而该车辆容易被误判定为异常车辆。

关联测试结果407可以为异常车辆在其他相关测试中的结果，其可以从另一个测试的角度反映异常车辆本身的车辆性能。例如，路径规划测试的关联测试可以包括但不限于：自动驾驶车辆的性能测试、安全可靠能力测试、联网性能和数据安全测试等。

在一些实施例中，关联测试结果407可以反映异常车辆本身的车辆性能，从而可以影响异常车辆的一致性条件402的设置。例如，关联测试结果407越好，说明异常车辆本身的车辆性能越好，从而可以设置约束越小的一致性条件402，以避免异常车辆的测试数据被误判定为需要进行补充的数据。

在一些实施例中，处理器可以通过多种方式获取到关联测试结果407。例如，处理器可以通过通讯网络与待测试车辆上设置的传感器建立通信，从而控制传感器获取关联测试结果407。

在一些实施例中，处理器可以基于车辆本身的性能设定一致性条件402，从而可以更加准确地确定是否需要进行补充测试，提高自动驾驶车辆测试方法的准确性。

在一些实施例中，一致性条件402还可以相关于异常车辆执行初始测试方案405时的天气恶劣程度408，天气恶劣程度408越高，异常车辆的一致性条件402越大。

由于天气情况可能会影响采集传感器的灵敏度，使得采集到的异常车辆的测试数据不够准确。如天气过于潮湿会导致传感器中部分硬件设备的灵敏度和性能下降，导致异常车辆的测试数据的准确度下降，处理器可以适当放宽或增大判定异常车辆的一致性条件402，以避免异常车辆的误判。其中，放宽或增大一致性条件402可以包括增大一致性阈值。

在一些实施例中，处理器可以通过多种方式获取天气恶劣程度408，如通过网络、人工输入等方式获取当前或未来时间段的天气恶劣程度408。

在本说明书实施例中，通过天气恶劣程度408调整一致性条件402，可以使得确定的异常车辆更加准确，从而提高自动驾驶车辆测试的准确性。

在一些实施例中，处理器可以根据异常车辆的初始测试方案405，确定其对应的测试路段404，测试路段、初始测试方案405以及车辆性能一致性结果305的更多细节，可以参看上述图2-图3及其相关描述。

在一些实施例中，处理器可以通过多种方式确定补充测试方案406。例如，处理器可以基于异常车辆的测试路段404、初始测试方案405以及车辆性能一致性结果305，构建异常车辆特征向量，在方案向量数据库中检索，检索到与异常车辆特征向量相似的参考异常车辆特征向量，将该参考异常车辆特征向量对应的参考补充测试方案406确定为补充测试方案406。其中，需求向量数据库中可以存储有多个参考异常车辆特征向量及对应的多个参考补充测试方案406，需求向量数据库可以基于历史补充测试数据构建，也可以由人工标注确定的。

在一些实施例中，处理器可以确定将所有异常车辆对应的测试路段404，作为补充测试车辆的测试路段，以获取对应的测试数据。在一些实施例中，处理器可以将异常车辆对应的初始测试方案405中的测试项，作为补充测试方案406中的测试项，以获取同一测试的测试数据。也就是说，补充测试车辆的测试路段可以与异常车辆的测试路段404相同，补充测试车辆的补充测试方案406的测试项，可以与异常车辆对应的测试项相同。

在一些实施例中，处理器还可以基于异常车辆的车辆性能一致性结果305，确定执行补充测试方案406的补充测试车辆的数量。

在一些实施例中，车辆性能一致性结果305与补充测试车辆的数量存在对应关系。异常车辆的一致性越小，其对应的测试数据越不可靠，也就需要更多的补充测试车辆来执行该车辆的测试项，故而需要增加补充测试车辆的数量，且车辆的一致性越小，增加的车辆可以越多。

相对应的，在一些实施例中，处理器可以基于预设的异常车辆的车辆性能的一致性与充测试车辆的数量之间的关系，确定补充测试方案中每个测试路段的调用车辆数量。

在本说明书实施例中，基于车辆性能一致性结果确定补充测试车辆的数量，可以使得后续补充数据的采集更加充分，从而提高车辆测试的准确性。

在本说明书实施例中，基于异常车辆的测试路段、初始测试方案以及车辆性能一致性结果，可以准确地确定补充测试方案，以补充表现不好的测试数据。

本说明书的一个或多个实施例中还提供一种自动驾驶车辆测试装置，包括至少一个处理器以及至少一个存储器；至少一个存储器用于存储计算机指令；至少一个处理器用于执行所述计算机指令中的至少部分指令以实如上任一实施例所述的自动驾驶车辆测试方法。

处理器可以指自动驾驶车辆测试装置的运算和控制核心，是信息处理、程序运行的最终执行单元。例如，中央处理器、图形处理器以及现场可编程逻辑门阵列等。在一些实施例中，处理器可以执行上述图2-图4所示的自动驾驶车辆测试方法，方法的更多细节可以参看上述相关描述。

在一些实施例中，通讯网络可以用于在处理器和自动驾驶车辆（如，待测试车辆、补充测试车辆等）之间传输数据。例如，处理器可以通过通讯网络向待测试车辆发出执行初始测试方案的指令。待测试车辆可以通过通讯网络向处理器反馈测试方案对应的测试数据。

本说明书的一个或多个实施例中还提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如上任一实施例所述的自动驾驶车辆测试方法。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20%的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件（当前或之后附加于本说明书中的）也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。

Claims (10)

1.一种自动驾驶车辆测试方法，其特征在于，所述方法由处理器执行，包括：

向待测试车辆发出执行初始测试方案的指令；

通过通讯网络获取所述待测试车辆反馈的所述初始测试方案对应的测试数据；

基于所述测试数据确定分析结果；

响应于所述分析结果不满足预设条件，基于所述分析结果确定补充测试方案；

生成并向补充测试车辆发送控制指令，以控制所述补充测试车辆执行所述补充测试方案。

2.根据权利要求1所述的方法，其特征在于，

所述分析结果包括车辆性能一致性结果，所述车辆性能一致性结果体现一辆所述待测试车辆对应的所述测试数据与全局测试数据的一致性程度；

所述预设条件包括一致性条件。

3.根据权利要求2所述的方法，其特征在于，所述待测试车辆包括多辆，所述测试数据包括多组，每组所述测试数据对应一辆所述待测试车辆；所述方法还包括：

基于多组所述测试数据，确定全局测试结果；

基于所述全局测试结果，确定多辆所述待测试车辆中的异常车辆；

基于所述异常车辆的异常程度，确定所述异常车辆的所述车辆性能一致性结果。

4.根据权利要求3所述的方法，其特征在于，所述基于所述分析结果确定补充测试方案包括：

将所述异常车辆的所述车辆性能一致性结果与所述一致性条件进行比较；

响应于比较结果不满足所述预设条件，基于所述异常车辆的测试路段、所述初始测试方案以及所述车辆性能一致性结果，为所述异常车辆的所述测试路段确定所述补充测试方案。

5.根据权利要求4所述的方法，其特征在于，所述响应于比较结果不满足所述预设条件，基于所述异常车辆的测试路段、所述初始测试方案以及所述车辆性能一致性结果，为所述异常车辆的所述测试路段确定所述补充测试方案包括：

基于所述异常车辆的所述车辆性能一致性结果，确定执行所述补充测试方案的所述补充测试车辆的数量。

6.根据权利要求1所述的方法，其特征在于，所述补充测试车辆包括当前时段的空闲车辆和/或未来时段的空闲车辆。

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

执行完成所述初始测试方案后，指示所述待测试车辆将车辆状态恢复至测试前状态；和/或

执行完成所述补充测试方案后，指示所述补充测试车辆将车辆状态恢复至测试前状态。

8.一种自动驾驶车辆测试系统，其特征在于，所述系统包括：

初始测试模块，被配置为向待测试车辆发出执行初始测试方案的指令；

数据获取模块，被配置为通过通讯网络获取所述待测试车辆反馈的所述初始测试方案对应的测试数据；

数据分析模块，被配置为基于所述测试数据确定分析结果；

方案生成模块，被配置为响应于所述分析结果不满足预设条件，基于所述分析结果确定补充测试方案；

补充测试模块，被配置为生成并向补充测试车辆发送控制指令，以控制所述补充测试车辆执行所述补充测试方案。

9.一种自动驾驶车辆测试装置，其特征在于，所述装置包括至少一个存储器和至少一个处理器，所述至少一个存储器用于存储计算机指令，所述至少一个处理器执行所述计算机指令或部分指令，以实现权利要求1-7中任一项所述的自动驾驶车辆测试方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储计算机指令，当计算机读取所述计算机指令时，所述计算机执行如权利要求1-7中任一项所述的自动驾驶车辆测试方法。