testingFuzz测试边界输入

用 Go 的 testing.F 测试边界输入，关键不在于盲目生成更多随机字符串，而在于先把业务边界放进 seed corpus，再用属性断言检查结果。常见做法是用 f.Add 放入空值、下限、上限、越界值和带噪声输入，用 f.Fuzz 接收同类型参数；普通 go test 先回放种子，go test -fuzz=... 再探索覆盖率。

把边界输入放在 seed corpus 中

以端口解析为例，边界不只是“随机字符串”。空字符串、0、65535、65536、带空格的数字和极长数字，分别对应缺失、下限、上限、越界、格式噪声与长度压力。把这些样本写进 f.Add，fuzz 引擎才有一组有意义的起点。

package port

import (
    "strconv"
    "testing"
)

func parsePort(s string) (int, error) {
    // 先解析十进制，再限制端口的业务范围。
    n, err := strconv.Atoi(s)
    if err != nil || n  65535 {
        return 0, strconv.ErrRange
    }
    return n, nil
}

func FuzzParsePort(f *testing.F) {
    // 种子覆盖缺失、上下限、越界和格式噪声。
    f.Add("")
    f.Add("1")
    f.Add("65535")
    f.Add("0")
    f.Add("65536")
    f.Add(" 8080 ")

    f.Fuzz(func(t *testing.T, input string) {
        // 断言结果边界，不假设每个随机输入都能成功解析。
        port, err := parsePort(input)
        if err == nil && (port  65535) {
            t.Fatalf("port out of range: %d", port)
        }
    })
}

让 f.Fuzz 参数与 f.Add 类型对齐

Go 要求 fuzz 测试函数写成 FuzzXxx(*testing.F)，并且一个 fuzz 测试只能提供一个 f.Fuzz target。上例里 f.Add 传入 string，所以 target 必须接收 func(t *testing.T, input string)。如果改成 []byte 或增加第二个参数，所有种子都要同步调整，不能靠类型转换掩盖错位。

断言也应围绕不变量写。对于解析器，最稳的检查是“成功时结果在合法范围内、失败时不 panic”；对于编码器，可以检查 round-trip；对于校验器，可以检查非法输入始终返回错误。随机输入没有固定答案，直接断言某个具体字符串通常会让测试失去意义。

让边界失败可以复现

先跑种子语料，确认已有边界输入没有问题：

# 先回放 FuzzParsePort 的种子和已保存失败语料
go test -run=FuzzParsePort

# 再限定探索时长，避免本地任务无限运行
go test -fuzz=FuzzParsePort -fuzztime=30s

启用 fuzz 后，Go 会利用覆盖率插桩保留能扩展路径的输入。发现失败时，输入会写入 testdata/fuzz/FuzzParsePort（无法写入时可能落到 fuzz cache），之后不带 -fuzz 的普通测试也会回放它。这个目录里的失败样本应当像回归用例一样提交；缓存里的生成语料只服务当前 fuzz 运行，不要误当成稳定测试资产。

边界语料的维护清单

维护 fuzz 测试时，先问“这个输入想覆盖哪条业务边界”，再决定加入 f.Add 还是提交到 testdata/fuzz。语料越贴近真实边界，属性断言越具体，随机探索才越容易产生可复现的价值。

相关问题

普通 go test 会执行 fuzz 测试吗？

会。默认不会持续生成新输入，但会执行 f.Add 和 testdata/fuzz/FuzzParsePort 中的种子，因此适合放进日常回归。

f.Add 和 f.Fuzz 的参数为什么必须一致？

f.Add 的参数就是 seed corpus 的字段，f.Fuzz 的参数是 target 接收的字段；类型或顺序不一致，语料无法按目标签名解释。

失败语料应该放在哪里？

需要长期回归的失败样本放在对应包的 testdata/fuzz/FuzzParsePort；只在当前探索中使用的生成语料留在 fuzz cache 即可。