基于混合测试和动态分析的分段代码测试

刘春宏,徐立华,颜 婷,杨宗源

(华东师范大学计算机科学技术系,上海200241)

基于混合测试和动态分析的分段代码测试

刘春宏,徐立华,颜 婷,杨宗源

(华东师范大学计算机科学技术系,上海200241)

传统混合执行测试方法无法对源代码不可见函数进行符号执行。针对该问题,将符号执行、分段式符号执行以及具体执行按需结合,提出一种分段式混合执行测试方法,将源代码不可见函数以分段式分析法截取为单独代码片段,结合动态执行和回归分析方法推导其相应的程序语义。为验证该方法的有效性,实现sCREST原型系统,并对5个应用广泛的开源系统进行测试。实验结果表明,该方法能够产生比传统方法覆盖更多分支数的测试数据。

软件测试;混合测试;分段式符号分析;动态分析;测试数据生成;分支覆盖

1 概述

混合执行测试[1-2]是一种将具体执行和符号执行相结合的有效测试方法,自动生成测试输入来执行程序中所有可行路径以进行错误检测,受到广泛关注[3-5]。CREST[3]在混合执行中提供多种基于程序控制流图的路径搜索策略,以尽量生成覆盖更多分支的测试输入。文献[4]提出一种目标制导的混合执行测试方法,只生成和执行可能会覆盖待检测缺陷语句的测试输入。文献[5]将混合执行测试应用于基于污点指针的二进制代码缺陷检测中。混合执行测试在100行～2 000行代码的小型系统的单元测试中非常有效[3],但目前将其用于工业界实际软件仍存在一些局限性[6]。本文主要专注于混合执行测试中源代码不可见的函数调用处理这一局限性(也称为native calls,它包括源代码不可获得的标准库函数或者第三方组件的使用)。文献[6]实验表明源代码不可见的函数调用是除指针外在被测软件系统中出现频率最高的局限性,阻碍工具产生高分支覆盖的测试数据。

混合执行测试继承于符号执行技术,无法对源代码不可见的被调函数进行符号执行。DART[1], CUTE[2]和CREST[3]使用运行时具体值代替符号值的“具体化”方法处理源代码不可见的函数调用,但在测试生成环境下,该方法并不精确,因为随之产生的测试数据只能覆盖某一具体输入值可以到达的被调函数中的一条路径,有时还可能导致路径分歧[1,7]。且如果符号路径条件中的函数调用没有得到有效处理,也会影响生成的测试数据的完备性。混合执行测试中采用函数跟进[1-3]和函数摘要[8]处理函数调用,但针对的是存在源代码函数体的函数,不适用于本文研究的源代码不可见的函数调用;对于无法获得源代码的第三方组件或标准库函数调用,如果采用函数摘要方法,则需要通过人工的编写完成[9]。

针对源代码不可见的函数,文献[7]提出一种使用未解释的函数符号表示源代码不可获得的函数的高阶测试生成方法,比具体化方法更加精确,但实现代价昂贵且受限于现有SMT solver的求解能力。文献[10]在Cloud9中手动开发库模型,但每一个新的应用程序可能会引入一个不同的库,模型并不总是可以重用。文献[11]在ICSE 2013上提出的分段式符号分析是一种将静态程序分析中无法继续的代码片段以动态分析的方式推导相应程序语义,按需对被测程序分段并交替使用动静态程序分析的方法,成功用于分析缓冲区溢出问题。

据笔者所知,目前还不存在分段式符号分析[11]应用于测试领域的通用方法。由于分段式符号分析中使用线性回归分析技术汇总了源代码不可见的函数代码片段的多次运行的动态信息,而“具体化”方法只执行了被调函数中某一特定的具体值所能执行到的一条路径,理论上,由此分析所得的转移函数相较单纯的“具体化”方法中的一次运行的具体值更准确,能更准确地模拟程序的执行情况和代表相应程序点的变量的符号值。

本文针对混合执行测试中的源代码不可见的函数调用问题,提出分段式混合执行测试方法,把分段式分析方法[11]引入传统混合执行测试中,将符号执行、分段式符号执行以及具体执行方法按需结合,针对符号执行无法分析的代码片段进行动态分析,以此替代简单使用运行时具体值代替符号值的方法,以期进一步缓解源代码不可见的函数调用这一局限性。基于CREST开发sCREST(segmented CREST)系统,实现并评估本文提出的分段式混合执行测试方法。

2 分段式混合执行方法

首先给出一个例子来直观解释分段式混合执行测试方法的工作方式,然后介绍本文在CREST上实现的分段式混合执行测试系统sCREST。

2.1 分段式混合执行方法

一个使用CREST测试,包含strcmp库函数的示例程序如下:

其中,CREST_char(tmp1)表示把tmp1作为符号变量来处理,CREST生成一个char型数据并赋值给tmp1,再把tmp1赋值给pattern数组的元素,表明pattern数组需要CREST为其生成测试数据。程序中if条件中包含一个源代码不可见的库函数strcmp,只有当CREST生成的测试输入等于“test”时,该if条件才会被满足,从而覆盖if分支。

该示例程序在CREST中很难生成覆盖所有分支的有效测试数据,只能迭代一次,覆盖else分支。这是因为strcmp函数的源代码不可见,CREST无法对其符号执行。CREST采取“具体化”方法,具体执行strcmp函数,使用具体值代替符号值构造符号条件,因此虽然pattern数组声明为符号变量,但strcmp的返回值仍然是运行时的具体值。CREST首次运行时的测试值是随机生成的,随机生成测试值“test”来满足if分支的概率很低,且“具体化”后,符号路径条件简化为一个具体值,不存在可被取非的某个符号分支条件,导致CREST只执行一次迭代,测试过程结束。因此“具体化”方法往往只能覆盖else分支,不能产生覆盖if分支的测试输入“test”。

本文提出的分段式混合执行测试方法,当遇到无法符号执行的源代码不可见的函数调用(如此处的strcmp)时,使用分段式符号执行处理:

步骤1截取与strcmp相关的代码片段,包括2个部分:(1)strcmp函数所在的语句strcmp (pattern,"test")。(2)库函数strcmp的参数变量的初始化语句char pattern[NUM_SYM_CHARS+1]。

步骤2分析上下文,提炼分段式符号执行所需的输入变量与输出变量在被测程序和库函数中对应的变量,这里提炼出的输入变量是pattern,输出变量是strcmp的返回值。

步骤3动态执行步骤1中得到的代码片段,并结合步骤2中提炼的输入变量与输出变量进行回归分析。

步骤4将回归分析推导出的输入变量与输出变量之间的符号表达式或者与被处理的函数strcmp等价的代码片段,代入程序体,使用混合执行测试产生系统的测试输入,使混合执行测试过程继续下去。

本文提出的分段式混合执行测试方法可以产生覆盖if和else两个分支的测试数据,而CREST中的“具体化”方法只能覆盖else分支的测试数据。由此可见,分段式混合执行测试方法比传统混合执行测试中使用具体值简化复杂符号条件的“具体化”方法更加准确,生成的测试数据能够覆盖“具体化”方法不能覆盖到的路径(或分支),因而执行更多系统路径,提高系统的分支覆盖。

2.2 sCREST系统

sCREST是在CREST上实现的分段式混合执行测试系统,将符号执行、分段式符号执行和具体执行按需结合。选择CREST基于以下原因:(1)CREST是针对C程序一个广泛认可的代码开源的工具;它对源程序静态插桩实现在运行时从具体执行抽取符号路径条件以实现混合执行,该方法的实现相对简单,因此相对方便在CREST上应用新的技术[12]。 (2)CREST只能对源代码已经被插桩过的函数进行符号执行,对于在编译时源代码不可见的函数,无法对其静态插桩导致无法对其符号执行。CREST使用“具体化”方法处理这类函数,但如果某源代码不可见的函数直接的出现在某个符号分支条件中,或间接影响到某个符号分支的真值,该方法有可能会导致不能产生到达某一特定分支的测试输入,或者会导致“路径分歧”现象迫使测试中止,这些会降低测试数据的分支覆盖。(3)在实际使用CREST测试大型程序时,时常需要手动添加常用的libc库函数的自定义代码[13-14],以便这些源代码不可见的函数可被静态插桩,从而被符号执行,产生到达与这些函数调用相关的分支(或路径)的测试数据,以此提高测试覆盖。但这种手动添加代码不可见的函数的自定义代码的方式效率不高,且也不容易确定需要添加哪些库函数的自定义的代码。

现阶段sCREST针对的是源代码不可见的库函数调用,sCREST是基于CREST实现的,重用CREST的3个主要模块:源代码插桩模块,进行动态符号执行的引擎组件(C++library)和搜索策略模块,本文对动态符号执行引擎中的Symbolic-Interpreter类做部分修改,并增加分段式符号分析组件。sCREST的概要执行流程如图1所示。

图1 sCREST系统的概要执行流程

如图1所示,传统混合执行测试方法中具体执行和符号执行同时进行,首先以一些随机输入值具体执行程序,同时进行动态符号执行,沿着具体执行路径收集符号路径条件,使用搜索策略选取符号条件的某个分支取非,调用约束求解器求解新的符号条件,产生执行新路径的测试输入。在混合执行测试产生测试输入的过程中,sCREST在遇到静态符号执行无法继续的源代码不可见的库函数时,使用分段式符号分析处理,推导出关联模型,将其代入到相应的截取点,使用混合执行测试产生系统的测试输入;同时,具体执行指导系统的执行路径,使混合执行测试过程进行下去。图2显示了sCREST的详细流程,突出说明分段式符号分析,其中的传统混合执行测试的内部细节与图1中的传统混合执行测试相同。

图2 sCREST系统的详细执行流程

在sCREST系统的详细执行流程中,不同组件对源程序进行处理的过程如下:

步骤1首先对被测程序进行预处理,识别出被测程序中接收输入的代码,把这些代码替换为CREST_int,CREST_char等调用,使被测程序可以接收symbolic inputs(使用CREST需要做的前期工作);然后使用插桩模块crestc对程序编译生成完成插桩的可执行文件;最后使用run_crest进行测试执行,生成测试数据。sCREST系统通过对CREST源代码中的SymbolicInterpreter类进行部分修改,使之输出测试中遇到的源代码不可见的函数的信息statement-id号。

步骤2sCREST系统的片段截取组件,实现对源代码不可见的函数相关的代码片段的截取以及函数名称的识别。代码片段包括2个部分:(1)源代码不可见的库函数所在的程序语句;(2)源代码不可见的库函数的参数变量的初始化语句。因为源程序(.c文件)在被crestc编译后会产生插桩后的文件(.cil.c文件),步骤1中输出的库函数的statementid号在其对应的.cil.c文件中是唯一的,所以通过编写perl程序在相应的.cil.c文件中查找该statementid号,确定此代码不可见的函数名称以及其在程序中所在的行号,得出代码片段的第(1)部分;第(2)部分则通过编写perl程序分析识别出库函数的参数变量,然后识别出参数变量的相应的初始化语句而获得。

步骤3根据步骤2识别出的源代码不可见的函数名称,在函数“摘要”库中查找,是否已存在该函数的“摘要”,如果已存在,则直接提取调用其“摘要”;否则,进入步骤4。

步骤4通过提炼输入与输出变量组件,分析上下文,提炼需要分段式符号分析的库函数代码片段的输入变量与输出变量在被测程序中对应的变量(输入变量一般是源代码不可见的库函数的输入参数,输出变量是库函数的返回值变量)。动态执行步骤2得到的源代码不可见的库函数的代码片段的测试单元,并结合当前步骤提炼的分段式符号分析的输入变量与输出变量,进入下一步的回归分析。动态执行的具体过程是,首先根据输入与输出变量以及步骤2得到的代码片段,构建一个可以独立运行的测试单元,然后自动生成输入变量的具体值集合,多次实际动态运行构建的测试单元,同时记录下每次运行的测试输入值及其相应的输出值[11]。

步骤5 经过回归分析组件,推导出输入变量与输出变量之间的符号表达式,或者推导出与被处理的源代码不可见的函数等价的代码片段(通过对步骤4得到的多个输入变量值与其对应的输出变量值,经过回归分析推导出输入变量与输出变量之间的关联模型[11]),并将其代入到程序中,使混合执行测试过程得以继续进行下去。同时将分段式符号分析自动生成的结果作为该函数的摘要保存到函数摘要数据库中。

3 实验与评估

为评估本文的分段式混合执行测试方法的性能,将sCREST应用于5个不同规模的开源应用程序的测试数据生成中。选取Siemens Benchmark Suite[15]中2个程序tcas和replace,其中,tcas是一个飞机防撞系统;replace是其中最大的测试程序,还有3个应用广泛的开源应用程序:gzip-1.2.4,grep-2.2,vim-5.7。所有的实验运行在VMware Workstation 8.0(RAM 2 GB)的ubuntu10.04上,使用的是CREST 0.1.1 (revision132)。宿主配置是Intel Pentium CPU,2.30 GHZ,内存8 GB。

针对每一个被测程序,在设置相同的迭代次数(即插桩程序的运行次数)和使用相同的搜索策略(本文使用深度优先策略dfs)前提下,分别使用sCREST与CREST系统对相同设置的同一程序进行测试,并对比测试情况,以评估本文方法。

本文实验的目的在于检验本文的分段式混合执行测试方法是否能提高测试数据的分支覆盖。采用2个评估指标是sCREST以及CRSET最终能够达到的分支覆盖数和各自的执行时间。由于CREST中存在随机因素,使得同一测试生成命令在不同的时刻运行,最终得到的覆盖分支数有所不同,因此,本文实验把CREST源代码中的随机数发生器的初始化函数srand函数注释掉,使得每次调用rand函数生成的伪随机数序列都是一样的,从而使得同一测试命令在不同的时刻运行最终得到的分支覆盖数相同;由于CREST中同一个测试生成命令在不同时刻运行的执行时间有所不同,因此这里的执行时间记录的是5次运行的平均执行时间。CREST和sCREST的实验对比结果如表1和表2所示。在表1中,dfs后面括号中的数字表示设置的搜索深度;在表2中,相对分支覆盖率=覆盖的分支数/到达的分支数;绝对分支覆盖率=覆盖的分支数/总分支数。

表1 CREST和sCREST系统的分支覆盖数与执行时间对比

表2 CREST和sCREST系统的分支覆盖率对比%

由表1可以看出,本文的分段式混合执行测试方法比传统的混合执行测试达到更高的分支覆盖,而且所有被测程序的测试过程都在一个合理的时间内完成。tcas在花费一些迭代次数生成有效范围内的测试数据后,CREST只执行了tcas中的一条路径,混合执行测试就被迫中止,执行时间不足1s,因此,表1中记为“-”,sCREST执行了tcas程序中的更多条路径,执行时间增加到35 s。

表2中分别对CREST和sCREST的分支覆盖率进行对比,除replace外,其他被测程序,无论是相对分支覆盖率还是绝对分支覆盖率,sCREST比CREST都有所提高。

表1和表2中的数据是实验总体情况,下面对具代表性的被测程序做详细说明。

3.1 tcas程序

tcas需要从程序外部接收12个输入参数,每一个输入参数都需使用atoi函数进行类型转换。本文将每一个输入参数设定为固定长度的符号字符数组,并添加限制条件使CREST和sCREST生成有效范围内的符号变量,提高测试数据的有效性。

从图3可见,tcas在CREST中只执行17次迭代测试过程中止,最终覆盖59个分支(tcas在CREST中的分支覆盖情况如图4所示);而tcas在sCREST中可以执行设定的2 000次迭代,最终覆盖93个分支。这是因为tcas的每一个输入参数必须经atoi函数进行类型转换,且符号路径条件中只有这一个源代码不可见的函数atoi,atoi对输入参数的测试数据的生成有非常重要的作用。CREST首先花费一些迭代用来生成在有效范围内的测试数据,由于atoi的源代码在程序中不可见,CREST无法对其符号执行,使用atoi的具体运行值代替符号值后,使得符号路径条件简化为一个具体值,导致测试过程中止; sCREST使用分段式符号分析方法对atoi处理后,使CREST中原本中止的测试过程继续进行,明显提高了被测程序的分支覆盖数。

图3 tcas程序的分支覆盖情况对比

图4 tcas程序在CREST系统中的分支覆盖情况

表1表明,tcas在sCREST中所需的测试执行时间比CREST有所增加,是因为tcas在CREST中使用“具体化”方法后,符号路径条件被简化为一个具体值,迫使只执行一条路径就结束了;sCREST使原本异常中止的混合执行过程继续进行,执行更多次迭代,生成更多的测试数据,使得测试时间有所增加。

3.2 gzip-1.2.4程序

gzip是一个开源的文件压缩程序。本文把gzip-1.2.4中的被解压缩的文件参数设置为某一固定文件,把gzip-1.2.4程序接收的命令行选项参数设置为符号变量,使工具为这些变量生成测试数据,并添加额外的限制条件使工具生成有效合理的测试数据。由图5可以看出,随着迭代次数的增加, sCREST系统可以显著提高被测程序的分支覆盖数。

图5 gzip-1.2.4程序的分支覆盖情况对比

3.3 grep-2.2程序

grep是一个开源C程序,用于使用正则表达式进行文本搜索。本文把程序中正则表达式设置为长度为5的符号字符数组,被搜索的文本设置为长度为40的符号字符数组,使用默认的匹配选项。为方便实验对比,此处设置与文献[3]中对grep-2.2程序的设置相同。

从图6中可见,sCREST比CREST能够覆盖更多的分支。但sCREST对grep-2.2的分支覆盖的提高幅度不如tcas程序明显,是因为虽然在测试grep-2.2时符号路径条件中出现一些库函数,但是在CREST中使用“具体值”简化后,符号路径条件中仍然存在其他的分支可以被取非,混合执行测试过程可以继续进行,没有出现中止的情况。

图6 grep-2.2程序的分支覆盖情况对比

在sCREST系统中,对grep-2.2中的源代码不可见的库函数进行分段式符号执行,因而库函数使用具体值代替符号值的次数有所减少,提高了符号路径条件的准确性,但是被分段式符号分析的库函数对被测系统行为的影响程度以及对测试数据的生成的影响程度不是很大,所以,分支覆盖数并没有得到非常明显的提高。

在replace程序以及大型开源程序vim-5.7[3]上进行实验,结果如表1所示。可以看出,sCREST也能够比CREST系统覆盖更多的分支。但由于篇幅限制,其分支覆盖变化不在此给出。

综上,从表1、表2及各个被测程序的分支覆盖变化曲线图(图3～图6)中可以发现,分支覆盖数提高的幅度并不是与被测程序的代码规模成正比。被分段符号分析处理的源代码不可见的库函数对整个程序行为的影响程度对分支数目的提高幅度起到重要的作用。库函数对程序行为的影响包括该该库函数是否对测试数据生成有影响(CREST为被定义为符号变量的变量生成测试数据,库函数是否直接或间接地对符号变量进行操作)以及库函数在程序中出现的次数。如果某个库函数在程序中出现多次,更重要的是它对符号变量的测试数据的生成具有影响作用,那么sCREST用分段式符号分析方法对这些库函数进行处理后,分支覆盖数可以得到明显的提高。

总之,分段式混合执行测试方法提高分支覆盖的幅度取决于被分段式符号分析的函数对被测系统行为的影响程度以及其对测试数据的生成的影响程度,影响程度越大,分支覆盖数提高越明显。

从表1中可见,sCREST系统所需的执行时间比CREST有所增加,经分析原因有2个:

(1)当CREST中的“具体化”方法处理源代码不可见的函数导致混合执行测试中止时,sCREST会使这些异常中止的混合执行继续进行,执行更多次迭代,致使执行时间增加(CREST使用“具体化”处理源代码不可见的函数导致测试中止一般有2种情况:1)“具体化”后的极端情况是符号路径条件被简化为一个具体值;2)由于“具体化”方法只对源代码不可见的被调函数进行具体执行,计算其运行时的具体值,无法对其跟进符号执行,导致没有考虑被调函数的表达式,因此得到的符号路径条件不完备,有可能使下次迭代程序的实际执行路径与预期执行路径不一致,导致路径分歧,出现“Predicate failure”错误,迫使CREST测试过程中止)。

(2)当CREST中使用“具体化”方法处理源代码不可见函数未导致测试过程异常中止时,由于在sCREST中对源代码不可见的函数进行分段式符号分析,比直接使用源代码不可见的库函数的某一具体运行值代替符号值需要更多的时间,因此sCREST的执行时间会增加。实验数据也表明,虽然sCREST的测试执行时间有所增加,但都是在可以接受的范围内。

4 结束语

本文针对混合执行测试中的源代码不可见函数调用问题,提出分段式混合执行测试方法,将分段式分析引入传统混合执行测试,按需结合符号执行、分段式符号执行以及具体执行,针对符号执行无法分析的源代码不可见函数代码片段进行动态分析,缓解了传统混合执行测试中的源代码不可见的函数调用处理的局限性;在CREST上实现sCREST系统,对本文提出的分段式混合执行测试方法与传统混合执行方法进行对比,结果显示本文方法提高了测试数据的分支覆盖数,验证了其可行性和有效性。

本文工作是分段式符号分析应用于混合执行测试的初步探索,现阶段sCREST系统针对的是源代码不可见,且分段式符号分析能够处理的标准库函数调用,但理论上,对于其他工作在源代码层的、通过对源程序静态插桩以实现从具体执行获取符号路径条件的混合执行测试工具,该方法也具有可行性。对分段式混合执行测试方法产生的测试数据进行检错能力评估,是下一步的工作。

[1] Godefroid P,KlarlundN,SenK.DART:Directed Automated RandomTesting[J].ACMSIGPLAN Notices,2005,40(6):213-223.

[2] Sen K,Marinov D,Agha G.CUTE:A Concolic Unit Testing Engine for C[J].ACM SIGSOFT Software Engineering Notes,2005,30(5):263-272.

[3] Burnim J,Sen K.Heuristics for Scalable Dynamic Test Generation[C]//Proceedings of ASE’08.L’aquila, Italy:[s.n.],2008:443-446.

[4] 崔展齐,王林章,李宣东.一种目标制导的混合执行测试方法[J].计算机学报,2011,34(6):953-964.

[5] 刘 杰,王嘉捷,欧阳永基,等.基于污点指针的二进制代码缺陷检测[J].计算机工程,2012,38(24): 46-49.

[6] Qu Xiao,Robinson B.A Case Study of Concolic Testing ToolsandTheirLimitations[C]//Proceedingsof ESEM’11.Banff,Canada:IEEE Press,2011:117-126.

[7] Godefroid P.Higher-order Test Generation[C]//Proceedings of PLDI’11.San Jose,USA:ACM Press,2011: 258-269.

[8] Godefroid P.CompositionalDynamicTestGeneration[C]//Proceedings of POPL’07.Nice,France: ACM Press,2007:47-54.

[9] 林锦滨,张晓菲,刘晖.符号执行技术研究[C]//全国计算机安全学术交流会论文集.丽江:[出版者不详], 2009:404-408.

[10] Chipounov V,Kuznetsov V,Candea G.S2E:A Platform for In-vivo Multi-Path Analysis of Software Systems[J]. ACM Transactions on Computer Systems,2012,30(1):1-49.

[11] Le W.Segmented Symbolic Analysis[C]//Proceedings of ICSE’13.San Francisco,USA:IEEE Press,2013: 212-221.

[12] Kim M,Kim Y,Jang Y.Industrial Application of Concolic TestingonEmbeddedSoftware:CaseStudies[C]// Proceedings of ICST’12.Montreal,Canada:IEEE Press, 2012:390-399.

[13] Kim Y,Kim M,Kim Y J,et al.Industrial Application of Concolic Testing Approach:A Case Study on Libexif by Using CREST-BV and KLEE[C]//Proceedings of ICSE’12.Zurich,Switzerland:IEEEPress,2012: 1143-1152.

[14] Jacob B.External Function Support[EB/OL].(2010-07-07).https://groups.google.com/forum/#1topic/ crest-users/UxRhhbSqNlk.

[15] Harrold J,Rothermel G.Siemens Programs,HR Variants [EB/OL].[2014-02-16].http://www.cc.gatech.edu/ aristotle/Tools/subjects/.

编辑 金胡考

Segmented Code Testing Based on Concolic Testing and Dynamic Analysis

LIU Chunhong,XU Lihua,YAN Ting,YANG Zongyuan
(Department of Computer Science and Technology,East China Normal University,Shanghai 200241,China)

Function calls with unavailable source codes can not be appropriately handled by symbolic execution in traditional concolic testing.To solve this problem,this paper proposes a segmented concolic testing method,which weaves,by demand,symbolic execution,segmented symbolic execution and concrete execution throughout the testing process.These function calls are treated as separate code segments,dynamically executed and analyzed to derive their corresponding program semantics.To demonstrate the effectiveness of the proposed method,this paper implements sCREST,a segmented concolic testing system based on CREST,and experiments with five open source systems. Experimental results show that segmente concolic testing is able to generate test data that covers more branches than that of the traditional approaches.

software testing;concolic testing;segmented symbolic analysis;dynamic analysis;test data generation; branch coverage

刘春宏,徐立华,颜 婷,等.基于混合测试和动态分析的分段代码测试[J].计算机工程, 2015,41(2):63-69,80.

英文引用格式:Liu Chunhong,Xu Lihua,Yan Ting,et al.Segmented Code Testing Based on Concolic Testing and Dynamic Analysis[J].Computer Engineering,2015,41(2):63-69,80.

1000-3428(2015)02-0063-07

:A

:TP311.5

10.3969/j.issn.1000-3428.2015.02.013

上海市自然科学基金资助项目(13ZR1413000)。

刘春宏(1988-),女,硕士研究生,主研方向:软件测试;徐立华(通讯作者),副教授、博士;颜 婷,硕士研究生;杨宗源,教授、博士生导师。

2014-03-12

:2014-04-15E-mail:lhxu@cs.ecnu.edu.cn