Go 模糊测试种子为什么没有覆盖到同一分支

Go 模糊测试里的种子已经执行，却没有带来你期待的分支覆盖，通常不是 f.Add 失效，而是把三件事混在了一起：种子是否进入 fuzz target、它是否命中目标条件、它是否提供了新的覆盖边。两个不同字符串完全可能经过规范化后走进同一条路径，因此都能执行，却只有相同的覆盖贡献。

官方文档：https://go.dev/doc/security/fuzz/

种子语料首先是可重复执行的输入，也是变异的起点；它并不保证每个种子都对应一个独立分支。Go 的 fuzzing 会用覆盖插桩寻找并缓存扩展覆盖的输入，所以判断种子是否“有效”，要看分支谓词和覆盖变化，不能只看输入长得是否不同。

先把现象说清：种子执行和覆盖增长不是一回事

Go 可以通过 f.Add 或包内的 testdata/fuzz/FuzzName 文件提供 seed corpus。普通 go test 模式下，fuzz target 会对这些种子逐个执行；启用 -fuzz 后，工具链还会编译覆盖插桩，先收集基线覆盖，再持续变异输入。

这意味着下面三个判断必须分开：

官方文档说明，fuzzing 开始时的 baseline coverage 会执行 seed corpus 与已有 generated corpus，用于确认没有失败并理解现有语料已经覆盖的代码。如果两个种子命中同样的覆盖边，它们仍然可以执行成功，但不会凭空变成两份不同的覆盖贡献。

一个常见现场：输入不同，规范化后的路径相同

下面的原创示例把协议文本分成普通请求与管理员请求。真正决定内层分支的不是原始字节，而是去空格、转小写、拆字段后的结果：

package route

import "strings"

func classify(raw []byte) string {
	// 先统一大小写和首尾空白，避免表面差异干扰协议判断
	s := strings.ToLower(strings.TrimSpace(string(raw)))

	if strings.HasPrefix(s, "auth:") {
		// 最多拆成两段，第二段才是权限角色
		parts := strings.SplitN(s, ":", 2)
		if len(parts) == 2 && parts[1] == "admin" {
			// 只有完整满足角色谓词才进入管理员分支
			return "privileged"
		}
		return "authenticated"
	}

	return "anonymous"
}

如果种子是 "AUTH:user" 和 " auth:user "，原始输入确实不同，但规范化后都是 auth:user。它们命中相同的外层守卫和相同的普通认证分支。期待第二个种子覆盖 privileged，自然不会发生。

另一个容易漏看的情况是种子只满足了外层前缀，却没有满足内层长度、字段数或枚举值。例如 auth: 会进入 auth 守卫，但角色字段为空；auth:admin:extra 在不同拆分策略下也可能与预想不一致。排错时要把完整谓词写出来，而不是笼统地说“这个输入看起来像管理员请求”。

种子应该表达不同语义，而不只是不同字节

针对上面的目标函数，一组更有代表性的种子应覆盖协议语义，而不是堆同义输入：

package route

import "testing"

func FuzzClassify(f *testing.F) {
	// 覆盖没有 auth 前缀的匿名分支
	f.Add([]byte("hello"))
	// 覆盖 auth 前缀存在但角色不是 admin 的普通认证分支
	f.Add([]byte("auth:user"))
	// 覆盖完整满足内层谓词的管理员分支
	f.Add([]byte("auth:admin"))
	// 覆盖规范化逻辑，确认空白和大小写不会改变语义
	f.Add([]byte(" AUTH:ADMIN "))

	f.Fuzz(func(t *testing.T, raw []byte) {
		got := classify(raw)

		// 结果必须落在明确的有限集合，其他值代表分类器失去约束
		switch got {
		case "anonymous", "authenticated", "privileged":
			// 合法结果无需额外处理
		default:
			t.Fatalf("unexpected class %q for %q", got, raw)
		}
	})
}

这里 auth:admin 与带空格、大小写不同的种子可能仍覆盖同一条管理员路径。保留后者的理由应是回归“规范化不改变语义”，而不是声称它增加了一条新分支。种子可以承担回归测试价值，也可以作为变异起点，但这两种价值不等同于新增覆盖。

实用的种子组合通常包含：

• 一个最小正常输入，确保主路径可达；
• 一个刚好越过外层守卫的输入；
• 一个满足内层特殊谓词的输入；
• 一个格式错误或边界输入，确认错误处理稳定；
• 一个历史失败输入，防止已经修复的问题回归。

不要为每种大小写、空格和等价编码都添加固定种子。变异器可以探索字节变化，人工种子更应该提供结构和语义上的跳板。

把执行、覆盖和语料增长拆成三个信号

排查时如果只盯着 fuzzing 输出中的 new interesting，很容易误判。这个数字反映的是当前 fuzzing 过程中加入 generated corpus 的有趣输入，不是 f.Add 的调用次数，也不是业务分支数量。

先确认固定种子能稳定执行

# 以普通测试模式运行 fuzz target 的固定种子
go test -run '^FuzzClassify$'

# 生成覆盖报告，先观察固定种子覆盖到哪些代码
go test -run '^FuzzClassify$' -coverprofile=seed.cover
go tool cover -func=seed.cover

普通模式适合确认种子类型、目标函数和断言没有问题。官方文档指出，未启用 fuzzing 时，fuzz target 会使用通过 f.Add 注册的种子以及 testdata/fuzz/FuzzName 中的种子，行为接近普通测试。

再观察覆盖引导是否找到新路径

# 限时运行，观察 baseline coverage 与 generated corpus 增长
go test -fuzz '^FuzzClassify$' -fuzztime=20s

启用 -fuzz 后，工具链会用覆盖插桩识别扩展覆盖的输入并缓存它们。如果种子已经覆盖管理员分支，后续许多不同的 auth:admin 变体可能不会继续增加 new interesting；这不是漏跑，而是覆盖反馈认为路径没有增加。

最后单独复现某个语料值

当 fuzzing 发现失败输入并写入 testdata/fuzz/FuzzClassify 后，可以使用输出中的子测试名称定向运行。不要手工猜哈希：

# 用失败输出给出的完整子测试名称做定向复现
go test -run 'FuzzClassify/输出中的语料标识'

这样能把“这个输入是否可重复失败”与“它是否贡献新覆盖”分开判断。

五类原因最容易让目标分支看起来失踪

Go 官方建议 fuzz target 保持快速且确定，不要让每次调用后的状态延续到下一次，也不要依赖全局状态。因为 fuzzing 会在多个 worker 中以不确定顺序调用目标函数，状态泄漏会让同一种子难以复现，更会掩盖真正的分支条件。

一套更稳的修正顺序

1. 确认输入进入目标函数。先用普通 go test 跑固定种子，排除类型、目录和测试选择问题。
2. 写出完整分支谓词。把规范化、解析、长度、枚举和错误返回都列出来，找出最早不满足的条件。
3. 缩成最小语义种子。只保留越过守卫并命中特殊分支所需的最少字节，减少无关格式噪声。
4. 把回归价值和覆盖价值分开。等价路径的种子只有在保护历史行为时才固定保留。
5. 再启用短时 fuzzing。确认 baseline coverage 正常后，观察生成语料是否继续发现新路径或失败。

如果目标分支涉及校验和、嵌套长度或相互关联字段，随机字节很难同时满足所有条件。此时应提供一个结构正确的最小种子作为起点，让变异发生在有效结构附近；不要直接在 fuzz target 里跳过大量输入后，又期待引擎轻易穿过复杂守卫。

相关问题

f.Add 的每个种子都会运行吗？

在普通测试模式下，fuzz target 会使用注册的种子语料运行。启用 fuzzing 后，基线覆盖阶段也会执行种子语料与已有生成语料。是否带来新的覆盖贡献则是另一件事。

为什么两个种子只看到一个覆盖结果？

它们可能经过解析或规范化后命中同一组覆盖边。输入不同不等于控制流不同，应比较完整分支谓词。

种子越多越好吗？

不是。官方文档强调小而覆盖良好的种子可以提高找错效率。大量等价种子会增加基线执行成本，却未必帮助覆盖增长。

历史失败输入应该放在哪里？

fuzzing 发现失败时会把输入写入对应的 testdata/fuzz/FuzzName 目录；它随后会作为种子输入参与普通测试和后续 fuzzing，适合承担回归测试。

排查这类问题时，最有效的视角不是“我加了几个种子”，而是“每个种子在规范化后满足了哪些谓词，并改变了哪些覆盖边”。一旦把执行、分支和覆盖反馈拆开，种子没有命中预期路径的原因通常会很快显现。