存量代码没人敢动?让AI先把测试补上,再谈重构
一、管理者视角下的真实困境
如果你带过一个小团队,下面这个场景大概率不陌生:
接手了一个跑了四五年的老项目,核心模块没有几行测试,覆盖率报告一打开,核心链路不到 15%。产品经理天天催新需求,团队里没人对这些老代码有完整认知,改一行挂三处。你想安排人补测试,算了一下:核心模块大概需要补 800~1000 条用例,一个中级开发全投入也要一个多月——这个人的产出在排期里“看不见”,业务方第一个不答应。
于是进入死循环:不敢动 → 没人补测试 → 更不敢动。
对独立开发者来说,问题换了个形态:项目是自己的,知道该补测试,但补测试这件事没有任何“创造快感”,写到第十条就放弃了。
这就是存量代码测试的真实痛点:不是不会写,而是写不起。
二、AI 在这件事上到底能做什么
先说清楚边界:AI 不能替你理解业务,但能把补测试这件事里 70% 的机械劳动吃掉。具体来说:
- 读懂存量代码并生成用例骨架。 把一个函数连同它的上下游依赖喂给模型,它能列出输入边界、异常分支、Mock 点,输出可直接运行的测试框架。
- 批量识别测试盲区。 配合覆盖率工具(JaCoCo、coverage.py 等),让 AI 对着未覆盖的行号逐段分析,产出“这行为什么没测到、该怎么测”的清单。
- 生成边界值和异常用例。 人写测试容易只写 happy path,AI 反而擅长穷举 null、空集合、超大数值、并发场景这类“烦人但重要”的分支。
- 让测试变得可评审。 AI 产出的是结构化代码,团队可以定标准:命名规范、断言密度、是否测异常,评审一条 AI 用例远快于从零写一条。
从管理者角度看,最关键的一点是:AI 把“补测试”从一个人的隐性苦力,变成了可排期、可评审、可验收的工程任务。
三、落地流程:四步走,风险可控
我们按小团队(2~5 人)的规模来设计流程,核心原则是“AI 产出,人来把关”:
第一步:圈定范围,不做全量。 挑出改动最频繁、风险最高的两三个模块作为首批目标。别试图一次性补全整个项目,那只会产出大量低质量测试。
第二步:准备上下文。 把目标模块的源码、依赖接口、已有的少量测试样例(让 AI 学习团队的测试风格)一起整理好。上下文质量直接决定产出质量,这一步值得花时间。
第三步:分批生成,小步提交。 每次让 AI 处理一个类或一个函数,生成后立即在本地跑通,确认断言真实有效——尤其警惕“永远为真”的假断言。每批通过评审后再合入。
第四步:建立验收标准。 最低要求:测试能跑过、断言有意义、覆盖了主要异常分支。可以规定 AI 生成的用例必须经过人工 review 才能进主干,把风险控制做在流程里,而不是事后补救。
四、提示词模板
下面这个模板可以直接复制使用,按需替换占位符:
你是一位资深测试工程师。请为下面的存量代码编写单元测试。
【代码】
{粘贴目标函数或类的源码}
【依赖说明】
{列出外部依赖、需要 Mock 的接口及其大致行为}
【团队测试规范】
- 测试框架:{JUnit 5 / pytest / Vitest 等}
- 命名规范:{如 should_xxx_when_yyy}
- 一个测试方法只验证一个行为
【要求】
1. 覆盖正常路径、边界值(空/null/极大极小值)、异常分支
2. 对外部依赖使用 Mock,不要发起真实网络或数据库调用
3. 每条用例的断言必须具体,禁止无断言或恒真断言
4. 在每条测试上方用一行注释说明:它防止的是哪类线上问题
5. 如果代码中存在你无法确定行为的地方,不要猜测,单独列出提问
【输出】
可直接运行的完整测试文件,以及一份“无法覆盖/存疑”清单。最后那条“列出存疑清单”很关键——它把 AI 从“猜一个答案”变成“暴露认知边界”,这正是管理者需要的风险信号。
五、用 AI 前后对比
| 维度 | 传统人工补测试 | AI 辅助流程 |
|---|---|---|
| 单条用例成本 | 全手写,含调试约 20~40 分钟 | 生成 1 分钟,人工评审 3~5 分钟 |
| 边界/异常用例 | 依赖个人习惯,常遗漏 | 系统性穷举,遗漏率明显下降 |
| 团队接受度 | 被视为低价值苦力,无人愿意认领 | 可排期、可评审的明确任务 |
| 覆盖率变化 | 排期难,常年停在低水平 | 核心模块数周内显著提升(具体数字因项目而异) |
| 风险 | 挤占业务开发时间 | 需流程约束:强制人工评审 + 假断言检查 |
一个务实的预期是:AI 不消灭人的工作,而是把人从“写用例”挪到“评审用例”。评审本身也是理解存量代码的过程——团队对老代码的心智模型,反而是这个流程的副产品。
六、几句风险提醒
- 不要追求覆盖率数字本身。 90% 覆盖率但全是假断言,比 40% 但条条扎实更危险。
- 涉及价格的工具选型,以官网价格页为准,先算清楚按 token 计费下批量生成测试的成本结构。
- AI 生成的测试也需要测试:定期在 CI 里跑突变测试(如 PIT、mutmut),检验断言质量。
写在最后
存量代码的测试债,靠“下个季度一定补”是还不清的。AI 的意义在于把还债的成本压到团队可以承受的水平,让“敢动老代码”重新变成可能。
如果你已经在考虑把 AI 能力系统性地接入团队的开发流程,可以看看这个平台,注册入口在这里:https://api.thistoken.ai/register ——从测试生成开始,把 AI 变成团队流程里一个可管理的环节。
---
本文的示例只需一个 API Key 就能复现:在 https://api.thistoken.ai/register 注册即用。