对软件系统的模糊测试的制作方法

本发明涉及对软件系统进行模糊测试的方法，以及用于执行此类方法的系统和计算机程序。

背景技术：

1、软件系统的测试是软件开发和部署的重要部分。构成软件系统的代码/指令的绝对数量(sheer volume)意味着在为软件系统编写代码时很可能(通常是意外地)引入“故障”(例如缺陷(bug)、错误、安全弱点或其他成问题的问题)。如果不执行软件系统的测试，此类故障将在部署后残留在软件系统中并可能随后在软件系统的执行期间引起问题。此类问题可能相对无害或不便；其他问题可能提供来自软件系统的意外/无意行为，包括软件系统的崩溃；其他问题可能更具灾难性，甚至可能导致生命损失(例如，如果软件系统正在控制涉及人/动物或与之交互的物理系统)。一些故障可能提供攻击向量(attack vector)，攻击者可以通过该向量执行一次或多次攻击，然后可能导致问题，诸如功能性丧失、向攻击者提供对功能性/数据的未授权访问等，所有这些都具有相应的后果成本和影响。

2、这里，“软件系统”可以被认为是完全/完整的软件系统(代码/指令)；然而，“软件系统”可以是更大的软件系统的子系统或部件。一般而言，软件系统包括多个“可调用(callable)单元”且被布置为接收软件系统的输入供处理。每个“可调用单元”可以是，例如，以下内容中的相应一个：例程；子例程；函数(function)；程序；过程；类方法；接口；部件；或更大系统的子系统；等。此处对特定类型的可调用单元的引用(例如，对“函数”或“部件”的引用)应被视为包括对其他类型的可调用单元的引用。

3、以下讨论将集中在是用于控制(至少部分地)车辆的操作的软件系统，诸如控制自主车辆驾驶的软件系统之类的“软件系统”。然而，应当理解，本文讨论的技术和问题更广泛地适用于其他类型的软件系统，并且本文的描述不应被认为仅限于用于控制(至少部分地)车辆的操作的软件系统.

4、车辆工业正面临着众多安全挑战。保护驾驶员不再局限于为车辆配备安全带和安全气囊，而是扩展到实施适当的安全性和安全措施，保护车辆免受恶意网络攻击。技术和网络连接性的快速发展改变了车辆的形状。现代汽车不仅仅是完全由人类控制和完全驾驶的机械设备。它们是互联自主车辆(cav)，其将基础设施和计算机处理与先进的无线通信相结合，以做出决策并为驾驶员和乘客提供更安全以及更有娱乐性的体验。

5、虽然原始设备制造商(oem)之间在自主驾驶和驾驶员辅助方面的竞争仍在继续，但攻击者控制车辆的机会增加了[1]。软件集成和连接性使车辆能够成为智能设备。然而，这为吸引恶意行为的软件缺陷和隐患(vulnerability)打开了窗口。事实上，与完全手动、断开连接的车辆或完全自主的车辆相比，具有人类驾驶员和自主驾驶或驾驶员辅助特征两者的车辆由于最大化的攻击表面而构成最大的风险。因特网暴露引入过多的隐患并促进了攻击者的工作。黑客在车辆领域的威胁不限于仅利用个人数据的破坏；他们可以通过更改车辆软件系统来放大风险。目前存在针对不同汽车制造商发起的有记录的车辆攻击[2]。因此，oem正在努力加强其安全措施，以增加车辆对网络攻击的抵御能力。

6、由于现代车辆开发依赖于软件，因此确保开发生命周期的安全是为消费者提供更好体验的重要任务。不同标准，比如汽车开放系统架构(autosar)[3]、j3061[4]和iso26262[5]，强调了在车辆软件工程(vse)[6]的所有阶段部署安全措施的重要性。由于开发安全车辆软件系统的需求比以往更高，国际标准化组织(iso)[7]正在与汽车工程师协会(sae)[8]合作设计标准，iso/sae 21434[9]，其专门针对安全开发。该标准旨在帮助oem解决整个车辆工程生命周期期间的网络安全问题。

7、在车辆发布之前，安全工程师需要验证系统的安全性以避免灾难性事故。车辆工业中缺乏质量保证和测试程序是导致隐患存在的主要因素之一[10]。清楚的是，安全测试是vse中标识隐患和系统弱点的关键阶段。车辆工业中使用不同的安全保证方法，包括静态代码分析、动态代码分析、以及隐患扫描、渗透测试和模糊测试[11]。这些安全测试技术可以减少系统中的隐患[12]。

8、无论如何，车辆软件系统的安全测试是复杂的任务，给oem带来了多重挑战[6]。车辆软件系统是复杂的系统，其具有在数十个电子控制单元(ecu)上驻留和运行的大约一亿行代码[13]。这些ecu可以基于来自雷达、激光雷达、照相机、超声传感器、温度传感器、轮胎压力传感器和许多其他传感器的输入进行操作。随着车辆在不断演进的环境中操作，ecu的输入可以发生巨大变化。因此，很难或不可能预测ecu的所有可能输入组合。

9、一些研究人员[10]、[14]-[17]认为模糊测试是发现车辆软件系统中的隐患的最合适的工具之一。然而，只有少数作品介绍了明确为车辆工业设计的模糊测试工具[10]、[15]、[16]、[18]。该领域中的研究努力限于评估和研究cav的黑盒模糊测试的适用性[19]、[20]。然而，对安全关键系统采用这种测试方法并不是可靠的解决方案。黑盒随机模糊测试无法提供测试了哪些部件的完整图片。为此，车辆工业需要一种软件安全测试解决方案，其可以促进测试过程、模拟车辆的环境并针对隐患。

10、安全测试是一种检测和标识系统的隐患的强大机制。在像车辆软件系统这样的关键系统中，软件测试可以防止危及生命的事故。然而，许多挑战使安全测试成为车辆工业中的复杂任务。下面列出了这些挑战中的一些。

11、·系统复杂性和大小

12、车辆软件系统包括异构功能性，如安全相关功能性、基础设施软件和多媒体系统[6]、[21]。cav必须执行的大量操作增加了源代码行(sloc)和所需的硬件设备。车辆软件系统被认为是最大现有系统之一[22]、[23]。安全工程师需要保证稳定的系统操作，但由于系统的大小相对大，所以这项工作是耗时的工作。使安全工程师的工作甚至更具挑战性的是系统的复杂性。车辆软件系统的异构功能采用了各种进步和技术，如传感器、ecu、网络连接性、人工智能、数据分析以及很多其他事物。所有这些部件使系统成为复杂系统并有望无缝且正确地运转。研究表明，复杂代码对设计和开发具有挑战性，为隐患和安全问题留下高余地(margin)[24]-[27]。安全工程师不得不管理代码复杂性和大小以验证安全性并确保系统在其整个操作生命周期期间不达到危险状态。

13、·外包

14、嵌入车辆软件系统内的异构功能性的开发需要不同的专业知识和技能。因此，oem倾向于外包大量车辆功能性[28]。虽然这可能改进产品质量，但外包使安全工程师的工作更加复杂。第三方开发的软件可以向系统引入新的威胁和隐患[29]。由于分层且有时复杂的供应链，这甚至变得更加困难。安全工程师必须在不知道其底层开发细节或完整出处(provenance)的情况下处理应用并证明其安全性和可靠性。此外，安全测试和系统故障率应该应用于整个系统。由于车辆软件系统中的许多功能性相互依赖，所以这个过程可能被延迟，直到所有部件都完全集成，从而显着减少可用的测试和分析时间。

15、·输入和输出波动

16、cav基于周围环境做出合理的决定以将乘客安全地运送到特定的目的地。它们可能利用设备，诸如传感器、雷达、激光雷达和照相机中的一个或多个，以收集所需信息来了解道路状况、天气状况和周围交通[30]。评估所有可能的外部环境数据的集合是棘手的问题。因此，测试和验证车辆软件系统的行为是具有挑战性的任务。除了外部数据，ecu还交换内部数据以触发特定事件。例如，动力总成(powertrain)控制模块(pcm)控制推进车辆所需的燃料消耗。pcm依靠不同的输入来确定正确的混合比，包括引擎温度、空气温度和节气门位置。在现代车辆中，pcm还从自适应巡航控制(acc)ecu接收内部信息以控制速度。安全工程师必须验证系统的灾难性故障率是否落在可接受的范围内，这需要数小时的密集测试，其应该涵盖大量可能性[31]。

17、·试验台(test-bed)复杂性

18、测试条件显著影响结果的准确性。系统的安全保证和验证应该在与真实世界场景相同的条件下进行。考虑到车辆软件系统的结构和复杂架构，模拟真实环境成为昂贵且耗时的工作[30]。车辆在各种不同的场景中操作，包括不同的道路、速度、能见度、密度、通信模式和驾驶员。模仿一种场景可能不足以确保安全和可靠系统。许多工业解决方案为oem提供软件在环中(sil)和硬件在环中(hil)测试模拟器，其模仿真实环境以评估车辆软件系统[33]-[36]。然而，一些限制阻碍了模拟器成为能够取代自主车辆的真实世界测试的完整解决方案。模拟器容易出错并且可能无法全面模拟真实世界场景[37]、[38]。

19、应当理解，上述挑战以及可能的其他挑战也同样适用于或类似地适用于具有其他用途的软件系统(即，不仅适用于车辆的软件系统)。

20、安全和可靠是车辆工业中强相关的学科。车辆软件系统中的任何安全漏洞(loophole)都可能对车辆的安全具有巨大影响，这使得网络安全保障成为vse中不可或缺的工作。在安全验证和验证阶段期间，安全工程师必须保证车辆系统被开发和设计符合如autosar、iso 26262和即将推出的iso/sae 21434标准之类的车辆标准的网络安全要求。这包括规划、报告以及最重要的一系列安全测试，以验证车辆软件系统的保护机制。由于车载系统融合了各种进步，包括不同的通信方式和硬件设备，确保了系统贯穿其生命周期的安全性需要采用若干安全测试技术。一些测试技术自动并入开发过程中以迅速标识潜在的弱点，而其他技术则需要人工干预并在开发阶段后运行[11]。车辆工业中利用的最常用的安全保证方法中的一些是：模糊测试、渗透测试、静态代码分析和隐患扫描。这些将在下面更详细地讨论：

21、·静态代码分析

22、除很多其他事物之外iso 26262[5]推荐的静态代码分析是一种白盒测试方法，其动态且自动地分析车辆系统的源代码，以标识导致系统脆弱编程错误[39]。imparato等人[40]检查现有静态分析工具在标识汽车软件部件中的漏洞方面的潜力。他们的研究表明，bug finder[41]和polyspace code prover[42]仅标识出几个不符合安全和可靠标准的代码部分，即使这些工具在其他系统中具有高性能。quality accelerated(qa)[43]工具在识别不符合汽车工业软件可靠性协会[44]开发的misra编码标准的软件缺陷方面表现更好。keul[45]强调了在汽车软件部件的多线程部件中标识竞争条件的重要性一一作者提出了一种静态竞争条件代码分析器并展示了它在检测导致安全关键系统进入危险状态的严重缺陷方面的潜力。

23、静态代码分析工具可以在开发阶段期间快速运行，以标识削弱系统的各种代码缺陷。它们通常被认为是值得的，尤其是在misra合规性方面。然而，这些扫描器(scanner)的能力有限。它们有高的假阳性警告，可以浪费安全测试人员的时间[46]。静态代码分析器无法发现其原因未在源代码中得到很好理解和建模的隐患(例如，未经检查的输入和边界)，并且因此需要额外的工具。

24、·动态程序分析

25、动态程序分析检查和监视程序执行以发现程序反应并确定不正确的行为。它涵盖了所有典型的软件测试形式，包括单元、部件、集成和系统测试。从安全的观点来看，它用于查找诸如存储器错误、并发错误和崩溃之类的危险条件。celik等人[47]激发程序分析技术来标识如汽车系统之类的物联网(iot)系统中的安全和隐私问题。在他们的研究中，研究人员展示了动态程序分析在发现不能利用如静态代码分析之类的其他技术标识的隐患方面的强大功能。koscher[48]强调了汽车系统中存在的隐患的严重性并强调了动态程序分析在快速且容易地标识汽车隐患方面的适用性。研究人员提出了一种动态分析工具，其近乎实时地模拟嵌入式ecu的输入和输出。cabodi等人[49]提出了一种用于汽车系统安全测试的动态程序分析工具，其监视和分析can消息路由和过滤以标识难以预测的行为。他们对网关ecu的案例研究显示了该工具在最小化工作量和标识异常反应方面的有效性。

26、虽然动态程序分析可以暴露静态代码分析无法触发的隐患，但它只能涵盖已知的软件问题。动态程序分析针对预定义的场景运行。因此，限制了测试范围。此外，这种安全测试保证方法可能无法执行所有系统部件，从而将隐患验证过程限制在仅某些代码区域。

27、·隐患扫描

28、隐患扫描验证车辆软件系统针对已知隐患和安全缝隙的弹性。换句话说，这种安全保证方法可以检测出不完全可追溯但具有相关攻击的开发错误。这种测试技术需要关于车辆工业中的攻击和安全的之前的知识。在2015年，行业内领先的先行者合作并且形成了汽车信息共享和分析中心(auto-isac)[50]以在全球范围内收集和分析车辆工业中的新兴的网络安全风险。auto-isac为oem提供有关超过30家汽车制造商的已标识隐患的信息，从而实现更快的隐患检测和共享责任。除了改进隐患扫描的工业力量外，研究人员还通过整合现有攻击为这一过程做出贡献。ring等人[51]构建了已发现隐患的数据库，以促进安全验证和验证阶段期间的访问。同样，sommer等人[52]检查和分类汽车安全攻击以丰富vse的安全测试阶段。毫无疑问，隐患扫描对于避免包括在渗透测试期间发现的攻击的重复攻击至关重要，并且也可以在开发周期中的非常早期应用。然而，这样的安全测试工具并不能对系统进行全面的评估。各方开发的系统都有隐患扫描无法识别的不同弱点。因此，扫描必须不断地针对每个特定系统进行定制，并且需要额外的测试工具。

29、·渗透测试

30、为了验证车辆软件系统对恶意行为的弹性，可以执行渗透测试。渗透测试是车辆工业中最多研究的测试技术[39]。koscher等人[53]通过进行若干种物理和远程攻击来试验车辆的安全性。通过模拟重放攻击，研究人员可以绕过车辆内的基本网络安全保护。cheah等人[54]采用渗透测试来评估车辆的蓝牙接口的安全性。

31、其他研究人员利用渗透测试来评估车载通信安全性。corbett等人[55]介绍了试图绕过车载网络入侵检测系统(nids)的测试框架。taylor等人[56]设计了适用于can总线的异常检测框架。研究人员研究以前的成功攻击以标识共同特性并模拟一系列新攻击。huang等人[57]通过提出一种自动将攻击包注入can总线的工具来验证can防御机制。

32、尽管研究人员通过进行渗透测试标识了车辆系统内部的若干安全漏洞，但是这种测试方法对于验证车辆网络安全性是最有效的。如果做得好，渗透测试产生最显著和有意义的结果，但也是最耗时、最不完整的，并且需要大量和罕见的专业知识。已知攻击的自动化始终是vse中功能渗透测试策略的重要方面。利用叠加的所有这些技术，可以很好地合理覆盖众所周知的问题和攻击的良好覆盖，以及最有可能和最重要的攻击。尽管如此，进行渗透测试以确保车辆软件系统的弹性是不够的。

33、·模糊测试

34、模糊测试是一种强健的测试技术，其针对任意输入来验证系统行为，以标识攻击者可用于发起攻击的意外行为[58]。另见https：//en.wikipedia.org/wiki/fuzzing(其全部公开内容通过引用其整体并入本文)。可以采用三种不同的测试方法：白盒、黑盒和灰盒模糊测试。

35、车辆工业中的研究人员专注于黑盒模糊测试并且避免采用白盒模糊测试。虽然白盒测试可以全面评估系统，但考虑到系统的复杂性和大小，在车辆工业中部署这样的机制是需要大量努力的耗时工作。此外，由于车辆软件系统的许多部件都是外包的，因此对所有部件应用白盒测试是不切实际的。

36、oka等人[19]将黑盒模糊测试视为发现车辆软件系统中的隐患的强大工具之一。他们通过对引擎ecu和网关ecu执行模糊测试来证明其效率。研究人员通过监视对模糊和随机消息的引擎ecu响应成功地标识出损坏的脉宽调制(pwm)频率。

37、在另一项研究工作中，oka等人[59]强调了验证和测试如车辆软件系统之类的复杂而广泛的系统的挑战。在系统完成后发起测试可能引起车辆生产的延迟。oka等人发现模糊允许测试在开发过程的较早期阶段开始。随机输入可以代替验证开发功能性所需的必要输入。

38、类似地，fowler等人[20]、[60]使用任意控制器局域网(can)模糊器(fuzzer)来标识ecu中的安全问题。他们在实验室车辆的显示ecu上执行黑盒模糊测试并展示模糊汽车输入以标识车辆软件系统中的缺陷和弱点的益处。

39、尽管具有管理系统的复杂性、外包以及输入和输出波动挑战的黑盒模糊测试的能力，但对安全关键系统进行盲测是有风险的。黑盒不能保证良好的覆盖和对系统的全面评估。此外，任意测试用例可能不通过初始输入验证要求，从而禁止测试扩展到系统的核心。在车辆工业中采用这种测试方法无法确保无风险的使用寿命。

40、·其他灰盒模糊测试技术

41、最近，灰盒模糊已成为一种流行的安全测试工具[61]。最著名的灰盒模糊测试技术是american fuzzy lop(afl)[62]。afl收集覆盖信息以标识有价值的测试用例，其扩展代码覆盖。引入了各种策略来增强afl的覆盖和性能[63]-[65]。

42、现有的灰盒模糊技术特别不适合诸如cav之类的系统及系统复杂性和大小的其关联的挑战。他们花费数小时进行测试，完全专注于扩展代码覆盖。

43、zhang等人[66]试图对afl生成的种子进行分级(rank)，但他们的测试用例优先化并没有指导特定方向上的测试。bohme等人[65]介绍了定向灰盒模糊测试(dgf)，它专注于测试用户指定的目标。该目标是通过消除远离目标的测试用例来实现的。他们计算系统节点之间的最小距离以标识相近的种子。最小距离形成了重要的限制，因为它消除了系统中可能存在缺陷的关键路径。dgf依赖于对脆弱区域的先验知识，这可以通过威胁和风险评估来指导，但不能是完整的。此外，在测试新开发的系统时，检查整个系统而不仅仅是特定的功能是必要的。

技术实现思路

1、本发明的实施例目的是解决软件测试和安全保证方面的上述不足。该目的是通过灰盒模糊测试框架实现的，该框架优化了隐患暴露过程，同时解决了安全测试挑战，诸如车辆工业面临的那些挑战。灰盒模糊测试是一种强健的安全机制，其在不增加测试复杂性的情况下积累关于系统的信息，使能快速和高效的安全测试。本发明的实施例提供了一种面向隐患的模糊测试框架，该框架可以针对软件系统(例如车辆软件系统)的薄弱部件系统地优先化测试。该框架利用被设计为标识软件系统中脆弱的部件的安全隐患度量并通过分配权重确保对这些部件的全面测试。此外，在一些实施例中，为了绕过一些系统的输入验证，本发明的一些实施例的变异引擎(mutation engine)可以在输入的高级设计处执行小数据类型变异。本发明的实施例可以在不增加测试复杂性的情况下有知识地验证系统的部件，提供一种安全测试工具，其有效和可靠地管理各种测试挑战。因此，它扩展了开发阶段期间的隐患标识，其可以增强软件系统抵御前所未有的网络攻击的弹性。

2、灰盒模糊测试提供了在不分析每行代码的情况下对软件系统的集中且高效的评估。与应用密集代码分析和约束解决的白盒测试不同，灰盒测试不导致高开销。同时，灰盒模糊在快速生成大量测试用例的同时克服了黑盒模糊随机性。因此，灰盒方法解决了三个测试挑战：通过避免密集的代码分析的系统的复杂性和大小，通过限制关于系统的知识的外包，以及通过创建大量输入的输入和输出波动。

3、根据本发明的第一方面，提供了一种用于执行软件系统的模糊测试的测试系统的方法，其中软件系统包括多个可调用单元并且被布置为接收用于软件系统的输入以处理，该方法包括：基于一个或多个安全隐患度量，为多个可调用单元中的每个可调用单元确定要测试可调用单元的目标次数；初始化分级的多个队列，每个队列用于存储一个或多个种子，所述初始化包括将一个或多个初始种子存储在分级的多个队列的相应队列中；执行测试的序列，其中执行每个测试包括：从最高分级的非空队列获得种子；对获得的种子执行变异过程以生成测试种子；提供测试种子作为软件系统的输入，供软件系统处理；并且评估软件系统对测试种子的处理以生成测试结果；其中分级的多个队列中的每个队列具有相关联的种子添加标准并且其中执行每个测试包括(a)将测试种子添加到测试种子满足与该队列相关联的种子添加标准的分级的多个队列中的最高分级队列；或(b)如果测试种子不满足与分级的多个队列中的任何队列相关联的种子添加标准，则丢弃测试种子；其中种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及感兴趣的可调用单元的执行或接近感兴趣的可调用单元的执行路径并且如果软件系统对第二测试种子的处理不涉及感兴趣的可调用单元的执行或接近感兴趣的可调用单元的执行路径，则添加第一测试种子的队列比添加第二测试种子的队列具有更高等级，其中可调用单元是感兴趣的可调用单元，如果导致了执行该可调用单元的测试的当前数量少于要测试该可调用单元的目标次数的话。

4、优选地，变异过程至少部分地由变异指导信息配置。

5、在第一方面的一些实施例中，变异指导信息被布置为配置变异过程，使得变异过程生成的测试种子不太可能是用于软件系统的无效输入。

6、在第一方面的一些实施例中，变异指导信息被布置成配置变异过程以增加软件系统对变异过程生成的测试种子的处理涉及感兴趣的可调用的单元的执行或接近感兴趣的可调用的单元的执行路径的可能性。

7、在第一方面的一些实施例中，变异指导信息指定由测试种子表示的量的值的范围，并且变异指导信息被布置为配置变异过程以(a)确保如由测试种子表示的所述量的值在值的所述范围内；或(b)确保如由测试种子表示的所述量的值在值的所述范围之外；或(c)将如由测试种子表示的所述量的值偏置于值的所述范围内；或(d)将如由测试种子表示的所述量的值偏置于值的所述范围之外。

8、在第一方面的一些实施例中，变异指导信息被布置为利用生成的测试种子表示的量的值的目标分布来配置变异过程。目标分布可以基于感兴趣的一个或多个可调用单元的算法特性。

9、在第一方面的一些实施例中，变异指导信息被布置为配置变异过程以针对至少一些生成的测试种子使用一个或多个预定值作为由那些测试种子表示的对应量的值。

10、在第一方面的一些实施例中，变异指导信息指定由测试种子表示的量的值的上述范围至少部分地基于由该测试种子或者由相应获得的种子表示的另一量的值来确定。

11、在第一方面的一些实施例中，变异指导信息指定由生成的测试种子表示的量的值的上述目标分布至少部分地基于由该测试种子或者由相应获得的种子表示的另一量的值来确定。

12、在第一方面的一些实施例中，变异指导信息被布置为配置变异过程以比实现对由获得的种子表示的至少一个其他量的值的改变更频繁地实现对由获得的种子表示的至少一个量的值的改变。实际上，变异指导信息可以被布置为配置变异过程以避免实现对由获得的种子表示的至少一个其他量中的一个或多个的值的改变。

13、在第一方面的一些实施例中，变异指导信息由测试系统的操作员提供和/或生成。

14、在第一方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及接近感兴趣的可调用单元的执行路径但不涉及感兴趣的可调用单元的执行，并且如果软件系统对第二测试种子的处理涉及感兴趣的可调用单元的执行，则添加第一测试种子的队列具有比添加第二测试种子的队列更高的等级。替代地，在第一方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及接近感兴趣的可调用单元的执行路径但不涉及感兴趣的可调用单元的执行并且如果软件系统对第二测试种子的处理涉及感兴趣的可调用单元的执行，则添加第一测试种子的队列具有比添加第二测试种子的队列更低的等级。

15、在第一方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及感兴趣的一个或多个第一可调用单元的执行或接近其的执行路径并且如果软件系统对第二测试种子的处理涉及感兴趣的一个或多个第二可调用单元的执行或接近其的执行路径，则如果：(a)感兴趣的一个或多个第一可调用单元中的至少一个具有大于要测试感兴趣的一个或多个第二可调用单元中的每个的剩余次数的要测试的剩余次数；或(b)要测试感兴趣的一个或多个第一可调用单元中的每个的剩余次数的和大于要测试感兴趣的一个或多个第二可调用单元中的每个的剩余次数的和，添加第一测试种子的队列具有比添加第二测试种子的队列更高的等级。

16、在第一方面的一些实施例中，用于第一队列的种子添加标准是软件系统对测试种子的处理涉及感兴趣的可调用单元的执行或接近其的执行路径。附加地或替代地，在第一方面的一些实施例中，用于第二队列的种子添加标准是软件系统对测试种子的处理到达在执行先前测试时尚未到达的软件系统中的分支点(branch point)。第一队列可以具有比第二队列更高的等级。分级的多个队列可以是包含第一队列和第二队列的集合。

17、在第一方面的一些实施例中，从最高分级的非空队列获得种子包括从最高分级的非空队列移除种子。

18、在第一方面的一些实施例中，方法包括针对测试种子确定对应的重新使用量，该重新使用量指示该种子可以用作获得的种子的未来测试的数量。针对测试种子确定对应的重新使用量可以包括：如果软件系统对测试种子的处理涉及感兴趣的可调用单元的执行，则将重新使用量设置为第一预定值；如果软件系统对测试种子的处理不涉及感兴趣的可调用单元的执行但涉及接近感兴趣的可调用单元的执行路径，则将重新使用量设置为第二预定值；如果软件系统对测试种子的处理不涉及感兴趣的可调用单元的执行或接近其的执行路径但到达了在执行先前测试时尚未到达的软件系统中的分支点，则将重新使用量设置为第三预定值。在一些这样的实施例中，(a)第一预定值大于第二预定值，并且第二预定值大于第三预定值；或者(b)第二预定值大于第一预定值，并且第一预定值大于第三预定值。附加地或替代地，方法可以包括，对于每个存储的种子，存储对应的重新使用量，其中从最高分级的非空队列获得种子包括递减对应于种子的重新使用量，并且或者(a)将种子保留在最高分级的非空队列中并且如果对应于种子的重新使用量是非零，并且(b)如果对应于种子的重新使用量是零，则从最高分级的非空队列移除种子。附加地或替代地，将测试种子添加到测试种子满足与该队列相关联的种子添加标准的分级的多个队列中的最高分级的队列可以包括将测试种子添加到测试种子满足与该队列相关联的种子添加标准的次数等于重新使用量的分级的多个队列中的最高分级的队列，其中从最高分级的非空队列获得种子然后可以包括从最高分级的非空队列移除种子。

19、在第一方面的一些实施例中，对获得的种子执行变异过程以生成测试种子包括使获得的种子变异以形成测试种子。

20、在第一方面的一些实施例中，对获得的种子执行变异过程以生成测试种子包括：(a)如果获得的种子是初始种子，则设置测试种子为获得的种子；并且(b)变异获得的种子来以其他方式形成测试种子。

21、在第一方面的一些实施例中，对于多个可调用单元中的每个可调用单元，当一个或多个安全隐患度量指示可调用单元的更高级别的安全隐患时，确定可调用单元要被测试的目标次数可以生成更高的目标数量。

22、在第一方面的一些实施例中，初始化分级的多个队列包括将一个或多个初始种子中的每个存储在最高分级的队列中。

23、在第一方面的一些实施例中，执行测试的序列直到满足终止条件，其中终止条件包括以下中的一个或多个：(a)分级的多个队列中的队列中的每个是空的；(b)已经执行了阈值数量的测试；以及(c)在执行测试的序列中已经花费了阈值时间量。

24、在第一方面的一些实施例中，如果第一可调用单元在软件系统的调用图中从最远的可调用单元可到达，则软件系统对测试种子的处理被认为涉及接近第一可调用单元的执行路径，其中最远可调用单元是不存在距离调用图中的根节点在调用图中更远的执行路径的其他可调用单元的执行路径的可调用单元，并且：(a)最远可调用单元和第一可调用单元之间的调用图中的可调用单元的数量至多是预定阈值；或者(b)最远可调用单元与根节点之间的调用图中的可调用单元的数量至少是预定阈值；或者(c)在最远可调用单元之上(above)的调用图中的代码的量至少是预定阈值；或者(d)在最远可调用单元之下的调用图中的代码的量至多是预定阈值；或者(e)最远可调用单元和第一可调用单元之间的调用图中的代码的量至多是预定阈值。

25、在第一方面的一些实施例中，方法包括基于从所执行的测试生成的结果来提供用于模糊测试的输出。

26、在第一方面的一些实施例中，软件系统是车辆的软件系统。

27、在第一方面的一些实施例中，每个可调用单元是以下中的相应一个：例程；子程序；函数；程序；过程；类方法；接口；部件；或更大系统的子系统。

28、在第一方面的一些实施例中，一个或多个安全隐患度量包括以下中的一个或多个：(a)表示可调用单元的安全关键性(criticality)和/或安全隐患的程度的度量；(b)表示恶意消息可以从一个可调用单元传递到另一个可调用单元的风险的度量；(c)基于可调用单元使用的通信技术的数量和/或类型的度量；(d)基于可调用单元的代码复杂性的水平的度量；(e)基于具有不同值的可调用函数的输入和输出参数的数量和/或可调用函数的输入和输出参数可以具有不同值的程度的度量；以及(f)基于与可调用单元相关的历史隐患数据的度量。

29、根据本发明的第二方面，提供了一种用于对软件系统进行模糊测试的测试系统，其中软件系统包括多个可调用单元并且被布置为接收用于软件系统的输入以处理，测试系统包括一个或多个处理器，其被布置成：基于一个或多个安全隐患度量，为多个可调用单元中的每个可调用单元确定要测试可调用单元的目标次数；初始化分级的多个队列，每个队列用于存储一个或多个种子，所述初始化包括将一个或多个初始种子存储在分级的多个队列的相应队列中；执行测试的序列，其中执行每个测试包括：从最高分级的非空队列获得种子；对获得的种子执行变异过程以生成测试种子；提供测试种子作为软件系统的输入，供软件系统处理；并且评估软件系统对测试种子的处理以生成测试结果；其中分级的多个队列中的每个队列具有相关联的种子添加标准并且其中执行每个测试包括(a)将测试种子添加到测试种子满足与该队列相关联的种子添加标准的分级的多个队列中的最高分级队列；或(b)如果测试种子不满足与分级的多个队列中的任何队列相关联的种子添加标准，则丢弃测试种子；其中种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及感兴趣的可调用单元的执行或接近感兴趣的可调用单元的执行路径并且如果软件系统对第二测试种子的处理不涉及感兴趣的可调用单元的执行或接近感兴趣的可调用单元的执行路径，则添加第一测试种子的队列比添加第二测试种子的队列具有更高等级，其中可调用单元是感兴趣的可调用单元，如果导致了执行该可调用单元的测试的当前数量少于要测试该可调用单元的目标次数的话。

30、优选地，变异过程至少部分地由变异指导信息配置。

31、在第二方面的一些实施例中，变异指导信息被布置为配置变异过程，使得变异过程生成的测试种子不太可能是软件系统的无效输入。

32、在第二方面的一些实施例中，变异指导信息被布置为配置变异过程以增加软件系统对由变异过程生成的测试种子的处理涉及感兴趣的可调用单元的执行或接近其的执行路径的可能性。

33、在第二方面的一些实施例中，变异指导信息指定由测试种子表示的量的值的范围，并且变异指导信息被布置为配置变异过程以(a)确保如由测试种子表示的所述量的值在值的所述范围内；或(b)确保如由测试种子表示的所述量的值在值的所述范围之外；或(c)将如由测试种子表示的所述量的值偏置于值的所述范围内；或(d)将如由测试种子表示的所述量的值偏置于值的所述范围之外。

34、在第二方面的一些实施例中，变异指导信息被布置为利用生成的测试种子表示的量的值的目标分布来配置变异过程。目标分布可以基于感兴趣的一个或多个可调用单元的算法特性。

35、在第二方面的一些实施例中，变异指导信息被布置为配置变异过程以针对至少一些生成的测试种子使用一个或多个预定值作为由那些测试种子表示的对应量的值。

36、在第二方面的一些实施例中，变异指导信息指定由测试种子表示的量的值的上述范围至少部分地基于由该测试种子或者由相应获得的种子表示的另一量的值来确定。

37、在第二方面的一些实施例中，变异指导信息指定由生成的测试种子表示的量的值的上述目标分布至少部分地基于由该测试种子或者由相应获得的种子表示的另一量的值来确定。

38、在第一第二方面的一些实施例中，变异指导信息被布置为配置变异过程以比实现对由获得的种子表示的至少一个其他量的值的改变更频繁地实现对由获得的种子表示的至少一个量的值的改变。实际上，变异指导信息可以被布置为配置变异过程以避免实现对由获得的种子表示的至少一个其他量中的一个或多个的值的改变。

39、在第二方面的一些实施例中，变异指导信息由测试系统的操作员提供和/或生成。

40、在第二方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及接近感兴趣的可调用单元的执行路径但不涉及感兴趣的可调用单元的执行，并且如果软件系统对第二测试种子的处理涉及感兴趣的可调用单元的执行，则添加第一测试种子的队列具有比添加第二测试种子的队列更高的等级。替代地，在第二方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及接近感兴趣的可调用单元的执行路径但不涉及感兴趣的可调用单元的执行并且如果软件系统对第二测试种子的处理涉及感兴趣的可调用单元的执行，则添加第一测试种子的队列具有比添加第二测试种子的队列更低的等级。

41、在第二方面的一些实施例中，种子添加标准被配置为使得如果软件系统对第一测试种子的处理涉及感兴趣的一个或多个第一可调用单元的执行或接近其的执行路径并且如果软件系统对第二测试种子的处理涉及感兴趣的一个或多个第二可调用单元的执行或接近其的执行路径，则如果：(a)感兴趣的一个或多个第一可调用单元中的至少一个具有大于要测试感兴趣的一个或多个第二可调用单元中的每个的剩余次数的要测试的剩余次数；或(b)要测试感兴趣的一个或多个第一可调用单元中的每个的剩余次数的和大于要测试感兴趣的一个或多个第二可调用单元中的每个的剩余次数的和，添加第一测试种子的队列具有比添加第二测试种子的队列更高的等级。

42、在第二方面的一些实施例中，用于第一队列的种子添加标准是软件系统对测试种子的处理涉及感兴趣的可调用单元的执行或接近其的执行路径。附加地或替代地，在第二方面的一些实施例中，用于第二队列的种子添加标准是软件系统对测试种子的处理到达在执行先前测试时尚未到达的软件系统中的分支点。第一队列可以具有比第二队列更高的等级。分级的多个队列可以是包含第一队列和第二队列的集合。

43、在第二方面的一些实施例中，从最高分级的非空队列获得种子包括从最高分级的非空队列移除种子。

44、在第二方面的一些实施例中，测试系统被布置为针对测试种子确定对应的重新使用量，该重新使用量指示该种子可以用作获得的种子的未来测试的数量。针对测试种子确定对应的重新使用量可以包括：如果软件系统对测试种子的处理涉及感兴趣的可调用单元的执行，则将重新使用量设置为第一预定值；如果软件系统对测试种子的处理不涉及感兴趣的可调用单元的执行但涉及接近感兴趣的可调用单元的执行路径，则将重新使用量设置为第二预定值；如果软件系统对测试种子的处理不涉及感兴趣的可调用单元的执行或接近其的执行路径但到达了在执行先前测试时尚未到达的软件系统中的分支点，则将重新使用量设置为第三预定值。在一些这样的实施例中，(a)第一预定值大于第二预定值，并且第二预定值大于第三预定值；或者(b)第二预定值大于第一预定值，并且第一预定值大于第三预定值。附加地或替代地，测试系统可以被布置对于每个存储的种子存储对应的重新使用量，其中从最高分级的非空队列获得种子包括递减对应于种子的重新使用量，并且或者(a)将种子保留在最高分级的非空队列中并且如果对应于种子的重新使用量是非零，并且(b)如果对应于种子的重新使用量是零，则从最高分级的非空队列移除种子。附加地或替代地，将测试种子添加到测试种子满足与该队列相关联的种子添加标准的分级的多个队列中的最高分级的队列可以包括将测试种子添加到测试种子满足与该队列相关联的种子添加标准的次数等于重新使用量的分级的多个队列中的最高分级的队列，并且从最高分级的非空队列获得种子然后可以包括从最高分级的非空队列移除种子。

45、在第二方面的一些实施例中，对获得的种子执行变异过程以生成测试种子包括使获得的种子变异以形成测试种子。

46、在第二方面的一些实施例中，对获得的种子执行变异过程以生成测试种子包括：(a)如果获得的种子是初始种子，则设置测试种子为获得的种子；并且(b)变异获得的种子来以其他方式形成测试种子。

47、在第二方面的一些实施例中，对于多个可调用单元中的每个可调用单元，当一个或多个安全隐患度量指示可调用单元的更高级别的安全隐患时，确定可调用单元要被测试的目标次数可以生成更高的目标数量。

48、在第二方面的一些实施例中，初始化分级的多个队列包括将一个或多个初始种子中的每个存储在最高分级的队列中。

49、在第二方面的一些实施例中，测试系统被布置为执行测试的序列直到满足终止条件，其中终止条件包括以下中的一个或多个：(a)分级的多个队列中的队列中的每个是空的；(b)已经执行了阈值数量的测试；以及(c)在执行测试的序列中已经花费了阈值时间量。

50、在第二方面的一些实施例中，如果第一可调用单元在软件系统的调用图中从最远的可调用单元可到达，则软件系统对测试种子的处理被认为涉及接近第一可调用单元的执行路径，其中最远可调用单元是不存在距离调用图中的根节点在调用图中更远的执行路径的其他可调用单元的执行路径的可调用单元，并且：(a)最远可调用单元和第一可调用单元之间的调用图中的可调用单元的数量至多是预定阈值；或者(b)最远可调用单元与根节点之间的调用图中的可调用单元的数量至少是预定阈值；或者(c)在最远可调用单元之上的调用图中的代码的量至少是预定阈值；或者(d)在最远可调用单元之下的调用图中的代码的量至多是预定阈值；或者(e)最远可调用单元和第一可调用单元之间的调用图中的代码的量至多是预定阈值。

51、在第二方面的一些实施例中，测试系统被布置为基于从所执行的测试生成的结果来提供用于模糊测试的输出

52、在第二方面的一些实施例中，软件系统是车辆的软件系统。

53、在第二方面的一些实施例中，每个可调用单元是以下中的相应一个：例程；子程序；函数；程序；过程；类方法；接口；部件；或更大系统的子系统。

54、在第二方面的一些实施例中，一个或多个安全隐患度量包括以下中的一个或多个：(a)表示可调用单元的安全关键性和/或安全隐患的程度的度量；(b)表示恶意消息可以从一个可调用单元传递到另一个可调用单元的风险的度量；(c)基于可调用单元使用的通信技术的数量和/或类型的度量；(d)基于可调用单元的代码的复杂性的水平的度量；(e)基于具有不同值的可调用函数的输入和输出参数的数量和/或可调用函数的输入和输出参数可以具有不同值的程度的度量；以及(f)基于与可调用单元相关的历史隐患数据的度量。

55、根据本发明的第三方面，提供了一种计算机程序，当由一个或多个处理器执行时，所述计算机程序使该一个或多个处理器执行根据上述第一方面或其实施例的方法。计算机程序可以存储在计算机可读介质上。