可执行程序测试用例集二进制代码覆盖率自动化评估方法

摘要

本发明提供了一种可执行程序测试用例集二进制代码覆盖率自动化评估方法，包括：第一步骤，执行对具有二进制代码表达形式的可执行程序的静态分析，在静态分析中，将二进制代码表达形式通过反汇编转换为汇编指令表达形式，随后对具有汇编指令表达形式的可执行程序进行基本块划分；第二步骤，利用测试用例执行程序过程的动态分析，在动态分析中执行插桩处理以捕获执行轨迹，并在插桩处理中执行过滤操作以进行基本块过滤以去除可执行程序的外部指令；第三步骤，利用可执行程序的虚拟内存地址通过匹配第一步骤的静态分析结果与第二步骤的动态分析结果来评估测试用例集的二进制代码覆盖率。

说明书

技术领域

本发明涉及计算机领域，更具体地说，本发明涉及一种可执行程序的测试 用例集二进制代码覆盖率自动化评估方法。

背景技术

代码覆盖是通过人工或工具生成的测试用例能够让被测程序达到或执行的 过程状态的数量，这是研究人员在测试领域进行开拓性研究的一个重要概念。 代码覆盖率是一种用于描述通过测试用例对程序进行测试所达到的程度的度 量。它是软件开发以及测试人员经常用来决定针对应用程序的测试是否充分的 依据之一，也是评估测试质量的重要指标。

可执行程序指加载到内存中可以完成指定任务的文件。可执行程序由二进 制代码构成，包含文件的基本信息以及可执行的指令集合。可执行程序由源代 码通过编译器生成。源代码需要先通过编译操作生成目标代码，再将目标代码 进行链接操作后得到可执行程序。

通常情况下，对程序的测试用例集代码覆盖率的评估需要在拥有源代码的 基础上，在源代码中添加调试代码以获取测试用例执行时的测试用例集代码覆 盖信息。在实际工作中，由于可能存在商业机密，软件的源代码并非公开，测 试人员无法直接对软件的源代码进行测试，这极大限制了面向源代码的测试用 例集代码覆盖技术的使用。另外，源代码的测试用例集代码覆盖情况和由源代 码生成的可执行程序的测试用例集二进制代码覆盖情况并不一定相同。这是由 于由源代码生成可执行程序的过程中，编译器可能对其进行了编译优化，修改 了其中某些代码的语义。因此，在需要评估可执行程序的测试用例集二进制代 码覆盖率的场合下，不能用源代码覆盖率替代。因而可执行程序的测试用例集 二进制代码覆盖相关技术的研究对实际测试工作来说是很有需要的。

对可执行程序的测试用例集二进制代码覆盖率评估有较大难度，目前尚未 有系统的方法进行指导。传统的测试用例集代码覆盖率评估更多的面向源代码 层面，源代码层面的代码覆盖率分析依赖于编程语言。例如，目前较为成熟的 面向C、C++的代码覆盖率评估的工具或商业软件：基于gcc调试信息的Gcov工 具、Lcov工具；IBM面向单元测试的覆盖率测试工具PureCoverage等。目前面 向Java的代码覆盖率评估工具或商业软件：印度的Raghu等研究人员开发的 JavaCode Coverage工具；Cenqua公司商业化Java测试工具Clover等。可执 行程序的测试用例集二进制代码覆盖率评估依赖于形成可执行程序的二进制代 码，人工解读二进制代码较为困难，一般转换成语义相同的可读语言，如汇编 指令。目前尚未出现通过分析汇编指令评估测试用例集代码覆盖率的自动化系 统方案或成熟的工具支持。

发明内容

本发明所要解决的技术问题是针对现有技术中存在上述缺陷，提供一种可 执行程序的测试用例集二进制代码覆盖率自动化评估方法，其能够结合针对可 执行程序的静态分析与动态分析，自动化评估测试用例集的二进制代码覆盖率。

为了实现上述技术目的，根据本发明，提供了一种可执行程序测试用例集 二进制代码覆盖率自动化评估方法，包括：

第一步骤：执行对具有二进制代码表达形式的可执行程序的静态分析，在 静态分析中，将二进制代码表达形式通过反汇编转换为汇编指令表达形式，随 后对具有汇编指令表达形式的可执行程序进行基本块划分；

第二步骤：利用测试用例执行程序过程的动态分析，在动态分析中执行插 桩处理以捕获执行轨迹，并在插桩处理中执行过滤操作以进行基本块过滤以去 除可执行程序的外部指令；

第三步骤：利用可执行程序的虚拟内存地址通过匹配第一步骤的静态分析 结果与第二步骤的动态分析结果来评估测试用例集的二进制代码覆盖率。

优选地，第一步骤中的基本块划分包括：对通过反汇编转换得到的汇编文 件进行一次顺序扫描，寻找基本块的入口和基本块的出口，并记录基本块信息， 所述基本块信息包括基本块的入口以及基本块的出口。

优选地，基本块的入口是基本块的第一条汇编指令，基本块的出口是基本 块的最后一条汇编指令。

优选地，在第二步骤中，过滤操作包括：对于测试用例执行过程覆盖到的 每一个基本块，如果基本块的入口虚拟内存地址处于可执行程序的内部指令范 围，则记录基本块信息作为执行轨迹的一部分。

优选地，如果基本块的入口虚拟内存地址不处于可执行程序的内部指令范 围，则丢弃该基本块信息而不记录基本块信息作为执行轨迹的一部分。

优选地，第一步骤得到的可执行程序的基本块信息以键值对形式存储；第 二步骤中得到的执行轨迹中的基本块信息以键值对形式存储；而且在第三步骤 中通过将第一步骤得到的可执行程序的基本块信息的键值对与第二步骤中得到 的执行轨迹中的基本块信息的键值对进行对比统计来确定程序运行过程中覆盖 的基本块。

源码语义并非等价于编译后发布的可执行程序的指令语义，可执行程序的 测试用例集二进制代码覆盖率评估相对于面向源代码的评估更能体现测试用例 集代码覆盖的真实情况。因此，本发明的该方法相对于传统面向源代码的代码 覆盖率评估有更高的准确性。该方法能确定由测试用例驱动程序执行的代码覆 盖情况。本发明设计二进制代码覆盖率评估的流程，并将其自动化。该方法的 评估结果提供了分析测试用例质量的必要数据，从而可进一步分析以提高测试 用例的质量。

附图说明

结合附图，并通过参考下面的详细描述，将会更容易地对本发明有更完整 的理解并且更容易地理解其伴随的优点和特征，其中：

图1示意性地示出了根据本发明优选实施例的可执行程序测试用例集二进 制代码覆盖率自动化评估方法的流程框架图。

图2示意性地示出了根据本发明优选实施例的采用的划分基本块实例图。

需要说明的是，附图用于说明本发明，而非限制本发明。注意，表示结构 的附图可能并非按比例绘制。并且，附图中，相同或者类似的元件标有相同或 者类似的标号。

具体实施方式

为了使本发明的内容更加清楚和易懂，下面结合具体实施例和附图对本发 明的内容进行详细描述。

本发明提出了一种可执行程序10的测试用例集二进制代码覆盖率评估流 程，采用匹配可执行程序的静态分析结果与测试用例集参与的动态分析结果评 估二进制代码覆盖率。

图1示意性地示出了根据本发明优选实施例的可执行程序测试用例集二进 制代码覆盖率自动化评估方法的流程框架图。如图1所示，根据本发明优选实 施例的可执行程序测试用例集二进制代码覆盖率自动化评估方法涵盖如下三个 步骤：

第一步骤S1：执行对具有二进制代码表达形式的可执行程序10的静态分 析，在静态分析中，将二进制代码表达形式通过反汇编S10转换为汇编指令表 达形式，随后对具有汇编指令表达形式的可执行程序10(即，汇编文件)进行 基本块划分S11(例如，根据基本块的定义对可执行程序10进行基本块划分)；

第二步骤S2：利用测试用例20执行程序过程的动态分析，在动态分析中执 行插桩处理S20以捕获执行轨迹，并在插桩处理S20中执行过滤操作S21以进 行基本块过滤以去除可执行程序10的外部指令；

第三步骤S3：利用可执行程序10的虚拟内存地址通过匹配第一步骤S1的 静态分析结果与第二步骤S2的动态分析结果来评估测试用例集的二进制代码覆 盖率。

下面将描述本发明的具体实施示例。

在具体实施例中，第一步骤S1中的对可执行程序的静态分析包括：

反汇编：

对可执行程序的静态分析是指在不运行可执行程序的状态下(即离线状态) 对可执行程序的内容进行分析。可执行程序的内容是二进制代码。二进制代码 难以分析，通常将二进制代码的表达形式通过反汇编技术转换为汇编指令的表 达形式。将可执行程序进行静态分析的效率依赖于反汇编技术的准确度与速度。 反汇编技术较为成熟，目前较为主要的两种反汇编算法是线性扫描反汇编和递 归下降反汇编，也有结合两种算法的改进算法。采用成熟的反汇编技术将可执 行程序的二进制代码转换为可分析的汇编指令。

基本块划分：

基本块是程序顺序执行的语句序列，其中只有一个入口和一个出口，入口 就是块的第一个语句，出口就是块的最后一个语句。对一个基本块来说，执行 时只从其入口进入，从其出口退出。根据定义，程序正常执行到某个基本块时， 会将基本块中包含的指令毫无例外的顺序执行一遍，因此覆盖了该基本块就等 于覆盖了基本块中包含的所有指令。可执行程序的汇编指令数量庞大，这将影 响测试用例代码覆盖的评估效率。将汇编指令集合根据基本块定义以基本块为 单位划分程序可以大大提高评估效率。

在具体实施例中，基本块划分方法可以包括：对通过反汇编技术得到的汇 编文件进行一次顺序扫描，寻找基本块的入口(基本块的第一条汇编指令)与 出口(基本块的最后一条汇编指令)，并记录基本块的入口、出口、块长度(指 令数量)等信息。

图2示出了划分基本块实例图。

在具体实施例中，以下三种指令可以作为基本块的入口：

代码片段标签(_start，_main等出现在代码片段前的标志)的下一条指令。

CALL指令在指令顺序流的下一条指令。

1.跳转语句在指令顺序流的下一条指令。

在具体实施例中，以下四种指令可以作为基本块的出口：

1.代码片段的最后一条指令。

2.CALL指令。

3.跳转指令。

4.返回指令。

在具体实施例中，第二步骤S2中利用测试用例执行程序过程的动态分析可以 包括：

(a)插桩处理S20：

插桩是在执行过程中或完成链接操作后的程序中插入额外的代码以获得程 序在执行时行为的信息的技术。采用插桩技术可以获取测试用例执行程序过程 中的代码覆盖情况。目前二进制代码插桩技术较为成熟，且有开源或半开源工 具支持，如Dyninst、Pin、Valgrind等。对可执行程序的插桩一般过程如下：

1.初始化插桩引擎，将参数输入到引擎中，参数包括可执行程序、用例信息 等。

2.将自定义插桩函数注册到插桩例程中。

3.确定二进制代码中调用插桩例程的位置。

4.向引擎注册一个结束函数，在可执行程序执行结束完毕时调用该函数。

5.启动插桩引擎。

以基本块为单位检测测试用例执行可执行程序时的代码覆盖情况，即记录 测试用例执行可执行程序过程中覆盖的基本块信息，插桩粒度为指令级。自定 义插桩函数伪代码如下：

程序执行某条指令后，首先判断当前执行的汇编指令类型，如该类型属于 基本块的出口指令类型，则将该指令的下一条指令作为下一个基本块的入口。 然后保存当前基本块的信息，继续执行程序。整个过程在程序执行过程中迭代 执行，被记录的基本块是程序执行过程中覆盖的基本块。基本块信息以键值对 存储，键为基本块的入口指令地址，值为基本块其他信息的组合：包括基本块 的出口地址、基本块大小、基本块的编号以及被覆盖的次数等。

(b)基本块过滤的过滤操作S21：

可执行程序在执行过程中可能会执行到动态链接库指令或系统调用指令。 动态链接库是可以被多个程序共享的程序模块，其中封装了一些可以被共享的 资源或例程，其链接方式是动态的。系统调用是运行在用户空间的程序向操作 系统请求更高权限的服务的方式，它将应用程序的请求传给内核，调用相应的 内核函数完成所需的处理，把处理结果返回给应用程序。两种指令并非可执行 程序的内部指令，执行过程中记录这些指令将会影响代码覆盖率评估的准确性。 因此，需要过滤执行过程中遇到的动态链接库指令或系统调用指令，可通过这 些指令的特殊地址进行过滤。

以Linux32位操作系统为例，对于每一个进程，操作系统都会为其分配4GB 的虚拟内存，而并不是真实的物理内存。在相同环境下，每个进程内存分配是 相对固定的。因此，可以根据指令地址分辨指令属于程序的内部指令还是外部 指令。例如，虚拟内存地址中，0xc0000000-0xFFFFFFFF地址区段为内核空间， 程序在系统调用后就在内核空间中执行。0x00000000-0xbFFFFFFF地址区段为 用户空间，其中有一块内存映射区，区中包含载入的动态链接库指令。执行程 序载入的动态链接库地址分布于0xb7000000–0xb8000000这个区段。可执行程 序代码段起始地址为0x08048000，代码段的大小不固定。从0x08048000内存地 址开始连续分配的内存段依次是代码段、数据段、BSS段、堆，堆的内存地址 不超过0x40000000。在所有执行指令中根据内存地址的范围就可以分辨出该程 序的代码段指令，作为内部指令。而不再这个地址范围内的指令则为执行程序 的外部指令，可过滤。

过滤操作S21在插桩处理S20中执行：对于测试用例执行过程覆盖到的每 一个基本块，如果基本块的入口虚拟内存地址处于可执行程序的内部指令范围 则记录基本块信息作为执行轨迹的一部分，否则丢弃该基本块信息。

在具体实施例中，第三步骤S3中的测试用例集二进制代码覆盖率评估可包 括：

可执行程序通过第一步骤S1生成的汇编文件中，汇编指令地址为虚拟内存 地址。测试用例通过第二步骤S2获取执行过程中覆盖的指令，其指令地址也是 虚拟内存地址。同一个程序无论处于未执行状态还是执行状态，为其分配的4GB (或其它适当大小的)虚拟内存空间中指令地址分布是固定的。利用这一特点， 可将对可执行程序由上述两个步骤获取的指令信息通过虚拟内存地址的匹配取 得代码覆盖信息，进而评估测试用例的代码覆盖率。

第一步骤S1得到的可执行程序的基本块信息以键值对形式存储；第二步骤 S2中得到的执行轨迹中的基本块信息以键值对形式存储；而且在第三步骤中通 过将第一步骤S1得到的可执行程序的基本块信息的键值对与第二步骤S2中得 到的执行轨迹中的基本块信息的键值对进行对比统计来确定程序运行过程中覆 盖的基本块(即，程序执行结束后在第三步骤S3中通过键值对的对比统计可以 确定程序运行过程中覆盖过哪些基本块)。

二进制代码层面可计算两种覆盖率：基本块覆盖率和指令集覆盖率。设用 例在可执行程序的执行过程中覆盖的基本块集合与指令集合分别为BB_cover， ，可执行程序的基本块集合与指令集合分别为，，则基本块覆 盖率及指令集覆盖率的计算公式如下：

其中，第一步骤S1可以得到可执行程序的所有内部指令的基本块信息，其 中包括每个基本块包含的指令数量；第二步骤S2中记录测试用例执行过程中覆 盖的基本块。对每个基本块按正整数编号，记第i个基本块所包含的指令数量为 。则公式中的可以通过以下公式得到。同样的方法可以计算出 [Inst_cover]。

由第一步骤S1得到BB_total，每个基本块所包含的指令数量，然后通过 第二步骤S2执行测试用例获取测试用例覆盖的基本块信息，统计后得到BB_cover。 根据上述公式计算出测试用例的代码覆盖率BBC和INC。

对于测试用例集合的代码覆盖率评估，将测试用例集中每个测试用例的基 本块覆盖信息进行合并。对每个基本块都按正整数编号，可以根据它们的编号 区分不同的基本块，进而基本块的覆盖情况可以用整数集合表示。因此，对于 用例集合的基本块覆盖情况就可以通过整数集合之间的逻辑运算表示。例如某 个二进制代码一共有500个基本块，对基本块编号后的基本块集合 BB_total＝{1，2，3，...，499，500}。用例A执行该二进制代码后覆盖了5个基本块，设覆盖 的基本块集合BB_cover：A＝{1，2，4，8，200}；用例B执行该二进制代码后覆盖了7个基本 块，设覆盖的基本块集合BB_cover：B＝{1，3，4，16，32，64，200}。用例A与用例B一共覆盖了 9个不同的基本块，即BB_cover：A∪BB_cover：B＝{1，2，3，4，8，16，32，64，200}；它们都覆盖了3个 同样的基本块，即BB_cover：A∩BB_cover：B＝{1，4，200}。对于用例集A{a₁，a₂，a₃，...，a_n}，其基 本块的覆盖集合。通过BBC或INC的计算公式 可得到用例集合A的二进制代码覆盖率。

【具体实例】

为了使本技术领域的人员更好地理解本发明中的技术方案，下面将描述本 发明方案的应用实施例，显然，所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的 所有其他实施例，都应当属于本发明保护的范围。

本发明的代码覆盖率评估方法可以获得对可执行程序进行测试的测试用例 集的二进制代码覆盖率信息。通过该方案开发的系统可以将二进制代码覆盖率 的评估流程自动化。系统导入可执行程序进行静态分析，然后导入测试用例集， 测试用例集在系统中执行该程序后可得到相应的二进制代码覆盖率评估结果。

以linux系统的某个ELF格式程序x为例。对程序x进行反汇编，得到x 程序的反汇编文件。扫描反汇编文件，以本发明描述的基本块划分准则划分出 500个基本块，令基本块集合为C_x，将这些基本块按照整数编号 每个基本块均包含2条指令。测试用例集S_x包含两个测试 用例s₁和s₂。通过插桩得到两个测试用例各自的基本块覆盖情况 将通过静态分析得到的C_x与通过动态分 析得到的s₁、s₂的基本块覆盖情况进行匹配，采用公式计算得到BBC_s1＝1.0％， BBC_s2＝0.8％，INC_s1＝1.0％，INC_s2＝0.8％。测试用例集的基本块覆盖情况通过公式计算得到BBC_sx＝1.2％，INC_sx＝1.2％。最 终通过本发明获得测试用例集S_x的二进制代码覆盖率：基本块覆盖率为1.2％， 指令集覆盖率为1.2％。

该发明可应用于模糊测试中。模糊测试是测试用例导向的测试方法，其实 现容易，但由于测试用例生成的数量和质量的限制，模糊测试方法存在比较明 显的缺陷。模糊测试生成测试用例的策略盲目性较大，测试用例在代码覆盖方 面的多样性不能保证，不能确定大量的测试用例是否有效；执行模糊测试时， 存在不能确定模糊测试何时终止的问题。采用该技术评估测试用例覆盖率可作 为指导模糊测试生成高覆盖率测试用例的量化标准，作为评价模糊测试质量的 重要依据，并且能克服当前几个模糊测试仍然存在的问题。例如对于x程序通 过模糊测试生成的用例集合S_x，若设置某次模糊测试终止条件为测试用例集基 本块覆盖率1.0％，因为S_x的基本块覆盖率大于这个条件，模糊测试可以终止。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来完成，所述的程序可存储于计算机可读取存储介质中， 该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介 质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储 记忆体(Random Access Memory，RAM)等。

此外，需要说明的是，除非特别指出，否则说明书中的术语“第一”、“第 二”、“第三”等描述仅仅用于区分说明书中的各个组件、元素、步骤等，而不 是用于表示各个组件、元素、步骤之间的逻辑关系或者顺序关系等。

可以理解的是，虽然本发明已以较佳实施例披露如上，然而上述实施例并 非用以限定本发明。对于任何熟悉本领域的技术人员而言，在不脱离本发明技 术方案范围情况下，都可利用上述揭示的技术内容对本发明技术方案作出许多 可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本发 明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、 等同变化及修饰，均仍属于本发明技术方案保护的范围内。