每次上线前，总担心漏测那几行不起眼的代码改动？别慌，这篇文章将带你搭建一套“AI测试脑细胞”，让它像老司机一样，盯着代码Diff自动给你生成精准的测试用例。
前言：那些年，我们为了“漏测”背过的锅
两年前的一次上线，我至今记忆犹新。当时只是为了修复一个文案拼写错误，顺手重构了工具类里一个私有方法。由于改动看起来“人畜无害”，我没有补充测试用例，Code Review 也只是一扫而过。
结果上线后，核心流程报错，直接导致了一个 P0 级故障。最后定位到原因：我重构的那个私有方法，被另一个完全无关的模块通过反射调用了。
从那以后我就意识到，人眼对于代码 Diff 的敏感度，会随着改动人数的增加而指数级下降。 我们急需一个机制，它能像保安一样，盯着每一行新增或删除的代码，然后自动告诉我们：“嘿，根据这几行改动，你应该去跑跑这几个场景！”
经过几个月的摸索和迭代，我们团队终于沉淀出一套基于代码 Diff 的智能用例推荐系统。本文将毫无保留地分享这套系统的实战搭建过程。
核心思想：为什么是“Diff”？
传统的自动化测试用例生成，往往是基于整个接口或模块的全量扫描。这不仅耗时，而且会产生大量无效的“废话”用例。
而我们只关注 Diff。
在 Git 版本控制的世界里，Diff 是代码变更的唯一真相 。任何 Bug 的引入，必然伴随着一段 Diff 的产生。如果能让 AI 读懂这次 Diff 的意图，以及它的“影响半径”，那么针对性地生成测试用例就变得可行了 。
我们的目标是：只要 Diff 涉及到的业务逻辑，就必须有对应的测试用例覆盖；如果没有，AI 自动生成并提醒开发者。
技术架构总览
为了实现这一目标，我们设计了一套基于 Git Diff + 静态分析 + LLM 的流水线。
整体流程图如下（建议保存）：
第一步：不只是文本 Diff，而是“语义 Diff”
普通的 git diff 输出的是文本行的增减。但如果直接把这种纯文本丢给 AI，它很容易被代码格式、空行变化干扰，产生误判 。
我们需要把文本 Diff 转化为结构化的变更信息。
实战工具：Tree-sitter我们用 Tree-sitter 来解析代码。它比正则表达式更靠谱，能精确识别出：这次修改究竟属于哪个函数、哪个类、哪个条件判断。
示例： 假设 Diff 显示了某行代码变更：
// 修改前
- const discount = price * 0.1;
// 修改后
- const discount = price > 100 ? price 0.15 : price 0.05;
Tree-sitter 会告诉我们：
变更所在的函数：calculateCheckoutPrice
变更类型：变量声明中的 binary_expression 变成了 conditional_expression
涉及的变量：price
这些结构化信息是我们构建高质量 Prompt 的关键。
第二步：影响范围分析——被忽视的“雷区”
回到文章开头提到的“反射调用”悲剧。为了预防这类问题，我们必须引入静态分析（Reachability Analysis） 。
在我们系统中，每当检测到一个函数内部的变更，我们会利用现有的代码分析工具（比如 EdgeBit 或自研的调用链工具）去反向查询：哪些地方调用了这个函数？这个函数又调用了哪些外部服务？
伪代码示例
def analyze_impact(changed_function, repo_ast):
callers = find_all_callers(changed_function, repo_ast) # 找出谁调用了它
callees = find_all_callees(changed_function, repo_ast) # 它调用了谁
return {
"direct_impact": callers,
"indirect_impact": callees,
"suggest_scope": ["单元测试", "集成测试"] if "数据库" in callees else ["单元测试"]
}
这一步分析的结果，会被拼接到最终的 Prompt 里，告诉 AI：“这次修改影响的不仅仅是当前文件，请连同这些调用方一起考虑测试场景。”
第三步：打造智能体协作流（Prompt 工程实战）
有了丰富的上下文，接下来就是让 AI 干活。参考 CrewAI 的多智能体协作模式 ，我们也划分了不同“角色”，但不是真的调用多个 Agent，而是在一个 Prompt 内划分清晰的思维链。
我们最终采用的 Prompt 结构（精简版）：
你是一位资深的测试开发工程师。请基于以下【代码变更】和【影响范围分析】，生成完整的测试用例。
【变更详情】（结构化输出）
- 文件：src/utils/price.ts
- 变更函数：calculateCheckoutPrice （第 45-48 行）
- 变更逻辑：价格折扣规则从固定10% 改为阶梯折扣 （满100减15%，否则5%）
- 调用方：checkoutService.ts、orderSummary.tsx
【影响范围】
- 本次修改可能影响结算流程和订单展示页。
- 涉及数据库操作：否（纯计算函数）
【要求】
- 使用 Jest + TypeScript 语法。
- 覆盖：正常逻辑（满100/不满100）、边界条件（price=100, price=0, price=负数）。
- 针对影响范围，额外考虑调用方
orderSummary.tsx的 UI 展示逻辑测试。 - 请直接输出可运行的测试代码块。
为什么这样设计？
去噪音：告诉 AI 哪些文件变了，防止它去臆想无关模块。
给上下文：把“调用方”喂给它，它生成的用例就会自然包含对调用结果的验证 。
定格式：直接要求 Jest/TS，输出即用，减少人工二次转换。
第四步：CI 集成与“守门员”策略
代码和 Prompt 都准备好了，怎么自然地融入开发流程？我们选择了 Danger.js 作为 CI 流程的“胶水” 。
工作流配置（.github/workflows/ai-test-suggestions.yml）：
name: AITestSuggestion
on:
pull_request:
types:[opened,synchronize]
jobs:
suggest-tests:
runs-on:ubuntu-latest
steps:
-uses:actions/checkout@v4
with:
fetch-depth:0# 必须拉取全量历史用于 diff
-name:SetupNode.js
uses:actions/setup-node@v4
with:
node-version:'20'
-name:InstallDependencies
run:npminstall
-name:RunAISuggestion
env:
GITHUB_TOKEN:${
{secrets.GITHUB_TOKEN}}
OPENAI_API_KEY:${
{secrets.OPENAI_API_KEY}}
run:npxdangerci--dangerfiledangerfile.test.ts
Dangerfile 的核心逻辑（dangerfile.test.ts）：我们在 Dangerfile 里完成所有脏活：获取 Diff、调用 Tree-sitter 分析、拼接 Prompt、调用 OpenAI API、最后把生成的用例贴到 PR 的评论区。
// dangerfile.test.ts
import { danger, warn, message } from"danger"
import { OpenAI } from"openai"
import { parseDiff } from"some-diff-parser-lib"
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY })
const runAIAnalysis = async () => {
const modifiedFiles = danger.git.modified_files
const diff = await danger.git.diffForFile(modifiedFiles[0]) // 简化处理，实际需遍历
// 这里拼接上面提到的复杂 Prompt
const prompt = buildPrompt(diff)
const completion = await openai.chat.completions.create({
model: "gpt-4o",
messages: [{ role: "user", content: prompt }],
temperature: 0.3, // 测试用例需要确定性，温度不宜高
})
const testCode = completion.choices[0].message.content
// 将生成的用例作为评论发出
message(`
🤖 AI 自动生成的测试建议
根据本次变更，我生成了以下测试用例，请Reviewer重点关注：
```typescript
${testCode}
```
`)
}
runAIAnalysis()
踩坑实录与效果展示
这套系统上线运行半年，经历了从被嫌弃到真香的转变。当然，过程并非一帆风顺。
遇到的坑
上下文窗口截断：一开始我们把整个文件都塞给 AI，结果经常超长。解决方案是只发送变更函数及其附近 20 行的上下文。
幻觉与误报：AI 偶尔会生成不存在的 API 或断言。我们增加了第二道“验证 Agent”，通过 tsc 静默编译生成的用例，编译不通过的自动过滤掉（参考双 AI 校验模式）。
噪音控制：修改 Readme 或配置文件时，也触发用例生成，导致开发者厌烦。后来加入了过滤器，只针对 src 目录下的 ts/js/jsx/tsx 文件生效。
真实效果
在一次典型的订单逻辑修改中，AI 生成了如下 PR 评论：
🤖 AI 自动生成的测试建议根据本次变更，我生成了以下测试用例，请 Reviewer 重点关注：
describe("calculateCheckoutPrice 阶梯折扣", () => {
test("消费金额 >100 应享受 15% 折扣", () => {
expect(calculateCheckoutPrice(200)).toBe(170); // 200 - 200*0.15
});
test("消费金额 =100 应享受 15% 折扣 （边界）", () => {
expect(calculateCheckoutPrice(100)).toBe(85);
});
test("消费金额 <100 应享受 5% 折扣", () => {
expect(calculateCheckoutPrice(80)).toBe(76);
});
test("消费金额为 0 应正确处理", () => {
expect(calculateCheckoutPrice(0)).toBe(0);
});
test("消费金额为负数应抛出异常或返回0", () => {
expect(() => calculateCheckoutPrice(-10)).toThrow();
});
});
// 针对影响范围 orderSummary.tsx 的额外验证
test("orderSummary 应正确显示折扣后的价格", () => {
// ... 模拟组件渲染逻辑
});
开发者看到评论后，直接复制代码到 tests 目录下，稍作调整即可运行。那种“漏测”的焦虑感，真的减轻了很多。
总结：AI 不是取代测试，而是补齐“人性”的短板
基于代码 Diff 的智能用例推荐，本质上是在对抗人脑的惯性思维——我们总是容易忽略修改带来的涟漪效应。
这套体系的核心价值在于：
及时性：在代码提交的那一刻就给出反馈，而不是等到提测阶段。
针对性：只关注变化，不啰嗦老代码，最大程度减少信息噪音。
可落地：生成的不是抽象的测试点，而是可执行的代码，采纳成本极低。
如果你也在被漏测问题困扰，不妨从这个思路开始尝试。毕竟，让 AI 替你盯着那些肉眼容易忽略的角落，我们才能更安心地去喝咖啡，不是吗？
