最近被一个工具治好了我的测试焦虑，想跟版面里的朋友聊聊。咱们平时写测试，说白了都是自己拍脑袋想用例，能想到的边界早就在掌控之中了，真正要命的永远是那些压根没想过的输入组合。
后来试了 fuzzing，感觉像雇了个不讲理的实习生：你只管写个 harness，把输入喂给解析函数这件事交代清楚，剩下的它全包了。它每秒变着法儿生成成千上万畸形输入往里灌，专挑代码里那些冷门路径钻。哪次崩了，它不光记下来，还能把触发崩溃的那串输入稳定复现出来，省得你对着偶现 bug 抓瞎。
说真的，现在那么多内存越界、解析器崩坏、还有一堆 CVE，都是 fuzzer 第一个发现的。比起等用户在生产环境帮你踩雷、再客客气气发邮件来吐槽，咱们自己上线前先折腾一遍，体面多了，也睡得安稳。
大家平时都用啥工具兜底？欢迎来聊聊，互相安利一下 (＾▽＾)
补充一个角度：'都是 fuzzer 第一个发现的’这个表述有点太满了。memory-safety 类的漏洞——内存越界、UAF 这些——确实大量是 coverage-guided fuzzing 先撞出来的。但逻辑错误、鉴权绕过、状态机缺陷，fuzzer 基本没脾气，它只会无脑灌畸形输入，理解不了业务语义约束。严格来说
所以上线前还是得 code review 和 static analysis 一起上。你们有没有遇到过 fuzzer 跑了几百万轮风平浪静，结果逻辑 bug 还是靠人工抓出来的情况？想听听实战样本。
你这"不讲理的实习生"比喻我笑出声了，贴切。
补几个实践中踩过的坑。fuzzing 的产出上限基本是被 harness 决定的——喂进去的路径没覆盖到，它再努力也钻不进去。常见的浪费是 harness 里把异常吞了，或者目标函数选错层，结果 fuzzer 拼命跑的全是已经处理好的上层逻辑。先确认 harness 真能把畸形输入送到"裸"的解析函数、且崩溃能原样冒出来，再让它跑。
另一个关键是别裸跑。光给随机字节不加 sanitizer，一大半内存错误根本不会以崩溃形式暴露，只是悄悄污染状态。libFuzzer 配 ASan/UBSan、AFL++ 配 sanitizer 才是标准打法。我见过有人跑了一周零崩溃就以为代码干净了，加上 ASan 当天就出 heap-buffer-overflow。
种子语料也值得花心思。空 corpus 冷启动慢得让人想关掉，拿几个真实样本当 seed，覆盖率起来得快得多。AFL++ 的 cmplog 模式对那种有多轮比较的解析器（比如带校验和的格式）提升很明显。
不过得说一句，fuzzing 再香也有盲区。它擅长的是内存安全和"输入→崩溃"这类确定路径，业务逻辑里的 off-by-one、状态机错乱、并发竞态基本靠它发现不了。别因为 fuzzer 安静就觉得能躺平，该写的性质测试还是得写。
你用的是什么 harness 框架？跑的时候开 sanitizer 了吗。
你们现在主要拿它跑哪类程序？我前阵子给一个自己写的小解析器接了 libFuzzer，体验和你说的差不多，真能钻出我自己压根没设想过的输入组合。
不过有处得补一句：fuzzer 能把崩溃稳定复现，前提是编译时把 sanitizer 开全、harness 的 oracle 也定清楚。我头一回跑，覆盖率死活上不去，后来才看出是 seed 太单薄，喂进去的输入一直在浅层分支打转，深的逻辑根本没摸到。
再有，复现出来不等于根因就明了。fuzzer 说到底是帮你把雷挖出来，定位和拆弹还得自己来，所以它跟手写单元用例是互补，不是替代。
cargo
不讲理实习生笑死 这比喻太绝了 我之前被畸形输入灌崩的时候还以为天塌了 结果它咣咣全给复现出来 省了我好几天对着偶现bug抓瞎
哈哈这个"不讲理的实习生"的比喻太传神了，我看着都乐了。
我之前也跟着版面里的朋友折腾过一阵子 libFuzzer，第一次看到它几秒钟就把我写得挺得意的解析函数搞崩溃的时候，心里那叫一个难受。但转念一想确实比上线之后等用户踩雷强，现在每次改完解析相关的代码，我都习惯先让它跑一会儿才敢提交，踏实不少。
你们一般跑多久算"够了"呀？我老担心跑五分钟没事，其实要紧的路径根本没覆盖到……
楼主那个"实习生"的比喻挺传神的。不过有一点想商榷：你说"那么多 CVE 都是 fuzzer 第一个发现的"，这话说得有点满。
从公开战绩看，fuzzing 确实是内存越界、解析器崩溃这类漏洞的主力发现手段，OSS-Fuzz 攒下的案例很能说明问题。但逻辑漏洞、权限绕过，还有不少靠人工审计和静态分析揪出来的 case，fuzzer 并不擅长。它本质靠海量畸形输入撞概率，撞不进的路径也没办法。
另外 harness 质量决定一切。你平时用 libFuzzer 还是 AFL 那一支？
我前阵子给手头一个小装置写固件，顺手试了 fuzzing，确实省心。补一句：它最擅长抓"崩了"那种错，可代码默默吐了个错答案、进程没崩，它基本发现不了。所以我在 harness 里多塞几个断言，把"输入 X 必得 Y"这种不变量写死，fuzzer 一撞上就报，覆盖面立马上来。
兜底工具可以看看 AFL++，比原版 AFL 能打，尤其对付自己撸的解析器。你那 harness 是手写还是直接挂 libFuzzer？
“实习生"这个比方挺传神的，但有一点可以补一刀：fuzzer 再"不讲理”，它能不能钻进那些冷门路径，其实高度取决于你给它的 harness 和种子语料。覆盖引导型（像 AFL++）本质上是个贪心搜索，种子太单一的话，它很容易在一片互相可达的状态里打转，根本够不到真正深的解析分支。所以"只管写个 harness"这步，恰恰是最吃功夫的地方，不是交代清楚喂输入就完事了。
另外楼主说"那么多 CVE 都是 fuzzer 第一个发现的"，这说法稍微绝对了些。以 Google 的 OSS-Fuzz 公开数据看，它确实在 1000 多个项目里揪出了上万处 bug、四万多起崩溃，贡献巨大；但现实里仍有相当比例的漏洞是靠人工审代码、静态分析、还有研究员手动构造畸形样本挖出来的。fuzzer 是主力之一，但不是唯一的"第一发现者"。严格来说
还有个盲区值得提一句：fuzzing 天然擅长找"会崩"的 bug，越界、空指针、断言失败都跑不掉。可一旦遇到带校验和的解析器（CRC 不对直接拒收），或者状态机类的协议，纯黑盒灌畸形输入常常在门口就被挡回来，进不去核心逻辑。更别提那些"不崩但算错"的语义 bug，fuzzer 基本是瞎的。所以我觉得它更像一道兜底网，和单测、property-based testing 配合着用才体面，单靠它"上线前折腾一遍"还是有点悬。
话说你们 harness 一般怎么处理带校验和的输入？是 hook 掉校验函数，还是预先生成合法壳子再变异？想听听实操经验 (｀・ω・´)
那个不讲理实习生的比喻太 genial 了 笑死 我之前也被偶现 bug 折磨到想摔键盘 后来丢给 AFL++ 一个周末 直接炸出俩崩溃 其中一个还是生产真能踩到的路径 又惊又爽
突然想到
不过它真不是万能 有些带状态的解析逻辑 fuzzer 钻不进去 手写用例还是逃不掉 体面是体面 全指望它兜底就太天真
笑死
你们一般跑多久 timeout 我这破机器一整晚风扇跟要起飞似的 (￣▽￣)
我年轻那会儿也跟你一样，测试全靠自己拍脑袋想用例，总觉得差不多覆盖到了。后来被一个偶现 bug 折磨了快两周，才老实去试了 fuzzing，感觉确实像雇了个不睡觉的实习生，ach，省心不少。
不过有个坑想提一句：harness 要是写得潦草，fuzzer 再猛也钻不进你想测的那层，它就卡在入口处反复撞同一个无效输入。我见过有人跑了一宿 libFuzzer，coverage 纹丝不动，还以为自己代码多干净，其实纯粹是喂数据的方式没设计好。
你现在用的是 AFL++ 还是直接 libFuzzer？我对 AFL++ 那套变异策略一直挺服气的，互相安利一下嘛 (＾▽＾)
实习生那句笑死。fuzzing抓崩溃是一绝，但逻辑层的静默错误它发现不了，还得自己动脑。你们跑一轮多久？