Go testing.F 如何设置模糊测试时间上限

写好 FuzzXxx(f *testing.F) 后，模糊测试不会因为函数返回就自动停下。真正的运行上限由 go test 的 -fuzztime 设置：可以写成时间，例如 30s、2m，也可以写成执行次数，例如 1000x。如果不设置，它默认会持续运行，直到找到失败输入或被中断。

Go 里要给 testing.F 模糊测试设置时间上限，最常用的方式是通过 go test 命令的 -fuzztime 参数配置，也能在测试代码里调用 f.Add() 之外的逻辑配合 context 自行控制运行时长。

不需要修改测试用例的内部代码，直接在执行模糊测试的时候追加 -fuzztime 标识就能指定单次模糊测试的最长运行时间，比如设成 30s 就代表测试最多跑 30 秒就自动结束，不用手动中断。

时间上限不写在 testing.F 里

testing.F 是 fuzz 测试入口参数。它可以用 Add 注册种子，再用 Fuzz 接收真正的 fuzz target；当 fuzzing 开启后，F.Fuzz 会持续调用目标函数，直到发现问题、时间用尽或进程被中断。因此不建议在目标函数中再创建一个定时器来“截断”测试，这会把业务输入检查和测试调度混在一起。

func FuzzParse(f *testing.F) {
    // 种子覆盖已知的正常输入和一个边界输入。
    f.Add("name=go")
    f.Add("")

    f.Fuzz(func(t *testing.T, raw string) {
        // 目标函数应尽量快速、确定，并把失败交给 *testing.T。
        if _, err := ParseQuery(raw); err != nil {
            t.Skip()
        }
    })
}

启动时只需要指定一个匹配的 fuzz 测试，并把预算交给命令行：

# 只运行 FuzzParse，并让 fuzzing 最多持续 30 秒。
go test -run '^$' -fuzz '^FuzzParse$' -fuzztime 30s ./...

这里的 -run '^$' 用来跳过普通测试，适合想单独观察 fuzzing 的场景；如果希望先运行包内普通测试再开始 fuzzing，可以去掉它。官方规则要求 -fuzz 最终只匹配一个包中的一个 fuzz 测试。

按时间还是按次数设置 -fuzztime

两种写法解决的是不同问题。按时间更适合给开发机或 CI 设置固定预算，按次数更适合比较两次运行的探索规模。次数不是所有测试耗时的保证：单次输入处理很慢时，1000x 仍可能运行很久；同样，30s 内能够执行多少次也会随机器和代码变化。

写法	含义	适合场景
-fuzztime 30s	按持续时间运行	本地快速探索、CI 时间预算
-fuzztime 5m	按持续时间运行	夜间任务或较大输入空间
-fuzztime 1000x	调用 fuzz target 1000 次	固定迭代规模、对比基准

例如，提交检查可以先用较小时间预算：

# CI 只给一个可控的短窗口；失败输入仍会被 Go 保存到语料目录。
go test -fuzz '^FuzzParse$' -fuzztime 45s ./path/to/parser

需要可重复比较时，则把机器差异从预算里拿掉：

# 用固定调用次数比较代码改动前后的 fuzz 探索结果。
go test -fuzz '^FuzzParse$' -fuzztime 2000x ./path/to/parser

别把三个超时参数混为一谈

排查“怎么还没停”时，先看参数控制的层级。-fuzztime 只限制 fuzzing 阶段；-timeout 是整个测试二进制的保护线，默认值由 go test 规定，设为 0 才是关闭；-fuzzminimizetime 则是在发现失败后，限制每次最小化尝试的预算。失败发生后，最终耗时可能超过你直觉里的 fuzz 时长，因为还包含了最小化阶段。

参数	控制对象	常见误解
-fuzztime	fuzz target 的探索时间或次数	以为能限制每个输入的处理时间
-timeout	整个测试二进制的最长运行时间	以为它只限制 fuzz 阶段
-fuzzminimizetime	失败输入的最小化尝试	以为它决定正常探索时长
-parallel	fuzz 进程并发度	以为并发数越高越稳定

一个更稳妥的 CI 组合是给 fuzz 本身一个明确预算，再给整个测试进程留出编译、普通测试和失败最小化的余量：

# fuzz 45 秒；整个测试进程最多 3 分钟；最小化失败样本最多 20 秒。
go test -fuzz '^FuzzParse$' -fuzztime 45s -fuzzminimizetime 20s -timeout 3m ./path/to/parser

让 CI 能判断“到时结束”还是“提前失败”

达到 -fuzztime 后没有发现问题，通常会以成功状态结束；如果 fuzz target 调用 t.Error、t.Fatal 或触发 panic，则会先写出失败输入并以失败状态结束。脚本不要只截取最后一行日志，至少保留测试退出码、选中的目标名和命令参数。

# 记录完整命令，便于复盘本次预算和目标是否一致。
go test -json -fuzz '^FuzzParse$' -fuzztime 45s ./path/to/parser
status=$?
# 退出码为 0 表示本轮没有以测试失败结束；非 0 需回看失败语料和日志。
exit "$status"

如果一直不结束，先确认是否漏写了 -fuzztime，再检查 fuzz target 是否存在死循环或单次输入耗时过长。若只是失败后的最小化太久，调整的是 -fuzzminimizetime，不要反复缩短 -fuzztime。

相关问题

只运行种子语料也需要设置 -fuzztime 吗？

不需要。没有 -fuzz 时，go test 会按普通测试方式运行种子语料；-fuzztime 主要限制启用 fuzzing 后的持续探索。

-fuzztime 1000x 能保证命令只运行 1000 次吗？

它限制的是 fuzz target 的迭代次数，不等于整个测试进程只做 1000 个动作；编译、普通测试、语料准备和失败最小化仍可能增加总耗时。

能在 testing.F 内调用计时器停止 fuzzing 吗？

不建议把它当总时长控制手段。优先使用命令行预算；目标函数内部只处理输入并通过 *testing.T 报告该输入是否失败。