很多朋友看到模糊测试这个名字|模糊测试与其他测试类型有什么不一样？( 二 )

该方法的缺点也很明显：1)在测试时， Driller需要将fuzzing算法与symbolicexecution算法同时进行，需要耗费大量的计算资源；2)symbolicexecution本身存在的一些问题（路径爆炸等）也难以通过fuzzing算法来补足；3)该测试方法为白盒，需要程序的源代码。
2、Eclipser
语言：F#
测试范围：Bin
推荐部署平台：Win
相关文献：Grey-boxConcolicTestingonBinaryCode.ICSE`19（私信回复“Eclipser”获取文献）
概述：Eclipser是一款基于路径（path）的灰盒fuzzing测试方法，其结合了白盒和灰盒fuzzing的优点。在不适用SMT求解器的情况下， Eclipser仅适用轻量级的工具便能达到和白盒测试中一样的路径探索。其核心技术点在于为种子的每个输入字节维护一个近似路径约束的独立子集。这样的约束有助于生成可以用来执行相同或相似执行路径的测试用例。通过这样的方法， Eclipser能在灰盒的条件下有效解决分支条件，同时保持系统轻便且可拓展。
当然， Eclipser设计的重点是解决分支条件。当条件中的操作数可以表示为输入字段的线性或者单调函数时，这个问题可以被Eclipser解决。但是如果操作数域输入字段的关系为复杂函数时，这个问题将变得更为复杂，也不能被Eclipser所解决［1］。模糊测试的不足与未来
上面说了那么多的模糊测试的相关内容，其实都离不开“随机”两个字。如何确保模糊测试工具可以产生真正的随机数据或者状态至关重要，但是在计算机世界里，我们很难去界定一个数据或者一个状态是否真的是随机的，所以模糊测试的不足之一就是由他的产生之初的理念与生俱来的。模糊测试中最重要的思想是，产生的随机值应该在合法值和非法值的边界区域，这样更有可能触发我们所要测试的系统内部的故障点，然而给定了边界的的随机数值还真的是随机数值吗？
模糊测试的第二个不足点就是对故障或者说漏洞的界定与监测问题，我们利用工具产生并且提交了我们的随机数据或者状态，系统也做出了响应，但是传统的模糊测试中，只是简单粗暴的认为系统发生崩溃才认为随机数据或状态运行到了程序的内部故障点，才记录下输入作为样本。然而事实上，大多数的系统在崩溃之前，内存中的数据己经遭到了踩踏，数据依然会继续保持运行。这就造成了，当后续输入使得程序发生崩溃时，模糊测试系统中记录的崩溃样本可能并不是系统漏洞的真正成因。
所以，如何去有效的检测和界定真正触发故障的数据或状态是当今模糊测试工具亟需解决的问题，这也是模糊测试提出之初未曾考虑完善的问题，虽然模糊测试不需要再让人工去不断的挖掘和考虑出在合法值和非法值之间的变异值，但是想在安全测试领域完全或者尽可能的去替代人工，还有很长的路要走。
参考资料：
【很多朋友看到模糊测试这个名字|模糊测试与其他测试类型有什么不一样？】［1］模糊测试调研报告V0-20210302[R]．深圳开源互联网安全技术有限公司研究院,2021年