CN115481036A - 一种驾驶模型的测试方法、装置、设备及介质 - Google Patents

Abstract

本发明提供一种驾驶模型的测试方法、装置、设备及介质，包括获取预设的驾驶模型的测试场景；获取所述测试场景中的多个变量信息，以创建变量标签集；对所述变量标签集进行多次赋值处理，以生成所述测试场景的多个变量参数集；基于多个所述变量参数集，依次更新并测试所述测试场景；获取所述测试场景的测试数据，生成测试报告。本发明简化了驾驶模型的测试过程，提高了测试效率。

Description

一种驾驶模型的测试方法、装置、设备及介质

技术领域

本申请涉及驾驶系统技术领域，具体涉及一种驾驶模型的测试方法、装置、设备及介质。

背景技术

在汽车驾驶系统的开发过程中，厂商会采用基于算法模型的开发模式，通过各种测试用例对驾驶模型的功能进行测试。驾驶模型可以代表实际驾驶系统的属性，通过测试用例验证驾驶模型的功能性，可以简化驾驶系统的开发过程，降低开发成本。

目前，在测试驾驶模型时，需要在不同测试场景下测试模型，测试过程复杂，开发人员工作量大，整体测试效率低。

发明内容

鉴于以上所述现有技术的缺点，本发明提供一种驾驶模型的测试方法、装置、设备及介质，以解决测试过程复杂，整体测试效率低的技术问题。

本发明提供的一种驾驶模型的测试方法，所述方法包括：

获取预设的驾驶模型的测试场景；

获取所述测试场景中的多个变量信息，以创建变量标签集；

对所述变量标签集进行多次赋值处理，以生成所述测试场景的多个变量参数集；

基于多个所述变量参数集，依次更新并测试所述测试场景；

获取所述测试场景的测试数据，生成测试报告。

于本发明的一实施例中，所述获取所述测试场景中的多个变量信息，以创建变量标签集的步骤包括：

对所述测试场景进行识别处理，以生成多个变量信息；

基于多个所述变量信息，生成对应的多个变量标签；

汇总多个所述变量标签，以创建变量标签集。

于本发明的一实施例中，所述对所述变量标签集进行多次赋值处理，以创建所述测试场景的多个变量参数集的步骤包括：

对所述变量标签集中每个变量标签进行赋值处理，生成每个所述变量标签的变量参数；

汇总每个所述变量标签的变量参数，生成所述测试场景的变量参数集；

重复对所述变量标签集进行赋值处理，以生成所述测试场景的多个变量参数集。

于本发明的一实施例中，所述基于多个所述变量参数集，依次更新并测试所述测试场景的步骤包括：

基于预设的排序规则，对多个所述变量参数集进行排序处理；

基于排序后的多个所述变量参数集，依次更新并测试所述测试场景；

于本发明的一实施例中，所述基于排序后的多个所述变量参数集，依次更新并测试所述测试场景的步骤包括：

基于排序后的多个所述变量参数集，依次更新所述测试场景的参数数据，并测试所述测试场景。

于本发明的一实施例中，所述获取所述测试场景的测试数据，生成测试报告的步骤包括：

获取所述测试场景的多个测试数据；

汇总多个所述测试数据，生成测试报告。

于本发明的一实施例中，所述汇总多个所述测试数据，生成测试报告的步骤包括：

基于所述测试场景的参数数据，定义每个所述测试数据的标识字符；

汇总所述测试数据与所述标识字符，生成测试报告。

本发明还提供的一种电子设备，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述的驾驶模型的测试方法。

本发明还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行上述的驾驶模型的测试方法。

本发明的有益效果：本发明中，针对驾驶模型的整体测试流程可自动化执行，自动更新测试场景并生成测试结果，降低人力成本，简化测试过程，提高测试效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本申请的一示例性实施例示出的驾驶模型的测试方法的实施环境示意图；

图2是本申请的一示例性实施例示出的驾驶模型的测试方法的流程图；

图3是图2所示实施例中的步骤S220在一示例性的实施例中的流程图；

图4是图2所示实施例中的步骤S230在一示例性的实施例中的流程图；

图5是图2所示实施例中的步骤S240在一示例性的实施例中的流程图；

图6是图2所示实施例中的步骤S250在一示例性的实施例中的流程图；

图7是图6所示实施例中的步骤S620在一示例性的实施例中的流程图；

图8是本申请的一示例性实施例示出的驾驶模型的测试装置的框图；

图9示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在下文描述中，探讨了大量细节，以提供对本发明实施例的更透彻的解释，然而，对本领域技术人员来说，可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的，在其他实施例中，以方框图的形式而不是以细节的形式来示出公知的结构和设备，以避免使本发明的实施例难以理解。

首先需要说明的是，随着智能网联汽车行业的发展，汽车驾驶系统也在快速更新。各种辅助驾驶系统为驾驶者提供了方便，降低了安全隐患。例如，辅助驾驶系统可以包括倒车辅助系统，基于倒车辅助系统的图像展示或语音提示，驾驶者可以知晓自车与障碍物的相对位置。在汽车驾驶系统的开发过程中，为了提高开发效率，厂商大多采用基于算法模型的开发模式，通过各种测试用例对驾驶模型的功能进行测试。驾驶模型可以代表实际驾驶系统的属性，通过测试验证驾驶模型的功能性，即可检验驾驶系统的功能性，从而简化驾驶系统的开发过程，降低开发成本。

值得提及的是，在测试驾驶模型时，需要在不同测试场景下测试模型。因此，测试过程复杂，开发人员工作量大，整体测试效率低。为此，本申请提出一种驾驶模型的测试方法，图1是本申请的一示例性实施例示出的驾驶模型的测试方法的实施环境示意图。如图1所示，服务端110可通过网络与开发人员的用户端120进行通信，开发人员可于用户端120预先设定驾驶模型的测试场景。服务端110可以通过用户端120获取预设的驾驶模型的测试场景。通过测试场景信息，可获取测试场景中的变量信息。变量信息可以指后续更新测试场景时需要变换的变量。变量信息可以包括多个，可以对每个变量信息分别创建变量标签，以标识变量信息。汇总多个变量标签，可生成变量标签集。由于需要在不同测试场景下测试模型，可以提取测试场景中需要更新的变量，在后续更新测试场景时，只需更新测试场景中的变量信息，即可实现测试场景的自动更新。为了实现测试场景的自动更新，可基于预先编写的脚本，自动对多个所述变量标签进行多次赋值处理，以生成所述测试场景的多个变量参数集。在场景测试时，基于多个所述变量参数集，可依次更新并测试所述测试场景。最后通过获取所述测试场景的测试数据，可自动生成测试报告。本发明可以简化测试过程，降低人力成本，并提高测试效率。其中，用户端120可以但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。服务端110可以用独立的服务器或者是多个服务器组成的服务器集群来实现。下面通过具体的实施例对本发明进行详细的描述。

请参阅图2所示，图2为本发明实施例提供的驾驶模型的测试方法的一个流程示意图，包括如下步骤，

步骤S210、获取预设的驾驶模型的测试场景。

步骤S220、获取所述测试场景中的多个变量信息，以创建变量标签集。

步骤S230、对所述变量标签集进行多次赋值处理，以生成所述测试场景的多个变量参数集。

步骤S240、基于多个所述变量参数集，依次更新并测试所述测试场景。

步骤S250、获取所述测试场景的测试数据，生成测试报告。

对于步骤S210、需要说明的是，为了进行自动化测试，开发人员可预先在其用户端120上定义驾驶模型的测试场景。例如，驾驶模型可设定为针对自动紧急制动系统(AEB)的测试模型，测试场景可设定为前方静止车辆追尾测试场景(CCRs)。需要进一步解释的是，在车辆行驶过程中，自动紧急制动系统(AEB)可通过车载传感器检测道路环境，当自动紧急制动系统检测到前方存在碰撞危险时，可对驾驶员提出预警，若驾驶员没有采取相应措施，自动紧急制动系统可对车辆进行自动制动。对于此自动紧急制动系统的测试是为了测试其预警功能与制动功能是否正常。在测试前，开发人员可预先搭建前方静止车辆追尾测试场景(CCRs)，当后续运行测试场景时，即可检测驾驶模型的预警及制动情况。

值得提及的是，此测试场景在进行搭建时，开发人员可建立至少包括车道、路径、自车模型及前车模型的仿真场景，并可设置自车模型及前车模型的初始位置、初始速度等。当后续运行测试场景时，即可检测驾驶模型的预警及制动情况。

可进一步说明的是，驾驶模型可不加限定，可以设定为针对自动紧急制动系统(AEB)的测试模型，也可设定为针对车道偏离报警(LDW)的测试模型，或者设定为车道保持辅助(LKA)的测试模型，或其他测试模型。测试场景也可不加限定，可以设定为前方静止车辆追尾测试场景(CCRs)，也可设定为前方匀速行驶车辆追尾测试场景(CCRb)，或者设定为前方匀速行驶车辆追尾测试场景(CCRm)，或其他测试场景。

对于步骤S220，需要说明的是，在进行某个测试场景的测试时，可进行测试场景的多个状态的测试，以实现全面的测试。例如，某个测试场景下，可以首先进行自车模型时速为20公里每小时的测试，再进行自车模型时速为30公里每小时的测试，最后进行自车模型时速为40公里每小时的测试。在此测试场景下，测试场景中的变量信息为自车车速。由上述示例可知，为实现后续测试时自动切换测试场景的测试状态，可对测试场景中的变量的参数值进行多次更新，每更新一次测试场景的参数值，可实现测试场景的状态变换。因此，在进行测试前，可先获取测试场景中需要变换的变量信息，以便后续对变量信息的参数值进行变换，实现测试场景的更新。

在获取测试场景中的变量信息时，变量信息可以为自车车速，自车运动轨迹，前车运动轨迹或其他变量。

值得提及的是，为了标识测试场景的变量信息，可以对每个变量信息创建变量标签。例如，当变量信息为自车车速时，可创建变量标签为V_Ego。当变量信息为自车运动轨迹时，可创建变量标签为rajectories_Ego。当变量信息为前车运动轨迹时，可创建变量标签为rajectories_Obj。汇总测试场景中的多个变量标签，可生成标量标签集。

对于步骤S230，需要说明的是，为了实现测试场景的状态变换，可预先对标量标签集中的多个变量标签进行多次赋值，每次赋值后的多个变量标签可以为后续测试场景的每个更新状态提供参数值。

例如，某个测试场景的变量信息为自车车速，自车运动轨迹及前车运动轨迹，自车运动轨迹的变量标签rajectories_Ego可赋值为Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj可赋值为Obj_CCRs，自车车速的变量标签V_Ego可赋值为20。上述三种变量标签以及标签值可形成一个变量参数集，为后续测试场景的一个状态提供参数值。可对变量标签集进行多次赋值，形成多个变量参数集。后续基于每个变量参数集，更新一次测试场景的参数值，可实现测试场景的状态变换。

对于步骤S240，需要说明的是，在开始测试场景的测试时，首先基于多个变量参数集中的某个变量参数集，对测试场景中的变量信息的参数值进行更新，并测试更新后的测试场景。然后基于第二个变量参数集，对测试场景中的变量信息的参数值进行更新，并测试更新后的测试场景。接着依次基于剩余的每个变量参数集，对测试场景中的变量信息的参数值进行更新，并测试更新后的测试场景，即可完成测试。

具体的来说，基于某个变量参数集，对测试场景中的变量信息的参数值进行更新时，是将测试场景中每个变量信息的参数值更新为变量参数集中每个变量标签的值。例如，测试场景中的变量信息如自车车速V_Ego，测试时，V_Ego可表示为变量参数集中相应的变量标签V_Ego的值如20。

值得提及的是，在测试场景的每次更新测试后，可保存每次的测试数据。测试数据可以包括测试过程中的具体数据及测试结果等。进一步的，可基于测试过程中的具体数据例如自车模型与前车模型的距离、自车速度及测试时间等，创建结果图，以供开发人员分析测试情况。例如，以自车模型与前车模型的距离为纵坐标，以测试时间为横坐标，可创建自车模型与前车模型的距离，以及测试时间之间的相关结果图。

对于步骤S250，需要说明的是，测试场景可进行多次更新实现多次测试，基于每次的测试数据，可创建每次测试的结果图。为了便于开发人员分析测试情况，可新建一个测试报告，将多次测试的结果图汇总并保存测试报告中，通过测试报告即可分析多次测试的结果。

值得提及的是，可将每次测试中测试场景的参数值作为标识，以定义每次测试生成的结果图。通过标识可知晓每个结果图对应的测试情况。例如，某个测试场景下某次测试的变量参数值为自车车速V_Ego＝20，前车运动轨迹rajectories_Obj为Obj_CCRs，则此次测试的结果图的场景标识可定义为CCRs_20kph。通过此标识，后续开发人员在数据库的多个结果图中查找某个结果图时，可输入相应的标识字符，即可查询到相应的结果图。

在一示例性的实施例中，如图3所示，获取所述测试场景中的多个变量信息，以创建变量标签集的过程可包括，

步骤S310、对所述测试场景进行识别处理，以生成多个变量信息。

步骤S320、基于多个所述变量信息，生成对应的多个变量标签。

步骤S330、汇总多个所述变量标签，以创建变量标签集。

需要说明的是，在某个测试场景在进行搭建时，开发人员可预先建立至少包括车道、路径、自车模型及前车模型的仿真场景，并可设置自车模型及前车模型的初始位置、自车速度、自车运动轨迹等。在进行测试时，服务端110可自动识别测试场景中需要变换的变量要素，例如自车速度、自车运动轨迹等。通过识别出的多个变量要素，可生成多个变量信息，每个变量要素即为一个变量信息。

值得提及的是，对每个变量信息创建变量标签，可标识测试场景的变量信息。例如，当变量信息为自车车速时，可创建变量标签为V_Ego。当变量信息为自车运动轨迹时，可创建变量标签为rajectories_Ego。当变量信息为前车运动轨迹时，可创建变量标签为rajectories_Obj。汇总多个变量信息的变量标签，可生成变量标签集。

进一步的，通过为变量标签集中的每个变量标签进行赋值，可便于后续场景更新时调用变量标签对应的参数值，实现场景的自动更新。

在一示例性的实施例中，如图4所示，对所述变量标签集进行多次赋值处理，以创建所述测试场景的多个变量参数集的过程包括，

步骤S410、对所述变量标签集中每个变量标签进行赋值处理，生成每个所述变量标签的变量参数。

步骤S420、汇总每个所述变量标签的变量参数，生成所述测试场景的变量参数集。

步骤S430、重复对所述变量标签集进行赋值处理，以生成所述测试场景的多个变量参数集。

需要说明的是，为了实现后续测试时自动更新测试场景，可预先编写脚本对变量标签集中的多个变量标签进行多次赋值，每次赋值后的多个变量标签可以为后续测试场景的每个更新状态提供参数值。

例如，某个测试场景的变量信息为自车车速，自车运动轨迹及前车运动轨迹，自车运动轨迹的变量标签rajectories_Ego可赋值为Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj可赋值为Obj_CCRs，自车车速的变量标签V_Ego可赋值为20。上述三种变量标签及其标签值可形成一个变量参数集，为后续测试场景的一个状态提供参数值。又例如，自车运动轨迹的变量标签rajectories_Ego可赋值为Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj可赋值为Obj_CCRs，自车车速的变量标签V_Ego可赋值为30，此三种变量标签及其标签值可形成另一个变量参数集，为后续测试场景的另一个状态提供参数值。通过对变量标签集中多个变量标签进行多次赋值，可形成多个变量参数集。

在测试自车车速为20公里每小时的测试场景时，可对应调用自车车速为20公里每小时的变量参数集，即自车运动轨迹的变量标签rajectories_Ego＝Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj＝Obj_CCRs，自车车速的变量标签V_Ego＝20。又例如，后续在测试自车车速为30公里每小时的测试场景时，可对应调用自车车速为30公里每小时的变量参数集，即自车运动轨迹的变量标签rajectories_Ego＝Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj＝Obj_CCRs，自车车速的变量标签V_Ego＝30。

在一示例性的实施例中，如图5所示，基于多个所述变量参数集，依次更新并测试所述测试场景的过程包括，

步骤S510、基于预设的排序规则，对多个所述变量参数集进行排序处理。

步骤S520、基于排序后的多个所述变量参数集，依次更新并测试所述测试场景。

需要说明的是，在基于多个变量参数集对测试场景进行多次更新测试时，可预先设定排序顺序，以进行依次更新。

具体的来说，预设的排序规则可以是基于变量参数集中的自车车速进行排序，自车车速越高，排序的优先级越高。例如，变量参数集可设定为三个，分别为，第一变量参数集：自车运动轨迹的变量标签rajectories_Ego＝Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj＝Obj_CCRs，自车车速的变量标签V_Ego＝20，以及第二变量参数集：自车运动轨迹的变量标签rajectories_Ego＝Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj＝Obj_CCRs，自车车速的变量标签V_Ego＝30，以及第三变量参数集：自车运动轨迹的变量标签rajectories_Ego＝Ego_Centerline，前车运动轨迹的变量标签rajectories_Obj＝Obj_CCRs，自车车速的变量标签V_Ego＝40。由于第一变量参数集的自车车速小于第二变量参数集，第二变量参数集的自车车速小于第三变量参数集，则第三变量参数集的优先级大于第二变量参数集，第二变量参数集的优先级大于第一变量参数集。基于上述排序规则，当进行多次更新测试时，可首先调用第三变量参数集对测试场景进行更新，更新测试场景的参数数据后，然后进行测试。再调用第二变量参数集对测试场景进行更新，更新测试场景的参数数据后，然后进行测试，最后可调用第一变量参数集对测试场景进行更新，更新测试场景的参数数据后，然后进行测试。

在一示例性的实施例中，如图6所示，基于多个所述变量参数集，依次更新并测试所述测试场景的过程包括，

步骤S610、获取所述测试场景的多个测试数据。

步骤S620、汇总多个所述测试数据，生成测试报告。

需要说明的是，测试场景可进行多次更新实现多次测试，生成多个测试数据。为了便于分析测试结果，可创建测试报告，将多次测试的测试数据汇总并保存测试报告中，通过测试报告即可分析多次测试的结果。

值得提及的是，服务端110在生成测试报告时，可自动获取当前系统时间，以当前系统时间及测试场景信息对测试报告进行命名时，可提高测试报告的后续查询效率。具体的来说，某个测试报告可命名为CCRs_TestReport_20220916153409。每个测试报告可对应不同的时间点，需要查询某个时间点生成的测试报告时，可在数据库中查询时间点编号，可快速获取相应的测试报告。

需要进一步说明的是，可将时间信息精确至秒、毫秒等，降低每个报告的后缀时间编码的重复率。以时间信息加入测试报告的命名时，由于时间不断推后，增加了多个测试报告的有序性。

在一示例性的实施例中，如图7所示，汇总多个所述测试数据，生成测试报告的过程包括，

步骤S710、基于所述测试场景的参数数据，定义每个所述测试数据的标识字符。

步骤S720、汇总所述测试数据与所述标识字符，生成测试报告。

需要说明的是，通过测试数据可以生成测试结果图，具体的，可基于测试过程中的具体数据例如自车模型与前车模型的距离、自车速度及测试时间等，创建结果图，以供开发人员分析测试情况。例如，以自车模型与前车模型的距离为纵坐标，以测试时间为横坐标，可创建自车模型与前车模型的距离，以及测试时间之间的相关结果图。

可将每次测试中测试场景的参数值作为标识字符，以定义每次测试生成的结果图。通过标识字符可知晓每个结果图对应的测试情况。例如，某个测试场景下某次测试的变量参数值为自车车速V_Ego＝20，前车运动轨迹rajectories_Obj为Obj_CCRs，则此次测试的结果图的场景标识可定义为CCRs_20。每个结果图及其标识字符形成一对结果数据，汇总多对结果数据，可生成测试报告。

可见，在上述方案中，整体测试流程可自动化执行，自动更新测试场景并生成测试结果，降低人力成本，简化测试过程，提高测试效率。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

在一实施例中，提供一种驾驶模型的测试装置，该驾驶模型的测试装置与上述实施例中驾驶模型的测试方法一一对应。如图8所示，该驾驶模型的测试装置包括获取模块801、创建模块802、处理模块803、测试模块804及生成模块805。

在一实施例中，创建模块802，具体用于，

对所述测试场景进行识别处理，以生成多个变量信息。

基于多个所述变量信息，创建对应的多个变量标签。

在一实施例中，处理模块803，具体用于，

对多个所述变量标签进行赋值处理，生成每个所述变量标签的变量参数。

汇总每个所述变量标签的变量参数，生成所述测试场景的变量参数集。

重复对多个所述变量标签进行赋值处理，以生成所述测试场景的多个变量参数集。

在一实施例中，测试模块804，具体用于，

基于预设的排序规则，对多个所述变量参数集进行排序处理。

基于排序后的多个所述变量参数集，依次更新并测试所述测试场景。

在一实施例中，生成模块805，具体用于，

获取所述测试场景的多个测试数据。

汇总多个所述测试数据，生成测试报告。

在一实施例中，生成模块805，还用于，

基于所述测试场景的参数数据，定义每个所述测试数据的标识字符。

汇总所述测试数据与所述标识字符，生成测试报告。

需要说明的是，上述实施例所提供的驾驶模型的测试装置与上述实施例所提供的驾驶模型的测试方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的路况刷新装置在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的驾驶模型的测试方法。

图9示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是，图9示出的电子设备的计算机系统仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统包括中央处理单元(Central Processing Unit，CPU)901，其可以根据存储在只读存储器(Read-Only Memory，ROM)902中的程序或者从储存部分908加载到随机访问存储器(Random Access Memory，RAM)903中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 903中，还存储有系统操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(Input/Output，I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分907；包括硬盘等的储存部分908；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入储存部分908。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机的处理器执行时，使计算机执行如前所述的驾驶模型的测试方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的驾驶模型的测试方法。

上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种驾驶模型的测试方法，其特征在于，所述方法包括：

获取预设的驾驶模型的测试场景；

获取所述测试场景中的多个变量信息，以创建变量标签集；

对所述变量标签集进行多次赋值处理，以生成所述测试场景的多个变量参数集；

基于多个所述变量参数集，依次更新并测试所述测试场景；

获取所述测试场景的测试数据，生成测试报告。

2.根据权利要求1所述的驾驶模型的测试方法，其特征在于，所述获取所述测试场景中的多个变量信息，以创建变量标签集的步骤包括：

对所述测试场景进行识别处理，以生成多个变量信息；

基于多个所述变量信息，生成对应的多个变量标签；

汇总多个所述变量标签，以创建变量标签集。

3.根据权利要求1所述的驾驶模型的测试方法，其特征在于，所述对所述变量标签集进行多次赋值处理，以创建所述测试场景的多个变量参数集的步骤包括：

对所述变量标签集中每个变量标签进行赋值处理，生成每个所述变量标签的变量参数；

汇总每个所述变量标签的变量参数，生成所述测试场景的变量参数集；

重复对所述变量标签集进行赋值处理，以生成所述测试场景的多个变量参数集。

4.根据权利要求1所述的驾驶模型的测试方法，其特征在于，所述基于多个所述变量参数集，依次更新并测试所述测试场景的步骤包括：

基于预设的排序规则，对多个所述变量参数集进行排序处理；

基于排序后的多个所述变量参数集，依次更新并测试所述测试场景。

5.根据权利要求4所述的驾驶模型的测试方法，其特征在于，所述基于排序后的多个所述变量参数集，依次更新并测试所述测试场景的步骤包括：

基于排序后的多个所述变量参数集，依次更新所述测试场景的参数数据，并测试所述测试场景。

6.根据权利要求1所述的驾驶模型的测试方法，其特征在于，所述获取所述测试场景的测试数据，生成测试报告的步骤包括：

获取所述测试场景的多个测试数据；

汇总多个所述测试数据，生成测试报告。

7.根据权利要求6所述的驾驶模型的测试方法，其特征在于，所述汇总多个所述测试数据，生成测试报告的步骤包括：

基于所述测试场景的参数数据，定义每个所述测试数据的标识字符；

汇总所述测试数据与所述标识字符，生成测试报告。

8.一种驾驶模型的测试装置，其特征在于，所述装置包括：

获取模块，用于获取预设的驾驶模型的测试场景；

创建模块，用于获取所述测试场景中的变量信息，以创建多个变量标签；

处理模块，用于对多个所述变量标签进行多次赋值处理，以生成所述测试场景的多个变量参数集；

测试模块，用于基于多个所述变量参数集，依次更新并测试所述测试场景；

生成模块，用于获取所述测试场景的测试数据，生成测试报告。

9.一种电子设备，其特征在于，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至7中任一项所述的驾驶模型的测试方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行权利要求1至7中任一项所述的驾驶模型的测试方法。

Images