编程面试：如何用 Go fuzz 测试把失败输入变成回归语料？

题干与适用场景

你维护一个 Go 输入解析器，线上偶发遇到 Unicode、截断字节或极端长度。请说明如何用 testing.F 设计 fuzz target，哪些输入应作为种子，如何表达不能预先知道精确输出的性质，以及失败后怎样修复并保留回归语料。

题目适合后端、基础设施和测试工具岗位。Microsoft 的技术面试指引把测试、边界和安全影响列为评价点；Amazon 的 SDE 指引也把编程与系统基础列为准备主题。这里的重点不是背命令，而是把测试不变量连接到可重复的工程流程。

面试官考察点

• 能否区分示例测试的期望值与 fuzz 测试的性质。
• 能否选择可快速执行、无外部副作用的 fuzz target。
• 能否解释种子语料、覆盖率引导、失败输入最小化和回归运行的关系。
• 能否处理无效 UTF-8、空输入、超长输入和资源上限。
• 能否把发现、修复、复跑和提交语料说成闭环。

普通回答只说“随机生成输入”；强回答会给出不变量、命令、失败文件位置和 CI 分层策略。

回答前需要澄清的问题

1. 解析器的输入是 string、[]byte 还是多个字段？这决定 fuzz 参数类型和语料格式。
2. 允许哪些无效输入？若无效输入应返回错误，就不能把“永不返回错误”当作不变量。
3. 单次调用的资源上限是多少？慢输入可能是拒绝服务信号，需要让 target 快速失败。
4. 目标是找 panic、语义错误，还是兼容性回归？不同目标需要不同断言和种子。

30 秒回答框架

我会先写出可判定的不变量，例如“编码器再解码应得到同一结构”或“无效输入只能返回受控错误”。用 f.Add 放入真实边界样本，再在 f.Fuzz 中保持 target 纯函数、快速且有资源上限。平时用 go test 跑种子和已保存失败样本，专门的 CI 任务再用 go test -fuzz 扩展覆盖。Go 会把失败输入最小化并写入 testdata/fuzz/<名称>；修复后我会复跑该样本、全量单测，再把语料作为回归资产提交。

分步骤深入解答

1. 从性质而非答案开始

对解析器可用往返性质：Encode(Parse(x)) 在规范化后应等于 x；对字符串变换可用幂等、长度守恒或 UTF-8 有效性。性质必须允许合法的规范化差异，不能把偶然的字节布局当作契约。

2. 设计可控的 fuzz target

func FuzzParseRoundTrip(f *testing.F) {
    f.Add([]byte("name=alice"))
    f.Add([]byte{})
    f.Fuzz(func(t *testing.T, input []byte) {
        t.Helper()
        if len(input) > 1<<20 {
            t.Skip()
        }
        got, err := Parse(input)
        if err != nil {
            return
        }
        encoded := Encode(got)
        again, err := Parse(encoded)
        if err != nil || !Equal(got, again) {
            t.Fatalf("round trip failed: err=%v", err)
        }
    })
}

f.Add 的类型和顺序必须与 fuzz 回调参数一致。target 不应写文件、发请求或依赖时间；否则失败难以复现，且并行 fuzz 会污染环境。

3. 让种子覆盖业务边界

种子不是随机样本清单，而是覆盖协议版本、空值、重复字段、非 ASCII、截断输入和历史线上样本的最小集合。Go 会先用种子执行普通测试，因此每个种子都应便宜且稳定。

4. 运行与分层

提交前运行 go test -run=FuzzParseRoundTrip 验证种子；在专门任务中运行 go test -fuzz=FuzzParseRoundTrip -fuzztime=10s。-fuzztime 给探索设置上限，避免开发机或 CI 无限占用。并行度、超时和包级资源预算应由 CI 控制，而不是写进业务代码。

5. 读取失败输入并判断根因

Go 会最小化仍能触发错误的输入，并写入 testdata/fuzz/FuzzParseRoundTrip/。先用 go test -run=FuzzParseRoundTrip/<id> 重放，再判断是断言错误、解析器 panic、资源耗尽还是测试本身的非确定性。最小样本应能解释根因，而不是只作为神秘字符串保存。

6. 修复后把发现固化

修复代码后先重放失败样本，再运行全部 go test。失败语料会在不带 -fuzz 的普通测试中继续执行，因此它是回归测试，不应被放进只在 fuzz 模式才读取的临时目录。审查时检查语料是否包含敏感数据、是否需要脱敏及是否有大小上限。

7. 监控 fuzz 质量

覆盖率长期不增长时，增加有意义的结构化种子或调整输入生成；不要单纯延长时间。若 target 经常因超时失败，先缩小输入、隔离昂贵路径或把该问题作为性能缺陷处理。Fuzz 发现量下降本身不代表安全性已经证明。

高质量示范回答

我会把 fuzz 目标定义成一个可重复的性质，而不是期待每个随机输入都有业务输出。比如解析器接受 []byte，合法输入满足解析后再编码仍代表同一结构；非法输入必须返回有限集合中的错误，不能 panic。先用 f.Add 放入空输入、最大允许长度、重复字段、Unicode 和线上脱敏样本，然后在 f.Fuzz 中限制长度并避免外部副作用。开发者用 go test -run=FuzzX 快速跑种子，CI 再用带 -fuzztime 的任务探索覆盖。失败后我会重放最小化样本，确认根因，修复实现，运行普通测试和 fuzz，再提交 testdata/fuzz/FuzzX 中的语料。这样一次随机发现会变成每次提交都执行的回归约束。

常见错误

• 把 fuzz 当随机压力测试 → 没有可判定性质，失败无法定位 → 先写不变量和错误契约。
• target 调用真实服务 → 结果受网络、时间和状态影响 → 把依赖替换为内存实现或固定 fake。
• 只在 fuzz 模式运行失败样本 → 修复可能回归而无人发现 → 将最小样本保留在 testdata/fuzz。
• 无限制接受超长输入 → fuzz 时间被单个样本吞掉 → 在 target 中设置输入上限，并记录为何跳过。
• 把所有生成语料提交进仓库 → 仓库膨胀且噪声大 → 只保留能复现缺陷或覆盖关键分支的样本。

追问及应对

如果解析器允许规范化，往返断言会不会过严？

会。改成比较规范化后的 AST 或字段集合，并明确哪些顺序、空白和大小写差异被忽略。断言应表达协议语义，而不是实现字节串。

失败样本包含用户机密，能否直接提交？

不能。先确认最小样本是否仍包含凭据、个人数据或业务内容；脱敏后必须重新确认它仍能触发缺陷。若无法安全提交，保留内部受控复现并提交等价的合成样本。

CI 只有五分钟，应该怎么安排 fuzz？

把种子和已知失败样本放在每次构建；把探索任务限制在固定时间、固定包集合和可观测资源预算内。超时不是静默跳过，应记录为待处理信号。

如何判断 fuzz 找到的是测试 bug？

用最小样本重放，检查 target 是否依赖全局状态、随机数或 goroutine 时序；再写一个确定性单测复现。若单测无法稳定复现，先修测试隔离而不是修改生产代码。

多个 fuzz target 如何共享语料？

只有在输入格式和语义契约一致时共享转换逻辑；每个 target 仍保留自己的目录和不变量，避免一个 target 的语料掩盖另一个目标的覆盖缺口。