AI 单测覆盖率攻坚：用 AI 编程工具补齐单元测试的实践指南

适用人群

三类人：接手遗留代码库、测试几乎为零的人、覆盖率卡在 40–60% 上不去的人、想用 AI 把「补测试」从苦役变成流水线的人。

目标不是追求 100% 覆盖率的数字游戏，而是用 AI 把关键路径与边界条件的测试快速补齐，让重构与发布有安全网。

为什么值得做（先算清这笔账）

补测试长期排在待办清单最后，因为它「不产生新功能」。但换算成成本就很清楚：

• 没有测试时，一次中等规模重构需要人工回归 2–4 小时，还不敢保证覆盖到边界；
• 有关键路径测试后，同一重构的验证压缩到一次 CI 运行（通常 5–15 分钟），且失败点精确定位到函数。

AI 工具改变的是补测试的单位成本：原本写一个带边界条件的用例要 10–20 分钟，现在生成骨架 + 人工订正约 2–3 分钟。这意味着「把覆盖率从 0 拉到 60%」第一次变成一件可以在一个迭代内完成的事。

但要小心反向风险：AI 生成的假测试会让覆盖率数字上涨，而风险一点没降。所以本流程把「人工审断言」设为不可跳过的关卡。

工作流总览

1. 先量后补：跑一次覆盖率报告，定位「零覆盖」文件与低覆盖函数，列出缺口清单
2. 按风险排序：优先核心域、资金 / 权限 / 解析逻辑，而不是按文件顺序平推
3. AI 生成初版用例：把函数 + 现有调用方喂给 AI，让它产出测试骨架
4. 人工订正断言：AI 容易写出「永远通过的假测试」，必须核对断言是否真在验证行为
5. 补分支与异常路径：让 AI 专门针对 if/else、空值、超时、错误码生成边界用例
6. 接 CI 门禁：把覆盖率阈值写进流水线，低于阈值阻断合并

第 1 步：先量，再补

不要凭感觉挑文件。先跑一次覆盖，导出 machine-readable 的报告：

# TypeScript / JavaScript
npx vitest run --coverage --coverage.reporter=json-summary --coverage.reporter=text

# Python
pytest --cov=src --cov-report=term-missing --cov-report=json

然后按「零覆盖 + 高改动频率」排序——从 git 历史里找改动最频繁的文件：

git log --format=format: --name-only | grep -E '\.(ts|py)$' \
  | sort | uniq -c | sort -rn | head -30

两个清单取交集：改动最频繁且零覆盖的文件，就是第一批目标。这类文件的每一行改动都在裸奔，补测试的边际收益最高。

第 2 步：可直接复用的提示词模板

提示词的质量直接决定用例质量。下面这段在 Cursor / Claude Code / Aider 里都可用：

阅读 @src/billing/settlement.ts 以及它现有的调用方。

请为 `calculateSettlement` 生成 vitest 单元测试，要求：
1. 用例覆盖以下分支：正常结算、金额为 0、金额为负、货币不受支持、上游汇率接口超时
2. 每个断言必须验证可观测行为（返回值、抛出的错误类型、或 spy 到的调用参数），
   禁止只断言「不抛错」或 `expect(true).toBe(true)`
3. 外部依赖用 vi.mock 隔离，但关键路径保留至少一个不 mock 的轻量集成用例
4. 每个用例用 it('should ...') 描述被测行为，不要写 `test1` 这类命名
5. 遵循仓库现有测试文件的风格（参考 @src/billing/__tests__/tax.spec.ts）

写完后自查一遍：有没有哪个用例即使被测函数被改成 return null 也能通过？
如果有，重写它的断言。

第 5 条（喂参考文件）是质量分水岭——让 AI 先读一个现有测试文件，风格、mock 方式、命名习惯会立刻对齐，省掉大量返工。

最后那句自查尤其有用：它把「假测试」的排查变成模型的自我约束，实测能过滤掉大部分只断言「不抛错」的用例。

第 3 步：人工订正——三种典型的假测试

AI 生成的用例里，这三种必须逐个改掉：

一个 Python 对照示例：

# ❌ 假测试：几乎任何实现都能通过
def test_parse_amount():
    result = parse_amount("¥1,234.50")
    assert result is not None

# ✅ 真测试：锁死行为，含边界
def test_parse_amount():
    assert parse_amount("¥1,234.50") == Decimal("1234.50")
    assert parse_amount("0") == Decimal("0")

def test_parse_amount_rejects_malformed():
    with pytest.raises(ValueError, match="unparseable amount"):
        parse_amount("abc")

def test_parse_amount_handles_none():
    assert parse_amount(None) is None   # 明确锁死 None 的契约

第 4 步：补分支与异常路径

覆盖率上不去的常见原因不是没写测试，而是只测了 happy path。第二轮专门针对分支：

针对 @src/billing/settlement.ts，列出所有 if / switch / try-catch 分支，
逐个标注「已有测试」与「无测试」。对无测试的分支生成补充用例，
特别关注：空值、空数组、超长输入、并发调用、依赖返回 null、超时与重试。

把输出做成清单贴在 PR 里，逐条勾掉——这比笼统地「补一补测试」更容易验收。

第 5 步：接 CI 门禁

覆盖率不进 CI 就一定会退化。GitHub Actions 示例：

# .github/workflows/test.yml
- name: Test with coverage
  run: npx vitest run --coverage --coverage.reporter=json-summary

- name: Enforce coverage gate
  run: |
    GLOBAL=$(node -p "require('./coverage/coverage-summary.json').total.lines.pct")
    echo "Global line coverage: $GLOBAL%"
    node -e "
      const pct = require('./coverage/coverage-summary.json').total.lines.pct;
      if (pct < 70) { console.error('❌ 覆盖率低于 70%'); process.exit(1); }
    "

两条建议：

• 双阈值：整体 ≥70% 且新增代码 ≥80%。只设整体阈值会让老代码拖住新代码，反之则纵容存量继续裸奔。
• 先设「不下降」再提阈值：第一周把门禁设成「不得低于当前值」，稳住之后每周 +2%，比一步到位更容易推行。

各工具怎么用

• Cursor / Claude Code / Aider：在编辑器内选中函数，用「为这个函数写单测」类指令生成；Claude Code / Aider 还能跨文件理解调用关系，适合补集成层测试。注意让模型先读测试文件约定（框架、mock 方式），保持风格一致。
• Qodo 等 AI 代码审查工具：不只补测试，还能在 PR 阶段标出「改动未覆盖」的语句，把覆盖率检查前移，避免事后补测。
• CI 侧：用 vitest --coverage / pytest --cov 出报告，设门禁（如整体 ≥70%、新增代码 ≥80%）。

常见坑

• 假测试：AI 生成的用例若断言过松（只 expect(true).toBe(true) 或只断言「不抛错」），覆盖率会涨但质量为零。务必审断言。
• mock 滥用：过度 mock 会让测试通过但脱离真实行为；关键路径保留真实依赖或轻量集成测试。
• 忽视测试可维护性：测试也要随代码演进；让 AI 在改实现时同步改测试，别留过期用例。
• 只追百分比：UI / 胶水层追求高覆盖性价比低，把额度留给核心逻辑。
• 把 AI 输出当终点：生成的是初稿，不是成品。跳过人工审断言这一关，等于用覆盖率数字自欺。

分阶段落地路线

怎么判断做对了

别只看覆盖率百分比，同时盯这三个更能反映真实收益的指标：

• 变更失败率（CFR）：上线后需要回滚 / 热修的比例，补测试后应可见下降；
• PR 平均评审时长：关键路径有测试覆盖时，评审者不必逐行推演边界，评审更快；
• 测试一次通过率：AI 生成的用例里，未经修改就能通过的比例，反映你的提示词模板成熟度。

延伸

• Qodo 工具卡：AI 代码审查
• Cursor 工具卡
• Claude Code 工具卡
• Aider 上手指南
• 代码审查提示词（Staff 级）