摘要

使用 Codex 补充单元测试时，经常会出现测试文件增加了很多，但覆盖率变化不大，或者覆盖率已经很高，线上仍然出现 Bug。原因通常是测试只执行了代码，没有覆盖关键业务分支。本文介绍如何让 Codex 分析未覆盖代码、设计有效测试场景，并通过变异测试和回归验证判断测试质量。

---

很多开发者会直接向 Codex 提出：

请为这个模块补充单元测试，
把覆盖率提高到 90%。

Codex 很快就能生成大量测试代码，但运行后可能出现两种情况：

• 测试数量增加，覆盖率只提升一点；

• 覆盖率已经达到 90%，实际问题仍然没有被发现。

这说明测试数量和测试质量并不是一回事。

一、先看哪部分没有覆盖

不要只看整体覆盖率，应重点查看覆盖率报告中的四个指标：

• Statements：语句覆盖率；

• Branches：分支覆盖率；

• Functions：函数覆盖率；

• Lines：行覆盖率。

其中，分支覆盖率往往最容易被忽略。

例如：

function getDiscount(
  isVip: boolean,
  amount: number
): number {
  if (isVip && amount >= 1000) {
    return 0.8;
  }

  if (isVip) {
    return 0.9;
  }

  return 1;
}

只测试普通用户，函数虽然执行了，但 VIP 满额、VIP 未满额两个分支都没有覆盖。

可以让 Codex先分析报告：

下面是当前测试覆盖率报告。

请先不要生成测试代码，输出：

1. 未覆盖的函数；
2. 未覆盖的条件分支；
3. 高风险但没有测试的业务逻辑；
4. 只是为了提高数字的低价值测试；
5. 建议优先补充的测试场景。

二、测试业务行为，而不是内部实现

低质量测试经常关注：

• 某个函数是否被调用；

• 某个内部变量是否被赋值；

• Mock 是否执行指定次数。

这些测试可能在代码重构后大量失败，却不能证明业务结果正确。

更有效的测试应该验证：

输入什么条件
→ 系统执行什么行为
→ 用户最终得到什么结果

例如订单取消功能，应覆盖：

• 未支付订单可以取消；

• 已发货订单禁止取消；

• 无权限用户不能操作；

• 接口失败时显示错误信息；

• 重复点击不会重复提交；

• 取消成功后列表状态更新。

这些场景比单纯验证函数调用次数更有价值。

三、不要让 Codex 只测试正常流程

AI 生成测试时，通常优先覆盖“输入正常、接口成功”的理想场景。

但真实 Bug 更多来自：

• 空值；

• 异常数据；

• 权限不足；

• 网络超时；

• 重复提交；

• 历史数据；

• 并发状态变化。

可以明确要求：

请为订单取消功能设计测试矩阵。

必须覆盖：

1. 正常成功；
2. 接口失败；
3. 用户无权限；
4. 订单状态已变化；
5. 用户重复点击；
6. 返回数据缺少字段；
7. 历史订单数据不完整。

先输出测试场景和预期结果，
确认后再生成测试代码。

先设计测试矩阵，再生成代码，通常比直接要求“补测试”更稳定。

四、警惕为了覆盖率而执行无效代码

下面这种测试可能提高行覆盖率，但几乎没有业务价值：

it("执行函数", () => {
  getDiscount(false, 100);
});

它没有任何断言，即使函数返回错误结果，测试仍然可以通过。

更合理的写法是：

it("普通用户不享受折扣", () => {
  expect(getDiscount(false, 100)).toBe(1);
});

还应继续补充：

it("VIP 满额享受八折", () => {
  expect(getDiscount(true, 1000)).toBe(0.8);
});

it("VIP 未满额享受九折", () => {
  expect(getDiscount(true, 500)).toBe(0.9);
});

覆盖率的意义不是让代码被执行，而是让关键结果被验证。

五、使用变异测试检查测试是否有效

即使覆盖率很高，也不能说明断言足够严格。

一种更深入的方法是变异测试：工具会故意修改代码，例如把：

amount >= 1000

改成：

amount > 1000

如果现有测试仍然全部通过，说明边界值测试可能缺失。

常见需要重点验证的边界包括：

• 0 和负数；

• 最大值与最小值；

• 等于临界值；

• 临界值前后；

• 空数组和单条数据；

• null 与 undefined。

Codex 可以帮助生成边界测试，但开发者仍需要确认这些边界是否符合真实业务。

六、测试完成后检查 Git Diff

补充测试后运行：

npm run test
npm run test:coverage
npm run type-check
npm run build

然后检查：

git status
git diff --stat
git diff

重点确认：

• 是否只修改测试和必要业务代码；

• 是否降低原有断言；

• 是否删除失败测试；

• 是否过度使用 Mock；

• 是否为了通过测试而修改业务逻辑；

• 是否真正覆盖关键分支。

如果测试文件增加数百行，但大部分只是重复 Mock 和无效断言，应重新精简。

七、什么时候适合评估升级 Pro？

偶尔为一个小函数补测试，现有使用方式通常已经足够。

但如果 Codex 每天都需要参与：

• 阅读大型项目；

• 分析覆盖率报告；

• 设计测试矩阵；

• 生成多文件测试；

• 反复运行测试并分析失败；

• 同时处理多个模块的回归验证；

任务会形成较长的连续工作流。

建议先通过限定模块、只运行相关测试和减少重复上下文控制消耗。如果工作流已经优化，但测试生成、失败分析和完整回归仍频繁受到使用限制影响，就可以进一步评估更适合高强度开发的 Pro 方案。

真正值得升级的信号不是“偶尔测试很多”，而是 Codex 已经长期参与代码修改、测试验证和项目交付。

总结

Codex 生成测试后覆盖率没有明显提升，通常不是测试数量不够，而是没有覆盖关键业务分支。

更有效的流程是：

分析覆盖率报告 → 设计业务测试矩阵 → 补充异常和边界场景 → 运行覆盖率与变异测试 → 检查 Git Diff。

高覆盖率只是一个参考数字。能够在代码错误时真正失败、在业务变化时及时报警的测试，才是有价值的测试。

---

CSDN 文章描述

Codex 生成了很多单元测试，为什么覆盖率仍然没有提升？本文介绍分支覆盖率、业务测试矩阵、边界测试、变异测试和 Git Diff 审查方法。

推荐标签

Codex 单元测试 代码覆盖率 自动化测试 ChatGPT Pro

参考资料

1. Vitest Coverage 官方文档

2. Jest Coverage 官方文档

3. Testing Library 测试实践

4. 软件测试与变异测试实践