Fuzz、Benchmark、Race 与回归门禁¶
要点卡¶
30 秒回答
单测验证已知案例，fuzz 用覆盖引导探索未知输入，race detector 只能发现实际执行路径上的数据竞态，benchmark 则必须在稳定环境下比较分布与 alloc，而不是迷信一次 ns/op。CI 应分层：快速单测每次提交，-race/fuzz seed/关键 benchmark 做门禁，长时间 fuzz 和全量压测进入 nightly；覆盖率只是发现未测试区域的信号。
3 分钟展开
- Fuzz：先放合法/非法 seed corpus，再写永远应成立的 invariant；发现的崩溃输入进入回归 corpus。
- Race：编译插桩 + happens-before 运行时分析；没报不等于无竞态。
- Benchmark：隔离初始化、报告分配、控制并发和数据规模；比较前后版本而非背绝对数。
- 门禁：按风险和耗时分层，避免把 flaky benchmark 当硬阈值。
| 记忆槽 | 内容 |
|---|---|
| 三个不变量 | fuzz、race、benchmark 和 coverage 回答不同问题；race 只发现执行路径；性能结论必须比较同环境分布 |
| 手画图 | commit → unit/vet → targeted race → fuzz corpus → benchmark compare，长测放 nightly |
| 项目落点 | 用实际交易解析、金额处理或并发状态机说明 invariant、回归 corpus 与基准门禁；只引用本人实际参与部分和可解释指标 |
| 一个取舍 | PR 门禁反馈快但覆盖有限；长 fuzz/压测更深却成本高，需按风险分层 |
错误表达
- ❌ “
-race没报就是无竞态；覆盖率 90% 说明代码正确；一次 ns/op 就能证明优化。” - ✅ “这些工具都提供证据而不是证明；结论必须说明执行路径、样本、环境和统计波动。”
自测追问：fuzz 应断言示例输出还是 invariant？benchmark 为什么要报告 alloc 并多次比较？
10 分钟版（原理 + 图示）¶
flowchart LR
Commit --> Unit["unit + vet"]
Unit --> Race["targeted -race"]
Race --> Seed["fuzz corpus regression"]
Seed --> Bench["critical benchmark comparison"]
Bench --> Merge
Nightly["nightly"] --> LongFuzz["long fuzz"]
Nightly --> Load["integration / load"]func FuzzDecodeAmount(f *testing.F) {
f.Add("0")
f.Add("1.23")
f.Add("-1")
f.Fuzz(func(t *testing.T, s string) {
amount, err := ParseAmount(s)
if err != nil {
return
}
if amount.Sign() < 0 {
t.Fatalf("accepted negative amount %q", s)
}
roundTrip, err := ParseAmount(amount.String())
if err != nil || roundTrip.Cmp(amount) != 0 {
t.Fatalf("round trip failed: %q", s)
}
})
}
Fuzz target 应快、确定、无外部网络；不要把“任何输入都不 panic”当唯一断言，还要验证业务不变量。
func BenchmarkEncode(b *testing.B) {
value := fixture()
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
Sink = Encode(value)
}
}
基准结果受 CPU 频率、热状态、后台任务、GC、编译器和数据分布影响。用多次样本和统计比较工具观察变化，阈值应给噪声留余量。
生产场景¶
- 钱包地址/交易解析器：fuzz 长度、编码、未知字段和恶意输入。
- 并发缓存：单测 +
-race+ 高冲突 benchmark。 - RPC JSON 解码：保存触发 panic 或极端分配的 corpus，防止回归。
- 核心撮合/账本：benchmark 同时看
ns/op、B/op、allocs/op和尾延迟压测。
排查与工具¶
go test ./...
go test -race ./...
go test -fuzz=FuzzDecodeAmount -fuzztime=30s ./path/to/pkg
go test -run='^$' -bench=. -benchmem -count=10 ./path/to/pkg
Fuzz 发现失败后先固定 corpus，再最小化并修复；不要只删掉失败文件。Race 报告要看双方访问栈和 goroutine 创建栈。
架构取舍¶
| 工具 | 找什么 | 找不到什么 |
|---|---|---|
| unit test | 已知行为回归 | 未想到的输入 |
| fuzz | 输入空间中的崩溃/不变量违反 | 未执行到的协议状态组合 |
| race | 被执行路径的数据竞态 | 业务竞态、死锁、泄漏 |
| benchmark | 微观性能变化 | 完整系统 P99 与容量 |
深挖问答¶
- Fuzz 是否替代单测？ → 否；seed 和明确案例仍用于可读的行为契约。
- Race 为什么不全生产开启？ → CPU/内存开销显著且依工作负载变化，通常放 CI/预发或少量 canary。
- Benchmark 变快 3% 能合并吗？ → 先判断是否超出噪声，并确认没有正确性/内存/尾延迟回退。
- 覆盖率 100% 就够吗？ → 可能没有有效断言，也可能没覆盖并发时序和真实依赖语义。
- 如何测并发 benchmark？ → 根据目标使用
RunParallel或显式 goroutine，并报告 contention 与工作负载。
反模式与事故¶
- Fuzz target 访问公网或共享 DB，结果不可复现。
- benchmark 把 fixture 创建和日志输出计入热路径。
- race 只跑几秒、路径覆盖很低，却宣称“没有竞态”。
- CI 对微小 benchmark 抖动硬失败，团队最后关闭门禁。