模糊测试实验
我们的目标是在几台笔记本电脑上做一个在周末长时间运行的模糊测试。我们运行了两个AFL和libFuzzer的实例，对上面的例子进行模糊测试。第一个实例是没有任何语料库的，第二个是W3C
XML Test
Suite的修剪语料库。然后可以通过执行所有四组的最小化语料库的运行来比较结果。这些fuzzer的结果不是直接可以比较的，因为两个fuzzer都使用不同的仪器来检测执行的代码路径和特征。libFuzzer测量两件事情，用于评估新的样本覆盖率，块覆盖率，被访问的隔离代码块和特征
覆盖，这是不同代码路径特征（如代码块和命中次数之间的转换）的组合。AFL不对观察到的覆盖率提供直接计数，但在我们的比较中我们使用总体覆盖图密度。地图密度表示我们所击中的多少个分支元组，与覆盖地图可以容纳多少个元组成比例。
我们的第一次运行并没有按预期的那样进行。2天7小时后，我们发现了大文件使用确定性模糊测试的缺点。我们的
afl-cmin最小化语料库包含了一些超过100kB的样本，导致AFL在加工之后减慢了运行速度，仅次于第一轮的38％。AFL需要几天的时间才能通过单个文件，我们在样本集中有四个，所以我们决定在我们删除超过10kB的样本后重新启动实例。可悲的是，星期天晚上11点，“备份第一”不是我们头脑中的第一件事，AFL的数据被意外覆盖，所以没有第一个比较的结果。我们设法在中止之前保存AFL
UI。
模糊测试两天的完整结果可以从下面的图表中找到。
我们实际上从来没有试图把这些fuzzer相互对抗。即使在我们的实验中，这两个fuzzer结果都是惊人的。从W3C样本开始，由libFuzzer测量的发现覆盖率之间的差异只有1.4％。同时这两个fuzzer都发现了几乎相同的覆盖。当我们合并了四个运行的所有收集的文件和原始的W3C样本时，组合覆盖率仅比libFuzzer单独发现的覆盖率高出1.5％。另一个值得注意的是，即使在2天之后，没有初始样本，libFuzzer或AFL都没有发现比以前的演示更多的覆盖率，在10分钟内反复产生了一个语料库。
我们还使用W3C样本在libFuzzer模糊测试运行期间生成了覆盖发现的图表。
我应该使用哪一个？
正如我们上面的详细说明一样，AFL使用起来非常简单，可以几乎无需安装即可开始使用。AFL负责发现错误处理以及与崩溃类似的东西。但是，如果你没有可用的命令行工具，如xmllint，并且需要编写一些代码来启用模糊测试，通常使用libFuzzer来获得卓越的性能。
与AFL相比，libFuzzer内置了数据清洗功能的支持，例如AddressSanitizer和UndefinedBehaviorSanitizer，可以帮助你在测试过程中发现微妙的错误。AFL对清洗功能有一些支持，但根据你的目标，可能会有一些严重的副作用。AFL的文档中建议在没有清洗功能的情况下运行模糊，并且使用清洗功能构建分开的运行输出队列，但没有实际的数据可用来确定该技术是否可以捕获与ASAN启用的模糊测试相同的问题。有关AFL和ASAN的更多信息，你可以从AFL的源码中找到docs/notes_for_asan.txt。
然而，在许多情况下，运行两个fuzzer是有意义的，因为它们的模糊测试，碰撞检测和覆盖策略略有不同。
如果你最终使用了libFuzzer，那么你应该参考一下Google编写的非常不错的 libFuzzer教程。
