AI自动化测试生成SOP：从单测到回归的人审门控

发布于 2026年8月5日 · 7 分钟阅读

AI 生成测试是当下最被低估又最易翻车的 LLM 编码场景。让模型照着函数吐 20 条 pytest 用例，几分钟就出，覆盖率数字立刻好看--但"绿条"不等于"测对了"。AI 最常见的失败是断言松到形同虚设、mock 漂移到与真实接口脱节、用例互相依赖导致删一条全红。这条 SOP 把 AI 测试生成拆成五步，每步给可复制的 Python(pytest) 与 JS(jest) 代码，附踩坑和 FAQ。

核心一条铁律：AI 只出草稿，人审通过且 CI 跑绿才合并。绕过人审把 AI 测试直推主分支，短期内覆盖率漂亮，长期一定是腐烂的测试库和比没测试更危险的虚假安全感。

一、何时用 + 量化基线

不是所有模块都值得让 AI 生成测试。先量两个数：当前覆盖率、缺陷逃逸率（线上 bug 数 / 总 bug 数）。两个数一起看：覆盖率高但逃逸率也高，等于测了一堆无关路径；都低，说明测试基本没起步。AI 生成测试适合"实现稳定、边界清晰、用例可枚举"的纯函数和工具函数；不适合"行为依赖外部系统、断言难定义"的胶水代码。

量化基线用 coverage.py（Python）和 jest 内置 coverage（JS），重点看未覆盖的行号而非总百分比。先记基线，AI 生成测试后再跑一次对比--如果覆盖率涨了但未覆盖行号没变，说明 AI 在测已有覆盖的路径，纯刷数字。

二、从代码生成单测

喂给 LLM 的不是"写测试"三个字，而是函数签名 + 完整实现 + 明确的用例要求（正常/边界/异常）。要求模型按 given-when-then 结构输出，并显式禁止"非空即过"的松断言、禁止 mock 被测函数本身。

GEN_UNIT_PROMPT = """你是测试工程师。下面是待测函数的源码。请用 pytest 生成单元测试，要求： 1. 覆盖正常路径、边界值（空、零、负、最大值）、异常输入； 2. 每条测试用 given-when-then 注释说明意图； 3. 断言必须检查具体返回值或抛出的异常类型，禁止只写 assert result is not None； 4. 不要 mock 被测函数本身。只输出代码，不要解释。  源码： {code} """

生成后立刻本地跑一遍，跑不通的把报错回贴给模型让它自修，循环 2-3 轮--而不是手动改。手动改会掩盖 prompt 缺陷，下一批还是错。这个"生成->跑->回贴报错->再生成"循环是关键，失败回贴让模型自修比人改高效得多。Jest 同理，把断言禁令换成"禁止只写 expect(x).toBeDefined()"。

三、从 issue 描述生成回归测试

线上 bug 复现是最该自动化的测试。把 issue 描述（含复现步骤、预期/实际）喂给模型，要求它先生成一个能复现 bug 的失败测试，再确认修复后该测试转绿。相比从零写测试，回归测试有天然锚点：issue 里写明了"实际发生了什么"，模型只需把它翻译成断言。但 issue 描述常缺关键上下文（输入数据、环境版本），喂之前要先补全，否则模型会编造一个自圆其说的复现场景。

关键纪律：先在未修复分支上跑这条测试确认它红，再合修复确认它绿。如果"未修复也绿"，说明测试根本没复现 bug，是假回归测试，直接丢。

四、边界参数化批量生成

边界用例最适合参数化：一组输入一个表，一条测试函数跑全部。让 AI 只负责生成参数表（输入 + 预期），你套用固定的参数化模板--这样 AI 出错面收窄到数据行，而不是测试结构。pytest 用 @pytest.mark.parametrize，jest 用 test.each。让 AI 输出 JSON 格式的参数表（而非整段测试代码），人审逐行核对预期值后再套模板，可把 AI 编造断言的风险降到最低--它只能编数据，编不了测试骨架。

五、人审门控 + CI 集成

AI 测试草稿进入主分支的唯一通道：人审 + CI 双门控。CI 必须跑通所有测试且覆盖率不降；人审必须看断言质量而非数量。两道门缺一不可：只靠 CI，绿条会放过所有"能跑但没测"的废用例；只靠人审，疲劳的审阅者迟早漏掉一条互斥分支。

# .github/workflows/ai-tests.yml - AI 测试门控 CI name: ai-test-gate on: [pull_request] jobs:   test:     runs-on: ubuntu-latest     steps:       - uses: actions/checkout@v4       - uses: actions/setup-python@v5         with: { python-version: '3.12' }       - run: pip install pytest pytest-cov       # 全量测试 + 覆盖率门槛，失败即拦截合并       - run: pytest --cov=src --cov-fail-under=70 -q

人审清单（贴在 PR 模板里）：每条断言检查具体值或异常类型，无 is not None / toBeDefined() 充数；用例之间无隐式依赖（可乱序单跑）；mock 的是外部依赖不是被测函数本身；回归测试在未修复分支确认真的红过；覆盖率提升来自未覆盖行号减少，非刷重复路径。

踩坑速查

坑一AI 断言过松。 模型爱写 assert result is not None、expect(x).toBeTruthy()，几乎任何返回值都能过等于没测。人审第一关就是把"非空即过"改成具体值比对。坑二测试互相依赖。 AI 共享全局状态或依赖执行顺序，删一条连锁失败。pytest 用 fixture 隔离、jest 每条 test 前重置状态，CI 里用随机顺序跑（pytest-randomly）暴露隐式依赖。坑三伪造覆盖率。 AI 大量测 trivial getter/setter 和已覆盖路径，覆盖率涨但未覆盖行号没动。盯 --cov-report=term-missing 的具体行号，而非总百分比。坑四mock 漂移。 AI 按它想象的接口写 mock，与真实 API 字段名/返回结构对不上，测试绿但生产挂。规则：mock 只用于外部 I/O（网络/磁盘/时钟），被测函数自身的分支必须走真实代码。

常见问题

Q1：AI 生成的测试跑不通怎么办？别手动改成能跑。跑不通说明 prompt 或喂的上下文不够。把失败报错回贴给模型让它自修，循环 2-3 轮；还不行就补全函数签名/类型注解/调用示例再试。手动改会掩盖 prompt 缺陷，下一批还是错。

Q2：怎么防止 AI 造伪用例（预期值是编的）？让 AI 只输出参数表的"输入"列，"预期"列由你跑一遍当前实现填入（前提是该实现已被认定正确），再锁定为回归基线。或者让 AI 同时给出预期值的推理依据，人审逐条核对。绝不能盲信 AI 给的 expected。

Q3：人审太慢，能全自动吗？不能。AI 测试的核心风险就是"看着绿实际没测"，全自动等于把质量门禁交给一个会编断言的模型。可以自动化"跑通"和"覆盖率不降"两道门，断言质量必须人看。折中：AI 生成 + 自动跑通 + 人审抽查高风险模块（支付、鉴权、数据迁移）。

参考来源

pytest 官方文档：docs.pytest.org ｜ Jest 官方文档：jestjs.io coverage.py：coverage.readthedocs.io ｜ pytest-cov：pytest-cov.readthedocs.io LLM 单元测试生成综述（arXiv）：arxiv.org/html/2511.21382v1 流程与代码依据各产品官方文档（2026-08，以官网实时为准）

往期推荐 ①《AI 模型退役潮：8 月 10 日 GPT 下线，10 月 GPT-4 退场》 ②《video-shotcraft：把 Claude Code 变电影感视频工作室》 ③《免费编程够用吗：商汤小浣熊等四款横评》AI 声明：本文由 AI 辅助生成，经人工审核编辑。工具能力与 API 以各产品官方文档为准。互动：你让 AI 生成过测试吗，踩过"绿条但没测"的坑吗？评论区聊聊你的对策。