长文“国外自动驾驶测试现状的调查”

自主驾驶显示出对于改革现代交通的巨大潜力。然而，它的可靠性和安全性已经引起了很多人的关注和担忧。与传统的软件系统相比，自动驾驶系统 (ADS) 通常将深度神经网络与基于逻辑的模块结合使用。这种新模式给软件测试提出了独特的挑战。最近，软件工程（SE）界投入了大量精力来开发自动驾驶系统的新测试技术。然而，尚不清楚这些技术在可以再多大程度上满足工业从业者的需求。为了填补这一空白，我们提出了第一个全面的研究，以确定目前工业中测试自动驾驶系统的实践和需求。我们对来自10家自动驾驶公司的开发者进行了半结构性访谈，并对100名曾从事自动驾驶系统的开发者进行了调。通过对访谈和问卷调查数据的系统分析，我们确定了来自业界测试自动驾驶系统的八种常见做法和四种常见需求。我们进一步调查了来自28个SE会议、期刊和研讨会的98篇高度相关的论文，以寻找解决这些需求的方案。最后，我们分析了现有测试技术的局限性，并为 SE 研究人员提出了几个未来的方向。

简介

近年来，自动驾驶技术一直在积极发展，并取得了令人鼓舞的成果。例如，谷歌 Waymo 已经在加利福尼亚开展了自动驾驶汽车试验，提供完全自动驾驶的叫车服务。然而，鉴于自动驾驶汽车造成的事故越来越多，越来越多的人对自动驾驶系统（ADSs）的可靠性和安全性表示担忧。

软件工程（SE）界已经提出了许多测试技术来提高ADS的安全性和可靠性。例如，DeepRoad 和 DeepTest利用变质测试在极端天气条件下测试 ADS。AC3R根据碰撞报告在模拟环境中生成关键驾驶场景（例如碰撞）。这些方法在检测端到端自动驾驶模型的潜在问题方面表现出了很好的效果。然而，目前还不清楚这些ADS测试技术在多大程度上满足工业需求。为了弥补这一差距，我们进行了一项访谈研究和一项大规模调查，以确定ADS测试的常见做法，以及SE界下一步的研究机会。

在这项研究中，我们首先采访了10家自动驾驶公司的开发人员，收集关于ADS测试实践和需求的定性反馈。根据访谈研究的见解，我们进一步开展了一项后续调查，并征求了广大观众的定量回答，以减少我们调查结果的偏见。具体来说，我们向ADS的开发者发出了1978份调查，收到了100份回复。基于定性和定量分析，我们确定了工业中开发和测试 ADS 的八种常见做法，其中一些尚未被现有测试技术考虑。例如，大多数ADS的测试方法集中在简单的端到端驾驶模型上，而工业ADS则更为复杂，使用带有逻辑模块的多个感知模型和多模式传感器数据，如视频和点云。此外，我们确定了测试 ADS 的四个常见需求：(1) 识别可能的极端情况和意外驾驶场景，(2) 加速 ADS 测试，(3) 构建复杂驾驶场景的工具支持，以及 (4) 数据标签的工具支持。

我们进一步对SE界提出的ADS测试方法进行了文献回顾。从 来自28 个 SE 研讨会中的 575 篇深度学习 (DL) 或自动驾驶论文中，我们确定了 36 篇与 ADS 测试相关的论文，以及 62 篇与 DL 测试相关的论文。我们确定了现有研究和工业需求之间的主要差距。例如，现有的ADS测试方法只考虑简单的图像转换。目前缺乏对识别更丰富、更复杂的交通场景的支持，而这些场景是开发者在实践中真正需要的。基于这些差距，我们提出了几个未来的方向。例如，SE研究人员可以利用测试选择和优先排序技术来加速ADS测试（需求2）。此外，考虑到 ADS 的多模块架构，测试选择方法可以表述为多目标优化问题，而不仅仅是优化单个测试指标，例如神经元覆盖率或意外充分性。

第二节讨论了ADS测试的相关工作。第三节说明了我们如何进行采访和调查。第四节提供了当前ADS测试在工业中的实践。第五节总结了工业界对ADS测试的需求。第六节讨论了针对这些需求和未来研究方向的现有 SE 解决方案。第七节讨论了本研究中对有效性的威胁。第八节总结了这项工作。

相关工作

有几篇关于机器学习（ML）模型的测试和验证的文献综述。最全面的文献综述是J.Zhang等人著作的。他们分析了114篇与机器学习测试相关的论文，并对各种测试属性、组件和ML模型的工作流程进行了概述。此外，J.Zhang等人还指出了测试ML模型的几个挑战，如如何产生自然的测试输入，并提出了研究机会。与这些研究相比，我们的研究重点是测试ADS。我们不仅进行了文献回顾，还进行了访谈和调查，以了解行业内测试ADS的普遍做法和需求。我们发现，与普通的ML模型相比，ADS的独特特征（如多模块结构）以及特殊的测试需求带来了新的挑战和机遇。

最近有两项研究分析了自主驾驶系统的代码库和错误。Peng等人对百度Apollo进行了案例研究，总结了Apollo系统的架构和各个模块。他们发现 Apollo 在系统层面缺乏足够的测试。Garcia等人分析了Apollo和Autoware的16851次提交和499个问题。他们对这些问题进行了分类，并总结了其表现和根本原因。还有一些关于 ML 应用程序中的错误的实证研究。例如，J.Zhang等人分析了由TensorFlow构建的ML应用程序中的175个软件缺陷。

与我们研究最相关的工作包括几篇关于自动驾驶测试的文献综述。Huang等人论述了智能汽车社区的测试和验证方法。他们不仅总结了软件堆中单个模块的测试方法，还总结了硬件组件的硬件在环测试方法和整车的集成测试。与Huang等人相比，我们侧重于从软件的角度讨论测试方法。我们的文献综述总结了软件工程界在ADS测试方面的最新进展。关于这些软件测试技术的详细总结和讨论，请参考第六节。Koopman 和 Wagner 提出了基于自动驾驶汽车的 V 模型测试自动驾驶汽车的五个挑战。Masuda 描述了自动驾驶汽车模拟的软件架构，并讨论了此类模拟的几个软件测试挑战。与他们相比，我们的讨论是基于对行业从业者的访谈和在线调查中测试ADS的常见做法和需求。

方法论

为了了解工业从业者的做法和需求，我们首先对来自10家不同自动驾驶公司的10名开发人员进行了半结构式访谈。基于这些访谈出现的新兴主题和发现，我们进一步对自动驾驶行业的 100 名开发人员进行了大规模调查，以定量验证我们从定性访谈研究中获得的发现。本节介绍了每项研究的设计和数据分析过程，以及每项研究中参与者的人口统计资料。

A. 访谈

访谈协议。我们为半结构化的访谈设计了一个访谈指南。访谈开始时，我们对研究进行了简短的介绍。然后，我们提出了有关以下方面的高级问题：1) 受访者的背景和专长，例如目前的工作角色以及他们在自动驾驶系统开发和测试方面工作了多久, 2) 目前在自动驾驶测试中使用的做法、方法和工具，以及 3) 他们面临的挑战和困难。我们首先进行了两次试点访谈，在此基础上，我们进一步完善了访谈指南。然后，我们采访了来自自动驾驶公司的十名开发人员。每次采访时间在30分钟到1小时之间，经允许后进行录音，然后转录以供分析。

参与人员。我们根据个人网络、行业合作和社交媒体，从十家不同的自动驾驶公司招募了十名软件开发人员。如表一所示，这些参与者至少有一年半的自主驾驶系统开发和测试经验（平均3.4年）。此外，他们的职责还涵盖了ADS测试的各个方面，包括模块测试、仿真平台测试和现实世界测试。

分析报告。我们使用名为iflyrec2的音频转录工具将总共7个小时的访谈录音转录为文本。我们手动纠正了笔录中的错误。T然后，我们使用名为MAXQDA3的定性数据分析软件从记录中提取有用的信息，突出显示参与者的所有相关或有洞察力的回答，并将其总结为简短的描述性文本，这被称为代码。

然后，前两位作者分别进行了归纳式主题分析，将相关代码归纳为主题。然后，他们互相讨论不同意见，以完善代码和主题。在讨论中，第一和第二作者不断调整代码和主题的描述和界限。用Cohen's Kappa来衡量，最终的测评者间一致性比率为0.85。专题分析的结果会定期报告，并与整个研究小组讨论。

B. 调查

由于访谈研究的结果只是基于10位参与者的回答，我们进一步进行了大规模的调查，以验证访谈的结果，并从更广泛的行业内的自动驾驶系统开发者那里征求更多的反馈。

调查设计。我们设计了一个调查问卷，包括背景、自动驾驶系统、ADS的测试实践和挑战、ADS的测试需求和后续工作等5个部分，共33个问题。背景部分询问了参与者的背景、专长知识以及他们目前在公司或组织中的角色。自动驾驶系统部分询问了调查参与者所测试的ADS系统的结构以及其开发过程。关于ADS的测试实践和挑战部分询问了三种常见的ADS测试类型，包括单元测试、模拟测试和道路测试，这是从访谈研究中确定的。对于每种类型的测试，我们根据访谈研究的结果设计了多项选择题。多项选择题中的选项来自于访谈研究的回答。参与者还可以选择 "其他 "来补充替代答案，或者选择 "我不知道 "来表示他们对该特定问题没有见解。对于每一种类型的测试，我们还在最后加入了一个开放式的问题，以征求参与者希望拥有或改进的额外反馈。ADS的测试需求部分列出了访谈研究中发现的四个共同需求。我们为每个需求设计了一个线性量表问题，并要求参与者提供一个数字回答，以表示每个需求在7点likert量表中的重要性，从 "完全不重要"到 "非常重要"。后续部分询问参与者他们的联系信息以及他们是否愿意参加后续调查。

参与人员。我们通过三种方式征集了调查参与者。首先，我们向受访者所在的自动驾驶公司发出了调查问卷。其次，我们使用 Twitter 和 LinkedIn 提供的 API 来抓取个人资料中提到自动驾驶的开发人员的联系信息（如果有的话）。最后，我们在Github上搜索了流行的自动驾驶软件存储库，如Apollo和DeepDrive。然后，我们手工识别了那些对这些资源库做出贡献的开发者的公共电子邮件地址（如果有的话）。

我们总共发出了1978份调查问卷，收到114份回复，回复率为5%。我们丢弃了14份调查问卷，因为它们并不完整。最后，我们收集了100份完整的调查答复，用于数据分析。

90%的调查参与者是男性，8%是女性，2%没有透露他们的性别。其中54%的人在研究机构或大学工作，36%的人在技术公司工作，7%的人在传统的汽车制造厂工作，3%的人是自营职业。关于他们的工作角色，33%的参与者在研发岗位上，14%在管理岗位上，24%是工程师，包括安全工程师、软件工程师和感知工程师。其余的参与者是从事ADS的学术研究人员。40%的参与者有两到三年的ADS工作经验，29%的参与者在ADS行业工作了三年以上，31%的参与者有不到两年的经验。

分析报告。对于每个多选题，我们将调查参与者的选择绘制成柱状图，如图1。具体来说，如果调查参与者补充了一个在我们的访谈研究中没有发现的备选答案，我们首先检查它是否与现有的选择相似。如果没有，我们就把它视为一个独特的答案，并为它创建一个简短的描述性标签。然后，我们将所有具有相同标签的备选答案合并起来，并将它们的分布情况也绘制在直方图中。对于线性范围的问题，我们计算了每个选项的总数和百分比，并使用百分比来说明调查参与者对工业需求的重要性的评估，如图4所示。对于开放式问题，前两位作者使用MAXQDA对每个答案进行单独编码，并根据本调查设计中的各个部分对这些答案进行分类，并相互讨论以完善编码和分类。

工业实践

本节总结了访谈和调查的结果。第IV-A节讨论了在工业界测试的自动驾驶系统的类型。第四节B、第四节C和第四节D分别讨论了三种常用的ADS测试方法--单元测试、真实世界测试和模拟测试。我们没有单独介绍访谈研究和调查的结果，主要有两个原因。首先，由于调查的目的是确认和补充访谈的定性研究结果，所以访谈研究和调查研究的结果有很多重叠之处。因此，如果我们分别报告这些调查结果，就会有很多冗余。其次，融合定量证据（如大规模调查的统计数据）和定性证据（如访谈参与者的语录），更便于读者阅读和理解调查结果。

A. 测试中的自动驾驶系统

工业中部署和测试的 ADS 主要有两种类型：多模块驾驶系统和端到端驾驶模型。

多模块驾驶系统。大多数受访者 (100%) 和调查参与者 (69%) 开发和测试了多模块驾驶系统。多模块架构被广泛用于工业规模的驾驶系统，例如Autoware和Apollo。它们包含感知、预测、规划和控制的几个模块。感知模块以道路图像、云点、GPS信号等多种传感器数据作为输入，对周围物体进行检测。预测模块预测这些周围物体的移动轨迹。鉴于感知和预测的结果，规划模块然后决定自我车辆的路线。最后，控制模块将规划路线转换为车辆控制指令，包括制动力和转向角。感知和预测模块严重依赖深度神经网络，而规划和控制模块通常由传统的基于逻辑的程序组成。

端到端驾驶模型。虽然SE测试研究主要集中在测试端到端（E2E）驾驶模型，但只有31%的调查参与者开发和测试E2E驾驶模型。E2E驾驶模型将整个驾驶流程视为一个单一的学习模型，从接收来自传感器的输入数据到生成车辆控制。PilotNet和OpenPilot是E2E驾驶模型的例子。

在采访中，参与者指出端到端模型不太受欢迎，因为它们无法处理复杂的驾驶场景，并且经常遇到泛化性问题。例如，P7（参与者7）表示，“训练一个端到端的驾驶模型需要大量的数据。端到端的驾驶模型也很容易过拟合，性能比多模块系统差。”

B. 单元测试

根据采访和调查，单元测试在ADS测试中被广泛使用。52%的调查参与者进行了单元测试。

测试目标。与传统软件系统的单元测试侧重于测试程序功能不同，ADS的单元测试侧重于测试感知模型，这些模型通常是深度神经网络。与程序功能不同，这些感知模型没有明确定义的控制逻辑或程序状态。相反，它们内部有大量的参数。例如，一个著名的图像识别模型，VGG16，包含1.38亿个参数。在ADS中生成涵盖所有可能的程序状态和场景的测试案例是具有挑战性的。此外，这些模型的输入数据很丰富，包括各种传感器数据，如相机图像和由光探测测距（LiDAR）产生的点云。

虽然 SE 测试研究主要关注道路图像作为测试输入，但只有 8% 的调查参与者表示他们的 ADS 只是使用道路图像作为输入。相比之下，超过68%的调查参与者表示他们的驾驶系统至少使用了四种常见传感器中的三种，包括摄像头、LiDAR传感器、雷达和GPS。ADS中使用的多个传感器使生成测试案例更加困难。来自不同采样频率的不同传感器的数据需要被同步（例如，通过时间戳）。此外，在转换一种类型的传感器数据时，如增加一个对象，其他类型的传感器数据必须一致地更新。目前，还没有提出任何技术来实现对来自传感器的多模式输入数据的这种同步转换。

测试指标。在ADS的单元测试中，开发人员使用不同的测试指标，包括准确性、精确性、召回率、接收者操作特征（ROC）和交叉联合（IoU）。此外，超过一半的调查参与者（51%）表示他们使用了为相应任务量身定制的特定指标，例如对象检测的一致性率。采访研究中的P1(参与者1) 和P9（参与者9）进一步阐述了这一点——在从视频流中检测车道线时，前后帧之间的车道线检测结果应该是一致的。通用性（即一个模型是否能在未见过的驾驶场景中保持其性能）是工业从业者考虑的另一个重要指标。

C. 真实世界测试

另一种广泛使用的ADS测试方法是真实世界测试。在ADS被部署到现场之前，开发者需要进行广泛的实际测试，以评估其性能、稳健性、用户体验等。57%的调查参与者进行了真实世界的测试。在工业领域，主要有两种类型的真实世界测试：基于场景的测试和道路测试。

基于场景的测试。在基于场景的测试中，自动驾驶汽车根据真实世界的驾驶场景在封闭的自动驾驶汽车试验场进行测试。图1显示了我们调查中报告的在真实世界测试中的常见驾驶场景。

图 1：路测和仿真测试中分别测试的常见驾驶场景

图 2：测试驾驶场景的来源

它包括变道、跟随其他车辆、左转或右转等常见驾驶场景（68%），以及交叉路口和环岛等特殊路段（超过 55%）。雨天（44%）和雪天（32%）等天气也被考虑在内。最后，危险的驾驶场景，如紧急制动和碰撞，也分别由28%和21%的调查参与者进行测试。在访谈研究中，P8（参与者8）和P9（参与者9）解释道，设置这些驾驶场景和进行测试是很耗时的，往往需要2周到1个月的时间。

当被问及这些驾驶场景来自哪里时，参与者报告了各种来源，如图2所示。大多数参与者表示，这些驾驶场景是根据现实世界常见的驾驶场景和驾驶经验设计的。超过一半的参与者使用诸如 CityScapes、ApolloScape和 Waymo 开放数据集等公共基准来为驾驶场景设计提供信息。此外，还使用交通法规和交通事故报告。

图 3：实际测试中使用的系统级指标

道路测试。在道路测试中，自动驾驶汽车在公共道路上进行测试，其中可能会出现各种场景和意外情况。在道路测试中，ADS在没有人类干预的情况下行驶的公里数（即每次脱离的公里数）被用来衡量ADS的可靠性。公司需要进行长距离的道路测试，以确保其驾驶系统的可靠性。如加州机动车管理局提供的脱离报告所示，Waymo在2020年进行了超过100万公里的公路测试，其每次脱离的公里数为48K公里。在采访中，P8（参与者8）说：“整个公路测试需要5万至10万公里，其中必须包括不同的驾驶场景，如高速公路、乡村道路和城市道路。” P9（参与者9）提到，在公路测试期间，测试人员必须坐在车内记录驾驶数据，特别是对于需要人为干预的驾驶场景。所收集的数据将被保存在本地存储或上传到云平台。后来，这些数据将被清理和标记，用于模型训练和测试。

测试指标。与单元测试中使用的指标相比，实际测试中使用了更多的系统级指标。如图3所示，有四个系统级指标被调查者频繁提及，包括通用性（78%）、乘客的体验（63%）、稳健性（53%）和系统延迟（49%）。泛化性侧重于 ADS 是否可以在未见过的驾驶场景中实现类似的性能。乘客的体验是真实世界测试中的另一个重要指标。正如P4（参与者4）所说，“当驾驶场景中有许多车辆时，ADS不应过于频繁地按下刹车，这可能会影响到乘客的舒适程度。”

稳健性评估了当存在噪音、外部干扰或攻击时，ADS是否能正常运行。由于ADS被期望对驾驶场景的变化做出快速、连续的反应，因此通常使用系统延迟来衡量 ADS 的决策速度。

D. 仿真测试

87% 的调查参与者表示他们还在 Carla、AirSim和 LGSVL等模拟器上进行了仿真测试。仿真测试经常被用作道路测试的替代品。当被问及为什么仿真测试被广泛采用时，调查参与者提到两个主要原因。

首先，54% 的调查参与者表示，现代模拟环境足够强大，可以测试在现实世界中设置成本高昂的极端案例。此外，对于碰撞等危险驾驶场景，出于安全考虑，仿真测试比实际测试更受欢迎。如图1所示，更多的参与者在模拟环境中做碰撞测试，而不是在真实世界中测试。

其次，55%的调查参与者提到，模拟器可以重放从真实世界测试中收集的传感器数据和车辆控制指令，这可以用来测试新发布的ADS的性能。仿真测试是 ADS 开发中回归测试的重要组成部分。在开发ADS时，如果开发者在现实世界中对ADS的每一次提交都进行测试，那么成本和时间都很高，因为每一次提交都可能有数百个测试案例需要测试。利用仿真平台，工业从业者不需要在真实的车辆上部署ADS的每一项提交，也不需要构建真实世界的测试场景。根据对P9（参与者9）的采访，他只需要重复使用之前建立的模拟测试场景，并自动测试这些场景。

仿真测试中使用的测试指标与道路测试相似，包括基于准确性的指标、通用性、乘客的体验和稳健性。然而，由于仿真平台是基于一个没有硬件延迟的理想环境建立的，所以在仿真测试中没有考虑系统延迟。

图4：调查参与者投票选出的四种共同需求的重要性。

需求

本节总结了访谈和调查中发现的测试驾驶系统的四个常见需求。图4显示了参与者对这些需求的重要性的认同度。大多数参与者认为这四个需求都是重要或非常重要的。具体来说，分别有38%、35%、25%和 24%的参与者认为需求4、需求1、需求3和需求2非常重要。

A. 需求1：识别可能的拐角用例和意料之外的驾驶场景

如图4所示，35%调查参与者认为这一需求是非常重要的，28%的参与者认为该需求是重要的。虽然现代驾驶系统经过了各种各样驾驶场景和数千英里的道路测试，但在道路测试中仍经常发现新的角拐角案例。A正如P9所说，"在加州高速公路上的道路测试中，我们发现在夕阳下很难分辨出车道线。这是我们在执行基于场景的测试时没有预料到的问题。”

目前，行业实践中，要发现更多拐角用例，需要进行更长时间的道路测试。然而，这种方法既费时又费钱。除了Waymo和Cruise等大型汽车公司拥有的车队可以同时收集数十辆汽车的驾驶数据之外，小公司缺乏资金来建立如此庞大的车队并收集长途驾驶数据。因此，更有效地识别拐角用例是行业的迫切需求。

B. 需求2：加速ADS测试

如图4所示，分别有24%和24%的调查参与者认为需求2是非常重要和重要的。如IV-C节所述，公路测试是很耗费时间的。从图5可以看出，8%的参与者进行了超过100,000公里的道路测试，11%的参与者进行了10,000至50,000公里的道路测试。为了实现高可靠性，在行驶1 ~ 10小时的过程中，ADS的灾难性故障率应最小化到10−7到10−9。

图5：工业调查参与者进行的道路测试的长度

为了验证灾难性故障率不超过107小时一次, 必须进行至少107小时的道路测试。这意味着，100,000公里的道路测试仍不足以确保ADS的可靠性。

目前的实践是在模拟器上回放驾驶场景。CarSim等广泛使用的模拟器支持在回放时加速，这只需要现实世界中十分之一的时间，来模拟相应的驾驶场景。然而，考虑到测试ADS的可靠性需要耗费大量的时间(即107小时的驾驶测试)，因此进行模拟测试仍需较长时间。一如P2所说的，"我们最初的目标是做20,000公里的测试。后来我们发现，即使它把速度加快5倍，测试的速度仍然比我们预期的要慢。" 因此，模拟加速并不是解决这个问题的灵丹妙药。我们还需要其他加快测试速度的方法。在SE界，已经提出了许多测试选择和优先级的方法来加速传统的软件测试过程，这些方法在ADS测试中有很大的应用潜力。这将在第VI-D节中详细讨论。

C. 需要3:构建复杂驾驶场景的工具支持

如图4所示，25%调查参与者认为这一需求是非常重要，26%的参与者认为该需求是重要的。正如IV-C节所讨论的，行业从业者根据各种来源（如真实的驾驶场景和交通事故报告）来设计驾驶场景。在模拟测试中，行业从业者需要在模拟环境中构建这些驾驶场景。65%的调查参与者认为使用这些仿真环境提供的工具包（如DSL、库等）来构建驾驶场景非常繁琐。以OpenScenario为例，构建一个简单的超车驾驶场景需要258行代码，更不用说更复杂的场景了。主要原因是这些驾驶场景构建API和DSL的设计是低层次的，有许多可定制的参数来精确定义驾驶场景中的细节。虽然这确保了它们的灵活性和表达能力，可以精确地指明任意驾驶场景，但这也带来了大量的编码工作。因此，ADS开发者希望他们能得到更多的工具支持，帮助他们在模拟环境中自动或半自动地构建驾驶场景，比如将交通场景的自然语言描述翻译成模拟环境中提供的API编写的低级代码。

D. 需求4: 用于数据标注的工具支持

38%调查参与者认为这一需求非常重要，30%的参与者认为该需求是重要的。如IV-C节所述，在道路测试中收集的驾驶数据，如点云和道路图像，通常用作后续开发及测试的训练和测试数据。然而，这些驾驶数据在模拟环境中重新播放或重新用于训练和测试DL模型之前，需要首先进行数据标注。数据标注人员需要添加的两个典型标注是2D边界框和语义分割掩码。一个2D边界框标注包括检测到的物体的高度和宽度以及物体的类型。而一个语义分割掩码需要数据标注员在像素级别上手动分割所有物体。鉴于从道路测试中收集到的驾驶数据非常多，标注工作的工作量是很大的。虽然近年来出现了一些辅助性的标注工具，但标注驾驶数据仍然需要很多人工劳动。例如，Amazon SageMaker可以为物体检测和图像分割任务自动分配标注。但它需要数据标注人员手动查看这些标注并进行修正。我们采访过几家ADS公司，他们表示，他们经常将数据标注任务外包给数据标注公司，或者使用众包平台，如亚马逊Mechanic Turks等。然而，即使是人工标注的数据，标注质量仍然令人担忧，特别是对于像自动驾驶这样的安全关键任务。根据最近的一项研究，诸如如ImageNet等一些著名的数据集，都充斥着人工标注的错误。因此，ADS开发者希望得到更多的工具支持来分析、识别和修复驾驶数据中的标注错误。

文献审查和研究差距

前面的章节中，通过访谈和调查总结了行业从业人员在ADS测试中的四个迫切需求。为了了解软件工程界(SE界)的研究如何满足这些需求以及满足的程度，我们调查了SE会议和期刊上的研究论文，并研究了最先进的研究在多大程度上满足了每种需求。

A. 文献审查方法

我们调查了28个SE会议、期刊和研讨会的研究论文，包括ICSE、ESEC/FSE、ASE、ISSTA、ISSRE、ICST、QRS、TSE、JSS和IST。我们的目标是找到能为测试ADS的挑战和需求提出潜在解决方案的研究论文，正如我们在采访和调查中发现的那样。具体来说，我们使用了39个关键词，包括深度学习、神经网络、自动驾驶汽车和自动驾驶，来识别与自动驾驶以及更广泛的深度学习相关的研究论文。我们用了一个爬虫程序，从各出版商的网站上下载了这些论文，我们发现有575篇论文的标题或摘要中至少包含上述关键词中的一个。

我们根据其中36篇自主驾驶测试论文的研究问题和解决方案，进一步手动将其分为不同的类别和子类别，如表II所示。此外，我们将62篇深度学习测试论文分为三类--测试生成、测试选择和优先级，以及测试覆盖率度量。最后，我们仔细审查了这些文件，并评估了它们能在多大程度上满足第五节中确定的工业需求。

B. 文献分类

我们将ADS测试的论文分为三大类，如表II.所示。归属于测试标准的论文引入了测试覆盖度量，评估以评估ADS的性能和测试用例的质量。在测试用例生成方面，文献中采用了变形测试、模糊测试、基于搜索的测试等测试方法来生成ADS的测试场景。除此之外，现有工作中还进行了一些实证研究，以分析ADS的安全问题或评估不同测试方法和测试场景的有效性。

我们还总结了ADS测试论文的研究目标和实验环境。可以看出，在9个子类别中，有7个子类别的现有工作集中在E2E ADS测试上。对于实验环境，研究中同时考虑了真实世界的数据集和仿真环境。

C. 需求1的差距和未来方向

ADS中的拐角用例被认为是现实世界中罕见的安全关键驾驶场景，可能导致交通事故(如碰撞)。正如V-A节中所讨论的，在行业中寻找拐角用例的事实方法是进行长时间的道路测试。然而，这种方法既费时又费钱。

SE界已经研究了各种方法来生成ADS的拐角用例。其中一种常见的方法是基于搜索的测试。基于搜索的测试旨在在参数搜索空间中找到一组测试参数，以模拟最有可能引起碰撞的测试场景。搜索过程通常由人工定义的适应度函数来指导，比如碰撞时间和自我车辆与行人之间的最小距离。这种适应度函数的最佳解决方案通常是通过应用遗传算法来找到的。这些方法需要先验知识来定义一个适当的搜索空间和适应度函数。鉴于现实世界驾驶场景的多样性和复杂性，预先定义一个可操作的搜索空间比较难。寻找未知也是一种挑战。Wang等人探讨了如何使用信息物理系统的NLP技术从用例规范中挖掘新的需求和相应的形式约束。Gambi等人探讨了如何基于历史碰撞报告生成驾驶场景。作为一个未来的方向，值得研究的是如何从现有的碰撞报告、交通规则和新的道路驾驶记录中引出新的安全要求。这些要求可用于生成新的适应度函数，或者改进现有的适应度函数，从而为更关键的任务测试场景增加搜索空间。

另一种类型的拐角用例的生成是从现有的测试数据中探索对抗性空间，从而误导模型做出错误的预测。Wang等人使用一个新的对抗性成本函数对输入数据进行干扰，以生成容易发生碰撞的轨迹。该成本函数结合了轨迹成本、碰撞成本和安全成本，为多模块驾驶系统生成对抗性轨迹。然后通过修改现有的真实激光雷达扫描来实现这些不安全的轨迹，以生成可行的碰撞场景。同样地，Mouret等人提出了一种利用光照搜索来确定最佳特征图的方法。然后利用该特征图生成拐角用例，对车道保持辅助系统进行测试。这些方法要么需要先验知识来定义所需的评估指标（如转向角的标准偏差），要么只限用于单模式传感器（LiDAR）。未来的工作中，需要新的对抗性空间搜索算法，以允许探索具有多模式传感器输入数据的危险交通场景。另一种方法是使用几何感知的对抗性成本函数来生成拐角用例场景，这更适合基础传感器数据。

此外，基于覆盖率的方法在SE界中得到了广泛的探索。基于覆盖率的方法依赖于神经元覆盖率的概念及其变体。这些方法假定，具有较高神经元覆盖率的测试用例可以暴露出DNN模型的更多错误行为。DeepXplore使用了一种基于梯度的搜索方法，来寻找能使神经元覆盖率最大化并在多个DNN系统中引起不一致行为的输入。DeepTest使用神经元覆盖率来识别道路图像，这些道路图像使驾驶模型的错误行为最大化。Harel- Canada等人表明，较高的神经元覆盖率实际上导致了相对较少的缺陷检测和较少的自然输入。Deep- Road扩展了DeepTest，其使用GAN生成更自然的道路图像。然而，它需要在大量的训练数据的基础上进行训练，而且仅限于简单的因素转变，如将晴天改为雨天。SE界应该探索更先进的CV技术，如，以便更有效地生成复杂且真实的驾驶数据。此外，现有的工作主要针对的是单模态和简单的端到端驾驶系统。未来的工作中，需要进行更系统的基于覆盖面的研究，以便为多模块和多模态的ADS生产真实的驾驶场景。

D. 需求2的差距和未来方向

正如第V-B节中所说的，道路测试是一个很费时的事情。虽然仿真测试被用来作为一种替代方法，但行业从业者发现它仍然不足以满足真实测试的需求。对于加快ADS测试的这种需要，SE界可以提供的一个可行的方向是测试场景的选择和测试优先级的确定。

也就是说，SE研究人员能开发出一种技术，可以忽略驾驶数据中重复性的测试场景，并优先考虑更有可能暴露ADS错误的测试用例。例如，当在高速公路上行驶时，自我的车辆经常以恒定的速度在特定的车道上直行。因此，没有必要回放整段高速公路行车记录，而只需要回放记录中的独特驾驶场景，如超车。

目前，ADS测试中关于测试选择和测试优先级的讨论很少，而SE界在传统的软件测试中对这两种技术的研究相当多。在传统的软件测试中，测试选择的目的只是选择并重新运行受代码变更影响的测试用例，而测试优先级则是根据测试用例暴露失败的可能性来排序测试用例。传统的测试选择和测试优先级技术依赖于代码覆盖率或程序分析（例如，调用图分析，依赖性分析）来衡量代码变更的影响。然而，传统的代码覆盖率和程序分析技术并不能直接适用于DL模型。

近年来，有几种类型的度量被提出来，用于DL模型中的测试选择或优先排序。除了基于覆盖率的度量（在第VI-C节中讨论过），其他一些技术也提出了基于置信度的度量来指导DL模型中的测试选择和测试优先级。例如，在置信度上，DeepGini采用了Gini系数来衡量输入错误分类的可能性，并将具有高Gini分数的测试用例列为优先事项。在之前的工作中，基于置信度的度量被应用于分类任务，而ADS包含许多回归模型。PRIMA通过离散化回归模型的输出来处理回归模型，并将回归模型视为分类模型。然后，它进行了小规模的突变，并训练了一个基于学习的排序模型，以确定所选测试用例的优先次序。

另一测试度量是基于相似性的测试度量。这些技术使用最后一个隐藏层的输出来表示测试用例的分布，并选择彼此之间差异最大的测试用例。类似地，基于可能性的意外充分性（likelihood-based surprise adequacy，LSA）和基于距离的意外充分性（distance-based surprise adequacy，DSA）支持使用一组选定神经元的输出嵌入测试用例。LSA通过估计每个选定的测试用例的向量表示的密度来测量意外率，而DSA使用欧氏距离来计算测试用例从相同类别到其他类别的比率。

评估了基于图像的端到端驾驶模型的测试选择和约简方法的有效性，并报告了很有希望的结果。然而，ADSs通常包含多个模块，并采用丰富的传感器数据作为输入，而不是单一的端到端模型(章节IV-A)。现有的测试选择或测试优先级方法并没有考虑到ADS中的这种多模块架构。在未来的工作中，值得研究的是如何嵌入多种类型的传感器数据，用以分析驾驶场景的相似性并过滤掉重复的场景。例如，研究人员可以设计一个新的模型，嵌入不同类型的传感器数据。另一方面，研究人员也可以不直接嵌入传感器数据，而是利用动态高清地图，这是ADS中驾驶场景的中间表示。高清地图包含了感知模型的输出，然后被输入到下级的预测和控制模块中。它们可以作为驾驶场景的整体表示。

为了解释多模块体系结构，研究人员可能会想要研究如何结合内部模型行为的测试指标，如神经元覆盖和意外充分性，以及基于逻辑的测试指标（如路径覆盖），以捕获多个模型之间的交互，以及模型与基于逻辑的控制模块之间的交互。一种可能的解决方案是将其表述为一个多目标优化问题。一项技术应该要寻找最小的测试用例集，这些用例集可以最大限度地提高单个ML模型的覆盖率，以及ADS的路径或依赖性覆盖率。例如，一个繁忙的交通路口的驾驶场景与一个流量较小的高速公路场景相比，可能在模型和系统层面有更高的集体覆盖率，因为它涉及多种类型的对象（例如，行人、车辆和红绿灯），它可能触发ADS中的多个执行路径，也可能触发多个感知模型。考虑到大量可能的测试用例组合，如何利用多目标优化算法有效地搜索最优测试集，是一个值得研究的问题。

E. 需求3的差距和未来方向 

正如第IV-D节中提到的，行业从业者使用特定领域语言（DSL）来构建驾驶场景，并设计参与者在模拟器上的运动。然而，如同第V-C节中所讨论的，目前的DSL通常受到其可用性的限制：在这些DSL中定义场景和物体运动是很麻烦的，因为即使是建立简单的场景，也要花费开发者大量的精力（例如，数百行代码）。

为了减少测试构建的工作量，ADS开发者希望DSL能够灵活地表达驾驶场景的语义，而不必指明所有的场景细节。目前，智能汽车界设计了一些能实现这种目标的DSL。例如，Scenic，它是一种概率编程语言，使开发者只需几行代码就能生成复杂的交通拥堵场景。这些新设计的DSL更加凝练和灵活。然而，行业从业者很少使用它们。一个可能的原因是，这些语言要适应现有的模拟器，其成本非常高。ML中也存在这个问题。为了解决这个问题，ML从业者提出了一个开放标准，即开放式神经网络交换（Open Neural Network Exchange，ONNX），以帮助开发者在不同的框架和硬件上训练和部署模型。同样，对于ADS的开发和测试，创建一个共享的中间件可以将模拟器和DSL解耦，从而减少将新的DSL适应于现有模拟器的工作量。目前，OpenScenario作为驾驶场景的一个标准，已经被现有的模拟器广泛支持，包括CARLA、CarMaker、PreScan、Cognata和Foretify。在未来的工作中，研究人员可能会设计OpenScenario-适应性DSLs，它可以被各种模拟器支持。

此外，可以利用各种形式的信息来指导驾驶场景的构建，如碰撞报告、视频、自然语言和流程图。例如，通过分析碰撞报告，提出了AC3R来自动模拟碰撞场景。该方法利用NLP技术从碰撞报告中提取关键信息（如交通参与者和驾驶行为），将碰撞信息转化为Lua脚本来控制模拟交通参与者，并在模拟器中生成相应的碰撞场景。AC3R仅限于一些简单的碰撞场景，比如两辆车追尾。此外，由于事故报告通常遵循严格的叙述标准，AC3R可能很难将自由形式的驾驶场景描述翻译成可执行的驾驶场景。未来的工作中，需要研究NLP和CV的新技术，以支持从文本或视频数据中自动构建驾驶场景。

F. 需求4的差距和未来方向

目前，行业从业者需要手动收集、清理和标注原始传感器数据，以便培训和测试ADS。正如V-D部分所讨论的，他们希望为这个过程提供更多的工具支持。一般来说，数据收集、清理和标注是基于ai的应用程序开发过程中的关键步骤，这已经被SE社区公认为一个重要的研究领域。但在文献调查中，我们只发现了几篇与此方向相关的SE工作。还有更多的SE研究人员可以做出潜在的贡献。

SE研究人员可以开发自动化或半自动化的工具支持，以减少数据标注的工作量。可以应用测试选择和优先级技术来推荐哪些测试需要先被标注。在SE界中，Kim等人提出使用意外充分性来减少数据标注的工作量。其他领域，如数据库和计算机视觉领域，已经提出了一些监督或半监督的学习技术来自动生成数据标签。我们建议读者参考Roh等人对其他研究领域建立的数据收集和标注工具的详细调研。人机交互界也探索了如何通过众包为数据标注提供更好的支持。研究如何将这些来自不同界的技术协同起来，以实现更有效的数据标注，这将是一件有趣的事情。

此外，SE社区可以通过开发驾驶数据的输入验证或离群点检测技术来帮助数据清理。传统的数据清理方法依赖于用户提供一套特定的规则，来确定约束条件。这些规则很容易在表格数据或文本数据上定义。然而，对于涉及复杂驾驶场景的传感器数据，如视频和点云数据，定义这些规则具有挑战性。SE界已经提出了许多技术，来识别软件测试和调试中的故障诱发输入。例如，Gulzar等人利用数据出处来追踪大数据系统中的错误传播，并识别诱发故障的数据。研究如何调整或翻新这些技术，有利于识别导致ADS中异常驱动行为的低质量数据。

对有效性的威胁

我们按照Wohlin等人提出的标准讨论了对有效性的威胁。

外部有效性。外部有效性关注的是我们研究结果的可推广性。为了减少对外部有效性的威胁，我们尽可能地提高了调研对象的多样性。如第2.1节所示，这10位受访者来自10家不同的公司，承担着不同的职责。此外，为了扩大我们的研究规模，我们还发出了100份问卷调查，这些受访者处于不同的位置，来自不同类型的公司和组织，如第2.2节所示。此外，这些受访者和问卷调查者所开发和测试的ADS从级别 1到5级，涵盖了行业ADS的所有级别。因此，本研究中的受访者和问卷调查者可以代表ADS测试的行业从业者。

构造有效性。构造有效性关注的是我们的访谈和调查问卷的设计。为了减轻这种威胁，对于采访，我们首先进行了两次试点访谈。根据这两次试点访谈的反馈，我们完善了访谈指南和访谈问题。另外，为了在访谈过程中不偏颇参与者的回答，我们进行了半结构化的访谈，并提出了开放式的问题，这使得在讨论过程中可以提出新的想法和问题。虽然调查问卷主要是选择题，但我们允许受访者填写其他答案。此外，调查中还增加了一些开放式的问题，供受访者补充调查中没有包括的问题和答案。

内部有效性。内部有效性关注的是参与者的回答能否准确地反映他们的真实需求，以及是否有其他复合因素可能会影响到结果。具体来说，由于受访者是来自科技公司的开发人员，出于保密的考虑，他们中的一些人可能不会忠实地透露他们团队的具体和最紧急的需求。在设计访谈时，我们尽力避免可能涉及技术细节或让他们感到不舒服的对话。此外，在每次访谈前，我们都与参与者分享访谈指南，并告知他们，我们的目标是征求高层次的反馈，而不是技术细节。为了避免主题分析步骤中的错误和偏差，第一和第二作者分别进行了这一步骤。然后，在Cohen’s Kappa中，两位作者不断调整提取结果，直到两位编码员之间的符合率达到0.85。同时，收集到的信息定期在整个研究小组中进行

文章转载自公众号：智能汽车开发者平台