再也不怕漏测！基于代码Diff的智能用例推荐实战

每次上线前，总担心漏测那几行不起眼的代码改动？别慌，这篇文章将带你搭建一套“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

【影响范围】
- 本次修改可能影响结算流程和订单展示页。
- 涉及数据库操作：否（纯计算函数）

【要求】
1. 使用 Jest + TypeScript 语法。
2. 覆盖：正常逻辑（满100/不满100）、边界条件（price=100, price=0, price=负数）。
3. 针对影响范围，额外考虑调用方 `orderSummary.tsx` 的 UI 展示逻辑测试。
4. 请直接输出可运行的测试代码块。

为什么这样设计？

• 去噪音：告诉 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()

踩坑实录与效果展示

这套系统上线运行半年，经历了从被嫌弃到真香的转变。当然，过程并非一帆风顺。

遇到的坑

1. 上下文窗口截断：一开始我们把整个文件都塞给 AI，结果经常超长。解决方案是只发送变更函数及其附近 20 行的上下文。
2. 幻觉与误报：AI 偶尔会生成不存在的 API 或断言。我们增加了第二道“验证 Agent”，通过 tsc 静默编译生成的用例，编译不通过的自动过滤掉（参考双 AI 校验模式）。
3. 噪音控制：修改 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 的智能用例推荐，本质上是在对抗人脑的惯性思维——我们总是容易忽略修改带来的涟漪效应。

这套体系的核心价值在于：

1. 及时性：在代码提交的那一刻就给出反馈，而不是等到提测阶段。
2. 针对性：只关注变化，不啰嗦老代码，最大程度减少信息噪音。
3. 可落地：生成的不是抽象的测试点，而是可执行的代码，采纳成本极低。

如果你也在被漏测问题困扰，不妨从这个思路开始尝试。毕竟，让 AI 替你盯着那些肉眼容易忽略的角落，我们才能更安心地去喝咖啡，不是吗？