对模糊测试中的测试用例进行优化的方法,装置和系统

摘要

本发明提供一种对测试用例进行排序的方法，装置和系统。所述方法包括：执行以下步骤一轮或多轮：按照初始测试用例集合中多个测试用例的排列顺序，使用所述多个测试用例中的每个测试用例对测试对象进行测试，监视每个测试用例的攻击效果，并且根据相应于每个测试用例的攻击效果来确定每个测试用例的优先级；根据所确定的每个测试用例的优先级，对所述测试用例集合中的多个测试用例重新排序；其中，在当前轮次中得到的重新排序后的测试用例的集合能够作为在下一轮次的执行中使用的初始测试用例集合。

说明书

技术领域

本发明总体上涉及软件测试技术领域，更具体地涉及对模糊测试中使用 的测试用例进行优化。

背景技术

软件（包括应用程序、通信软件等）的安全性测试实际上是在软件输入 空间中的一种探测。软件的输入空间由该软件的所有可能的输入或所有可能 的输入的组合构成。穷举是验证软件行为正确性的一种最极端的方法，然而， 穷举对大部分案例来说不具备可操作性，因为通常情况下，软件程序的输入 空间非常巨大，甚至可能是无穷大。

相比于穷举的方法来说，模糊测试（Fuzz Testing）作为一种随机样本方 法，是一种更具可行性的黑盒测试方法。模糊测试通过以下方式来工作：自 动地为测试对象（即应用程序、通信软件等）提供随机的或半有效的输入（即 测试用例（Test Case）），以尝试触发故障指示以及使测试对象崩溃。这种程 序故障或错误可以指示存在安全脆弱性。作为一种黑盒测试方法，模糊测试 通常用于大型软件开发项目。目前，最常用的模糊测试是基于字符的，基于 字符的模糊测试提供随机数据流（从文件或其他数据流中提供，例如，从套 接字中提供）作为被测软件程序的输入。基于字符的模糊测试正广泛应用于 协议或网络服务的安全性测试。模糊测试被认为能够提高软件的安全性，这 是因为：模糊测试总是能检测出一些测试人员未能发现的漏洞（bug），这些 漏洞往往会被软件测试工程师所忽略。模糊测试的主要优势在于：进行测试 的成本相对较低，并且完全可以自动实现；此外，模糊测试经常能找出比较 严重的且可被利用的漏洞，这些漏洞可以被攻击者加以利用。

使用模糊测试的一个挑战是，如何利用有限的测试资源来选择能够有效 地检测漏洞的测试用例。有许多方法用来选择用于模糊测试的测试用例。一 个简单的方法叫作随机模糊测试（RFT），该方法随机地从输入域（即，所 有可能的输入的集合）中选择测试用例。RFT具有以下优点：成本低；能够 自动地生成大量测试用例；以及在无需软件规范和源代码的情况下生成测试 用例。除此以外，RFT将“随机性”引入测试过程。这种随机性能够最好地 反映系统运行环境的混乱。因此，RFT能够检测到通过确定性的方法所不能 暴露的某些漏洞。所有这些优点使得RFT在发现软件漏洞的行业中被广泛 的使用。

然而，在RFT中，并不尝试使用任何可用的信息来引导测试。由于现 在的软件至少具有基本的机制来检查输入的有效性，所以与合法输入显著不 同的过于特别的“模糊”数据将被容易地检测到并被丢弃。此外，在RFT 中，非常可能具有重复的测试用例，因为一些测试用例对于目标软件具有相 同的攻击效果。因此，RFT的主要缺点是效率差。

发明内容

根据本发明的一个方面，提供了一种用于对测试用例进行排序的方法， 包括：执行以下步骤一轮或多轮：按照初始测试用例集合中多个测试用例的 排列顺序，使用所述多个测试用例中的每个测试用例对测试对象进行测试， 监视每个测试用例的攻击效果，并且根据相应于每个测试用例的攻击效果来 确定每个测试用例的优先级；根据所确定的每个测试用例的优先级，对所述 测试用例集合中的多个测试用例重新排序；其中，在当前轮次中得到的重新 排序后的测试用例的集合能够作为在下一轮次的执行中使用的初始测试用 例集合。

进一步地，在所述方法中，所述一个或多个标准至少包括以下各项之一： 测试用例能够单独地导致测试对象发生故障，测试用例能够与其他测试用例 共同地导致测试对象发生故障，测试用例与能够单独地导致测试对象发生故 障的测试用例的类似度达到预定程度，以及测试用例导致测试对象响应延 迟。

进一步地，在所述方法中，通过优先级值来表示优先级，当测试用例的 攻击效果满足所述一个或多个标准时，在测试用例的当前优先级值上增加相 应的优先级值。

进一步地，在所述方法中，增加相应的优先级值包括：当一测试用例能 够单独地导致测试对象发生故障时，为该测试用例增加第一高的优先级值； 当一测试用例能够与其他测试用例共同地导致测试对象发生故障时，为该测 试用例增加第二高的优先级值；当一测试用例与能够单独地导致测试对象发 生故障的测试用例的类似度达到预定程度时，为该测试用例增加第三高的优 先级值；当一测试用例导致测试对象响应延迟时，为该测试用例增加第四高 的优先级值。

进一步地，在所述方法中，按照初始测试用例集合中多个测试用例的排 列顺序，使用所述多个测试用例中的每个测试用例对测试对象进行测试具体 为：按照初始测试用例集合中多个测试用例的排列顺序连续应用测试用例对 测试对象进行测试，直至应用一个测试用例后所述测试对象发生故障，则重 新所述启动测试对象并使用应用的最后一个所述测试用例重新测试该测试 对象，如果所述测试对象再次发生故障，则判断所述应用的最后一个测试用 例能够单独地导致测试对象发生故障，否则判断所述应用的最后一个测试用 例能够与其他测试用例共同地导致测试对象发生故障。

进一步地，在所述方法中，所述判断该测试用例能够与其他测试用例共 同地导致测试对象发生故障包括：（a）重新启动测试对象；（b）使用该测试 用例之前的j个测试用例以及该测试用例重新测试该测试对象；循环执行以 上步骤（a）和（b），直到测试对象发生故障为止，此时判断该测试用例以 及该测试用例之前的j个测试用例能够共同地导致测试对象发生故障，其中， j的初始值为1，并且每次循环后j的值加1。

进一步地，在所述方法中，在向测试对象应用测试用例后，如果没有接 收到测试对象的响应，则向测试对象发送正常输入，如果仍然没有接收到响 应，则判断测试对象发生故障；如果接收到相应，则根据响应时间来判断当 前测试用例是否导致响应延迟。

进一步地，在所述方法中，所述测试对象是通信软件。

根据本发明的另一个方面，提供了一种用于对测试用例进行排序的装 置，包括：故障监视模块，用于监视按照初始测试用例集合中多个测试用例 的排列顺序，使用所述多个测试用例中的每个测试用例对测试对象进行的测 试的攻击效果，并且根据相应于每个测试用例的攻击效果，来确定每个测试 用例的优先级；优化模块，用于根据所确定的每个测试用例的优先级，对所 述多个测试用例重新排序。

进一步地，在所述装置中，所述一个或多个标准至少包括以下各项之一： 测试用例能够单独地导致测试对象发生故障，测试用例能够与其他测试用例 共同地导致测试对象发生故障，测试用例与能够单独地导致测试对象发生故 障的测试用例的类似度达到预定程度，以及测试用例导致测试对象响应延 迟。

进一步地，在所述装置中，通过优先级值来表示优先级，当测试用例的 攻击效果满足所述一个或多个标准中的一个标准时，在测试用例的当前优先 级值上增加相应的优先级值。

进一步地，在所述装置中，增加相应的优先级值包括：当一测试用例能 够单独地导致测试对象发生故障时，为该测试用例增加第一高的优先级值； 当一测试用例能够与其他测试用例共同地导致测试对象发生故障时，为该测 试用例增加第二高的优先级值；当一测试用例与能够单独地导致测试对象发 生故障的测试用例的类似度达到预定程度时，为该测试用例增加第三高的优 先级值；当一测试用例导致测试对象响应延迟时，为该测试用例增加第四高 的优先级值。

进一步地，在所述装置中，所述故障监视模块包括：自动重启模块，用 于当测试对象发生故障时，重新启动测试对象；其中，当应用一测试用例时 测试对象发生故障，则在通过所述自动重启模块重新启动测试对象并使用该 测试用例重新测试该测试对象后，如果该测试对象再次发生故障，则所述故 障监视模块判断该测试用例能够单独地导致测试对象发生故障，否则判断该 测试用例能够与其他测试用例共同地导致测试对象发生故障。

进一步地，在所述装置中，所述判断该测试用例能够与其他测试用例共 同地导致测试对象发生故障包括：（a）重新启动测试对象；（b）使用该测试 用例之前的j个测试用例以及该测试用例重新测试该测试对象；循环执行以 上步骤（a）和（b），直到测试对象发生故障为止，此时判断该测试用例以 及该测试用例之前的j个测试用例能够共同地导致测试对象发生故障，其中， j的初始值为1，并且每次循环后j的值加1。

进一步地，在所述装置中，所述故障监视模块包括存活性探测模块，用 于在向测试对象应用测试用例后，如果没有接收到测试对象的响应，则向测 试对象发送正常输入，如果仍然没有接收到响应，则判断测试对象发生故障； 如果接收到响应，则根据响应时间来判断当前测试用例是否导致响应延迟。

进一步地，在所述装置中，所述测试对象是通信软件。

根据本发明的又一个方面，提供了一种用于模糊测试的方法，包括：生 成多个测试用例；执行以下步骤一轮或多轮：监视按照初始测试用例集合中 多个测试用例的排列顺序，使用所述多个测试用例中的每个测试用例对测试 对象进行的测试的攻击效果，并且根据相应于每个测试用例的攻击效果，来 确定每个测试用例的优先级；根据所确定的每个测试用例的优先级，对所述 多个测试用例重新排序；其中，在当前轮次中得到的重新排序后的测试用例 的集合能够作为在下一轮次的执行中使用的初始测试用例集合。

根据本发明的另一个方面，提供了一种用于模糊测试的系统，包括：测 试用例生成器，用于随机地生成多个测试用例；测试用例存储器，用于按顺 序存储生成的所述多个测试用例；模糊测试器，用于按照所述多个测试用例 的存储顺序，使用所述多个测试用例中的每个测试用例来对测试对象进行测 试；故障监视器，用于监视测试过程，并且根据相应于每个测试用例的攻击 效果，来确定每个测试用例的优先级；优化器，用于根据所确定的所述多个 测试用例中的每个测试用例的优先级，对所述多个测试用例重新排序，并且 将重新排序后的所述多个测试用例存储回所述测试用例存储器。

通过使用本发明提供的方法，能够自动地优化随机生成的测试用例，以 使得能够极大地改进RFT的漏洞检测效率。本申请的优化方法的优化过程 是自适应的，并且能够根据攻击效果来优化测试用例。

本发明的这些及其他特性、特征和优势将在参考附图描述的说明书中变 得明显，其中附图以示例的方式图示说明了本发明的原理。说明书仅是出于 示例目的，而不限制本发明的范围。下文所引用的参考图都是指附图。

附图说明

通过参考下面结合附图给出的说明，本文描述的各个方面将变得更加显 而易见，其中：

图1是根据本发明的一个实施例的方法的流程图；

图2是根据本发明的一个实施例的装置的示意图；

图3是根据本发明的一个实施例的方法的流程图；

图4是根据本发明的一个实施例的回溯测试的方法的流程图；

图5是根据本发明的一个实施例的系统的示意图。

应当理解的是，在所有上述附图中，同样的附图标记指代同样、相似或 对应的特征或功能。

具体实施方式

本申请将针对具体实施例并且参考特定附图进行描述，但是本申请并不 局限于此，本申请仅是通过权利要求进行限定。所描述的附图仅为示意性的 而非限制性的。在附图中，为便于说明，一些元件的尺寸可能被放大而未按 比例绘制。对于在提到单数名词时使用的不定冠词或定冠词，例如“一”、“一 个”和“该/所述”，除另有明确规定外，这包括该名词的复数形式。

在以前的对随机模糊测试的研究中，最经常使用两种尺度来评估测试用 例集合的有效性，一种尺度是检测到至少一个漏洞的可能性（称为PF尺度）， 另一种是预计检测到的漏洞的数量（称为EF尺度）。尽管这两种尺度非常流 行，但是他们仍有许多不足。例如，对于EF尺度来说，更高的EF尺度并 不必然意味着可以检测到更多的失效或更多不同的漏洞；对于PF尺度来说， 其没有反映能够检测到不同数量的漏洞的用例之间的区别。因此，上述两种 评估有效性的尺度在许多情况下并不很理想。

在本发明中，使用一种与前述两种有效性尺度不同的尺度来评估有效 性，即，使用“检测到第一个漏洞所需的测试用例的预计数量”这一有效性 尺度（称为FF尺度）。FF尺度能够更自然地、更直接地反映测试策略的有 效性。如果FF尺度的值越低，则意味着相应的测试策略更有效，这是因为 只需要更少的测试用例就可以揭露出第一个漏洞。在实际中，当检测到漏洞 时，通常会停止测试并开始进行调试，只有当修复所述漏洞后才重新开始测 试阶段。因此，在实际的模糊测试中，能够更快的检测到第一个漏洞的测试 用例集合往往是更有效的。

本发明提供了一种自适应方法，对于随机模糊测试，该方法能够实现更 小的FF。本发明的总体构思是：基于随机测试用例的攻击效果来对这些测 试用例进行排序，从而使得在随后的测试中能够尽快使用最可能揭露软件脆 弱性的测试用例来进行测试。

图1示出了根据本发明的一个实施例的对测试用例进行排序的方法100 的流程图。给定包含随机生成的多个测试用例的一个集合，以及作为测试对 象的软件程序，例如测试对象可以为一个通信协议，通过图1所示的方法来 对测试用例进行排序。

在步骤S101中，按照测试用例的排列顺序（第一次时测试用例的排列 顺序是随机生成时的排列顺序），使用所有测试用例来对待测软件程序进行 测试，检测每个测试用例的攻击效果，并且根据相应于每个测试用例的攻击 效果为集合中的每个测试用例确定相应的优先级。可以使用一种或多种标准 来评估攻击效果，例如，一个测试用例是否能够单独地导致被测软件的发生 故障（例如对请求无响应），以及一个测试用例是否能够与其他测试用例共 同导致被测软件的发生故障。另外，可以将测试用例划分为两个或更多个优 先级。

在步骤S102中，根据所确定的每个测试用例的优先级，对测试用例重 新排序，从而得到重新排序后的测试用例的集合。当按照重新排序后的顺序， 使用所述生成的测试用例来测试同类型的软件程序时，将能够更快地发现第 一处漏洞。例如，当使用排序后的测试用例集合对运行在另一台机器上的同 一个软件程序或者另一个版本的软件程序进行测试时，将能够更快地发现第 一处漏洞。。

在以上实施例中，只描述了对测试用例进行一轮排序的步骤。在另一个 实施例中，可以对测试用例进行两轮或更多轮的排序，并且在每一轮排序中 执行相同的步骤。也就是说，可以循环地执行步骤S101和S102，在每一次 循环中，将前一轮次中得到的重新排序后的测试用例的集合作为在下一轮次 的排序中使用的初始的测试用例的集合，来对另一个被测软件程序进行测 试，并依据测试结果再次排序。通常，如果循环的轮次越多，则对初始生成 的测试用例的集合的优化越准确，即使得越可能导致被测软件发生故障的测 试用例将排在越靠前的位置。使用由此得到的按顺序排列的测试用例来对软 件程序进行测试时，将能够通过更少数量的测试用例、更快地揭露漏洞。

图2示出了根据本发明的一个实施例的对测试用例进行排序的装置 200，其能够实现如图1所示的方法。如图所示，装置200包括故障监视模 块201和优化模块202。故障监视模块201用于监视按照初始测试用例集合 中多个测试用例的排列顺序，使用所述多个测试用例中的每一个测试用例对 测试对象进行测试的攻击效果，并且根据相应于每个测试用例的攻击效果， 来确定每个测试用例的优先级。优化模块202用于根据所确定的所述多个测 试用例中的每个测试用例的优先级，对所述多个测试用例重新排序。

图3示出了根据本发明的一个实施例的对测试用例进行排序的方法 300。在图3中，示出了使用m个随机测试用例的集合T={t₁,t₂，…,t_m}进行 第R_j（j≥1）轮测试的具体流程。在测试过程中，将根据测试用例的攻击效 果，为每一个测试用例t_i确定相应的优先级。可以使用优先级值来表示优先 级，并且可以采用多个标准来衡量测试用例的攻击效果。在该实施例的每一 轮测试中，可以为各个测试用例分配对应于如下所述的四种标准的优先级 值：

（1）单独地导致发生故障：能够单独的导致被测软件发生故障的测试 用例被分配最高优先级值PRI_IDV；

（2）共同地导致发生故障：有时软件故障是由多个个测试用例共同导 致的，为这些测试用例分配对应的第二高优先级值PRI_CLB；

（3）与单独地导致发生故障的测试用例类似：具有与能够单独地导致 发生故障的测试用例类似的内容的测试用例将被分配对应的第三高优先级 值PRI_IDV_SIM（可以将所有的测试用例看作是字符串，因此可以采用例 如序列对齐算法来测量两个测试用例之间的相似度，如果相似度达到预定的 阈值，那么测试用例可以被标记为该优先级）；

（4）响应延迟：导致延迟的响应的测试用例被认为有可能触发故障， 为该测试用例分配对应的第四高优先级值PRI_RSP（当被测程序是通信协议 软件时，这一标准特别有用，例如，如果软件程序的响应时间超过了上一轮 测试的平均响应时间，那么可以认为发生了响应延迟）。

在一轮测试中为一个测试用例分配的优先级值可以被累加到该测试用 例当前具有的优先级值上，每个测试用例的初始优先级值可以被设置为相同 的数值，例如0。可以采用不同的数值来表示不同的优先级，在图3的实施 例中，为每个测试用例分配对应的优先级值p_i，p_i值PRI_IDV、PRI_CLB、 PRI_IDV_SIM以及PRI_RSP可以分别为4、3、2、1，也可以为8、6、4、2 等等。

如图3所示，每一轮测试开始于步骤S301，例如当前测试为第R_j轮。 在步骤S301，从其中具有按p_i值大小排序的多个测试用例的测试用例集合T 中，按顺序选择一个测试用例t_i来应用于被测软件程序，然后执行步骤S302。

在步骤S302判断应用了测试用例的被测软件程序是否还在活动状态， 例如通过向被测软件程序发送正常输入（例如标准的文件或数据包），来观 察被测软件程序是否有响应。如果没有响应，则表明被测软件程序发生故障 并且继续执行步骤S305；如果有响应，则表明被测软件程序未发生故障并 且继续执行步骤S303。正常输入是只要被测软件存活着就必然会做出响应 的输入，获得正常输入的方法很多，一种方法是使用一个合法的、标准的软 件（除被测软件外）与被测软件通讯。这期间，他们的通讯肯定是正常的（因 为符合协议规范）。使用量Wireshark或者Tcpdump等工具可以捕捉到正常的 输入。另外还可以手工构造符合被测软件协议规范的正常输入。

在步骤S305，判断被测软件程序的故障是否由单独的测试用例引起的。 如果是的话，则将当前测试用例t_i的优先级值p_i更新为p_i=p_i+PRI_IDV，然 后执行步骤S310；如果不是的话，则将当前测试用例t_i的优先级值p_i更新为 p_i=p_i+PRI_CLB，然后执行步骤S310。例如，可以通过如下方式来判断故障 是否由单独的测试用例引起：按照初始测试用例集合中多个测试用例的排列 顺序连续应用测试用例对测试对象进行测试，直至应用一个测试用例后所述 测试对象发生故障。此时，重新所述启动测试对象并使用应用的最后一个所 述测试用例重新测试该测试对象，如果所述测试对象再次发生故障，则判断 所述应用的最后一个测试用例能够单独地导致测试对象发生故障，否则判断 所述应用的最后一个测试用例能够与其他测试用例共同地导致测试对象发 生故障。

在步骤S303，判断当前测试用例是否与能够单独地触发故障的测试用 例类似。如果类似，则执行步骤S308，否则执行步骤S304。

在步骤S308，将当前测试用例t_i的优先级值p_i更新为 p_i=p_i+PRI_SIM_CLB，然后执行步骤S310。

在步骤S304，判断响应时间是否超过阈值RT_j-1。例如，值RT_j-1可以是 上一轮测试中计算的测试用例的平均响应时间。如果超过了阈值RT_j-1，则在 步骤S309将当前测试用例t_i的优先级p_i更新为p_i=p_i+PRI_RSP，然后执行步 骤S310。如果未超过阈值，则直接执行步骤S310。

在步骤S310，判断当前测试用例是否是集合T中的、在本轮测试中应 用的最后一个测试用例。如果不是最后一个测试用例，则返回到步骤S301， 以选择下一个测试用例进行测试；如果是最后一个测试用例，则执行步骤 S311。

在步骤S311，计算在本轮测试中集合T中的所有测试用例t_i的平均响应 时间RT_j，然后执行步骤S312。在实际计算时，例如可以只根据产生了响应 的测试用例的响应时间来计算RT_j。

在步骤S312，根据每个测试用例t_i的当前的优先级值p_i，将集合T中的 测试用例重新排序，然后结束第R_j轮的测试。

以上描述了对测试用例集合T应用一轮测试的详细方法流程，但是在其 他实施例中，可以对测试用例集合T应用多轮测试。当进行第R_j轮的测试 时，将按照在第R_j-1轮测试后对T中的测试用例重新排序后得到的顺序来应 用T中的测试用例。

在执行图3所示方法的一个实施例中，启动测试对象，然后向运行中的 测试对象应用测试用例，如果在应用一个测试用例后测试对象没有发生故 障，则可以在保持测试对象运行的情况下继续应用下一个测试用例，而无须 重启该测试对象。如果在应用一个测试用例后测试对象发生故障，则重新启 动该测试对象，并使用该测试用例重新测试该测试对象，如果该测试对象再 次发生故障，则判断该测试用例能够单独地导致测试对象发生故障，否则判 断该测试用例能够与其他先前使用的测试用例共同地导致测试对象发生故 障。也可以回溯多个测试用例来确定共同导致测试对象发生故障的测试用 例，下面结合图4用一个例子来说明回溯多个测试用例的测试过程。

例如，用一个测试用例集合中的第i个测试用例测试一个通信软件，如 果通信软件有响应，则应用第i+1个测试用例继续运行该通信软件进行测试。 如果应用第i个测试用例后软件无响应，则向该软件发送正常的输入，如果 软件对发送的正常输入无响应，则确定软件产生故障。

在此情况下，重新启动该被测通信软件，再单独应用第i个测试用例测 试软件。此时，如果通信软件无响应，则向该软件发送正常的输入，如果软 件对发送的正常输入无响应，则确定软件产生故障，并且得出结论当前故障 是由第i个测试用例单独地触发的，因此为其增加第一高的优先级值。反之， 如果单独应用第i个测试用例时，通信软件对第i个测试用例有响应，则重 新启动软件连续应用第i-1个和第i个测试用例。如果软件无响应，则发送 正常的输入，如果软件对发送的正常输入无响应，则确定软件产生故障，并 且得出结论当前故障是由第i-1个和第i个测试用例共同触发的，因此为二 者都增加第二高的优先级值。

如果软件对第i-1个和第i个测试用例有响应，则重新启动软件，并连 续应用第i-2个、第i-1个和第i个测试用例。如果软件无响应，则发送正常 的输入，如果软件对正常的输入也无响应，则确定软件产生故障，并且确定 当前故障是由第i-2个、第i-1个和第i个测试用例共同触发的，从而赋予第 i-2个、第i-1个和第i个测试用例第二高的优先级值。

反之，如果软件对第i-2个、第i-1个和第i个测试用例有响应，则重新 启动软件，从第i-3个测试用例开始重新应用测试用例，重复上述步骤，直 至找到共同触发故障的所有测试用例，并赋予他们第二高的优先级值。但是， 为防止测试循环太长，兼顾到测试效率，可以设定此循环的上限数目。例如 如果将循环的上限数目设定为10，则在上述例子中，仅仅回溯到第i-10个 测试用例。

在结合图3描述的实施例中，采用如上所述的四个标准来评估所述测试 用例的攻击效果，从而分配对应的优先级值。但是，评估标准并不限于以上 四种类型。在其他实施例中，可以采用其他数量或其他类型的标准来评估攻 击效果，因而所划分的优先级的数量也可以不同。

在结合图3描述的实施例中，通过向被测软件程序发送正常输入，来确 定被测软件程序是否真正地发生了故障。但是，在其他实施例中，可以采用 其他方式来判断被测对象是否发生故障。

在结合图3描述的实施例中，利用上一轮测试中计算的测试用例的平均 响应时间作为响应时间的阈值。但是，在其他实施例中，可以采用其他值作 为阈值。

下面以集合T={t₁,t₂,t₃,t₄,t₅,t₆}为例，说明应用图3所示的方法后所可 能得到的结果。t₁至t₆的顺序是这些测试用例初始生成的顺序，在使用它们 进行测试前，它们各自的优先级值p_i都为0。在第一轮测试时，按照它们初 始生成的顺序来将这些测试用例逐个应用于被测软件程序。在经过一轮测试 后，测试用例t₁至t₆的优先级值分别变为p₁＝0，p₂=0，p₃=3，p₄=4，p₅=2， p₆＝1。也就是说，当使用t₁和t₂,测试第一个被测软件程序时，它们都无法导 致如上所述的四种标准中的任意一种情况发生；当使用t₃测试第一个被测软 件程序时，程序发生故障，并且该故障可能与之前运行的测试用例有关；当 使用t₄测试第一个被测软件程序时，会单独地导致程序发生故障；而测试用 例t₅与t₄非常类似；当使用t₆测试第一个被测软件程序时，导致被测程序响 应延迟。因此，按照上述优先级值，测试用例集合T中的测试用例将被重新 排序为{t₄,t₃,t₅,t₆,t₁,t₂}。使用重新排序后的测试用例来对其他测试对象进 行测试时，将有可能更快地发现第一个漏洞，从而提高了测试效率。

在对上述测试集合T进行第一轮测试并排序后，还可以在其基础上，再 次应用集合T进行第二轮测试。在第二轮测试中，按照t₄,t₃,t₅,t₆,t₁,t₂的顺 序向第二个被测软件程序（例如通过修改第一个被测软件程序得到的程序， 或与第一个被测软件程序版本不同的程序等）应用测试用例。在第二轮测试 中，分配给测试用例t₄,t₃,t₅,t₆,t₁,t₂的优先级值将分别为4，0，2，4，0，1。 也就是说，在第二轮测试中，当使用t₄和t₆测试第二个被测软件程序时，都 会单独地导致程序发生故障；而测试用例t₅与t₄非常类似；当使用t₃和t₁测 试第二个被测软件程序时，都无法导致如上所述的四种标准中的任意一种情 况发生；当使用t₂测试第二个被测软件程序时，导致被测程序响应延迟。从 而，在经过两轮测试后，对应于各个测试用例的总的优先级值将变为p₁=0， p₂=1，p₃=3，p₄=8，p₅=4，p₆=5。因此，在经过两轮测试后，各个测试用例 的优先级的顺序将对应于如上的总的优先级值的大小的顺序。因此，此时， 对测试用例集合T中的测试用例按优先级重新排序后的顺序将为{t₄,t₆,t₅,t₃, t₂,t₁}。使用重新排序后的测试用例来对其他测试对象进行测试时，将可能比 使用第一轮排序后的测试用例更快地发现第一个漏洞，从而提高了测试效 率。

以上描述了两轮测试或排序，在实践中，可以对测试用例集合T进行更 多轮的排序。

图5示出了根据本发明的一个实施例的用于模糊测试的系统500的示意 图。如图5所示，系统500包括测试用例生成器510，用于随机地生成多个 测试用例，该多个测试用例构成测试用例集合T，例如在上述各个实施例中 描述的测试用例集合T。

系统500还包括测试用例存储器520，用于按顺序来存储所述生成的多 个测试用例。

系统500还包括模糊测试器530，用于按照测试用例存储器520中的多 个测试用例的存储顺序，逐个使用所述多个测试用例中的每一个测试用例来 对测试对象进行测试，例如，运行被测软件程序，并向被测软件程序输入上 述测试用例。

系统500还包括故障监视器540，用于监视模糊测试过程，并且根据相 应于每个测试用例的攻击效果，来确定每个测试用例相应的优先级。所述故 障监视器540可以进一步包括存活性探测模块541和自动重启模块542。其 中，自动重启模块542用于当测试对象发生故障时（例如，被测软件程序没 有任何响应时），重新启动测试对象。存活性探测模块541用于在所述测试 期间（例如向测试对象输入了测试用例之后），向测试对象发送正常输入， 并且如果接收到响应，则根据响应时间来判断当前测试用例是否导致响应延 迟；如果没有接收到响应，则判断当前测试用例导致测试对象发生故障。当 应用一测试用例时测试对象发生故障，则可以使用自动重启模块542来重新 启动测试对象，并使用该测试用例重新测试该测试对象，如果该测试对象再 次发生故障，则判断该测试用例能够单独地导致测试对象发生故障，否则判 断该测试用例能够与其他测试用例共同地导致测试对象发生故障。

此外，系统500还包括优化器550，用于根据分配给所述多个测试用例 中的每个测试用例的优先级，对所述多个测试用例重新排序，并且将重新排 序后的所述多个测试用例存储回所述测试用例存储器520，从而完成一轮对 测试用例排列顺序的更新。下一次使用更新后的顺序排列的测试用例来对测 试对象进行测试，并且还可以对存储器520中存储的测试用例进行更多轮的 更新。

以上结合具体实施例描述了本发明。本领域的技术人员还应认识到，可 以将结合本文公开的各方面描述的各种示例性逻辑框、模块、单元、装置、 电路和算法步骤实现为电子硬件、由处理器执行的各种形式的包含指令的程 序或设计代码（本文为了方便起见可以将其称为“软件”或“软件模块”） 或两者的组合。为了清楚地说明硬件和软件的这种可互换性，上文一般从它 们功能性的角度来描述各种示例性部件、框、模块、单元和步骤。将这些功 能实现为硬件、固件还是软件取决于特定的应用和施加在整个系统上的设计 约束条件。技术人员可以针对每种特定应用以不同的方式实现所述的功能， 但不应将这种实现决定解释为导致脱离本公开的范围。

应该注意的是，给出上述实施例是为了描述本发明而非限制本发明，在 上述各个实施例中包括的特定特征并不限于仅包括在该特定实施例中，对于 不同实施例中的特征可以进行适当组合，而不脱离本发明的范围。并且要理 解的是，本领域技术人员很容易想到在不脱离本发明的精神和范围的情况下 可以采取修改和变更。这种修改和变更被视为在本发明和权利要求书的范围 内。本发明的保护范围由权利要求书进行限定。另外，权利要求书中的任何 附图标记均不应被解释为对权利要求的限制。