写一条真能抓住 bug 的测试：借鉴 TestGen-LLM

AI 一口气补了十条测试，运行全绿，看起来很安心。现在把那个已经修过的 bug 放回来：它们会红吗？这一篇最有意思的时刻，就在测试终于抓住错误的那一下。

AI 可以提出很多测试，执行结果决定哪些值得留下。 TestGen-LLM 从已有人工测试出发生成增强版本，再通过构建、稳定运行与覆盖率等检查筛选。

资料核对：2026-10-22；论文提交于 2024-02-14，发表于 FSE 2024。

Meta 怎样筛掉无用候选

实际部署论文。 Meta 的论文记录了 Facebook 和 Instagram 的实际使用。在 Instagram Reels、Stories 的评估中，生成测试有 75% 能构建、57% 能可靠通过、25% 能增加覆盖率；在另外的测试活动中，工程师接受了 73% 的推荐用于生产部署。论文与摘要

前三个比例描述生成测试的构建、运行和覆盖结果；73% 的分母则是测试活动中提交给工程师的推荐，并非所有原始生成测试。先筛选，再交人判断，正是这项实践值得借鉴的部分。

让候选测试过几道关

已有测试与待覆盖行为 → AI 生成候选测试
                   → 构建 → 重复运行 → 检查新增覆盖 → 人检查断言

覆盖率增加说明测试执行到了更多代码，还需要检查断言是否表达真实需求。TestGen-LLM 是 Meta 的内部工具，这里借鉴的是生成后再筛选的流程。

小挑战：亲眼看见它由绿变红

建议在有明确风险的纯函数上实验，例如检查一个路径转换函数是否正确保留 URL 锚点。把预期行为和已有测试交给 AI，让它最多提出三个候选，检查断言是否真的约束了输出结果。

先运行候选测试，看见绿；再在临时分支中故意制造对应错误，例如丢掉锚点，观察哪个测试变红；最后恢复实现，确认它重新通过。留下这份 正确实现 → 目标错误 → 恢复实现 的对照，保留能发现目标错误的测试，删除重复或没有有效断言的候选。

如果始终全绿，回头看断言：它究竟要求结果满足什么？这个小实验借用了筛选原则，不是复现 Meta 的完整系统。

这一局的成果：一条能在目标行为出错时失败的测试。 不必为了提高覆盖数字给低风险代码批量补测试。

返回实践目录。