自动化测试实验：基于变异测试的模糊器评估

已于 2023-01-11 14:09:01 修改
阅读量830 收藏 2
点赞数
分类专栏： 实战项目 文章标签： 测试工具
于 2022-12-06 14:33:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/KKKEVVINNN/article/details/128202094
版权

​
简述：模糊测试是一种重要的软件测试技术，得到了学术界和工业界的广泛关注。近年来，关于模糊测试的研究不断涌现。实现模糊测试的程序称为模糊器（Fuzzer）。面对如此众多的 Fuzzer，如何准确、有效地评估 Fuzzer 的性能成了一项值得关注的难题。本文从变异杀死的角度对 Fuzzer 进行评估。
实验流程：编写脚本，利用变异测试工具重新运行模糊测试的产生的测试输入，从变异测试的角度（变异得分）评估 Fuzzer 的性能，工具：AFL（Fuzzer） + Mull（变异测试工具）
测试对象：所有 Real-world Projects
步骤：（1）利用 AFL 对实验对象进行模糊测试，产生测试输入；（2）利用Mull 复现 AFL 产生的测试输入，记录变异杀死情况；（3）编写脚本对运行结果进行分析，绘制统计图。

实验过程报告：

AFL过程解析

AFL对原程序进行模糊测试产生的用例分为两类：

1.一类会让原程序报错，这类测试用例存于crashes文件夹中。
2.另一类探明了原程序新的执行路径，这类测试用例存于queue文件夹中。

mull过程解析

按照定义好的变异算子，mull 先对源程序变异，得到变异体，利用变异体去衡量AFL产生的测试用例质量，分为三类情况：

1.AFL产生的测试用例会使变异体崩溃（变异体被杀死）
2.AFL产生的测试用例会使变异体输出和原程序不一样的结果（差分测试思路，同样导致变异体被杀死）
3.AFL产生的测试用例会使变异体输出和原程序一样的结果(变异体存活)
衡量指标

变异得分，即为所有被杀死的变异体除以变异体总数。变异得分越高则表明 AFL 效果越好。

注意：由于mull对每个变异体的执行过程高度封装，难以进入到子进程内部去修改运行逻辑，因此我们将变异被杀死的情况1和情况2分别进行实验。

主要工作：

在这里插入图片描述

硬件配置

服务器：华为云服务器 2核 CPU 4G 内存 50M 带宽 40G 云存储空间 Ubuntu 20.04 操作系统。

软件环境

操作系统：Ubuntu 20.04
C++项目构建：clang 12
脚本版本：python 3.8

测试源程序

在这里插入图片描述

Fuzzing 配置

fuzzer
afl-2.52b
补充库
bison 3.5.1
texinfo 6.7.0

实验过程解析

AFL

AFL的运行流程如下图：
在这里插入图片描述

AFL工作流程
①从源码编译程序时进行插桩，以记录代码覆盖率（Code Coverage）；
②选择一些输入文件，作为初始测试集加入输入队列（queue）；
③将队列中的文件按一定的策略进行“突变”；
④如果经过变异文件更新了覆盖范围，则将其保留添加到队列中;
⑤上述过程会一直循环进行，期间触发了crash的文件会被记录下来。
我们在实验过程中大致遵循上述流程，步骤如下：
1.下载
从AFL官网下载AFL。
2. 安装
将压缩包解压完成之后，进入到其目录下打开终端。

make
sudo make install

如果在该目录下，出现了afl-fuzz的可执行文件，说明安装成功。
3. 模糊测试实验–以readelf为例
下载binutils，完成后解压进入其目录。
必须修改编译器环境为afl-gcc和afl-g++，在大部分的源码编译插桩中基本都需要这一步。

CC=~/.../afl-gcc CXX=~/.../afl-g++ ./configure  //替换为自己afl的目录
make

>mkdir fuzz_in
>mkdir fuzz_out
>~/../afl-fuzz -i fuzz_in -o fuzz_out binutils/readelf -a @@
AFL结果

输出文件夹fuzz_out内部结构如下：
在这里插入图片描述

  1. crashes：引起原程序崩溃的测试用例；
  2. queue：能探明原程序新的执行路径的测试用例；
  3. plot_data：按时间顺序存储了afl执行过程，用于绘图；
  4. hangs：导致目标超时的独特测试用例；
  5. fuzzer_stats：afl-fuzz的运行状态。
    选择说明：
    本实验后续基本使用 queue 中的用例作为变异测试的用例输入。这是有缺陷的，因为queue文件夹中存放的是所有具有独特执行路径的测试用例，一般并不会导致变异杀死，因此变异得分总体较低。但是crashes文件夹中的测试用例过少。权衡之后，我们更多衡量queue文件夹中的测试用例质量。
对AFL用例筛选:

由AFL得到对readelf分支全覆盖的用例，使用脚本筛选出可正确执行的部分用例并记录。

python3 select.py ./readelf

运行select.py脚本，尝试运行所有模糊输入，找出使其不崩溃的模糊输入。

import sys
import subprocess
import os
# select.py
test_executable = sys.argv[1]


path = "./fuzz_out/queue" #文件夹目录
files= os.listdir(path) #得到文件夹下的所有文件名称
s = []
for file in files:
    if not file.endswith(".elf"):
        os.rename(path+"/"+file,path+"/"+file+".elf")
record = open("./fuzz_out/correct","w+")
recordE = open("./fuzz_out/error","w+")
for file in files: #遍历文件夹
    if not os.path.isdir(file) and file!=".state": #判断是否是文件夹，不是文件夹才打开
        try:
            subprocess.run([test_executable, "-a",path+"/"+file], check=True)
            record.write(file+'\n')
        except:
            recordE.write(file+'\n')
            
record.close()

变异测试

变异测试是一种基于故障的软件测试技术。它通过计算变异分数来评估测试套件的质量。它通过创建原始程序、和其稍微修改的版本（称为变异体），并针对每个版本运行测试套件来实现评估测试套件。如果测试套件检测到变更，则认为变异体已被杀死，否则该变异体得到存活。如果至少有一项测试使得运行失败，那么变异体就会被杀死。
mull作为变异测试工具，先对源程序变异，得到变异体。利用AFL的输出作为测试套件，衡量其质量。变异得分，即为所有变异体在这个测试用例组合的通过率越高，则AFL产生的测试套件的质量越好。
​变异测试运行示例
以下流程均以readelf为例。
1.首先需要 配置&编译&插桩，命令如下：

export CC=clang-12 
export CXX=clang++-12 //更改编译器环境
./configure  CFLAGS="-O0 -fexperimental-new-pass-manager -fpass-plugin=/usr/lib/mull-ir-frontend-12 -g -grecord-command-line -fprofile-instr-generate -fcoverage-mapping"

make

2.通过编写脚本 test.py 使得测试能够自动化进行,命令如下：

mull-runner-12 ./readelf -ide-reporter-show-killed   -test-program=python3 -- test.py ./readelf

test.py

import sys
import subprocess
import os

test_executable = sys.argv[1]


path = "./fuzz_out/queue" #文件夹目录
file = open("./fuzz_out/correct","r")
records = file.read().splitlines()
records = records[200:210]
for record in records:
    subprocess.run([test_executable, "-a",path+"/"+record], check=True)
file.close()

3.运行结果截图：
在这里插入图片描述

差分测试

思路：将AFL产生的未导致原程序崩溃的测试用例在原程序中的运行结果存储下来（利用select.py脚本），并且将同一测试用例在变异体中的运行结果存储下来（利用test.py脚本）。比较同一用例在原程序和变异体上运行的结果，若不同，则该变异体被杀死，否则该变异体存存活（利用differential_comparing.py脚本）。

脚本如下：
select.py

import sys
import subprocess
import os

test_executable = sys.argv[1]


path = "./fuzz_out/queue" #文件夹目录
files= os.listdir(path) #得到文件夹下的所有文件名
s = []
for file in files:
    if not file.endswith(".elf"):
        os.rename(path+"/"+file,path+"/"+file+".elf")
record = open("./fuzz_out/correct","w+")
recordE = open("./fuzz_out/error","w+")
i = 0
for file in files: #遍历文件夹
    if not os.path.isdir(file) and file!=".state": #判断是否是文件夹，不是文件夹才打开
        file1 = open("./fuzz_out/correct_result/"+str(i),"w+")
        try:
            subprocess.run([test_executable, "-SD",path+"/"+file], check=True,stdout=file1)
            record.write(file+'\n')
        except:
            recordE.write(file+'\n')
        file1.close()
        size = os.path.getsize("./fuzz_out/correct_result/"+str(i))
        if size==0:
            os.remove("./fuzz_out/correct_result/"+str(i))
            i-=1
        i = i+1
record.close()

test.py

import sys
import subprocess
import os

test_executable = sys.argv[1]


path = "./fuzz_out/queue" #文件夹目录
files= os.listdir(path) #得到文件夹下的所有文件名
s = []
for file in files:
    if not file.endswith(".elf"):
        os.rename(path+"/"+file,path+"/"+file+".elf")
record = open("./fuzz_out/correct","w+")
recordE = open("./fuzz_out/error","w+")
i = 0
for file in files: #遍历文件夹
    if not os.path.isdir(file) and file!=".state": #判断是否是文件夹，不是文件夹才打开
        file1 = open("./fuzz_out/correct_result/"+str(i),"w+")
        try:
            subprocess.run([test_executable, "-SD",path+"/"+file], check=True,stdout=file1)
            record.write(file+'\n')
        except:
            recordE.write(file+'\n')
        file1.close()
        size = os.path.getsize("./fuzz_out/correct_result/"+str(i))
        if size==0:
            os.remove("./fuzz_out/correct_result/"+str(i))
            i-=1
        i = i+1
record.close()

differential_comparing.py

import sys
import subprocess
import os

path1 = "./fuzz_out/correct_result/"
file2 = open("./fuzz_out/final", "rb")
corrects = []
for i in range(20, 50):
    with open(path1 + str(i), "rb") as file1:
        try:
            corrects.append(file1.read().split(str.encode('\n' + "./fuzz_out/queue/"))[1])
        except:
            corrects.append("")
check = file2.read()
checks = check.split(str.encode('\n' + "./fuzz_out/queue/"))
length = len(checks) - 1
count = 0
for i in checks:
    if i in corrects:
        count += 1

print(count)
print(length)
print(count / length)
file1.close()
file2.close()
差分测试结果

readelf
输出结果相同的测试用例数量：8
所有测试用例数量：197408
输出结果不同的比例：99 . 995947479332144593937429080888%
optdump
输出结果相同的测试用例数量：350188
所有测试用例数量：756270
输出结果不同的比例：53 . 695373345498300871381913866741%
size
输出结果相同的测试用例数量：64,804
所有测试用例数量：122,384
输出结果不同的比例：47 . 04863380834096%
nm
输出结果相同的测试用例数量：12
所有测试用例数量：144510
输出结果不同的比例：99.991696076396097155906165663276%
cxxfilt
输出结果相同的测试用例数量：30
所有测试用例数量：135510
输出结果不同的比例：99.97786141245%

差分测试结果说明

如上文所述，由于mull对每个变异体的执行过程高度封装，因此难以进入到子进程内部去修改运行逻辑，我们难以得到测试用例在每个变异体上的表现情况，即无法获知对于特定变异体，AFL产生的测试用例运行的结果是否与原程序有区别。而考虑到，mull工具对每个变异体都会执行相同的测试用例，因此我们转变视角：以测试用例为基准，计量有多少测试用例的在不同程序上的输出有区别。以此虽不能得出变异得分，但也能反映出AFL产生的测试用例的质量。即差分测试结果中的输出结果不同的比例。

结果分析

模糊测试过程及变异测试结果的绘图结果

对变异测试结果中，各变异算子的解释可查看 mull 官网：mull官网
cxxfilter：
模糊测试过程：
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
nm
模糊测试过程：
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
objdump
模糊测试结果：
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
readelf
模糊测试过程：
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
size
模糊测试过程：
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
strip
模糊测试过程
在这里插入图片描述
变异测试结果：
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
xpdf
模糊测试过程：
在这里插入图片描述

结论

1.通过上述项目afl模糊测试过程结构可知，afl工具的执行效率较高，每个程序都能在每秒有大于750次执行，此外，由于待测程序本身质量较高，因此模糊测试过程中，并未得出能让待测程序崩溃的测试用例。而当AFL模糊测试过程进行充足时间后，可以探测出大量的独特的原程序执行路径，生成的测试用例保存在queue文件中。
2.在本次实验，变异体被杀死条件是测试用例使得变异体崩溃。而AFL在进行模糊测试过程中，因为测试的对象基本都是广泛在真实世界使用的程序，因此其bug较少，导致存储导致原程序崩溃的测试用例的crashes文件几乎没有结果。因此将queue文件夹中存有的测试用例用于mull的输入，其导致变异体崩溃的概率较小是正常的，因此变异得分低并不能说明AFL的效果不佳。
3.在本次实验中，我们进行了差分测试，以测试用例为基准，计量有多少测试用例的在不同程序上的输出有区别。以此虽不能得出变异得分，但也能反映出AFL产生的测试用例的质量，通过差分测试，我们发现，AFL的效果较好。

KKKEVVINNN
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
变异测试(mutation testing)：一种评估测试用例集错误检测能力的方法
行步至春深
10-03 3643
错误检测能力如何衡量？一个朴素的想法是，对源程序做一些微小的改动，改动后的程序被称作变异程序/变异体。理想的测试脚本会让源程序通过，而拦截住所有的变异程序。
超详细AFL模糊测试实战，手把手教学
热门推荐
m0_60363092的博客
12-23 1万+
介绍 AFL模糊测试框架的使用方法，使用AFL模糊测试软件或者1000行以上的代码， （1） 构造或选用合适的字典； （2）使用多核并行测试，需要给虚拟机分配多个核； （3）使用动态内存错误检查器，如ASAN等；
Hap-Eval：Sentieon团队开发的开源结构变异SV准确率评估工具
bio2s
11-09 148
Sentieon开发的Hap-eval准确率评估工具在设计之初就考虑到了复杂以及重复的基因组区域，采用了基于单倍型拼接序列的矩阵比较模式，兼容包括PacBio和ONT在内的主流三代长读长测序数据。另外值得一提的是，Hap-eval基于python所写，运行效率非常高，速度快，非常适用于大规模分析场景。
实验五： 自动化测试.doc
05-18
这是软件质量测试课程的实验五：自动化测试的实验报告模板
Mutation Testing(变异测试)
weixin_34101229的博客
05-15 2216
　　变异测试是一种 fault-based 的软件测试技术。这项技术已经广泛研究并使用了三十余年。它为软件测试贡献了一系列方法，工具，和可靠的结果。本文将对变异测试进行深入的调查，分析它的优势和不足之处，并对比几种不同的变异测试方法，提出一些改进的建议。 　　下面用一个例子来解释什么是变异测试，考虑以下代码片段： 　　if(a && b) c = 1; 　　else c = ...
基于突变的模糊测试
大草的博客
01-30 1100
模糊测试中随机生成的字符串大概率是无效的。这导致很多时间被浪费在无效的测试输入中。 我们可以采用合法有效的输入进行初期的测试。这些有效的输入，我们称之为种子。 我们对种子进行突变，将其中的bit(s)进行突变(翻转、删除、增加)。由于突变的部分相对于某个种子的整体，变化较小。那么突变之后的种子，也很可能是合法的。 种子突变的越多，不合法的可能性越大。那么如何控制突变呢？这里引入基于覆盖率引导的模糊测试。当突变生成中输入可以发现新路径的时候，我们将该输入放入仓库中。其中，仓库使用种子进行初始化。这样，突
【网安专题10.25】10 TitanFuzz完全自动化执行基于变异的模糊测试：生成式（如Codex）生成种子程序，逐步提示工程+第一个应用LLM填充模型(如InCoder)+差分测试
定期分享我的发现和想法，感谢你的陪伴和支持
11-08 6046
TitanFuzz：第一个应用填充模型(例如InCoder)直接执行基于变异的模糊测试使用大型预训练语言模型进行深度学习库的模糊测试背景深度学习库（TensorFlow和Pytorch）中的bug对下游任务系统是重要的，保障安全性和有效性。在深度学习（DL）库的模糊测试领域，直接生成满足输入语言(例如Python)语法/语义和张量计算的DL API输入/形状约束的深度学习程序具有挑战性。此外，深度学习API可能包含复杂的输入条件约束，难以在没有人工干预的情况下生成符合条件的输入用例。解决方案。
基于变异树的黑盒模糊测试方法及系统
05-09
本发明公开了一种基于变异树的黑盒模糊 测试方法及系统，包括：S1，构建变异树，生成模 糊测试用例组；S2，确定除根节点以外的每个节 点的估值并设定估值的阈值；S3，对未遍历的各 个节点的估值进行排序，选出估值...
基于变异树的黑盒模糊测试方法
06-22
本发明公开了一种基于变异树的黑盒模糊 测试方法及系统，包括：S1，构建变异树，生成模 糊测试用例组；S2，确定除根节点以外的每个节 点的估值并设定估值的阈值；S3，对未遍历的各 个节点的估值进行排序，选出估值...
pitest-example_JAVA变异测试_greatestd76_自动化测试_pitest_
10-01
代码变异，要把变异算子分类，把所有变异算子根据分类方法评估其重要性，在其可以实行的基础进行优化去变异代码。第二步就是确定变异的实现方式和对应变异算法的优化，要结合已经提出的变异方法进一步的改善。确定好...
《软件测试技术》_实验报告_测试用例设计与自动化测试
06-15
实验类别：综合性实验 实验目的： 1、 掌握QTP进行功能自动化测试。 2、 掌握LoaderRunner进行性能自动化测试。 3、 掌握其他自动化测试工具。 4、 掌握编写测试报告方法。 实验内容： 实验课前准备一个系统，选择QTP进行功能自动化测试或选择Loadrunner进行性能自动化测试。 实验步骤 1、 拟定测试计划。 2、 撰写测试方案。 3、 设计测试用例。 4、 录制或编写脚本。 5、 执行自动化测试。 6、 填写测试报告。 7、分析测试结果。
基于文件格式信息的改进模糊测试方法
05-06
本文针对盲目变异的模糊测试策略带来的效率低下的问题，综合程序控制流图、输入种子样本特征、异常样本发现、...我们的实验表明，增加定向变异之后的模糊测试器在代码覆盖率，以及模糊测试的效率上都有较为显著的提升.
基于深度学习的模糊测试种子生成技术
05-06
模糊测试被广泛应用于各种软件和系统的漏洞挖掘中.而模糊测试的效果与其采用的变异策略以及初始种子文件的代码覆盖率有直接的关系....同时实验证明该方法在针对多种PDF阅读器进行模糊测试时都获得了更高的代码覆盖率.
AutoRunner 功能自动化测试项目实训之第二个实战案例（五）
Small_But_Strong的博客
12-04 2834
一、被测系统介绍： 客户是公司最宝贵的资源，为了更好的挖掘老客户的价值，并开发更多新客户， 公司决定实施客户关系管理系统。希望通过这个系统完成对公司客户基本信息、联系 人信息，交往信息，服务信息的规范化管理，希望通过对销售机会、客户开发过程的 跟踪和记录，提高新客户的开发能力，希望系统提供相关报表，以便公司高层领导能 够随时了解公司客户情况。 客户服务是一个设计多个部门，存在一定的流程工作，客户服务水平的高低决定 着公司的核心竞争力。希望通过该系统，让相关人员可以在线完成对客户相关的处理 和
软件测试实验五 自动化测试
qq_64314976的博客
06-25 782
通过实验成功安装了自动化测试工具Selenium，熟悉工具的流程和业务功能。在实验过程中也遇到了各种各样的问题，通过与同学们相互讨论，所有问题都迎刃而解，并且成功完成了实验。2. 使用自动化测试工具Selenium IDE，自选系统进行Web 自动化测试。2. 使用自动化测试工具Selenium IDE，自选系统进行Web 自动化测试。1. 自动化测试工具自动化测试工具Selenium环境安装及熟悉。1. 自动化测试工具自动化测试工具Selenium环境安装及熟悉。（5）执行py脚本（pytest）
自动化测试与手工测试
Hello World！
08-13 1164
     曾经公司的同事对软件测试有两种看法：     一、自动化无用论：测试组里有些业务方面专家，他们认为自动化测试是无用的，理由有三：自动化不能发现bug、自动化测试技术要求高、自动化脚本维护太难。    二、自动化万能论：另外的一种观点是，自动化测试可以完全替代所有的手工测试，到时候自动化测试能够完善到测试到所有细节功能，测试人员就不用执行测试，只需要执行方案，设计用例等分析工作。
如何评估模糊测试工具-unibench的使用
^_^
03-02 1049
unibench是一个用来评估模糊测试工具的benchmark。这个benchmark集成了20多个常用的测试程序，以及许多模糊测试工具。
猿创征文｜聊聊“高大上“的变异测试（Mutation Testing）
所寫即所思｜一个阿里质量人对测试的所感所悟。
10-16 1737
变异测试是一种基于故障注入的测试技术，将错误代码插入到被测代码中，以验证当前测试用例是否可以发现注入的错误。我认为该测试手段理论上属于白盒测试范畴。变异测试的主要目的是为了验证测试用例的有效性，在注入变异后，测试用例能发现该错误，则表明用例有效的；反之，表明测试用例是无效的，需要补充该变异的测试用例。变异测试有助于评估测试用例的质量，以帮助测试人员编写更有效的测试用例。测试人员设计的测试用例发现的变异体越多，表明其设计的测试用例质量就越高。在深入理解变异测试之前，让我们先搞懂和它相关的几个核心概念。
【Java面试】七、SpringMvc的执行流程、SpringBoot自动装配原理
最新发布
llg___的博客
05-31 781
旧项目中，未前后端分离时，用到JSP，相关流程为： 请求达到前端控制器DispatcherServlet，它相当于一个调度中心，会加载处理器映射器、处理器适配器、视图解析器。DispatcherServlet被Tomcat容器初始化，所有的请求先经过它。 DispatcherServlet向处理器映射器去查询handler，即查询这个接口该调哪个Controller的哪个方法。处理器映射器里以key-value形式存了接口路径合类名+方法名 流程总结：不再返回一个ModelAndView，而是返回一个J
软件突变测试的原理,变异测试小记
05-18
软件突变测试的原理是通过对软件系统进行人为的修改（称为“突变”），以测试这些突变是否会导致软件系统的错误或故障。这种测试方法旨在提高测试的覆盖率，从而发现更多的潜在问题。 突变测试的基本步骤包括：选择一个程序集合，然后执行一系列的突变操作，每个突变操作都会修改程序的某个方面。接下来，使用测试用例来运行每个突变版本，以检测它是否会产生错误或故障。 突变测试的核心思想是通过制造“人为错误”的方式来模拟软件系统中的错误，从而提高测试的覆盖率和测试用例的质量。该方法可以用于各种编程语言和软件系统，并已被证明是一种有效的测试方法。 变异测试是突变测试的一种形式，其基本思想是通过对源代码进行人为修改来制造不同的变异版本，然后使用测试用例来检测这些变异版本是否会产生错误或故障。变异测试可以用于各种编程语言和软件系统，并已被证明是一种有效的测试方法。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值