Go fuzz测试把崩溃输入写入回归语料的流程

Go fuzz 测试发现崩溃输入后，不需要把那段输入复制到另一个测试文件里。只要 fuzz 目标返回失败或发生 panic，Go 测试框架就会把触发问题的参数写入 testdata/fuzz/；以后执行普通的 go test 时，这些文件会作为种子再次运行。真正要做的是固定 fuzz 函数名、保留失败文件，并把它当成回归语料维护。

先把 fuzz 目标和回归目录对齐

Go 的绑定规则很直接：测试函数名为 FuzzNormalize，自动发现的语料目录就叫 testdata/fuzz/FuzzNormalize。目录放在包含 fuzz 测试的包目录下，而不是项目根目录的任意位置。这个约定很重要，因为它同时决定了失败输入保存在哪里，以及普通测试下一次从哪里读取。

下面的示例故意把被测逻辑写得很小，重点是观察测试入口、种子和语料目录之间的关系。代码中的断言代表业务不变量，实际项目可以换成协议解析、压缩解码或配置归一化规则。

package normalizer

import (
    "bytes"
    "testing"
    "unicode/utf8"
)

func Normalize(in []byte) []byte {
    return bytes.ToValidUTF8(in, []byte("?"))
}

func FuzzNormalize(f *testing.F) {
    // 人工种子负责覆盖空值、普通文本等可读起点。
    f.Add([]byte("Go"))
    f.Add([]byte{})

    f.Fuzz(func(t *testing.T, in []byte) {
        // 这里验证归一化结果必须是合法 UTF-8，失败输入会被框架保存。
        got := Normalize(in)
        if !utf8.Valid(got) {
            t.Fatalf("Normalize returned invalid UTF-8: %x", got)
        }
    })
}

让失败输入自然落到 testdata/fuzz

执行持续 fuzz 时，-fuzz 选择目标，-run=^$ 用来避免同时跑普通测试，-fuzztime 则限制本次探索时间。例如：

# 只探索 FuzzNormalize，避免把其他普通测试混在本轮输出里
go test -fuzz=FuzzNormalize -run=^$ -fuzztime=30s

如果某个输入使 fuzz 目标调用 t.Error、t.Fatal 或产生 panic，测试框架会把导致失败的参数写入 testdata/fuzz/FuzzNormalize。文件名通常包含由框架生成的标识，内容格式由参数类型决定。不要把它当成业务日志，也不要为了“好读”改成普通文本；它是测试框架再次构造原始参数的依据。

失败发生后先保留文件，再确认问题是否真的是被测逻辑缺陷。若只是环境资源不足、临时网络依赖或输入不满足前置条件，应在 fuzz 函数中用 t.Skip 明确排除，而不是把偶发环境错误永久写入回归语料。

普通 go test 如何把崩溃输入变成回归用例

语料文件落盘后，持续 fuzz 不是唯一的复查方式。关闭 -fuzz，直接运行包测试，Go 会读取 FuzzNormalize 的人工种子和目录种子，并把每个输入交给同一个 fuzz 回调。这样可以把“曾经触发过的问题”纳入每次提交的快速回归。

# 提交前重放所有已保存种子，确认修复没有回退
go test ./...

# 只运行这个 fuzz 目标的种子回归
go test -run=^$ -fuzz=FuzzNormalize -fuzztime=1x

实际维护时可按下面的检查表处理：

维护语料时要守住哪些边界

第一，fuzz 目标要尽量确定性。依赖当前时间、随机数、外部服务或共享临时目录的目标，即使能找到失败，也很难判断失败文件是否代表代码缺陷。第二，回归文件要和修复提交绑定，提交说明中写清触发条件，方便以后判断它是在保护协议边界还是只保留了一个偶然样本。第三，参数中可能含有令牌、个人数据或业务密文时，先脱敏或改造测试输入，不能因为它来自测试目录就默认安全。

还要区分“发现问题”和“修复问题”：Go 自动保存输入只负责让问题可重放，不会替你证明修复正确。修复后先用普通测试跑目录种子，再重新开启一小段 fuzz，确认附近输入没有再次触发同一不变量。

相关问题

为什么 testdata/fuzz 里的文件没有写入普通测试目录？

目录必须位于对应包下，并使用 testdata/fuzz/ 结构；名称或层级不匹配时，测试框架不会把它识别为该 fuzz 目标的语料。

手工添加语料时应该用文件还是 F.Add？

少量稳定、可读的基础样本适合 F.Add；需要保留真实失败输入或较复杂的二进制参数时，用 testdata/fuzz 文件更合适。

失败文件能不能直接删除？

只有确认它不再表达回归边界、且删除后仍有其他样本覆盖该问题时才清理。若它对应一次真实缺陷，通常应随修复一起保留。