Go testing.F 怎样为模糊测试限制输入

Go 的模糊测试适合探索普通单元测试没有覆盖到的输入组合，但“让它一直跑、让输入一直变大”并不是稳定的测试策略。更可控的做法是把预算拆成四层：用 F.Add 提供小而有代表性的 seed，在 fuzz target 入口拒绝超长或明显无效的输入，再用 -fuzztime 限制总运行时间，最后保留失败样本作为回归测试。

Go testing 官方地址：https://pkg.go.dev/testing

限制输入不等于削弱模糊测试，而是先定义“什么输入值得进入被测逻辑”，再给探索过程一个明确的时间和并发预算。

先把模糊测试的预算拆开

一个 fuzz 用例通常同时面对三种输入：代码里用 F.Add 注册的 seed、testdata/fuzz/ 中已经保存的 seed，以及 fuzzing 过程中由引擎基于 seed 变异出的新输入。seed corpus 不是输入上限，它的作用是让探索从有意义的路径开始。

真正需要限制的是被测逻辑收到的输入成本。对字节切片来说，最常见的第一道边界是长度；对字符串或结构化文本，还要把嵌套深度、字段数量和单次解析工作量纳入考虑。命令行层面则单独限制整个 fuzz 任务运行多久，避免一次调度把测试机长期占用。

用 F.Add 让 seed 小而有覆盖

seed 的目标不是穷举所有情况，而是用少量样本触达不同的解析分支。以一个接收字节流的解析函数为例，可以同时准备空输入、合法短输入、边界分隔符和一条带错误标记的输入。这样既能保留回归价值，也不会从一开始就把 corpus 变成大文件集合。

package parser_test

import "testing"

func FuzzParseRecord(f *testing.F) {
	// seed 只负责覆盖典型分支，不把大文件直接塞进 fuzz corpus。
	f.Add([]byte("id=7;name=go"))
	f.Add([]byte(""))
	f.Add([]byte("id=;name=?"))

	f.Fuzz(func(t *testing.T, input []byte) {
		// 这里把输入预算写在 target 入口，避免解析器处理无意义的大样本。
		if len(input) > 4

F.Add 的参数类型必须和 fuzz target 的参数类型一致；上面的 seed 都是 []byte，因此回调也接收 []byte。长度判断放在被测函数之前，能把明显超预算的样本挡在解析、分配或递归逻辑之外。至于“格式错误”是否应该跳过，要看测试目标：如果目标是验证解析器对任意字节都不崩溃，就不应因为解析错误直接跳过；如果目标只研究合法记录的后续语义，才适合先过滤语法。

在 fuzz target 前置过滤高成本输入

输入过滤最好分成“便宜检查”和“业务解析”两层。先检查字节长度、分隔符数量等无需分配的条件，再进入 JSON、压缩格式或自定义协议解析。这样限制的是每次 fuzz 调用的成本，而不只是最终测试命令的总时长。

func FuzzDecodeEnvelope(f *testing.F) {
	// 用短 seed 覆盖空包、最小包和带字段的常见包形态。
	f.Add([]byte{0x01, 0x00})
	f.Add([]byte{0x01, 0x02, 0x03, 0x04})

	f.Fuzz(func(t *testing.T, input []byte) {
		const maxEnvelope = 64  maxEnvelope {
			// Skip 表示样本不进入本次断言，不把预算溢出误报为缺陷。
			t.Skipf("envelope is %d bytes; limit is %d", len(input), maxEnvelope)
		}
		if len(input) 

这里的边界不是为了隐藏错误，而是把测试问题说清楚：decodeEnvelope 的目标是验证“支持的 envelope 在约束内能够正确解码”。如果你要验证它面对任意输入都不会 panic，就应保留任意字节，使用 recover 或测试框架的失败机制记录异常，而不是用过滤条件把所有异常格式跳过。

用 go test 参数限制运行时间

代码内的长度和格式边界解决的是单个输入成本，命令行参数解决的是整个 fuzz 会话的时间预算。开发阶段可以先用较短时长快速反馈，专门复现某条失败样本时再配合 -run，而不是默认让每次本地测试都长时间运行。

# 只给当前 fuzz 任务 30 秒，避免本地调试无限运行。
go test -run '^$' -fuzz '^FuzzDecodeEnvelope$' -fuzztime=30s ./...

# 限制失败样本最小化阶段的时间，并控制并行 fuzz 工作量。
go test -run '^$' -fuzz '^FuzzDecodeEnvelope$' \
  -fuzztime=2m -fuzzminimizetime=5s -parallel=2 ./...

-fuzztime 控制 fuzzing 过程的时间或次数预算；-fuzzminimizetime 约束发现失败后寻找更小复现输入的阶段；-parallel 则影响同时运行的 fuzz 工作量。三者应该按机器资源和被测逻辑的成本一起设置。参数只限制运行计划，不会替代 target 内的输入上限：一个单次处理就很慢的 64 MiB 输入，仍可能在短时间内拖垮测试。

失败样本要留下，普通无效样本要分清

当 fuzz target 报错或 panic 时，Go 会把导致失败的输入保存到对应 fuzz 测试的 seed 目录或 fuzz cache 中。这个样本应该被当作回归输入：先确认问题已经修复，再把它纳入小而明确的 seed 集合，避免同一缺陷只靠随机探索再次出现。

t.Skip 适合表示“这个样本不属于当前测试契约”，不适合拿来掩盖所有错误。可以用下面的判断表做边界选择：

最后可以把限制策略收敛成一张清单：seed 负责覆盖路径，target 负责单样本边界，命令行参数负责总时间与并发，失败样本负责回归。这样既不会用一个过大的 corpus 代替设计，也不会把“测试跑得久”误认为“覆盖一定更好”。

相关问题

输入越大，模糊测试越容易找到 bug 吗？

不一定。大输入会增加解析和分配成本，只有在缺陷确实依赖长度或深度时才值得提高上限；更好的起点是用小 seed 覆盖不同分支，再针对发现的问题扩大边界。

所有解析错误都应该用 t.Skip 吗？

不应该。先确定测试契约：合法格式的语义测试可以跳过不合法样本，但“任意输入不得崩溃”的健壮性测试必须保留这些输入。

只设置 -fuzztime 够不够？

不够。它只限制整个 fuzz 会话的预算，不能替代对单个输入长度、结构深度和解码工作量的前置控制。