多年来，我惊叹于有如此大量能够使MicrosoftWord崩溃的坏文件。少数字节错位，会使整个应用程序毁于一旦。在旧式的、无内存保护的操作系统中，整个计算机通常就这样宕掉了。Word为什么不能意识到它接收到了坏的数据，并发出一条错误信息呢？为什么它会仅仅因为少数字节被损坏就破坏自己的栈、堆呢？当然，Word并不是惟一一个面对畸形文件时表现得如此糟糕的程序。
本文介绍了一种试图避免这种灾难的技术。在模糊测试中，用随机坏数据（也称做fuzz）攻击一个程序，然后等着观察哪里遭到了破坏。模糊测试的技巧在于，它是不符合逻辑的：自动模糊测试不去猜测哪个数据会导致破坏（就像人工测试员那样），而是将尽可能多的杂乱数据投入程序中。由这个测试验证过的失败模式通常对程序员来说是个彻底的震憾，因为任何按逻辑思考的人都不会想到这种失败。
模糊测试是一项简单的技术，但它却能揭示出程序中的重要bug。它能够验证出现实世界中的错误模式并在您的软件发货前对潜在的应当被堵塞的攻击渠道进行提示。
模糊测试如何运行
模糊测试的实现是一个非常简单的过程：
● 准备一份插入程序中的正确的文件。
● 用随机数据替换该文件的某些部分。
● 用程序打开文件。
● 观察破坏了什么。
可以用任意多种方式改变该随机数据。例如，可以将整个文件打乱，而不是仅替换其中的一部分，也可以将该文件限制为ASCII文本或非零字节。不管用什么方式进行分割，关键是将大量随机数据放入应用程序并观察出故障的是什么。
测试基于C的应用程序
当字符串包含额外的零时，许多用C编写的程序都会出问题——这类问题太过频繁以至于额外的零能够彻底隐藏代码中其他的问题。一旦验证出程序存在零字节问题，就可以移除它们，从而让其他的问题浮现出来。
可以手动进行初始化测试，但要想达到最佳的效果则确实需要采用自动化模糊测试。在这种情况下，当面临破坏输入时首先需要为应用程序定义适当的错误行为。（如果当输入数据被破坏时，您发现程序正常运行，且未定义发生的事件，那么这就是第一个bug。）随后将随机数据传递到程序中直到找到了一个文件，该文件不会触发适当的错误对话框、消息、异常，等等。存储并记录该文件，这样就能在稍后重现该问题。如此重复。
尽管模糊测试通常需要一些手动编码，但还有一些工具能提供帮助。例如，清单1显示了一个简单的Java??类，该类随机更改文件的特定长度。我常愿意在开始的几个字节后面启动模糊测试，因为程序似乎更可能注意到早期的错误而不是后面的错误。（您的目的是想找到程序未检测到的错误，而不是寻找已经检测到的。）
清单1.用随机数据替换文件部分的类
importjava.io.*;
importjava.security.SecureRandom;
importjava.util.Random;
publicclassFuzzer{
privateRandomrandom=newSecureRandom();
privateintcount=1;
publicFilefuzz(Filein,intstart,intlength)throwsIOException
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
