Go fuzzing 怎样为解析器设计最小种子

为 Go 解析器设计 fuzzing 最小种子，先列出输入语法里的不同判断，再为每种关键情形放一份短小代表：空输入、短头、最小合法帧、错误标记、长度不匹配和合法边界。用 f.Add 注册这些输入，并给 fuzz 目标加入可判断对错的性质断言；种子少不等于测试弱，只有种子没有断言也不等于能发现逻辑错误。

Go fuzzing 官方地址：https://go.dev/doc/security/fuzz/

先把解析器的输入契约缩到能说清

假设要给一个小型二进制帧解析器补充自动测试。直接塞进几十个业务文件的问题，不只是慢：每个文件为什么存在、缺少哪类边界，很难解释。这里选择一个原创的小协议，方便把选择依据完整展示出来，不借用生产流量或真实账号数据。

帧只有三个部分：一字节标记字段必须为 ASCII 字符 Q；一字节长度字段取值 0–255；剩余载荷字段的字节数必须恰好等于该长度。最短合法帧是两个字节，空载荷允许，尾随多余字节不允许。

我们把一次传入的字节切片称作原始输入，它依赖这三个字段的组合；帧契约定义接受条件，解析结果只在接受时提供载荷。这个协议不处理校验和、网络分包或流式读取，避免一份入门目标承担不相干的职责。

按语义分支挑种子，不按文件大小排名

这里的“最小”是每个代表值尽量短、整组理由尽量清楚，不是数学上证明无法再删的最优集合。下面九个代表值可用于起步；是否删减，要结合解析器的实际判断和测试目标决定。

表中的 0、1、255 都是单个字节的数值，不是把数字写成十进制文本。最后一行稍长，是为了直接给最大合法长度一个可解释的代表；不必为了“每个都越短越好”删掉这个语义边界。

短头和载荷不足都是截断，但它们触达不同的检查位置，因此不应仅凭“都返回 error”判断完全重复。反过来，十份同样结构的合法文本未必带来十份有效差异。初始种子是引擎探索的入口，不是穷举全部输入。

F.Add 负责输入，断言负责发现问题

下面两份代码放在已有模块的同一个 frame 包目录。解析器保存为 frame.go，目标保存为 frame_test.go。本文使用的 bytes.Clone 需要 Go 1.20 或更新版本；Go 原生 fuzzing 自 Go 1.18 提供。示例不依赖外部服务或磁盘数据。

package frame

import "errors"

var ErrFrame = errors.New("invalid frame")

// Parse 接收 Q 标记、单字节长度和恰好匹配的载荷。
func Parse(b []byte) ([]byte, error) {
    // 先判断短头，后续索引才有定义。
    if len(b) 

下面的种子集合由 F.Add 注册给模糊目标。目标内调用解析器，观察输入快照，并通过性质断言报告失败样本。每次调用都使用本次局部数据，不跨调用保留切片。

package frame

import (
    "bytes"
    "testing"
)

func FuzzParse(f *testing.F) {
    seeds := [][]byte{
        {}, {'Q'}, {'Q', 0}, {'Q', 1, 'z'},
        {'R', 0}, {'Q', 1}, {'Q', 0, 'z'}, {'Q', 255},
    }
    // 最大合法载荷是一个额外的边界代表，不是性能样本。
    seeds = append(seeds, append([]byte{'Q', 255}, bytes.Repeat([]byte{'x'}, 255)...))
    for _, seed := range seeds {
        f.Add(seed) // 参数类型与下面的 []byte 保持一致。
    }

    f.Fuzz(func(t *testing.T, b []byte) {
        before := bytes.Clone(b) // 用副本观察解析是否修改了输入。
        payload, err := Parse(b)
        if !bytes.Equal(b, before) {
            t.Fatal("parser modified input")
        }
        // 从帧总长表达契约，短路条件保护下标。
        wantOK := len(before) >= 2 &&
            before[0] == 'Q' &&
            len(before) == 2+int(before[1])
        if err != nil {
            if wantOK {
                t.Fatal("valid frame rejected")
            }
            return // 预期的格式错误不是 fuzz 失败。
        }
        if !wantOK {
            t.Fatal("invalid frame accepted")
        }
        if !bytes.Equal(payload, before[2:]) {
            t.Fatal("payload mismatch")
        }
    })
}

这份目标没有在调用 Parse 前跳过短输入。短头恰恰是要交给解析器处理的情形，提前过滤会把需要观察的边界排除在外。正常拒绝格式错误就返回，不把它误报为 bug；如果一个按协议合法的帧被拒绝，才让断言失败。

成功路径也不能只判断 err 为 nil。这里检查载荷字节是否等于原输入的载荷部分，同时检查接受条件。原始切片没有被修改是一条额外性质；返回值是否与输入共享底层存储则是本例明确允许的设计，不应该为它编写相反的断言。

这个 oracle 是独立表达的短小协议判定，但依然可能与被测实现共享理解错误。对于真实协议，应结合带明确期望值的表驱动测试、规范样例或独立实现比较，不能把一个往返断言当作全部正确性的证明。

把短时探索和日常回归分开安排

testing 官方文档：https://pkg.go.dev/testing

种子参数的类型及次序必须与 fuzz 目标一致。本例只有一个 []byte 参数，不要把某个种子改成 string。F.Add 放在 F.Fuzz 之前；目标内用 t.Fatal 报告性质失败，不在每次调用里追加种子。

# 在已有 Go 模块的 frame 包目录运行，先执行种子回归。
go test -run '^FuzzParse$' .
# 单目标探索，限制时长与工作进程；不是生产服务测试。
go test -run '^$' -fuzz '^FuzzParse$' -fuzztime=20s -parallel=2 .
# 日常回归也应保留普通测试。
go test ./...

这些命令是读者可自行执行的步骤，本轮没有执行它们，也没有给出虚构 PASS 或吞吐数字。普通测试运行种子语料，不等于启用持续生成；带 -fuzz 的命令才安排探索。20 秒和两个工作进程是示例预算，不代表充分测试或通用最佳设置。

接入 CI 时，可以把种子回归放在普通测试任务中，把有界探索安排到单独作业。使用隔离工作目录和非生产身份，不授予解析器不需要的网络、凭据或文件权限；语料目录需要可写以保留失败输入。并发 fuzz 作业不要竞争同一个可变工作目录，日志和语料也不要混入用户隐私。

如果真实解析器有业务输入上限，测试应围绕这个上限设计边界。为了吞吐而随便跳过所有长输入，会缩小实际测试范围，必须明确记录。对本例而言最大合法帧为 257 字节，但较长的无效输入仍应交给解析器拒绝，不能与合法长度上限混为一谈。

发现失败以后，留下可解释的回归样本

引擎发现失败时会尝试缩减输入，并把失败语料保存到对应 fuzz 目标的 testdata 目录。它和写作时挑选“最小种子”不是同一件事：前者尽量缩小某个已经出现的问题，后者为探索提供不同语义入口。

处理失败时，先区分解析器缺陷、性质写错和环境依赖。修复后保留有解释价值的失败语料作为回归；共享样本前去除敏感内容，并使用工具生成或认可的语料格式，不把任意原始二进制文件直接冒充 Go corpus 文件。不要为了让作业变绿就无条件删除失败输入。

通知中更有用的是目标名称、可复现输入位置、触发的性质、工具链与修复说明，而不是简单写“随机测试失败”。没有发现失败只能说明当前运行未触发已定义的失败条件，不能保证没有漏洞、逻辑错误或资源耗尽问题。

常见问题

只放合法帧可以吗？可以作为部分入口，但短头和错误长度等直接代表能让拒绝路径的意图更清楚，不必把一切寄托于随机变异。

一个空种子是不是足够？接口允许没有手工种子，也能从很少输入起步；但对具有结构的解析器，少量能进入不同语义分支的样本通常更值得维护，不能把空输入等同于完整覆盖。

种子越多是不是越好？不是。保留能解释的新语法、边界或历史回归；不要仅因文件不同就不断增加同质样本，也不要仅按字节数删掉关键边界。

要把 panic 恢复成普通错误吗？如果协议要求任意输入都不应 panic，测试目标就不应静默吞掉 panic。输入拒绝和程序异常要分清。

最终要维护的不是一个越来越大的文件夹，而是能说清理由的入口样本和能发现错误的断言。先把协议画小、每个种子的作用写清，再让引擎扩展输入，才容易把探索结果接回日常回归。

参考：Go fuzzing 官方说明；testing.F.Fuzz 接口契约。