自动驾驶软件的测试方法、装置、设备及介质

技术领域

本公开涉及自动驾驶技术领域，尤其涉及一种自动驾驶软件的测试方法、装置、设备及介质。

背景技术

随着车辆技术和电子技术的快速发展，自动驾驶车辆越来越多地出现在人们的生活中。自动驾驶车辆一般通过自动驾驶软件实现车辆的自动驾驶。

为了保证自动驾驶的安全性，在自动驾驶软件的研发和使用过程中，经常需要对自动驾驶软件进行测试。目前，对自动驾驶软件进行测试的方式主要有三种：仿真测试、封闭场地测试和开放环境测试。由于封闭场地测试和开放环境测试的测试代价较大，因此，自动驾驶软件主要通过仿真测试发现问题。

但是，车辆的自动驾驶环境十分复杂，测试人员所能设计的仿真场景有限，无法对自动驾驶软件进行全方位的测试。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种自动驾驶软件的测试方法、装置、设备及介质。

第一方面，本公开提供了一种自动驾驶软件的测试方法，该方法包括：

获取自动驾驶车辆行驶过程中的问题数据，所述问题数据包括所述车辆在紧急控制干预状态下的行驶数据；

根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例；

通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果。

在一些实施例中，所述行驶数据包括所述车辆的动力学数据、所述车辆所处环境的环境数据和所述车辆的驾驶人员的行为数据中的至少一种。

在一些实施例中，所述获取自动驾驶车辆行驶过程中的问题数据，包括：

接收所述自动驾驶车辆实时发送的所述问题数据。

在一些实施例中，所述问题数据包括所述自动驾驶车辆的符合问题数据筛选条件的历史行驶数据。

在一些实施例中，在所述获取自动驾驶车辆行驶过程中的问题数据之前，所述方法还包括：

接收所述自动驾驶车辆发送的历史行驶数据；

其中，所述获取自动驾驶车辆行驶过程中的问题数据，包括：

在所述历史行驶数据中，筛选出符合所述问题数据筛选条件的所述问题数据。

在一些实施例中，所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例，包括：

根据预设的参数组合策略和所述问题数据中的各个参数，生成参数组合；

为所述参数组合中的各个参数分别设置参数阈值，得到所述测试用例，所述参数阈值包括根据所述自动驾驶软件的性能确定的至少一个阈值。

在一些实施例中，在所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例之后，该方法还包括：

根据所述问题数据中的各个参数对应的场景要素标签，为所述问题数据打标，得到所述问题数据对应的目标场景要素标签；

根据所述测试用例和所述目标场景要素标签，构造测试场景；

其中，所述通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果，包括：

在所述测试场景下，通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果。

在一些实施例中，所述场景要素标签包括一级场景要素标签和二级场景要素标签，所述一级场景要素标签包括要素类型标签，所述二级场景要素标签包括要素属性标签。

在一些实施例中，在所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例之前，该方法还包括：

根据所述问题数据中的各个参数对应的场景要素标签，为所述问题数据打标，得到所述问题数据对应的目标场景要素标签；

确定具有所述目标场景要素标签的历史问题数据量；

其中，所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例，包括：

在所述历史问题数据量等于预定数量的情况下，根据所述问题数据，生成所述测试用例。

在一些实施例中，在所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例之前，该方法还包括：

将所述问题数据输入预设的数据识别模型，得到数据识别结果；

其中，所述根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例，包括：

在所述数据识别结果指示所述问题数据为非误判数据的情况下，根据所述问题数据，生成所述测试用例。

在一些实施例中，在所述将所述问题数据输入预设的数据识别模型，得到数据识别结果之后，所述方法还包括：

在所述数据识别结果指示所述问题数据为误判数据的情况下，删除所述问题数据。

在一些实施例中，在所述通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果之后，该方法还包括：

对所述测试结果进行诊断分析，得到诊断信息；

根据所述测试结果和所述诊断信息，生成测试报告。

第二方面，本公开提供了一种自动驾驶软件的测试装置，该装置包括：

第一获取模块，配置为获取自动驾驶车辆行驶过程中的问题数据，所述问题数据包括所述车辆在紧急控制干预状态下的行驶数据；

第一生成模块，配置为根据所述问题数据，生成用于测试所述自动驾驶软件的测试用例；

软件测试模块，配置为通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果。

在一些实施例中，所述行驶数据包括所述车辆的动力学数据、所述车辆所处环境的环境数据和所述车辆的驾驶人员的行为数据中的至少一种。

在一些实施例中，所述第一获取模块具体配置为：

接收所述自动驾驶车辆实时发送的所述问题数据。

在一些实施例中，所述问题数据包括所述自动驾驶车辆的符合问题数据筛选条件的历史行驶数据。

在一些实施例中，该装置还包括：

数据接收模块，配置为接收所述自动驾驶车辆发送的历史行驶数据；

其中，所述第一获取模块具体配置为：

在所述历史行驶数据中，筛选出符合所述问题数据筛选条件的所述问题数据。

在一些实施例中，所述第一生成模块具体配置为：

根据预设的参数组合策略和所述问题数据中的各个参数，生成参数组合；

为所述参数组合中的各个参数分别设置参数阈值，得到所述测试用例，所述参数阈值包括根据所述自动驾驶软件的性能确定的至少一个阈值。

在一些实施例中，该装置还包括：

数据打标模块，配置为根据所述问题数据中的各个参数对应的场景要素标签，为所述问题数据打标，得到所述问题数据对应的目标场景要素标签；

场景构造模块，配置为根据所述测试用例和所述目标场景要素标签，构造测试场景；

其中，所述软件测试模块具体配置为：

在所述测试场景下，通过所述测试用例，对所述自动驾驶软件进行测试，得到测试结果。

在一些实施例中，所述场景要素标签包括一级场景要素标签和二级场景要素标签，所述一级场景要素标签包括要素类型标签，所述二级场景要素标签包括要素属性标签。

在一些实施例中，该装置还包括：

数据打标模块，配置为根据所述问题数据中的各个参数对应的场景要素标签，为所述问题数据打标，得到所述问题数据对应的目标场景要素标签；

数据量确定模块，配置为确定具有所述目标场景要素标签的历史问题数据量；

其中，所述第一生成模块具体配置为：

在所述历史问题数据量等于预定数量的情况下，根据所述问题数据，生成所述测试用例。

在一些实施例中，该装置还包括：

数据识别模块，配置为将所述问题数据输入预设的数据识别模型，得到数据识别结果；

其中，所述第一生成模块具体配置为：

在所述数据识别结果指示所述问题数据为非误判数据的情况下，根据所述问题数据，生成所述测试用例。

在一些实施例中，该装置还包括：

数据删除模块，配置为在所述数据识别结果指示所述问题数据为误判数据的情况下，删除所述问题数据。

在一些实施例中，该装置还包括：

诊断分析模块，配置为对所述测试结果进行诊断分析，得到诊断信息；

第二生成模块，配置为根据所述测试结果和所述诊断信息，生成测试报告。

第三方面，本公开提供了一种自动驾驶软件的测试设备，包括：

处理器；

存储器，用于存储可执行指令；

其中，处理器用于从存储器中读取可执行指令，并执行可执行指令以实现第一方面所述的自动驾驶软件的测试方法。

第四方面，本公开提供了一种计算机可读存储介质，该存储介质存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现第一方面所述的自动驾驶软件的测试方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例的自动驾驶软件的测试方法、装置、设备及介质，能够将实车测试数据引入自动驾驶软件的仿真测试中，即利用车辆自动驾驶过程中的问题数据生成用于测试自动驾驶软件的测试用例，并通过测试用例对自动驾驶软件进行测试，能够实现对自动驾驶软件进行全方位的测试。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开实施例提供的一种自动驾驶软件的测试方法的流程示意图；

图2为本公开实施例提供的另一种自动驾驶软件的测试方法的流程示意图；

图3为本公开实施例提供的一种自动驾驶软件的测试装置的结构示意图；

图4为本公开实施例提供的一种自动驾驶软件的测试设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，但应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施例提供的自动驾驶软件的测试方法可以应用于对自动驾驶软件进行测试，具体地，可将实车测试数据引入仿真测试中，并可仿真测试后再次进行实车测试，并将实车测试数据再次引入仿真测试中，如此可形成自动驾驶软件的闭环测试，改善了由于测试人员所能设计的仿真场景有限而无法对自动驾驶软件进行全方位测试的问题；同时，可实现多种复杂的自动驾驶环境下的测试，减少实车测试问题发现的成本。

下文中结合图1-图4对本公开实施例提供的自动驾驶软件的测试方法、装置、设备以及介质进行示例性说明。

图1示出了一种自动驾驶软件的测试方法的流程示意图。如图1所示，该自动驾驶软件的测试方法包括如下步骤。

S110、获取自动驾驶车辆行驶过程中的问题数据。

其中，问题数据可以包括车辆在紧急控制干预状态下的行驶数据，即问题数据可以为实车测试数据。

其中，紧急控制干预(脱离或介入)状态也可理解为自动驾驶车辆脱离自动驾驶模式，并且进入人为控制状态。在人为控制状态下，自动驾驶车辆不再基于自动驾驶软件实现行驶，包括前行、转向、速度调控等车辆状态的控制，而是基于驾驶人员(例测试员)的操作实现车辆控制。

示例性地，自动驾驶车辆脱离自动驾驶模式的时机可包括：自动驾驶技术检测到故障而失效，或者测试员基于安全准则脱离自动驾驶模式，或者考虑车辆安全、车上人员安全、公众安全等需要脱离自动驾驶模式。例如，自动驾驶软件无法获取车辆的位姿信息、速度信息、加速度信息等车辆行驶相关状态信息时，转由测试员控制车辆行驶；或者，自动驾驶车辆行驶过程中，驾驶人员发现有人、动物或其他车辆突然穿插至车辆的前方，则可立即自主控制车辆减速或停车；或者在其他紧急控制干预状态下。

示例性地，自动驾驶车辆在自动驾驶状态下行驶时，若驾驶人员发现其他车辆突然穿插至该自动驾驶车辆的前方，则驾驶人员可立即控制车辆减速或停车。

其中，行驶数据为紧急控制干预对应的行驶时间段内的车辆状态相关的数据，可包括车辆外的环境数据、车辆驾驶人员的行为动作数据以及车辆的动力学数据等，下文中详述。

该步骤中，可实时获取自动驾驶车辆发送的问题数据；或者在自动驾驶车辆完成单次测试后，一次性获取该单次测试过程中的问题数据，或者已经上线的车辆在行驶一段时间之后，一次性获取该段时间的问题数据。数据获取方式可采用例如人工拷贝方式获取，或将问题数据打包后通过无线传输的方式获取，本公开实施例不限定。

S120、根据问题数据，生成用于测试自动驾驶软件的测试用例。

其中，测试用例(Test Case)是指对自动驾驶软件进行测试任务的描述，体现测试方案、方法、技术和策略；测试用例的内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。

该步骤中，可基于车辆在紧急控制干预状态下的行驶数据，生成用于测试自动驾驶软件的测试用例，从而将实车测试数据引入自动驾驶软件的测试过程中，有利于实现对自动驾驶场景的全方位还原。

S130、通过测试用例，对自动驾驶软件进行测试，得到测试结果。

其中，测试结果可理解为针对自动驾驶软件的测试进行的报错提醒或者软件没有问题的消息提醒。示例性地，报错提醒例如可包括自动驾驶软件中的某个控制模块(例如驱动模块)存在问题，或者代码段运行错误，或者软件参数缺失，或者软件参数范围设置不合理，以及可包括其他软件错误提醒结果，本公开实施例不限定。

该步骤中，利用前述步骤中基于问题数据生成的测试用例，对自动驾驶软件进行测试，生成包括上述软件错误提醒结果的自动驾驶软件的测试结果。

可选的，可利用前述步骤中基于问题数据生成的测试用例，对自动驾驶软件进行离线测试，实现对自动驾驶过程中的问题重现，且生成包括上述软件错误提醒结果的自动驾驶软件的测试结果。

其中，自动驾驶车辆可以为已经上线的车辆，离线测试可为通过独立于自动驾驶车辆以外的测试装置(即自动驾驶软件的测试装置，也简称为装置)对已经上线的或者未上线的自动驾驶软件进行测试。

本公开实施例提供的自动驾驶软件的测试方法中，能够将实车测试数据引入自动驾驶软件的仿真测试中，即利用车辆自动驾驶过程中的问题数据生成用于测试自动驾驶软件的测试用例，并通过测试用例对自动驾驶软件进行测试，如此能够实现对自动驾驶软件进行全方位的测试。

下面对行驶数据进行示例性说明。

在一些实施例中，行驶数据包括车辆的动力学数据、车辆所处环境的环境数据和车辆的驾驶人员的行为数据中的至少一种。

其中，车辆的动力学数据可包括垂直动力学数据、纵向动力学数据及横向动力学数据。例如，垂直动力学数据可包括车辆的减震器、弹簧、橡胶金属部件以及轮胎等垂向运动相关数据，纵向动力学数据可包括加速和制动相关的驱动力、阻力、速度、加速度等数据；横向动力学数据可包括车身侧倾转向角、转向伸缩性、侧偏刚度、回正力矩等数据。

其中，车辆所处环境的环境数据可包括路况、天气、周围的行人、动态目标以及静态目标等相关的数据。例如，路况相关数据可包括道路路基、路面、构造物及附属设施等的技术状况，以及道路中的车辆密集程度，即道路拥挤情况等数据。天气相关数据可包括气象类型、气温等影响车辆行驶或出行体验的数据；周围的行人相关数据包括行人与车辆的相对位置、行人的数量、行人的位姿、行进方向、行进速度等数据；动态目标相关数据可包括该车辆周围的车辆、行人以及其他相对地面位置发生变化的目标的相关数据，例如可包括该目标的行进方向、行进速度等数据；静态目标相关数据可包括该车辆周围的固定位置的建筑物、绿植、静止未动的车辆、人或其他相对于地面位置不变的目标的相关数据，例如可包括该目标的位置、其与该车辆之间的距离、姿态、外形轮廓等数据。本段中，动态目标或静态目标的界定以该车辆经过某目标前后预设距离内，目标的位置是否发生变化为准进行界定；或者以该车辆检测到某目标后，直至经过该目标后预设时间内，目标的位置是否发生变化为准进行界定；或者采用本领域技术人员可知的其他准则进行界定，本公开实施例对此不限定。

其中，驾驶人员的行为数据可包括驾驶人员与车辆进行交互的相关数据，例如可包括驾驶人员控制车辆转向、加速、减速、调节车辆的行驶平顺性、稳定性等行为相关的数据，例如可包括转动方向盘的角度、加速的快慢、制动的快慢、点击(长按或滑动)人机交互界面的对应按键等，本公开实施例对此不限定。

前述S110中的问题数据包括车辆在紧急控制干预状态下的上述行驶数据。

下面对问题数据的获取方式进行示例性说明。

在一些实施例中，在图1的基础上，S110可包括：

接收自动驾驶车辆实时发送的问题数据。

其中，自动驾驶车辆行驶过程中，判断车辆是否处于紧急控制干预状态下；若是，则将紧急控制干预时段内的行驶数据，即问题数据实时发送至测试装置；对应的，测试装置接收自动驾驶车辆实时发送的问题数据。

需要说明的是，紧急控制干预状态的判断需结合紧急控制干预的介入时刻以及其前后预设时段内的行驶数据实现，以避免误判，同时有利于构建完整的测试场景，后文中进行示例性说明。

示例性地，结合上文示出的场景，问题数据可包括驾驶人员自主控制车辆时刻的行驶数据、该时刻向前连续一段时间内的行驶数据和该时刻向后连续一段时间内的行驶数据，以获取完整的紧急控制干预场景。

在一些实施例中，问题数据包括自动驾驶车辆的符合问题数据筛选条件的历史行驶数据。

其中，历史行驶数据包括紧急控制干预状态下的行驶数据，也包括自动驾驶状态下的行驶数据。自动驾驶状态下的行驶数据为车辆在自动驾驶软件的控制下行驶时的行驶数据，自动驾驶状态下无驾驶人员的介入，此时车辆可正常行驶，满足行驶需求。

其中，问题数据筛选条件可以是测试人员根据测试需求预先配置的筛选条件，本公开实施例不限定。

通过设置问题数据筛选条件，可将紧急控制干预状态下的行驶数据与自动驾驶状态下的行驶数据区分开，如此可将问题数据从历史行驶数据中筛选出来，仅利用问题数据对自动驾驶软件进行测试，从而有利于减少自动驾驶软件测试过程中的测试数据量，提高测试效率。

示例性地，问题数据筛选条件可包括对车辆控制状态的判断。判断历史行驶数据是否为车辆在紧急控制干预状态下的行驶数据；若是，则历史行驶数据为问题数据，否则对应的历史行驶数据不是问题数据。

其中，问题数据筛选条件可包括对车辆控制状态的判断。例如，在车辆自动驾驶过程中，由于其他车辆穿插至当前车辆的前方而驾驶人员介入使车辆减速所对应的历史行驶数据是车辆在紧急控制干预状态下的行驶数据，其为问题数据。在这种情况下，示例性地，问题数据筛选条件可以包括：车辆在当前时刻的速度小于或等于预设速度阈值，且上一时刻的速度与当前时刻的速度之间的差值大于或等于预设速度差值。若检测到车辆的速度满足上述问题数据筛选条件，则可以确定其对应的历史行驶数据为问题数据。或者问题数据筛选条件可以包括：车辆的方向盘的转向角度大于或等于预设角度阈值，且上一时刻的角度与当前时刻的角度之间的差值大于或等于预设角度差值。若检测到车辆的方向盘的转向角度满足上述问题筛选条件，则可以确定其对应的历史行驶数据为问题数据。

其中，预设速度阈值、预设速度差值、预设角度阈值、预设角度差值等可以为根据用户需要设置的任意数值，在此不作限制。

在其他实施方式中，还可利用两个或多个参数的组合实现对车辆控制状态的判断，以实现对问题数据的筛选，在此不限定。

在一些实施例中，对历史行驶数据的筛选可在自动驾驶车辆内执行。即，自动驾驶车辆间隔一段时间，在该段时间内的历史行驶数据中，筛选出符合问题数据筛选条件的问题数据，并将筛选出来的问题数据发送至测试装置。

在一些实施例中，对历史行驶数据的筛选还可在测试装置中执行。即，在图1的基础上，在S110之前，该方法还包括：

接收自动驾驶车辆发送的历史行驶数据。

其中，自动驾驶车辆将历史行驶数据发送至测试装置，具体的，可实时发送，可间隔预设的时间段(例如30分钟、1小时或其他时间长度)发送，也可将单次测试得到的历史行驶数据一次性发送；发送方式可采用无线传输方式，或采用有线传输方式，或采用存储介质进行历史行驶数据的由车辆向测试装置的传输，本公开实施例不限定。

在此基础上，S110可包括：

在历史行驶数据中，筛选出符合问题数据筛选条件的问题数据。

具体地，判断历史行驶数据是否满足问题数据筛选条件；若是，则将其作为问题数据；否则不将作为问题数据。

由此实现基于历史行驶数据，通过问题数据筛选条件，确定满足问题数据筛选条件的问题数据。

下面示例性地说明测试用例的生成方式。

在一些实施例中，在图1的基础上，S120可包括如下步骤。

步骤一：根据预设的参数组合策略和问题数据中的各个参数，生成参数组合。

其中，问题数据中包括多种不同类别的数据，例如车辆动力学数据、环境数据和驾驶人员的行为数据等；每种类别的数据可由至少一种参数进行表征。例如，车辆动力学数据的参数可包括驱动力、阻力、速度、加速度、车身姿态、平顺性、稳定性等参数，环境数据可包括路况、天气、周围静态目标和动态目标的位置、速度等参数，驾驶人员的行为数据可包括转动方向盘、踩油门、踩刹车、电机人机交互界面中的设定按钮等动作相关的参数。

其中，预设的参数组合策略可为基于车辆由自动驾驶状态转换为紧急控制干预状态时的参数变化情况，经过对参数的统计而确定的不同参数的组合。

示例性地，针对驾驶人员人为转动方向盘、踩油门、踩刹车等导致的车辆由自动驾驶状态转换为紧急控制干预状态的场景，预设的参数组合策略可包括车辆动态相关参数，例如：方向盘旋转角度、速度、加速度、周围环境中的动态或静态目标的位置、速度、加速度以及其与车辆之间的距离等参数。

在其他实施方式中，当针对其他紧急控制干预状态的具体场景时，预设的参数组合策略还可为与具体场景对应的其他参数组合策略，本公开实施例不限定。

该步骤中，通过将问题数据中的各个参数，基于预设的参数组合策略进行组合，可得到参数组合。

步骤二：为参数组合中的各个参数分别设置参数阈值，得到测试用例。

其中，参数阈值包括根据自动驾驶软件的性能确定的至少一个阈值。例如，针对同一个参数，可仅包括参数上限值，或仅包括参数下限值，或同时包括参数上限值和参数下限值，或设置多个连续或不连续的参数区间。

其中，参数阈值的大小与紧急控制干预状态的具体场景相关，可根据经验值以及自动驾驶软件的性能设置。

结合上文，示例性地，以驾驶人员看到其他车辆穿插至本车车道的场景下，紧急介入(例如减速)，以避让该车辆的场景为例，参数组合中包括本车的实时位置、速度、其他车辆的实时方位以及速度。其中，对应于自动驾驶状态下的实时位置和速度，可设置多个速度区间，以满足不同的行进需求；对应于紧急控制干预状态下的实时位置和速度，可结合其他车辆的实时位置和速度，设置多个位置和速度区间，以满足避让需求，同时满足当前车辆的行进需求；对应于驾驶人员介入时的位置和速度，可统计两车的相对位置和相对速度得到对应于每个速度区间的速度上限值，作为人为介入的速度阈值，也称为速度调节阈值。

如此，基于参数组合中的各个参数及其参数阈值，可得到测试用例，以便后续实现对自动驾驶软件的测试。

示例性地，测试用例的格式可为数据文件格式，例如EXCEL表格、可扩展标记语言XML文本或其他格式的数据文件。

在上述实施方式的基础上，该方法还可包括基于问题数据，构建(或称构造)测试场景；并在构建的测试场景下，通过测试用例对自动驾驶软件进行测试，以实现对多种复杂应用场景的还原，以及在各不同应用场景下的软件测试，具体如下。

在一些实施例中，在图1的基础上，在S120之后，该方法还包括如下步骤。

步骤一：根据问题数据中的各个参数对应的场景要素标签，为问题数据打标，得到问题数据对应的目标场景要素标签。

其中，场景要素标签为区分不同的场景而设置的标签，各不同的场景可与紧急控制干预状态相关联，其关联关系可为一对一、一对多、多对一或多对多的关联对应关系。

示例性地，场景要素标签可包括环境要素标签、车辆动力学标签和用户行为标签，下文中详述。

该步骤中，为问题数据打标，也即为问题数据添加场景要素标签，可为关联于同一目标场景的问题数据添加对应的目标场景要素标签，从而实现对应于同一目标场景的问题数据的关联，以便实现后续步骤中的构造测试场景。

步骤二：根据测试用例和目标场景要素标签，构造测试场景。

具体地，将打标后的问题数据，依据测试用例构造测试场景。

其中，问题数据为实车测试数据，基于此构造的测试场景为对实车测试过程中的场景的还原，或至少部分还原。基于此，可实现对复杂的自动驾驶环境的还原，避免了由于测试人员设计仿真场景而导致的场景有限的问题，有利于实现对自动驾驶软件的全方位测试。

对应的，S130可包括：

在测试场景下，通过测试用例，对自动驾驶软件进行测试，得到测试结果。

其中，该步骤中的测试场景为前述步骤中基于实车测试数据而构建的测试场景，可还原自动驾驶过程中的实际场景；测试用例为前述步骤中基于实车测试数据而得到的测试用例，也可实现对自动驾驶过程中的场景和紧急控制干预状态的表征；在此基础上对自动驾驶软件进行测试，可将实车测试数据自动化引入仿真测试过程中，完善了测试场景，提高了测试效率。

在一些实施例中，场景要素标签包括一级场景要素标签和二级场景要素标签，一级场景要素标签包括要素类型标签，二级场景要素标签包括要素属性标签。

具体地，将场景要素标签进行不同层级的划分，以为数据进行不同层级的标识。

其中，一级场景要素标签(即首层标签)包括要素类型标签，用于区分问题数据的特征级别，例如可包括天气标签、道路类型标签、路况标签、动态目标标签一级静态目标标签等。

二级场景要素标签为基于首层标签对问题数据进行进一步的细化的标签，包括要素属性标签。例如，基于天气标签，其对应的要素属性标签可包括晴朗、雨天、阴天、雪天、霾等；基于道路类型标签，其对应的要素属性标签可包括高速道路、城市道路、农村道路等。

在一些实施例中，场景要素标签还可仅包括一级场景要素标签，以实现对问题数据的按照要素类别进行分类、统计等。

在其他实施方式中，场景要素标签还可包括更多级场景要素标签，用于对场景要素标签进行逐步细化，以实现对问题数据进行进一步细化分类，本公开实施例对此不限定。

在上述实施方式的基础上，可选地，该方法中，还可以非实时地基于问题数据生成测试用例。例如，测试设备可以将获得的问题数据保存，得到历史问题数据，当每次获得新的问题数据时，还可对问题数据所对应的场景中的历史问题数据进行统计，并在对应目标场景的历史问题数据量达到预设数量时，基于问题数据，生成测试用例，如此提高数据准确性，从而提升自动驾驶软件的测试准确性，具体如下：

在一些实施例中，在图1的基础上，在S120之前，该方法还包括如下步骤。

步骤一：根据问题数据中的各个参数对应的场景要素标签，为问题数据打标，得到问题数据对应的目标场景要素标签。

具体地，为问题数据添加场景要素标签，即可为关联于同一目标场景的问题数据添加对应的目标场景要素标签，从而便于实现对应于同一目标场景的问题数据的关联统计，以便实现后续步骤中的统计历史问题数据量。

步骤二：确定具有目标场景要素标签的历史问题数据量。

其中，通过将具有某一目标场景要素标签的问题数据进行累加统计，可确定该目标场景要素标签的历史问题数据量。

具体地，对历史问题数据量进行统计时，以分类最细的场景要素标签为准进行统计。例如，若场景要素标签仅包括一级场景要素标签，则以一级场景要素标签为准，对问题数据进行统计，将具有完全相同的一级场景要素标签的一个或多个问题数据进行累加，以实现对具有目标场景要素标签的问题数据进行统计。若场景要素标签包括一级场景要素标签和二级场景要素标签，则以二级场景要素标签为准，对问题数据进行统计，将具有完全相同的二级场景要素标签的一个或多个问题数据进行累加，以实现对具有目标场景要素标签的问题数据进行统计。

基于此，在一些示例中，S120可包括：

在历史问题数据量等于预定数量的情况下，根据问题数据，生成测试用例。

其中，预设数量可用于界定问题数据所对应的紧急控制干预状态是偶发性的，还是惯常发生的。具体地，当历史问题数据量小于预设数量时，其对应的紧急控制干预状态是偶发性的；当历史问题数据量等于(或大于)预设数量时，其对应的紧急控制干预状态是惯常发生的，此时需要基于该达到预设数量的历史问题数据对自动驾驶软件进行测试可调整。

基于此，判断历史问题数据量是否达到预设数量；若是，则可以根据问题数据生成测试用例；否则无需生成对应于该部分问题数据的测试用例。

在另一些示例中，S120还可包括：

在历史问题数据量等于预定数量的情况下，根据问题数据和历史问题数据，分别生成问题数据对的测试用例和历史问题数据对应的测试用例。

其中，生成历史问题数据对应的测试用例与生成问题数据对应的测试用例的方法相似，在此不做赘述。

如此，提高了问题数据的有效性，同时减少了软件测试过程中的数据处理量，提高了测试效率和测试准确性。

在上述实施方式的基础上，该方法中，还可对问题数据进行识别和筛选，以排除误判数据对测试结果的影响，具体如下。

在一些实施例中，在图1的基础上，在S120之前，该方法还包括：

将问题数据输入预设的数据识别模型，得到数据识别结果。

其中，数据识别模型可为分类模型，其用于鉴别问题数据为误判数据或非误判数据。

在该步骤之前还包括：生成数据识别模型。

具体地，可利用样本数据对分类模型进行训练。样本数据可包括正样本数据和负样本数据；其中，正样本数据可以为误判数据，其标记值可为1；负样本数据可以为非误判数据，其标记值可为0。将每个样本数据分别输入到分类模型之后，分类模型可以输出每个样本数据的预测值，进而根据每个样本数据的标记值和预测值，利用反向传播法调整分类模型的模型参数，直至分类模型的准确率达到预设的准确率阈值，得到训练后的数据识别模型。

具体地，样本数据也称为训练数据，其可采用已经上线的车辆在前期行驶过程中得到的历史行驶数据；当训练数据的量足够多的情况下，数据识别模型的识别结果的准确率会提高。

进一步地，将问题数据输入预设的数据识别模型之后，可以得到问题数据对应的预测值，可以将问题数据对应的预测值与预定阈值(即预设的准确率阈值)进行比较，在误判数据为正样本数据的情况下，当问题数据对应的预测值大于或等于预定阈值时，可以确定数据识别结果为问题数据是误判数据，否则，可以确定数据识别结果为问题数据是非误判数据。

在一些实施例中，预定阈值可以为0.5，在其他实施例中，预定阈值还可以为根据需要设置的其它(0,1)之间的数值，在此不做限制。

该步骤中，当接收到新的问题数据时，可以利用预设的数据识别模型识别其是否为误判数据，如果是非误判数据，则后续步骤中根据问题数据，生成测试用例。

即，S120可具体包括：

在数据识别结果指示问题数据为非误判数据的情况下，根据问题数据，生成测试用例。

其中，非误判数据对应的场景可包括避免了事故发生、提高了行车体验或其他产生了积极效果的数据。

该步骤中，基于非误判数据生成测试用例，可提高测试用例的准确性，减少后续数据处理量，有利于提升测试效率和测试结果准确性。

在一些实施例中，在将问题数据输入预设的数据识别模型，得到数据识别结果之后，方法还包括：

在数据识别结果指示问题数据为误判数据的情况下，删除问题数据。

其中，误判数据可为针对车辆自动驾驶过程的实现或行程体验不具有积极效果的数据。其对应的场景可包括驾驶人员自主更改目的地或行进路线而导致的车辆状态变化的场景。

例如，当自动驾驶车辆按照既定的导航路线向一目的地行进时，驾驶人员想要更换至其他目的地，此时驾驶人员人为控制自动驾驶车辆改变其既定的导航路线；对应的，车辆由自动驾驶状态转换为紧急控制干预状态，但该状态的转换并非由于自动驾驶软件的自身问题导致的，而是驾驶人员基于自身想法主动控制导致的，对自动驾驶软件的测试以及改善不具有有益效果，因此其为误判数据。

该步骤中，通过将误判数据删除，有利于减少后续数据处理量，提高软件测试效率。

在一些实施例中，在图1的基础上，在S130之后，该方法还包括如下步骤。

步骤一：对测试结果进行诊断分析，得到诊断信息。

该步骤中，对前述步骤中得到的测试结果进行诊断分析，以确定导致上述测试结果的原因，即得到诊断信息。

示例性地，诊断信息可包括：自动驾驶软件中的逻辑问题、语句问题、参数问题；或者基于问题数据生成测试用例以及构建测试场景过程中的数据问题、步骤问题等，以实现对测试过程的全方位诊断。

示例性地，诊断分析可由测试人员执行，也可以基于预先训练得到的诊断分析模型执行。具体地，诊断分析模型可基于样本数据训练得到，该样本数据中，输入数据可为测试结果，输出数据可为测试结果的产生原因。

步骤二：根据测试结果和诊断信息，生成测试报告。

具体地，将测试结果与诊断信息关联，得到测试报告。其中，可基于预设的报告格式，生成向用户展示的测试报告。预设的报告格式可包括文本类型格式、文本中各部分内容的分布格式以及其他报告相关格式，本公开实施例不限定。

后续对自动驾驶软件进行调整，对软件测试过程进行优化。

图2示出了本公开实施例的另一种自动驾驶软件测试方法，包括如下步骤。

S200、开始。

具体地，启动自动驾驶软件的测试方法，例如可为运行该测试方法对应的程序。

S201、接收问题数据。

在一个示例中，车端可以基于问题数据筛选条件，在历史行驶数据中筛选出车辆在紧急控制干预状态下的行驶数据，即得到满足问题数据筛选条件的问题数据，并发送至测试装置。对应的，测试装置可以接收自动驾驶车辆发送的问题数据。

在另一个示例中，车端可以实时监测车辆是否处于紧急控制干预状态下，如果监测到车辆处于紧急控制干预状态下，则可以获取车辆在紧急控制干预状态下的行驶数据，即得到问题数据，并发送至测试装置。对应的，测试装置可以接收自动驾驶车辆发送的问题数据。

S202、判断问题数据是否为误判数据。

具体地，将问题数据输入预设的数据识别模型，得到数据识别结果，根据数据识别结果判断问题数据是否为误判数据。

基于此，若判断结果为是(Y)，则执行S2031；若判断结果为否(N)，则执行S203。

S2031、删除误判数据。

具体地，将误判数据剔除可以使测试装置仅采用非误判数据执行后续步骤。以便后续生成完整且准确的测试用例和测试场景，从而有利于提高软件测试效率和准确性。

后续步骤可包括生成测试用例(即S203-S208)、构建测试场景(即S209)以及进行软件测试(即S210-S212)。

S203、生成参数组合。

具体地，根据预设的参数组合策略和问题数据中的各个参数，对应于不同的场景，基于该场景关联的预设的参数组合策略和问题数据中的各个参数，生成与场景关联的参数组合。

S204、设置参数阈值。

具体地，基于经验值、自动驾驶软件的性能以及车辆的性能，为参数组合中的各个参数分别设置参数上限值和/或参数下限值。

S205、为问题数据打标。

具体地，根据问题数据中的各个参数对应的场景要素标签，为问题数据添加场景要素标签，得到问题数据对应的目标场景要素标签，以便实现后续步骤中的构建测试场景以及统计历史问题数据量。

S206、确定具有目标场景要素标签的历史问题数据量。

具体地，统计与问题数据具有相同目标场景要素标签的历史问题数据的数据量，得到历史问题数据量。

S207、判断历史问题数据量是否达到预设数量。

具体地，随着历史问题数据的累加，在历史问题数据量达到(包括等于或大于)预定数量的情况下，可根据问题数据及其参数阈值、历史问题数据及其参数阈值，生成测试用例。

若该步骤的判断结果为是(Y)，则继续执行后续步骤；否则(N)，重新基于历史问题数据量和预设数量进行判断，即返回循环执行S207。

S208、生成测试用例。

具体地，在历史问题数据量达到预设数量的情况下，基于问题数据及其参数阈值、历史问题数据及其参数阈值，生成测试用例。

S209、构造测试场景。

具体地，基于前述步骤中得到的测试用例和问题数据对应的目标场景要素标签，构建测试场景，以实现对自动驾驶环境的实际场景的还原。

S210、离线测试，得到测试结果。

具体地，在前述步骤得到的测试场景下，通过前述步骤得到的测试用例，对自动驾驶软件进行离线测试，得到测试结果。

S211、诊断分析，得到诊断信息。

具体地，对测试结果进行分析，发现导致测试结果中出现的问题的原因，即得到诊断信息。

在一些实施例中，当测试结果中不包括自动驾驶软件或软件测试相关的问题时，可省略该步骤；或者该步骤的输出结果为空、“结果良好，无成因”或为其他表面测试结果没有问题的呈现方式。

S212、生成测试报告。

具体地，根据测试结果和诊断信息，生成包括测试结果和诊断信息的测试报告，从而完成对自动驾驶软件的完整测试。

S213、结束。

具体地，程序运行结束。

后续，可关闭自动驾驶软件的测试方法对应的程序，以及关闭该程序的运行环境，例如后台服务器。

本公开实施例提供的自动驾驶软件的测试方法，可将实车测试数据自动化引入仿真测试，仿真测试后再次进行实车测试，打造自动驾驶测试闭环，完善了测试场景，提高了测试的自动化率；其次，通过设置不同的场景要素标签，可完善自动驾驶场景的全方位覆盖，实现对较为复杂的自动驾驶环境的全方位测试；同时，结合历史问题数据量等于预设数量时的问题数据生成测试用例并完成软件测试，可利用数据驱动的方式完善问题数据的筛选及误判剔除，可减少数据处理量，有利于提高测试效率，提升测试准确性。

在上述实施方式的基础上，本公开提供了一种自动驾驶软件的测试装置，可用于执行上述实施方式中的任一种自动驾驶软件的测试方法的步骤。

在一些实施例中，图3示出了一种自动驾驶软件的测试装置。如图3所示，该装置30包括：第一获取模块301，配置为获取自动驾驶车辆行驶过程中的问题数据，问题数据包括车辆在紧急控制干预状态下的行驶数据；第一生成模块302，配置为根据问题数据，生成用于测试自动驾驶软件的测试用例；软件测试模块303，配置为通过测试用例，对自动驾驶软件进行测试，得到测试结果。

本公开实施例提供的自动驾驶软件的测试装置中，能够将实车测试数据引入自动驾驶软件的仿真测试中，即利用车辆自动驾驶过程中的问题数据生成用于测试自动驾驶软件的测试用例，并通过测试用例对自动驾驶软件进行测试，可选的，进行离线测试，如此能够实现对自动驾驶软件进行全方位的测试。

在一些实施例中，行驶数据包括车辆的动力学数据、车辆所处环境的环境数据和车辆的驾驶人员的行为数据中的至少一种。

如此，可实现对车辆行驶状态的全方位还原，有利于提高测试准确性。

在一些实施例中，第一获取模块具体配置为：接收自动驾驶车辆实时发送的问题数据。

对应的，数据筛选过程可在车端(即自动驾驶车辆中)完成。即车辆仅将其处于紧急控制干预状态的行驶数据发送至第一获取模块，而不发送其处于自动驾驶状态的行驶数据。

如此，可减少测试装置的数据处理量，有利于提高测试效率。

在一些实施例中，问题数据包括自动驾驶车辆的符合问题数据筛选条件的历史行驶数据。基于此，该装置还包括：

数据接收模块，配置为接收自动驾驶车辆发送的历史行驶数据；

其中，第一获取模块具体配置为：

在历史行驶数据中，筛选出符合问题数据筛选条件的问题数据。

具体地，数据筛选过程在测试装置中完成。即车辆将其行驶过程中产生的数据，即历史行驶数据均发送至数据接收模块；对应的，数据接收模块接收历史行驶数据，第一获取模块基于历史行驶数据筛选出问题数据。

如此，可减少车端的数据处理量，有利于简化车端结构。

在一些实施例中，第一生成模块具体配置为：

根据预设的参数组合策略和问题数据中的各个参数，生成参数组合；

为参数组合中的各个参数分别设置参数阈值，得到测试用例，参数阈值包括根据自动驾驶软件的性能确定的至少一个阈值。

如此，可基于对问题数据中的参数进行组合，并设置各参数的参数阈值，以得到测试用例。

在一些实施例中，该装置还包括：

数据打标模块，配置为根据问题数据中的各个参数对应的场景要素标签，为问题数据打标，得到问题数据对应的目标场景要素标签；

场景构造模块，配置为根据测试用例和目标场景要素标签，构造测试场景；

基于此，软件测试模块具体配置为：

在测试场景下，通过测试用例，对自动驾驶软件进行测试，得到测试结果。

如此，可基于问题数据及其对应生成的测试用例，并结合场景要素标签，构造测试场景，以实现对自动驾驶环境的场景还原，从而实现在多种复杂场景下，通过测试用例对自动驾驶软件的测试，并得到对应的测试结果。

在一些实施例中，场景要素标签包括一级场景要素标签和二级场景要素标签，一级场景要素标签包括要素类型标签，二级场景要素标签包括要素属性标签。

其中，通过一级场景要素标签可实现对要素类别的划分，通过二级场景要素标签可实现对不同场景的区分。如此设置，便于实现对测试场景的构建，以及实现对关联于同一测试场景的问题数据的统计。

在一些实施例中，该装置还包括：

数据打标模块，配置为根据问题数据中的各个参数对应的场景要素标签，为问题数据打标，得到问题数据对应的目标场景要素标签；

数据量确定模块，配置为确定具有目标场景要素标签的历史问题数据量；

其中，第一生成模块具体配置为：

在历史问题数据量等于预定数量的情况下，根据问题数据，生成测试用例。

如此，可剔除历史问题数据量小于预设数量的问题数据，从而减少数据处理量，有利于提高测试效率。

在一些实施例中，该装置还包括：

数据识别模块，配置为将问题数据输入预设的数据识别模型，得到数据识别结果；

其中，第一生成模块具体配置为：

在数据识别结果指示问题数据为非误判数据的情况下，根据问题数据，生成测试用例。

在一些实施例中，该装置还包括：

数据删除模块，配置为在数据识别结果指示问题数据为误判数据的情况下，删除问题数据。

如此，可剔除误判数据，仅利用非误判数据生成测试用例，从而可提高问题数据的准确性，同时减小后续数据处理量，从而有利于提高测试效率，同时提升测试结果的准确性。

在一些实施例中，该装置还包括：

诊断分析模块，配置为对测试结果进行诊断分析，得到诊断信息；

第二生成模块，配置为根据测试结果和诊断信息，生成测试报告。

如此，可确定测试结果对应的原因，即得到诊断信息；并生成包括测试结果和诊断信息的测试报告，为后续优化自动驾驶软件以及优化测试过程提供支持。

需要说明的是，图3所示的自动驾驶软件的测试装置30可以执行上文所示的方法实施例中的各个步骤，并且实现上文所示的方法实施例中的各个过程和效果，在此不做赘述。

在上述实施方式的基础上，本公开实施例还提供了一种自动驾驶软件的测试设备，可用于实现上述任一种自动驾驶软件的测试方法。

示例性地，图4为本公开实施例提供的一种自动驾驶软件的测试设备的结构示意图。参照图4，该自动驾驶软件的测试设备40包括：处理器401以及用于存储可执行指令的存储器402；其中，处理器401用于从存储器402中读取可执行指令，并执行可执行指令以实现上述任一种自动驾驶软件的测试方法。

具体地，上述处理器401可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器402可以包括用于信息或指令的大容量存储器。举例来说而非限制，存储器402可以包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个及其以上这些的组合。在合适的情况下，存储器402可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器402可在综合网关设备的内部或外部。在特定实施例中，存储器402是非易失性固态存储器。在特定实施例中，存储器402包括只读存储器(Read-Only Memory，ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable ROM，PROM)、可擦除PROM(Electrical Programmable ROM，EPROM)、电可擦除PROM(Electrically ErasableProgrammable ROM，EEPROM)、电可改写ROM(Electrically Alterable ROM，EAROM)或闪存，或者两个或及其以上这些的组合。

处理器401通过读取并执行存储器402中存储的计算机程序指令，以执行本公开实施例所提供的多媒体文件播放方法的步骤。

在一个示例中，该多媒体播放设备40还可包括收发器403和总线404。其中，如图4所示，处理器401、存储器402和收发器403通过总线404连接并完成相互间的通信。

总线404包括硬件、软件或两者。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(ExtendedIndustry Standard Architecture，EISA)总线、前端总线(Front Side BUS，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industrial Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low Pin Count，LPC)总线、存储器总线、微信道架构(MicroChannel Architecture，MCA)总线、外围控件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial Advanced TechnologyAttachment，SATA)总线、视频电子标准协会局部(Video Electronics StandardsAssociation Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线404可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

在上述实施方式的基础上，本公开实施例还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现上述任一种自动驾驶软件的测试方法。

示例性地，可结合图4，一种包括指令的存储介质，例如包括指令的存储器402，上述指令可由处理器401执行以完成本公开实施例所提供的自动驾驶软件的测试方法。

可选地，存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(Random Access Memory，RAM)、光盘只读存储器(Compact Disc ROM，CD-ROM)、磁带、软盘和光数据存储设备等。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。