CN111459808A - 一种基于类型推断的具有引导性的测试用例变异方法 - Google Patents

Abstract

本发明公开了一种基于类型推断的具有引导性的测试用例变异方法，针对JavaScript语言及其引擎设计一个测试用例产生器，该测试用例产生器可以产生具有强语义、高代码覆盖率的测试用例，用以提升模糊测试过程中发现JavaScript引擎缺陷的效率；测试用例产生器在产生和处理测试用例时的流程由预处理方法和生成与变异方法两部分组成，其中：预处理方法是对原始语料进行函数化操作，将原始语料拆分成一个一个的function，经语法检查、过滤后得到预备测试用例；生成与变异方法是对得到的预备测试用例进行参数类型推断，然后生成自调用表达式，进而得到测试用例文件。当function的参数所需的数据类型被成功推定后，就可以有针对性地对相应数据类型的参数的值进行有效的变异。

Description

一种基于类型推断的具有引导性的测试用例变异方法

技术领域

本发明涉及计算机软件的测试领域，具体涉及一种基于类型推断的具有引导性的测试用例变异方法。

背景技术

1.1相关技术背景

根据测试目标的不同和产生测试用例的方法的不同，将软件测试方法分为基于断言的测试和模糊测试两种。

基于断言的测试一般用于测试目标明确的场景中，即测试人员清楚地知道要测试的是系统的哪个模块，然后有针对性地对相应的模块编写特定的测试用例，在对模块执行测试用例的表现进行预估之后设定断言，最后调用被测模块执行测试用例，将模块的执行结果和测试前设定的断言进行比对，如果一致则该模块通过测试，否则判定该模块存在缺陷。

如存在一个计算两数相加的软件模块add，现有一个测试用例包含两个数3和5，可以设定断言，调用add(3，5)应当得到结果8，然后真正得使用上述测试用例去调用add模块，如果实际结果和断言中的8一致，即说明模块add通过了测试，否则说明其内部逻辑存在缺陷。

模糊测试是一种自动化的软件测试技术。相对于基于断言的测试方法，模糊测试不仅关注系统中的一个个模块，而更加关注系统整体；它不关注模块的正确性，而更加关注系统的稳定性。它不需要人为编写测试用例，而具有自动产生测试用例的能力。模糊测试通过快速生成大量的测试用例对应用程序进行反复测试，目的是发现系统中的不稳定性的缺陷。即通常情况下，模糊测试只关注系统是否会发生崩溃，而不关注系统的执行结果是否符合预期。

可见，由于模糊测试方法具有自动产生测试用例的能力，减少了人工的参与，因此可以大幅度得提高软件测试的效率。然而如何设计一个模糊测试框架中的测试用例产生方法，使其可以高效得产生语义丰富的、具有高测试效能的测试用例，这具有很高的研究和实践的价值和意义。

1.2与本发明相关的现有技术

模糊测试框架的测试用例产生途径有测试用例生成方法和测试用例变异方法两种。本发明中，所涉及的测试用例文件属于后者。

当前较为知名的模糊测试框架AFL(American Fuzzy Lop)就设计了较为复杂的测试用例变异方法(下文中简称为变异方法)。使用AFL时首先需要为它输入多份原始的测试用例文件，然后AFL会调用其变异方法逐一对这些测试用例文件进行多种变异，产生多份新的测试用例。最后使用它们分别对被测试对象展开测试，以期通过这些变异手段将原本可以正常执行的测试用例，变异成可以触发被测试对象隐含的缺陷的异常测试用例文件。

另一个最新的模糊测试框架Nautilus设计了一种基于语法树的上下文无关的树表达式。其在产生测试用例时，首先根据写定的语法规则产生语法树表达式。然后使用该表达式构建语法树，接着按照设计的变异策略对语法树中的节点进行变异。最后再将语法树转译为代码，这样便达到了对产生的代码的进行变异的目的。

1.3 JavaScript编译器测试过程中存在的问题

JavaScript是一种基于原型的动态弱类型脚本语言。其弱类型区别于Java、C等编程语言的强类型。所谓强类型，即程序在编写的时候就指定了一个对象的类型。例如，Java中共有以下8种：int、long、float、double、char、boolean、short和byte，它们分别代表：整型、长整型、浮点型、双精度浮点型、字符型、布尔型、短整型和字节型。而弱类型又称为无类型，即程序在编写的时候不指定每个对象的类型，解释器或编译器只能在执行到相应的语句时才对对象的类型进行判断。由此，许多在强类型语言中可以规避的类型异常都可能被隐藏，难以发现问题所在。

另外，如图3中的JavaScript测试用例所示，这段代码的第1行在控制台中输出一个变量variable_which_undefined的值。2-4行定义了一个函数vulnerable_func，这个函数有两个参数param1和param2，返回两个参数相除的结果。第5行传入两个参数2019和0调用了前面定义的函数vulnerable_func。将这段代码输入到JavaScript引擎中运行时，会在第1行报出“变量variable_which_undefined未被定义”的错误，并异常终止运行。而后面的第2-5行原本会执行2019/0这样的运算逻辑，以测试编译器如何应对除法运算中除数为0的情况，现在因为程序在第1行异常终止运行，导致这4行代码无法被执行到。即在本条共5行的测试用例中，只有1行被执行，4行无法被执行到，其代码覆盖率为1/5×100％＝20％.

由此可见，若直接将整份的JavaScript代码作为测试用例输入到其引擎中进行测试，测试用例整体的运行会受到位置靠前的某些行代码的限制，导致测试用例过早地异常退出，进而使整份测试用例的代码覆盖率大幅度降低。这造成了很大的浪费，同时，在很大程度上也降低了测试的效率。

1.4现有变异策略存在的问题

在上述1.2节中，已经介绍过的模糊测试框架AFL，其测试用例变异方法中设计了6种变异策略，如表1所示。

表1：AFL变异方法的变异策略

从表1中可以看出，AFL的变异方法所执行的策略大多接近于穷举方法，即将所有可能的情况都做一次尝试，这样的操作由于不具有导向型，其效率十分低下。如图1所示的一个较为极端的测试用例，其函数体中的代码逻辑即定义一个长字符串，然后输出它，代码中包含的原始代码语义很少。如果将其输入到AFL中进行变异和测试，AFL的变异方法首先会对用例的每一位进行一次按位翻转，每个英文ASCII字符占8位，字符串snow_white_story中有数百个字母，即这一操作就要进行上千次。然而这上千次的按位变异只会改变字符串的值，并不能对测试的效果产生太大的影响。其后，剩下的5种变异规则会被逐一运用在该用例上，之后才会再开始处理下一个用例。可见，对于这类文本量很大，但语义信息很少的测试用例，AFL对其进行大量穷举变异的效率十分低下。

同样，在1.2小节中介绍过的模糊测试框架Nautilus，其测试用例变异方法中设计的变异策略如表2所示。

表2：Nautilus变异方法的变异策略

从图2和上述介绍中可以看出，Nautilus组合了基于语法的测试用例生成方法和测试用例变异方法而构建了一个独特的测试用例产生方法。除了变异方法中的变异策略不具有导向性(即不经过其他方法引导的随机变异)外，这类基于语法的代码产生方法还有一个严重的缺陷，即用于生成测试用例的语法的好坏受制于编写语法规则的人的知识储备、实践经验和对这门语言的熟悉程度。如果所设计的语法的语义信息不够复杂和丰富，其所生成的代码所具有的语义信息也会相应地大打折扣。如果这些原始测试用例中很少隐含着可以触发引擎缺陷的代码片段，即便多么复杂的变异方法设计都对实际的测试效果无济于事。

综上所述，作为模糊测试框架中最重要的方法设计，基于语法的测试用例生成方法和无引导性的测试用例变异方法这两种测试用例产生方法存在以下的问题：

1)基于语法的测试用例生成方法，其写定的语法的好坏受制于编写者在这种编程语言上的熟练程度的高低和实践经验的多少。

2)无引导性的测试用例变异方法，其使用的变异策略对每一份测试用例进行无差别的随机穷举变异，其效率十分低下，降低了模糊测试的整体效能。

发明内容

针对上述现有技术存在的上述技术问题，本发明的目的在于，提供一种基于类型推断的具有引导性的测试用例变异方法。

为了实现上述任务，本发明采取如下的技术解决方案：

一种基于类型推断的具有引导性的测试用例变异方法，其特征在于，该方法针对JavaScript语言及其引擎设计一个测试用例产生器，该测试用例产生器可以产生具有强语义、高代码覆盖率的测试用例，用以提升模糊测试过程中发现JavaScript引擎缺陷的效率；

所述测试用例产生器在产生和处理测试用例时的流程由预处理方法和生成与变异方法两个部分组成，其中：

所述预处理方法是对原始语料进行函数化操作，将原始语料拆分成一个一个的function，经语法检查、过滤后得到预备测试用例；

所述生成与变异方法是对得到的预备测试用例进行参数类型推断，然后生成自调用表达式，进而得到测试用例；当function的参数所需的数据类型被成功推定后，就可以有针对性地对相应数据类型的参数的值进行有效的变异。

根据本发明，所述参数类型推断是通过对function的参数进行预先的静态文本分析，来确定其可能的数据类型；在对参数param进行的类型推断过程中，首先对参数类型待定的function的函数体进行遍历扫描，统计函数体中与参数param相关的各种数据类型的推断因子，然后对各类型推断因子的个数进行比较，最后推断因子数量最多的数据类型即被推定为该参数param的数据类型。

本发明的基于类型推断的具有引导性的测试用例变异方法，一方面针对JavaScript语言及引擎设计了测试用例产生器，并给出了类型推断方法，可以提升测试用例的代码覆盖率，另一方面设计了基于类型推断的测试用例变异方法，提升了模糊测试中原始语料的利用率和产生测试用例的效率，具有强引导性。本发明和相较于现有技术中的随机变异相比，带来的技术效果在于：

1、从开源的代码托管平台Github中下载数千个JavaScript代码仓库，这足以使收集到数百万份的JavaScript原始语料，远丰富于少数几个人编写的语法规则所能包含的代码语义信息。且通过这样的测试用例获取渠道，可以快速地更新以实时地获取源源不断的测试用例。

2、为了有针对性地对代码进行变异，首先将原始语料拆分成一个一个的function，然后针对JavaScript语言弱类型的特性，并且特别设计了一套参数类型推断方法，对function的参数进行类型推断，当function的参数所需的数据类型被成功推定后，就可以有针对性地对相应数据类型的参数的值进行有效的变异。

附图说明

图1是针对AFL变异方法的一个极端的测试用例示例；

图2是Nautilus产生和变异测试用例的示例；

图3是JavaScript测试用例示例；

图4是测试用例产生器在产生和处理测试用例时的流程图；

图5是测试用例生成的代码变化图；

图6是生成与变异阶段的代码变化图；

图7是参数类型推断示例；

图8是基于类型推断的测试用例变异示例；

图9是实验验证结果。

以下结合附图和实施例对本发明作进一步地详细说明。

具体实施方式

首先需要说明的是，本发明是一种基于类型推断的具有引导性的测试用例变异方法，通过该方法的指导可以自动化地、源源不断地生成高质量的JavaScript测试用例，用这些生成出来的JavaScript测试用例可以测试JavaScript引擎是否含有缺陷，尤其是崩溃缺陷。

申请人对本发明中所涉及的技术术语作如下说明：

1、代码(文件)：

代码是开发者用特定编程语言所写成的包含一定逻辑思想的一段非自然语言文本。文件作为代码的载体，代码必须写在文件中才能存在，因此代码＝“代码文件”。

2、测试用例：

测试用例，英文作：Test case，是一个组合起来的专有名词，即用来做测试的例子。测试用例是代码，但是代码不一定都是测试用例，把一些代码特别用来测试一些被测试对象(在本发明中指JavaScript引擎)，这些代码称作测试用例。同样的，测试用例以文件为载体。

3、JavaScript引擎、编译器、解释器：

JavaScript引擎是用来特定的执行JavaScript代码的软件，其共分为编译器和解释器两种。本发明中将其统一看作JavaScript引擎，不做进一步细分，即根据本发明所述的方法产生的测试用例文件是对编译器和解释器通用的。类比于衣服有很多品牌，现存的JavaScript引擎也有很多，分别由不同的人或组织实现，例如SpiderMonkey、JavaScriptCore、Chakra等。

4、崩溃：

所谓崩溃即软件(在本发明中指JavaScript引擎)因一些特异的输入(本发明中指可以触发引擎崩溃的测试用例)造成其异常退出，不能继续提供正常的功能和服务。

5、可以触发引擎崩溃的测试用例：

JavaScript引擎可以对没有语法错误的代码文件进行一视同仁的执行，碰到有语法错误的代码，JavaScript引擎会报告错误，停止执行(这种停止是正常的，它可以继续处理下一份代码，不属于崩溃)。起初，申请人无法直接辨别哪份测试用例可以触发引擎崩溃，只能将一份份的测试用例都输入到JavaScript引擎中进行执行，当引擎执行到某一份测试用例时，发生了崩溃，那么该测试用例就是可以触发引擎崩溃的测试用例。

6、测试的最终目标：

由上面的5可知，在测试过程中发现了许多份测试用例可以导致JavaScript引擎崩溃，因此可以将该份测试用例写进缺陷报告中提交给该JavaScript引擎的维护者，便与其发现并修复相应的缺陷。

本实施例给出一种基于类型推断的具有引导性的测试用例变异方法，该方法首先针对JavaScript语言及其引擎设计一个能高效产生优质测试用例的测试用例产生器，该测试用例产生器可以产生具有强语义、高代码覆盖率的测试用例，用以提升模糊测试过程中发现JavaScript引擎缺陷的效率。

整个测试用例产生器在产生和处理测试用例时的流程如图4所示。

从图4可以看出，测试用例产生器在产生和处理测试用例时的流程为预处理方法和生成与变异方法两个部分组成：其中：

(1)预处理方法设计

预处理方法是对原始语料进行函数化操作，函数化操作解决了原始语料在被执行时，代码覆盖率低的问题。它将原始语料拆分成一个一个的function(JavaScript语言的函数体)，这是本实施例中测试用例生成与处理所需的基本单元。经过前面的函数化操作得到的function可能会包含一些语法错误，这些语法错误可能来自于原始的语料，也可能是在前面的处理流程中引入的。检查代码的语法错误是引擎在执行代码前所需的必要步骤，因此包含语法错误的function并没有执行的收益，反而会带来为尝试它而引入的时间开销，因此需要通过语法检查将其过滤，得到预备测试用例。

(2)生成与变异方法的具体设计

所述生成与变异方法是对得到预备测试用例进行参数类型推断，生成自调用表达式，进而得到测试用例。然后用该测试用例去测试JavaScript引擎，当function的参数所需的数据类型被成功推定后，就可以有针对性地对相应数据类型的参数的值进行有效的变异。

前文中简单介绍过模糊测试，它通过不断输入不同的测试用例让待测目标去执行以发现其隐含的漏洞(以崩溃类型为主)。经过前面步骤的处理，得到的预备测试用例尚不能直接用来测试，因为单独的function不能自动执行，必须从外部调用它，才可以执行其内部的代码逻辑。

更进一步，对于占多数比例的有参数的function而言，调用它们时还需要传入相应的参数，此时便通过所设计的类型推断方法推断出参数可能的数据类型，然后根据推断结果传入相应类型的参数并调用该function，以此来提高测试用例的代码覆盖率，进而提高模糊测试的效率。最后，在测试中对经过了精准传参的function使用传统的变异方法进行参数值范围的变异，以期可以触发更多由数值临界条件引起的引擎漏洞。

以下是发明人给出的具体实施和实验过程。

一、方法概述

1、预处理

前文中说过，为了提高测试用例的代码覆盖率，需要原始语料进行拆分。进而获得测试用例生成与处理所需的最小单元——JavaScript的function。预处理阶段对语料库所作的操作如图5所示。

1.1函数化

函数化操作顾名思义，即将代码转化为一个一个的函数。在JavaScript语言中，函数通过“function”关键字来定义。在收集自各种渠道的JavaScript代码中，存在着以下两种可以导致其代码覆盖率低的情况：

1)即前文中多次提到的由于整份代码的前半部分含有语法错误，导致后面的代码无法被引擎执行到。

2)有的代码本身就是一个函数库，其中的function包含丰富的语义信息，但是由于这些function需要外部的调用才能执行，因此如果不做处理，这些语义丰富的代码也会被浪费掉。这种情况并不在少数，当前较为流行的许多JavaScript框架如jQuery、Bootstrap、Vue.js等内部含有对象操作、渲染操作、网络请求等多种功能的大量function，这些含有丰富语义的框架也是用来测试JavaScript引擎的很好的测试用例来源。

如图5所示，在进行函数化提取function的同时，删去了所有function的名称，这样做是为后面步骤中的统一化处理做预备。

1.2语法过滤

经过函数化的操作，得到了大量的function，但这些function并非完全符合JavaScript的语法规则。语法检查是一种静态检查，即在引擎执行代码之前对代码文本进行的检测，如果代码中有任何的语法错误，JavaScript引擎不应当执行这段代码，而是应该直接抛出异常，退出执行。

因此，包含语法错误的function并不会被执行，而且还会因为引擎的启动和退出时延降低测试的效率，因此需要对包含语法错误的function进行过滤删除。如图5中的示例，包含有为常量1赋值操作的function无法通过语法检测。通过了语法过滤剩下的function在本文中称为预备测试用例。

1.3生成与变异

在这个阶段我们需要讨论的是如何使用上一步骤所得到的大量预备测试用例，更进一步的即如何调用这些经过了一系列优化处理的function？尤其是针对一些具有参数的function，应该传入怎样的参数来调用这些function，使其得到更高的代码覆盖率，进而更多的覆盖到被测试的JavaScript引擎的功能模块？如何确定function所需的参数的类型？

整个模糊测试过程中测试用例的变化如图6所示。首先，通过参数类型推断操作来推断出function的参数parameter可能的数据类型，然后根据推断结果生成相应类型的参数，最后使用这个参数调用该function执行函数体中的内部代码逻辑。为了提高每个测试用例的测试效能，更多地触发因数值边界条件引发的引擎缺陷，对一个测试用例所传的参数还会经过多轮的变异。

1.3.1参数类型推断

为了解决function调用传参的问题，本实施例给出了一种参数类型推断方法。该方法通过对function的参数进行预先的静态文本分析，来确定其可能的数据类型。如图7中的例子所示，该function有一个参数param，函数体中有三行代码。代码语义是，首先将param转换为小写形式，然后获取它的长度，最后返回它的后二分之一。

在对参数param进行的类型推断过程中，首先对参数类型待定的function的函数体进行遍历扫描，统计函数体中于参数param相关的各种数据类型的推断因子，然后对各类型推断因子的个数进行比较，最后推断因子数量最多的数据类型即被推定为该参数param的类型。

如图中的例子，与param相关的String类型的推断因子有[.toLowerCase，.length，.substr]等3个，而Array类型的推断因子只有[.length]这1个，因此推定参数param所需的数据类型为String，即字符串类型。

下面对类型推断因子进行详细的说明。为了尽可能准确地标识一种数据类型的变量在JavaScript代码中所具有的特有表现，本实施例提出了类型推断因子的概念。

类型推断因子，即一种数据类型在代码层面所具有的独有功能的集合。如图7中的代码示例，“.toLowerString”和“substr”是JavaScript语言中String类型特有的函数，其语义分别为获得字符串的小写字母形式和获取字符串的子串。而“.length”是String类型和Array类型都具有的函数，即分别表示获得字符串和数组的长度。因此“.length”被统计为String和Array两种数据类型的推断因子。

本实施例中，所设计的类型推断因子不仅仅包含各数据类型所独有的函数，还包含了从一些类型的变量所特有的操作中截取的文本片段，如“&&”逻辑与操作常与Boolean类型的操作相关，所以作为Boolean类型的一个推断因子；“++”自增操作可以使Number类型的变量的值自增1，因此作为Number类型的推断因子；“[”和“]”常常与Array类型的变量一同出现，用于指示下标为指定值的数组元素，因此可以作为Array类型的推断因子。

总之，除了上述简单介绍的以外，针对JavaScript语言的Array、Boolean、Number、String和Function这5种数据类型设计了许多的类型推断因子，具体如下表3所示。

表3：各数据类型的推断因子

从表3中可以看到，对于不同的数据类型，设计了前缀、后缀和环绕三种类型推断因子。除了大多数以“.”号开头的表示函数名的后缀推断因子外，Boolean和Number具有许多前缀推断因子，同时为Function类型设计了一些环绕推断因子。

需要注意的是，当在一些特殊的情况下，如果一个函数的参数在两个及两个以上的数据类型上统计出来的类型推断因子数相同，那么，可以认为这些数据类型都可能是这个参数所需的，然后对该参数给出一个包含所有可能类型的推断结果集合。另外，当一个参数在所有数据类型上统计出来的推断因子数都为0，那么将为它推荐结果“none”，即没有类型。上述推断结果将作为下一个步骤的输入。

1.3.2生成自调用表达式

前文中曾提到过，未被显式调用的function，其函数体中的代码逻辑不会被执行，这也是本文对原始JavaScript语料进行函数化的初衷，即让尽量多的测试用例得到执行，提到测试用例的代码覆盖率。经过上一小节中所做的类型推断，已经推定了function中参数的数据类型，现在需要根据上述推断结果生成相应的实际参数，然后使用这些生成的实际参数产生调用这些function的代码语句，这种代码语句即称为自调用表达式。

针对不同的数据类型和推断结果，设计了不同的参数生成策略。具体的说明和示例如下表4所示。

表4：各数据类型参数的生成策略及示例

需要进一步说明的是，数组类型的成员仍可以是数组类型，即可以生成多维数组。当类型推断无法推定参数的数据类型时，将会为[param:none]的推断结果随机生成上述其他类型的一个值。

最后，使用函数名和参数名生成函数的调用表达式，即自调用表达式。如图6的右上方所示，一个最终的测试用例由function、实际参数列表和自调用表达式三个部分组成。

1.3.3测试用例变异

如图8给出的示例所示，函数func的参数parameter所需的数据类型被推断为Number类型，首次随机传参时给出的值为637，它不能通过函数体中的if(parameter＞1024)的条件判断，因此无法深入执行下面的代码块。而当变异方法针对Number数据类型将parameter的值由637变异为其2倍的1274时，就可以进入到条件判断的代码块中执行，提高了测试用例的代码覆盖率。进而可以执行到更多的测试用例代码逻辑，进而提高了触发引擎缺陷的可能。

针对前文中提到的Boolean、Number、String、Array和Function这5种数据类型，分别设计了许多相应的变异策略，以使测试用例可以在变异的过程中具有更加广泛的值范围，进而进入更多的条件代码块中触发JavaScript引擎中更多的临界条件。具体的设计如下表5所示。

表5：基于类型推断的测试用例变异策略

1.4小结

上述内容主要介绍了本实施例所涉及的基于类型推断的具有引导性的测试用例变异方法的设计。并从整体介绍了该方法设计的测试用例产生器在产生测试用例时所经历的两个阶段，即预处理方法和生成与变异方法。其中的预处理方法部分，需要对预处理后的语料进行函数化和语法过滤操作，其中前者用于提高测试用例的代码覆盖率。而后者删除了不符合语法规则的语料减少了测试效率的浪费。最后也是最重要的生成与变异方法阶段，在经过了参数类型推断后，确定了预备测试用例(即一个一个的function)的参数所需的数据类型，然后对特定的类型生成特定的参数值，进而生成自调用表达式，用这些生成的参数去调用目标function，以进一步提高测试用例的代码覆盖率。进而，针对每种数据类型的值进行具有强引导性的测试用例变异，相较于AFL等使用随机变异策略组成变异方法的知名模糊测试框架，具有更高的变异效率。

二、实验部分

2.1实验环境

2.2代码覆盖率实验

2.2.1实验设计

代码覆盖率是衡量一个测试用例生成、处理或变异方法效果的重要衡量标准，其表示的是被统计的测试用例中，可以被执行到的代码的行数、分支数、表达式数和函数数量等占总数的比例。由于代码中分支条件不满足或某些函数未被显式调用等原因都可能导致上述四种覆盖率的降低。

本实验用于证明本实施例给出的基于类型推断的具有引导性的测试用例变异方法的有效性。即使用相同的1万份测试用例，设置三组对照试验，即：

1)随机传参的结果；

2)经过类型推断后1次传参(即0次变异)的结果；

3)经过类型推断后100次传参(即99次有引导的变异)的结果。

然后分别对这三组的结果从表达式覆盖率、分支覆盖率、函数覆盖率和行覆盖率等4个维度进行统计，得到实验结果。

2.2.2实验结果

实验验证结果如图9所示，对测试用例的function进行随机传参，其表达式、分支、函数和行的覆盖率分别为(51.50％，47.47％，71.06％，52.17％)，而经过了类型推断的传参后，其覆盖率分别为(71.49％，66.21％，87.20％，72.21％)，分别有(19.99％，18.74％，16.14％，20.04％)的覆盖率提升，最后，经过一次类型推断传参和99次变异后，分概率分别达到了(81.72％，77.05％，91.08％,82.36％)，较类型推断后的单次传参，覆盖率分别又有(10.23％，10.84％，3.88％，10.15％)的提升。即第三组和第一组相比，覆盖率分别提升了(30.22％，29.58％，20.02％，30.19％)。

2.2.3实验结果分析

上述的实验结果显示，经过了类型推断的测试用例在代码覆盖率上有16.14％～20.04％的提升，证明了本实施例提出的基于类型推断的具有引导性的测试用例变异方法具有很好的提升测试用例代码覆盖率的效果。而在类型推断之后，再对测试用例进行99次变异，其代码覆盖率又有了3.88％～10.84％的提升，再次证明了本实施例的基于类型推断的具有引导性的测试用例变异方法，同样具有提升测试用例代码覆盖率的效果。

最后，将第三组和第一组进行纵向比较，与随机传参相比，本实施例给出的基于类型推断的具有引导性的测试用例变异方法，对测试用例的代码覆盖率有20.02％～30.22％的大幅度提升。

Claims (2)

1.一种基于类型推断的具有引导性的测试用例变异方法，其特征在于，针对JavaScript语言及其引擎设计一个测试用例产生器，该测试用例产生器可以产生具有强语义、高代码覆盖率的测试用例，用以提升模糊测试过程中发现JavaScript引擎缺陷的效率；

所述测试用例产生器在产生和处理测试用例时的流程由预处理方法和生成与变异方法两个部分组成，其中：

所述预处理方法是对原始语料进行函数化操作，将原始语料拆分成一个一个的function，经语法检查、过滤后得到预备测试用例；

所述生成与变异方法是对得到的预备测试用例进行参数类型推断，然后生成自调用表达式，进而得到测试用例；当function的参数所需的数据类型被成功推定后，就可以有针对性地对相应数据类型的参数的值进行有效的变异。

2.如权利要求1所述的方法，其特征在于，所述参数类型推断是通过对function的参数进行预先的静态文本分析，来确定其可能的数据类型；在对参数param进行的类型推断过程中，首先对参数类型待定的function的函数体进行遍历扫描，统计函数体中与参数param相关的各种数据类型的推断因子，然后对各类型推断因子的个数进行比较，最后推断因子数量最多的数据类型即被推定为该参数param的数据类型。

Images