CN115599694A - 一种自动驾驶软件版本集成测试方法 - Google Patents

Abstract

本发明涉及一种自动驾驶软件版本集成测试方法，该方法先将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例；然后通过自动化的方式遍历仿真用例集；最后通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，再正式发布评估合格的软件版本到系统测试。本发明通过用例泛化手段，验证出特殊场景的临界值。自动化批量验证算法测试，可同时并发10次换道场景用例，相较于全场景实车测试，针对换道算法的验证，更加有效。可重读精准执行同一条测试用例，验证算法的稳定性。

Description

一种自动驾驶软件版本集成测试方法

技术领域

本发明属于自动驾驶技术领域，具体涉及一种自动驾驶软件版本集成测试方法。

背景技术

针对无人驾驶领域的软件版本集成测试，目前业界的软件集成测试包含静态代码检查和代码编译检查，测试的重点多为代码语法相关的检查，而采用静态代码检测等手段只能拦截代码语法以及编译相关的问题，对集成后的软件版本所存在的功能性问题，例如规划算法不能换道等问题，往往需要流转到系统测试阶段，才能被发现。这样，从版本发布到系统测试反馈问题，再到研发修复问题，提交代码，迭代版本，再系统测试验证，所消耗的研发周期较长，人力成本较高，但是工作效率较低。

发明内容

本发明的目的在于，针对现有技术所存在的自动驾驶软件开发阶段中版本集成后系统测试不可用的问题，提出一种自动驾驶软件版本集成测试方法，该方法将仿真测试引入到软件集成测试阶段，利用丰富的仿真场景对软件中的规划及融合算法进行仿真模拟测试，在版本发布到系统测试前进行自动化测试，以拦截功能性问题，并对版本各项指标进行评分，有效的缩短了研发周期，能够快速精准地定位软件版本异常，提高软件版本的有效性。

为了达到以上目的，本发明提供一种自动驾驶软件版本集成测试方法，包括以下步骤：

步骤一、将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例；

步骤二、通过自动化的方式遍历仿真用例集；

步骤三、通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，再正式发布评估合格的软件版本到系统测试。

本发明通过仿真器模拟系统的测试场景对软件集成版本进行评估，用于保障自动驾驶软件发布版本质量，降低因功能性问题导致的系统测试验证不通过的问题，以缩短暴露软件版本缺陷的时间。

本发明进一步的采用如下技术方案：

所述步骤一中，在通过仿真器模拟系统的测试场景对软件集成版本进行评估之前，还具有以下操作：

步骤1、版本构建—构建自动驾驶软件的代码，并将代码递交到仓库储存，提取仓库内储存的源码进行编译、整合，得到集成的自动驾驶软件版本，将软件版本上传到制品库进行版本维护；

步骤2、环境部署—通过软件集成版本部署仿真平台，并进行仿真场景库建设，将检索到的制品库上最新的软件版本拉取到测试服务器进行测试。

所述步骤2中，仿真场景库建设的具体方法是：仿真用例的设计，通过仿真云平台的编辑器，编辑相应的用例场景，其中包含的用例元素有高精地图、模型库、场景元素构成；仿真器首先加载相应的高精地图，加载地图引擎，然后通过拖拽被测车辆吸附到地图道路中心线，设置车辆的速度、偏移量、触发条件参数，由于高精地图文件记录了路网的方向信息，车辆摆放过程中Heading自动识别匹配，加入用例需要的不同类型的交通流目标车，通过设置途径点的方式设计目标车路线，在云端保存用例；根据不同的测试场景与算法验证需求开发仿真用例，云端形成换道、绕行、切入、过闸机、红路灯的仿真场景库。

所述步骤2中，通过设置途径点的方式设计目标车路线，在云端保存用例的具体方式是：通过编辑连线的方式画出途径点设计目标车路线，可通过距离和时间设定目标车触发条件，在云端保存用例配置文件，记录了车辆位置、调用地图信息、日志是否打印、车辆类型、调用车辆模型信息、速度、加速度、触发条件、途经点信息。

所述步骤一中，将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例的具体方式是：

仿真主要针对自动驾驶软件版本中的规划算法进行测试，仿真通过拉去上游规划算法和仿真引擎进行工具链的整体编译，生成指定算法的软件包仿真环境，用于后续的验证。软件版本架构基于ROS2，各算法模块有各自的文件维护，其中包含可执行文件及相关的配置文件，将规划算法的上游输入话题，包含自车定位信息、任务管理器中的任务命令和任务路线、底盘信息、故障itc码、可通行空间、预测目标话题，将仿真message数据传入给到规划算法模块，将规划算法模块、公共依赖仓库、地图sdk与仿真模块中的中间件、仿真引擎进行编译，得到仿真环境软件包。

所述步骤二中，通过自动化的方式遍历仿真用例集，对软件版本进行测试，具体方法如下：

通过k8s集群的部署方式搭建自动化测试仿真云平台，完成仿真场景库的并发测试；k8s集群由1台master主节点和10台node节点组成，将仿真环境软件包拉取到云服务器存储，下发任务，实现定时任务多节点部署及自动任务分发，对文件路径下的用例遍历执行，直至生命周期函数触发，并发测试结束，上传测试生成的日志文件到云服务器存储。

遍历仿真用例集的目的是提高版本测试效率，通过k8s集群并发构建任务，自动化执行指定用例集的测试用例，提升了测试效率，降低漏测风险。

所述步骤三中，通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，具体的操作方法是：

通过云上仿真测试执行后的存储在云服务器的日志，对日志进行解析，以提取日志中的时间戳、速度、加速度、碰撞状态值、刹车状态值、，形成记录数据，以数据表格作为输出数据，记录数据的第一列为时间戳，并对应时间戳所在时刻的状态数据。对除时间戳外的所有数据进行最大值、最小值、均值、方差、标准差、中位数、众数的计算。再对记录数据进行统计学指标抽象，得到除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数，然后通过除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数对得出的指标进行抽象层评价，进而对产品的平顺性、稳定性、安全性、高效性进行综合评价，综合评价的计算公式如下所示：

Y=i⁰*X₀+i¹*X₁+i²*X₂+i³*X₃……i^j*X_j

i⁰+i¹+i²+i³……+i^j=1

式中，i⁰～i^j为权重系数且均为正数，X₀～X_j代表各种不同类型的评测指标，其中X₀表示平顺性的评测指标，X₁表示稳定性的评测指标，X₂表示安全性的评测指标，X₃表示高效性的评测指标，X_j 表示后续扩充的指标，Y为最后的算法综合得分。

所述抽象层评价时，采用横偏数据和速度数据作为考察被测车辆平顺性的指标，即通过所有时刻速度方差与急刹判定结果对被测车辆的平顺性进行综合评价；

通过所有时刻加速度的均值和方差，速度的均值和方差，急刹判定结果，碰撞判定结果对被测车辆的稳定性进行评价；

通过所有时刻碰撞状态值和急刹判定结果对被测车辆的安全性进行评价；

通过时间戳和速度对被测车辆的高效性进行评价。

所述抽象层评价前，需要用例的碰撞判定结果、换道判定结果和急刹判定结果进行评测，评测的具体方法如下：

通过时间戳和碰撞状态值，即可判断出用例测试过程中是否发生过碰撞及发生碰撞时的碰撞时刻，以判定碰撞的测试结果，获得碰撞判定结果。具体地，通过碰撞状态值判断是否发生碰撞，当碰撞状态值超出预设阈值时，说明车辆发生碰撞，记录超出阈值的碰撞状态值所对应的时刻为碰撞时刻，否则说明车辆没有发生碰撞。

通过时间戳、方向盘转角/规划换道状态值来判断用例测试过程中是否发生换道及发生换道时的换道时刻，获得换道判定结果。上述换道判定结果有两种评测方法，一是方向盘转角，二是规划换道状态值，采用方向盘转角判定换道结果时，判断方向盘转角是否超出阈值，若超出阈值，则判定车辆换道，并记录超出阈值方向盘转角所对应的时刻为车辆换道时刻，否则说明车辆没有换道，当判定车辆换道时还可以获取方向盘转动到车辆回正过程所用的时间；采用规划换道状态值来判定换道结果时，判断规划换道状态值是否超出阈值，若是则判定车辆换道，并记录超出阈值规划换道状态值所对应的时刻为车辆换道时刻，否则说明车辆没有换道。还可以通过检测规划换道状态时间差，比对上述两种评价换道方式的差异。

通过时间戳、刹车状态值，即可判断出用例测试过程中是否出现急刹车行为及发生急刹时的急刹时刻，获得刹车判定结果。具体地，通过刹车状态值判断是否发生急刹车，当刹车状态值超出预设阈值时，说明车辆发生急刹车，记录超出阈值的刹车状态值所对应的时刻为急刹时刻，否则说明车辆没有发生急刹车。

进一步的，所述被测车辆进行高效性评测时，将车辆速度为0时刻提取后，将时间戳做差值得到等待时间，查看等待时间是否超出阈值，即可判断是否存在不合理及影响效率等待的情况。

本发明的优点是缩短了系统测试和回归的时间，快速精准的定位了算法问题，同时覆盖边角案例（Corner Case），尤其是危险场景的测试，提升了场景覆盖，降低了实车路测风险，相比较系统测试，不受恶劣自然环境影响，大大减少了安全隐患。

本发明通过用例泛化手段，验证出特殊场景的临界值。自动化批量验证算法测试，可同时并发10次换道场景用例，相较于全场景实车测试，针对换道算法的验证，更加有效。可重读精准执行同一条测试用例，验证算法的稳定性。

附图说明

下面结合附图对本发明作进一步的说明。

图1为本发明的流程图。

图2为本发明中精准测试的原理示意图。

图3为本发明中评价体系的示意图。

具体实施方式

本发明的自动驾驶软件版本集成测试方法，包括以下步骤：

步骤一、将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例。具体方式是：

仿真主要针对自动驾驶软件版本中的规划算法进行测试，仿真通过拉去上游规划算法和仿真引擎进行工具链的整体编译，生成指定算法的软件包仿真环境，用于后续的验证。软件版本架构基于ROS2，各算法模块有各自的文件维护，其中包含可执行文件及相关的配置文件，将规划算法的上游输入话题，包含自车定位信息、任务管理器中的任务命令和任务路线、底盘信息、故障itc码、可通行空间、预测目标话题，通过proto数据结构将仿真message数据传入给到规划算法模块，通过Cmakelist编译方式，将规划算法模块、公共依赖仓库、地图sdk与仿真模块中的中间件、仿真引擎进行编译，得到仿真环境软件包。

步骤二、通过自动化的方式遍历仿真用例集。

通过自动化的方式遍历仿真用例集，对软件版本进行测试，具体方法如下：

通过k8s集群的部署方式搭建自动化测试仿真云平台，完成仿真场景库的并发测试；k8s集群由1台master主节点和10台node节点组成，Jenkins将仿真环境软件包通过webhook的方式，拉取到云服务器OSS存储，通过job引擎下发任务，Redis（远程字典服务）实现定时任务多节点部署及自动任务分发，对文件路径下的txt格式用例遍历执行，直至Job下pod生命周期函数触发，并发测试结束，上传测试生成的日志文件到云服务器OSS存储。

步骤三、通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，再正式发布评估合格的软件版本到系统测试。具体的操作方法是：

通过云上仿真测试执行后的存储在云服务器OSS的日志，对db3文件格式日志进行解析，以提取日志中的时间戳、起止点坐标、routing路线、速度、加速度、航向角、横偏、碰撞状态值、刹车状态值、方向盘转角、车轮转角、规划换道状态值、所在道路ID等基础数据，形成json文件记录数据，以数据表格作为输出数据，记录数据的第一列为时间戳，并对应时间戳所在时刻的状态数据。对除时间戳外的所有数据进行最大值、最小值、均值、方差、标准差、中位数、众数的计算。再对记录数据进行第二轮统计学指标抽象，得到除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数，然后通过除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数来评价速度的稳定性等，对得出的指标进行第三轮的抽象层评价，进而对产品的平顺性、稳定性、安全性、高效性进行综合评价。综合评价的计算公式如下所示：

Y=i⁰*X₀+i¹*X₁+i²*X₂+i³*X₃……i^j*X_j

i⁰+i¹+i²+i³……+i^j=1

式中，i⁰～i^j为权重系数且均为正数，X₀～X_j代表各种不同类型的评测指标，其中X₀表示平顺性的评测指标，X₁表示稳定性的评测指标，X₂表示安全性的评测指标，X₃表示高效性的评测指标，X_j 表示X_j 表示后续根据业务需求需要扩充的评价指标，Y为最后的算法综合得分。

抽象层评价前，需要用例的碰撞判定结果、换道判定结果和急刹判定结果进行评测，评测的具体方法如下：

通过以上json文件中的时间戳和碰撞状态值，即可判断出用例测试过程中是否发生过碰撞及发生碰撞时的碰撞时刻，以判定碰撞的测试结果，获得碰撞判定结果。具体地，通过碰撞状态值判断是否发生碰撞，当碰撞状态值超出预设阈值时，说明车辆发生碰撞，记录超出阈值的碰撞状态值所对应的时刻为碰撞时刻，否则说明车辆没有发生碰撞。

通过以上json文件中的时间戳、方向盘转角/规划换道状态值来判断用例测试过程中是否发生换道及发生换道时的换道时刻，获得换道判定结果。上述换道判定结果有两种评测方法，一是方向盘转角，二是规划换道状态值，采用方向盘转角判定换道结果时，判断方向盘转角是否超出阈值，若超出阈值，则判定车辆换道，并记录超出阈值方向盘转角所对应的时刻为车辆换道时刻，否则说明车辆没有换道，当判定车辆换道时还可以获取方向盘转动到车辆回正过程所用的时间；采用规划换道状态值来判定换道结果时，判断规划换道状态值是否超出阈值，若是则判定车辆换道，并记录超出阈值规划换道状态值所对应的时刻为车辆换道时刻，否则说明车辆没有换道。还可以通过检测规划换道状态时间差，比对上述两种评价换道方式的差异。

通过以上json文件中的时间戳、刹车状态值、速度，即可判断出用例测试过程中是否出现急刹车行为及发生急刹时的急刹时刻，获得刹车判定结果。具体地，通过刹车状态值判断是否发生急刹车，当刹车状态值超出预设阈值时，说明车辆发生急刹车，记录超出阈值的刹车状态值所对应的时刻为急刹时刻，否则说明车辆没有发生急刹车。

抽象层评价时，采用横偏数据和速度数据作为考察被测车辆平顺性的指标，即通过所有时刻速度方差偏离程度与急刹判定结果对被测车辆的平顺性进行综合评价；

通过所有时刻加速度的均值和方差，速度的均值和方差，急刹判定结果，碰撞判定结果对被测车辆的稳定性进行评价；

通过所有时刻碰撞状态值和急刹判定结果对被测车辆的安全性进行评价；

通过时间戳和速度对被测车辆的高效性进行评价。被测车辆进行高效性评测时，将车辆速度为0时刻提取后，将时间戳做差值得到等待时间，查看等待时间是否超出阈值，即可判断是否存在不合理及影响效率等待的情况。

另外，在通过仿真器模拟系统的测试场景对软件集成版本进行评估之前，还具有以下操作：

步骤1、版本构建—构建自动驾驶软件的代码，并将代码递交到仓库储存，提取仓库内储存的源码进行编译、整合，得到集成的自动驾驶软件版本，将软件版本上传到制品库进行版本维护；

步骤2、环境部署—通过软件集成版本部署仿真平台，并进行仿真场景库建设，将检索到的制品库上最新的软件版本拉取到测试服务器进行测试。仿真场景库建设的具体方法是：仿真用例的设计，通过Web端仿真云平台的编辑器，编辑相应的用例场景，其中包含的用例元素有高精地图、模型库（车辆、行人、障碍物、路侧设施）、场景元素构成；仿真器首先加载相应的高精地图bin文件，加载地图引擎，然后通过拖拽被测车辆吸附到地图道路中心线，设置车辆的速度、偏移量、触发条件等参数，由于高精地图文件记录了路网的方向信息，车辆摆放过程中Heading自动识别匹配，加入用例需要的不同类型的交通流目标车，通过设置途径点的方式设计目标车路线，在云端保存用例；根据不同的测试场景与算法验证需求开发仿真用例，云端形成换道、绕行、切入、过闸机、红路灯的仿真场景库。

通过设置途径点的方式设计目标车路线，在云端保存用例的具体方式是：通过编辑连线的方式画出途径点设计目标车路线，可通过距离和时间设定目标车触发条件，在云端保存用例配置文件，记录了车辆位置、调用地图信息、日志是否打印、车辆类型、调用车辆模型信息、速度、加速度、触发条件、途经点（waypoint）信息。

实施例一

如图1所示，一种自动驾驶软件版本集成测试方法，包括以下步骤：

步骤1、版本构建

各模块开发人员上传代码到Gitlab平台各自分支，代码中包含Dockerfile,CMakeLists.txt，将代码提交到远程仓库，可直接webhook触发Jenkins。Jenkins构建任务，触发条件设置每周构建时间以及相应的webhook URL，构建任务中配置好Git仓库地址及对应的分支名，版本号信息，服务类型，服务名称，资源数量，实例个数等。

每周固定时间触发软件版本集成构建，流水线自动到对应Git仓库的分支拉取源码到编译服务器，编译脚本build_integration.sh根据上下游依赖关系及第三方依赖库进行逐层编译，编译通过后，调用common_function.sh对版本号进行提取，调用common_commit.sh对git近一周的提交信息进行整合，以版本号加日期作为名字进行打包，上传到JFrog制品库，进行版本维护。

步骤2、环境部署

仿真平台一般包括仿真框架、物理引擎和图形引擎；其中仿真框架是平台软件平台的核心，支持传感器仿真、车辆动力学仿真、交通环境仿真、云仿真等。

交通场景仿真：包括静态场景还原和动态场景仿真两部分，静态场景还原主要通过高精地图和三维建模技术来实现；动态场景仿真既可通过把真实路采数据经过处理还原，也可以通过算法生成。动静场景结合起来形成实际车辆行驶面临的交通场景。

传感器仿真：支持支持摄像头、激光雷达、毫米波雷达以及GPS/IMU等传感器仿真，实现这些传感器信号的回放或者构造能力。

云仿真：支持云服务的模拟，与端进行持续交互，包括高并发等特殊场景。

车辆动力学仿真：基于多体动力学搭建的模型，将包括转向、悬架、制动、I/O硬件接口等在内的多个真实部件进行参数化建模，进而实现车辆模型运动过程中的姿态和运动学仿真模拟。这是车辆自身部分的仿真。

仿真平台部署——UTOSIM仿真器环境部署

通过uto_sim_cli.py软件集成版本自动部署，每周定时触发检索JFrog上最新的软件版本，拉取到测试服务器，拉取步骤包含UTOSIM仿真器的版本包拉取，规划、控制、融合算法的版本包拉取，第三方依赖库的拉取，地图map_sdk（最新的高精地图）拉取到docker下的/opt/uto/pilot/路径下。

测试用例组成，每个测试用例的配置为.txt文件，场景要素包含：

调用的map_version地图版本；

目标车，目标车ID，目标车类型，物理尺寸，初始位置，车速，加速度，指定途经点的选择，横偏距离，触发条件；

动态障碍物，障碍物类型，物理尺寸，初始位置，车速，加速度，途经点的选择，横偏距离，触发条件，纵向距离，触发条件；

静态环境，静态障碍物，障碍物类型，物理尺寸，初始位置，障碍物物理属性，触发条件；

气象，雨，雪天气属性配置；

用例执行时长配置；

云服务配置。

仿真场景根据方案的不同分为Worldsim和Logsim。

Logsim是由路测数据提取的场景，提供复杂多变的障碍物行为和交通状况，使场景充满不确定性。路测时录制log，通过平台回放log实现场景重现。Logsim数据来源于真实的路测，是最真实，正确有效的。但是Logsim数据的内容通常无法根据需求进行更改，这种数据回放的形式多用于回归测试。

Worldsim是由人为预设的障碍物行为和交通灯状态构成的场景，可以简单高效的测试自动驾驶车辆，但缺乏真实交通环境中复杂的情况；worldsim假设感知是正确工作的，用的是模拟数据，复杂度更高。

场景库建设—测试用例开发及调试步骤：

通过WorldEditor编辑器开发测试用例场景，可实现单个用例开发，用例泛化，泛化内容包含配置中的横偏、车速、纵向距离、触发条件等参数。

启动python3 uto_sim_cli.py -r worldsim，请将批量运行的case存放在test_case文件夹中，即可实现批量调试。

启动python3 uto_sim_cli.py -r logsim，将要运行的rosbag包存放在bags文件夹下，即可完成回放测试。

UTOSIM自动化测试用例集，涵盖换道，绕行，跟车，巡线，避障，侵入路网边界值，红绿灯，闸机，多车协同，压力测试，Corner Case等测试场景。

步骤3、集成测试

集成测试包括k8s云服务（k8s并发测试）和精准测试，其中k8s并发测试是基于k8s搭建自动化测试平台，完成仿真场景库的并发测试。k8s环境由多台master节点和多台node节点组成，搭建部署在公有云IaaS上。集群部署架构最主要包含管理平面和业务平面，核心则是降低平台的使用复杂度和运维复杂度，不仅需要有高可用的业务集群，还需要有相应的配套服务机制，其中包括监控（metrics）、日志（Logs）、网络管控、存储管控、负载均衡、私有云场景还需要提供yum源和镜像仓库服务等。 CICD拉取版本到云服务器OSS存储，通过job引擎下发任务，Redis实现定时任务多节点部署及自动任务分发。job下pod生命周期函数触发，上传测试结果到OSS存储。集群并发测试的优势，可动态分配空闲资源，高效完成测试。每轮软件版本集成测试1小时内，共测试50条用例，每条测试用例执行10次。

如图2所示，精准测试包括测试充分性和精准测试，先进行测试充分性，再进行精准测试。测试充分性包括刻画和度量有限测试集合的充分性，如何挑选有限测试集合并充分执行，如何让上述过程更加自动化、更加精准；精准测试包括通过代码覆盖率度量测试充分性，通过精准推荐代替人工进行变更影响范围评估指导用例回归，精准推荐自动化和用例执行失败快速定位。

步骤4、测试评价体系

通过仿真测评体系，对以上测试执行后的结果进行自动判断。

后处理模块，对日志中的数据进行指标的提取，通过统计学方式对指标进行二次抽象（最大值，最小值，均值，方差，标准差，中位数），Σ指标*权重，根据不同的测试需求重点，制定不同的权重，对产品评价维度进行打分，其中临界值用例，通过测试结果通过与不通过的用例，作为临界值输出；

评价维度：安全性，合规性，舒适性，可靠性，高效性（见图3）；

仿真评价：场景真实度，场景有效性，场景覆盖度，仿真效率。

输出指标：

模块间延迟；

横偏；

有无急加减速；

收到Brake命令到制动完成（v=0）的纵向距离；

制动完成距离障碍物的纵向距离；

开始避障时车头距离障碍物的纵向距离、避障完成时车尾距离障碍物的纵向距离；

避障过程中距离障碍物的横向距离；

跟车距离。

步骤5、看板展示

每周发布集成测试结果，基于kiwi看板展示内容，包含测试用例总数，测试时长，每条用例测试时长，测试结果以及临界值的输出，失败用例占比，测试日志链接，对于版本的综合打分。

本发明首次将仿真测试引入到集成测试阶段，具有高效性，提升场景覆盖，安全合规，不受天气环境影响，边界值测试，测试有效性等特点。本发明基于Jenkins部署CICD；软件版本集成测试引入仿真测试，在流转到系统测试之前，暴露算法问题，缩短研发周期；基于k8s云服务进行自动化并发测试；引入精准推荐算法，避免漏测，快速精准测试；建立测试分析体系，基于仿真评测指标，多维度度量版本质量，对版本进行质量评估。

除上述实施例外，本发明还可以有其他实施方式。凡采用等同替换或等效变换形成的技术方案，均落在本发明要求的保护范围。

Claims (10)

1.一种自动驾驶软件版本集成测试方法，其特征在于，包括以下步骤：

步骤一、将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例；

步骤二、通过自动化的方式遍历仿真用例集；

步骤三、通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，再正式发布评估合格的软件版本到系统测试。

2.根据权利要求1所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤一中，在通过仿真器模拟系统的测试场景对软件集成版本进行评估之前，还具有以下操作：

步骤1、版本构建—构建自动驾驶软件的代码，并将代码递交到仓库储存，提取仓库内储存的源码进行编译、整合，得到集成的自动驾驶软件版本，将软件版本上传到制品库进行版本维护；

步骤2、环境部署—通过软件集成版本部署仿真平台，并进行仿真场景库建设，将检索到的制品库上最新的软件版本拉取到测试服务器进行测试。

3.根据权利要求2所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤2中，仿真场景库建设的具体方法是：仿真用例的设计，通过仿真云平台的编辑器，编辑相应的用例场景，其中包含的用例元素有高精地图、模型库、场景元素构成；仿真器首先加载相应的高精地图，加载地图引擎，然后通过拖拽被测车辆吸附到地图道路中心线，设置车辆的速度、偏移量、触发条件参数，加入用例需要的不同类型的交通流目标车，通过设置途径点的方式设计目标车路线，在云端保存用例；根据不同的测试场景与算法验证需求开发仿真用例，云端形成换道、绕行、切入、过闸机、红路灯的仿真场景库。

4.根据权利要求3所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤2中，通过设置途径点的方式设计目标车路线，在云端保存用例的具体方式是：通过编辑连线的方式画出途径点设计目标车路线，可通过距离和时间设定目标车触发条件，在云端保存用例配置文件，记录了车辆位置、调用地图信息、日志是否打印、车辆类型、调用车辆模型信息、速度、加速度、触发条件、途经点信息。

5.根据权利要求1所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤一中，将软件版本的规划算法接入仿真环境，通过仿真用例编辑工具开发测试用例的具体方式是：

将规划算法的上游输入话题，包含自车定位信息、任务管理器中的任务命令和任务路线、底盘信息、故障itc码、可通行空间、预测目标话题，将仿真message数据传入给到规划算法模块，将规划算法模块、公共依赖仓库、地图sdk与仿真模块中的中间件、仿真引擎进行编译，得到仿真环境软件包。

6.根据权利要求1所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤二中，通过自动化的方式遍历仿真用例集，对软件版本进行测试，具体方法如下：

通过k8s集群的部署方式搭建自动化测试仿真云平台，完成仿真场景库的并发测试；k8s集群由1台master主节点和10台node节点组成，将仿真环境软件包拉取到云服务器存储，下发任务，实现定时任务多节点部署及自动任务分发，对文件路径下的用例遍历执行，直至生命周期函数触发，并发测试结束，上传测试生成的日志文件到云服务器存储。

7.根据权利要求1所述一种自动驾驶软件版本集成测试方法，其特征在于，所述步骤三中，通过仿真评价体系对测试结果进行多维度量化评估，给出综合打分及相关测试风险项，具体的操作方法是：

通过云上仿真测试执行后的存储在云服务器的日志，对日志进行解析，以提取日志中的时间戳、速度、加速度、碰撞状态值、刹车状态值、，形成记录数据，再对记录数据进行统计学指标抽象，得到除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数，然后通过除时间戳外的记录数据的最大值、最小值、均值、方差、标准差、中位数对得出的指标进行抽象层评价，进而对产品的平顺性、稳定性、安全性、高效性进行综合评价，综合评价的计算公式如下所示：

Y=i⁰*X₀+i¹*X₁+i²*X₂+i³*X₃……i^j*X_j

i⁰+i¹+i²+i³……+i^j=1

式中，i⁰～i^j为权重系数且均为正数，X₀～X_j代表各种不同类型的评测指标，其中X₀表示平顺性的评测指标，X₁表示稳定性的评测指标，X₂表示安全性的评测指标，X₃表示高效性的评测指标，X_j 表示后续扩充的评价指标，Y为最后的算法综合得分。

8.根据权利要求7所述一种自动驾驶软件版本集成测试方法，其特征在于，所述抽象层评价时，通过所有时刻速度方差与急刹判定结果对被测车辆的平顺性进行综合评价；

通过所有时刻加速度的均值和方差，速度的均值和方差，急刹判定结果，碰撞判定结果对被测车辆的稳定性进行评价；

通过所有时刻碰撞状态值和急刹判定结果对被测车辆的安全性进行评价；

通过时间戳和速度对被测车辆的高效性进行评价。

9.根据权利要求8所述一种自动驾驶软件版本集成测试方法，其特征在于，所述抽象层评价前，需要用例的碰撞判定结果和急刹判定结果进行评测，评测的具体方法如下：

通过时间戳和碰撞状态值，即可判断出用例测试过程中是否发生过碰撞及发生碰撞时的碰撞时刻，获得碰撞判定结果；

通过时间戳、刹车状态值，即可判断出用例测试过程中是否出现急刹车行为及发生急刹时的急刹时刻，获得刹车判定结果。

10.根据权利要求7所述一种自动驾驶软件版本集成测试方法，其特征在于，所述被测车辆进行高效性评测时，将车辆速度为0时刻提取后，将时间戳做差值得到等待时间，查看等待时间是否超出阈值，即可判断是否存在不合理及影响效率等待的情况。

Images