本发明涉及根据专利权利要求1和11的前序部分的用于生成用于自主车辆的测试用例的方法和装置。
背景技术：
对于系统级的软件验证和确认，传统上指定系统的一组刺激和预期反应。直接从相应要求推断出该刺激和预期反应。这些要求的范围以及因此还有测试用例的范围，通常限制于一组有限的识别的应用实例。通常，测试用例由测试工程师使用软件测试工具来指定。这种工具可以包含用于协助测试自动化以及用于提高测试成熟度(版本管理、任务跟踪器、图形测试规范等)的功能。
还有用于软件实施没有侵犯特定规则的更系统的检查的正式验证方法。
在系统级用于自主车辆的软件的测试带来新的挑战，即属于这种系统的该组应用实例几乎是无限的。实际上，系统因此必须能够处理任何驾驶员在其一生中可能面对的大多数驾驶状况。不同的驾驶员面对不同类型的应用实例，取决于大量的环境因素(其他道路使用者、一天中的时间、天气、健康、车辆磨损、道路状况等)。这些因此似乎是极多的测试组合。
用于自主车辆的虚拟测试环境是已知的。例如，期刊“机电一体化”，atz01/2008，卷110，页2-8中的出版物“车辆在回路中”，描述了用于驾驶员辅助系统的测试和仿真环境，不在公共道路交通中移动而是在自由表面或测试区域上移动的真实的试验车辆在该测试和仿真环境中与驾驶模拟器结合。用被称为“车辆在回路中”的这种测试设置，在没有风险的情况下测试驾驶员辅助功能如何对虚拟驾驶环境中的其他虚拟交通或其他虚拟物体作出反应是可能的。
simul2014，isbn9781612083711，页14-17的“朝向作为关键情况的自主车辆的混合实际/虚拟仿真”，描述了特别在虚拟传感器和真实的车辆作为“仿真回路中的硬件”的情况下，作为关键情况的自主车辆的混合实际/虚拟仿真。
然而，仍然有对改进的工具和方法的需要，其可以更有效地生成用于自主车辆的测试用例。
技术实现要素：
本发明的目的是在系统级允许用于自主车辆的测试用例的自动生成，以及特别是在系统级辅助工程师识别必要的所有测试以便验证自主车辆的运转。
该目的是通过具有专利权利要求1和11的特征的方法和装置来实现。
在从属权利要求中规定本发明的有利改进。
根据本发明的方法使用多达3种类型的输入变量：驾驶员的真实驾驶员体验(海量数据)；为自主车辆限定的应用实例；以及安全和可靠性过程可能所需的特殊应用实例。
生成的测试用例可以是占位符，即系统以旨在要测试的高级编程语言生成测试用例标题和简要说明。特别地，测试用例可以直接是以高级编程语言的说明和正式测试指令，其可以由机器解释。
通过在系统级为合适的测试用例的有效识别提供自动化平台，因此对正在开发的用于自主车辆的软件测试的新的挑战作出反应是可能的。
根据本发明的方法是基于作为输入变量的至少一个来自真实的驾驶员体验的数据源的分析，并且最好是作为另外的输入变量的预定义的系统应用实例以及安全和可靠性相关的系统应用实例。
真实的驾驶员体验是收集的现实世界中经过相对长的一段时间车辆车队中的许多车辆的驾驶员的体验。驾驶员是所有那些例如驾驶特定品牌或特定类型的车辆的驾驶员。收集例如can总线数据、传感器数据、车辆通信数据等这样的海量数据。分析并分类所有这些数据以便识别驾驶状况并且编译驾驶状况连同其频率的集合。驾驶状况可以通过不同的方法分类。例如目录可以给出什么类型的状况是相关的这样的粗略指示，例如静止、加速、紧急制动、启动发动机等。可选地，分类算法可以在例如车辆速度、发动机速度、踏板使用等这样的不同特征方面编译驾驶状况组。
根据以这种方式识别的驾驶状况，生成测试用例，该测试用例在此也被称为来自现实世界的测试用例。也可以分析导致特定驾驶状况的各种步骤和驾驶员的平均反应。这种信息然后形成测试用例的生成的步骤和验收标准的基础。可以识别的代表性测试用例的一个示例是车辆在交通信号灯处的平缓减速和停止。在海量数据和预测分析的帮助下，通常可以执行驾驶状况的识别和测试用例的生成。
在基于模型的系统开发中，限定代表车辆、驾驶员和环境之间的相互作用的系统应用实例是一般做法。可以以文本形式或通过例如统一建模语言(uml)或系统建模(sysml)这样的建模语言来描述这种应用实例。实际上，应用实例可以非常简单地被认为是测试用例。然而，在目前的情况下，比较分析优选地在基于测试用例的应用实例和通过来自现实世界的数据的分析识别的应用实例之间执行，并且当检测到可比较实例时，这些合并以形成一个实例。在这种情况下，在群论中也可以表示为合并操作符的这种合并可以根据各种惯例执行。例如，优选权可以赋予“理论”实例，即从预定义的应用实例或安全且可靠相关的应用实例获得的实例，并且可以删除相同类型的“现实世界实例”。
然而，将来自两种实例类型的方面纳入考虑以用于合并也是可想得到的。预定义的应用实例可以例如用作实例定义的框架并且以便从“现实世界实例”补充细节，例如实际测量的速度曲线。
同样必须保持专用于例如iso26262这样的安全过程的特殊应用实例，或例如故障模式与效应分析(fmea)这样的可靠性过程。如果安全/可靠性测试用例已经被来自现实世界的一些测试用例覆盖，那么它们可以相应地在方法中标记，因为这种测试用例可能需要例如正式测试这样的其他测试方法。
附图说明
接下来是在附图的帮助下的示例性实施例的说明。其单个附图显示用于在系统级自动生成用于自主车辆的测试用例的系统的概述。
具体实施方式
参考附图，在包含中央数据库的框1中，连续地收集从现实世界中的真实车辆——特别是不需要自主或自主地控制但可以由人类驾驶员控制的参与正常的公共道路交通的车辆——获取的数据。
在框2中，限定用于自主车辆或用于这种类型的特定车辆类型的系统应用实例。
在框3中，安全和可靠性相关系统应用实例限定用于自主车辆或用于这种类型的特定车辆类型。
在框4中，在收集的海量数据的帮助下，执行预测分析以便识别来自现实世界的代表性测试用例。为了这个目的，例如，使用典型驾驶状况的目录引用到其中的模式识别算法是可能的，输入系统应用实例和/或安全且可靠性相关的系统应用实例。
在框6中，执行比较分析以便将在框5中获取的来自现实世界的测试用例与在框2中获取的基于应用实例的测试用例相比较，“副本”在预定规则的帮助下合并以形成单个测试用例。为了这个目的，可以指定优先规则(例如，优先于基于应用实例的测试用例或来自现实世界的测试用例)，或可以组合来自两个实例的特定数据。这个步骤合并了框2和5的内容以便编译扩展组的测试用例。
在框7中，执行比较分析以便将在框6中获取的扩张组的测试用例与在框3中获取的安全和可靠性相关的系统应用实例相比较。再次，副本可以根据预定的规则合并以便形成数据集。这个步骤合并框6和3的内容并且传送用于自主车辆的一组更完整的测试用例。
可选择地，根据在框1中获取的来自真实世界的数据，在框8中生成关于各个测试用例的测试步骤指令和验收。
框9表示中央测试计划系统。该测试计划系统可以由用于项目生命周期管理和/或应用生命周期管理的工具控制，以便生成并且询问适合于自主车辆的测试用例。中央测试计划系统可以配备有用于持续整合的规则以便定期地更新来自现实世界的测试用例，也就是通过框4的定期启动。这使自动生成新的测试用例成为可能，该新的测试用例仅非常少地发生或仅可以在非常特殊的情况下被识别。
框10表示在框9中获取的用于自主车辆的一组完整测试用例，其可以由测试工程师用于测试文件和/或用于执行测试，或者手动或者自动。
上面描述用于在系统级自动地生成用于自主车辆的测试用例的系统的工作原理现在将要在参考附图的单个示例的帮助下更详细地解释。
在这个示例中，测试工程师旨在当需要这样时以其软件可以在城市交通中使车辆减速至停车的方式配置自主车辆的测试。这可以在大量可能的情况下发生。为了这个任务，测试工程师愿意发现哪种测试场景要被限定以便实现一组代表性的测试用例。
测试工程师已经在框2中预定义下面的测试场景并且将其输入到框9中：
-测试当接近静止车辆或车辆的固定线时使车辆减速至停止
-测试当接近人行横道同时行人正穿过道路时使车辆减速至停止
-测试当接近停车标志时使车辆减速至停止
通过框1，包含现实世界中车辆的旅程的记录的中央数据库是可用的，这已经做了几年了。关于各种车辆类型、各种车辆环境等的数据是可用的。可以指出的是，数据没有必要从自主车辆记录，但可能已经从人类驾驶员控制的传统车辆记录。虽然在这里假定当测试工程师希望询问它时它具有冻结且代表性的内容，但这个数据库不断地扩大并且不断地记录数据。
测试工程师在中央测试计划系统中将询问指定到中央数据(框9)。他希望获得现实世界中关于驾驶状况“在城市交通中减速至停止”的测试用例。测试计划系统分析数据库中存在的数据，同时使用框4中的特殊分析算法以便分类数据，并且如下传送框5中的一列识别的测试用例，各自频率以百分比指示：
a)车辆由于识别的障碍物而减速至停止(至静止障碍物的距离小于阈值)：30％
b)车辆由于红色交通灯而减速至停止：30％
c)车辆由于停车标志而减速至停止：10％
d)车辆由于行人而减速至停止(假设自动行人识别是可能的)：10％
e)车辆由于接近气泵而减速至停止：8％
f)当被警官询问时车辆减速至停止：5％
g)车辆在接近具有关闭的栅栏的道路交叉口时减速至停止：4％
h)车辆在驾驶到汽车餐厅等时减速至停止：3％
在接下来的步骤中，在框6中执行比较分析，即来自现实世界的测试用例(框5)和在框2中由测试工程师限定的基于应用实例的测试用例之间的映射。在上述示例中，测试用例a)至d)映射到由测试工程师限定的测试用例上。根据现实世界的数据，测试用例e)至h)在从框9到框6的比较分析的结尾已经被识别为附加测试场景。
此后，测试工程师具有根据来自现实世界的数据生成测试步骤指令(框8)的可能性，即改进测试场景。在测试工程师限定的测试用例中的一个与来自现实世界的测试用例相交的情况下，测试工程师限定的测试用例可以通过使用来自现实世界的测试场景来改进。例如，可以增加新的测试步骤、新的步骤序列、新的可选事件流等。
在过程的末尾，测试工程师最后获得一组车辆测试场景(框10)，其由测试工程师限定的测试用例(框2)并且由来自现实世界的附加测试场景(框6)形成。测试工程师现在可以用一组代表性且更现实的测试来测试用于自主车辆的要测试的软件。框10中获取的测试用例或者可以是以高级编程语言的说明或者可以是动作和反应的详细序列，取决于需求。