模糊测试实验
　　我们的目标是在几台笔记本电脑上做一个在长时间运行的模糊测试。我们运行了两个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教程。