在软件开发过程中，"能跑的代码"往往不难得到，但覆盖全面的测试用例却常常被忽视。尤其在对老旧项目进行接口改造时，开发人员通常优先关注功能实现和联调结果，而边界条件、异常分支和兼容性逻辑往往要等到测试阶段甚至线上运行后才暴露出来。

本文将以一个 Node.js + Express 优惠券接口的重构实践为例，探讨如何利用大语言模型（LLM），如 Grok 4.3，来辅助理解接口逻辑、拆解潜在测试点、并生成可供审查的测试代码。同时，我们也将结合 ChatGPT、Claude、Gemini、DeepSeek 等其他模型进行交叉验证。我们的核心目标并非让 AI 完全取代测试或开发工作，而是将其融入到一个受控且高效的研发流程中。

一、场景概览：一个看似简单的优惠券发放接口

假设我们有一个电商后台接口，负责处理用户领取优惠券的请求。最初的需求相对直观：

• 新注册用户可以领取新人专享券；
• 老用户无法领取新人专享券；
• 每个用户对同一种优惠券只能领取一次；
• 优惠券必须在有效期限内才可领取；
• 当库存不足时，用户不能领取。

以下是接口的简化代码实现：

const express = require("express");
const app = express();
app.use(express.json());

// 模拟优惠券库存数据
const voucherCatalog = {
  "WELCOME_DISCOUNT": {
    id: "WELCOME_DISCOUNT",
    type: "NEW_USER_ONLY",
    remainingStock: 100,
    activeFrom: "2025-01-01T00:00:00Z",
    expiresAt: "2025-12-31T23:59:59Z"
  }
};

// 模拟用户已领取的优惠券记录
const userVoucherClaims = new Set();

/**
 * 判断用户是否为新用户
 * @param {object} userInfo - 用户信息
 * @returns {boolean}
 */
function checkIfFirstTimeUser(userInfo) {
  return userInfo.registrationDays <= 7 && userInfo.orderCount === 0;
}

app.post("/api/v1/voucher/apply", (req, res) => {
  const { user: requestUser, voucherId: requestedVoucherId } = req.body;
  const currentVoucher = voucherCatalog[requestedVoucherId];

  // 1. 参数校验及优惠券是否存在
  if (!requestUser || !currentVoucher) {
    return res.status(400).json({ message: "无效的请求参数或优惠券ID" });
  }

  const currentTime = new Date();
  const voucherStartTime = new Date(currentVoucher.activeFrom);
  const voucherExpireTime = new Date(currentVoucher.expiresAt);

  // 2. 有效期校验
  if (currentTime < voucherStartTime || currentTime > voucherExpireTime) {
    return res.status(400).json({ message: "优惠券未生效或已过期" });
  }

  // 3. 用户类型校验（新人券）
  if (currentVoucher.type === "NEW_USER_ONLY" && !checkIfFirstTimeUser(requestUser)) {
    return res.status(403).json({ message: "无权限领取此优惠券" });
  }

  // 4. 重复领取校验
  const claimIdentifier = `${requestUser.id}:${requestedVoucherId}`;
  if (userVoucherClaims.has(claimIdentifier)) {
    return res.status(409).json({ message: "您已领取过此优惠券" });
  }

  // 5. 库存校验
  if (currentVoucher.remainingStock <= 0) {
    return res.status(409).json({ message: "优惠券已发放完毕" });
  }

  // 6. 领取成功，更新库存和记录
  currentVoucher.remainingStock -= 1;
  userVoucherClaims.add(claimIdentifier);

  return res.json({ success: true, message: "优惠券领取成功" });
});

module.exports = app;

尽管这段代码看起来并不复杂，但在编写测试用例时，我们很快会发现其内部存在许多分支路径：

• 请求体缺少关键参数；
• 请求的优惠券 ID 不存在；
• 新用户判断逻辑的边界（例如注册天数、订单数量）；
• 优惠券有效期的起始和结束边界；
• 用户尝试重复领取同一优惠券；
• 优惠券库存已为零；
• 成功领取后，优惠券库存是否正确减少；
• 成功领取后，用户领取记录是否正确更新。

如果完全依赖人工临时补充这些测试点，很容易造成遗漏。

二、首先让大语言模型分析代码，而非直接生成测试

许多开发者在使用 AI 生成测试用例时，会直接发出"请为这段代码生成单元测试"的指令。虽然这种方式能快速得到一些结果，但其输出通常较为粗糙，需要大量后期修改。

更稳妥的策略是：首先引导模型理解代码逻辑，然后列出详细的测试点，最后再根据这些测试点生成具体的测试代码。

提示词示例：引导 AI 拆解测试点

你是一位资深的 Node.js 测试开发工程师，精通 Express 框架、Jest 测试框架和 Supertest HTTP 断言库。
下面是一段处理优惠券领取的接口代码。请你不要立刻生成测试代码，而是先完成以下任务：
1.  用简洁的语言概括接口的核心业务逻辑。
2.  按照"正常业务流程"、"异常请求参数"、"业务规则不符"、"边界条件"这四个类别，详细列出所有可能的测试点。
3.  为每个测试点标注预期的 HTTP 状态码。
4.  指出当前代码中任何不利于测试的设计缺陷。
5.  给出对这些测试点进行测试的建议优先级。

请粘贴接口代码：[此处粘贴接口代码]

Grok 4.3 等模型在此类"先分析、再生成"的任务中表现出色。它通常会以表格形式整理出测试点，例如：

分类	测试点描述	预期 HTTP 状态码
正常流程	新用户首次成功领取有效期内且有库存的新人券	200
异常参数	请求体缺少用户（user）信息	400
异常参数	请求的优惠券 ID (voucherId) 不存在	400
业务规则不符	老用户尝试领取新人专享券	403
业务规则不符	用户重复领取同一优惠券	409
边界条件	优惠券库存已为零	409
边界条件	当前时间早于优惠券的生效时间 (activeFrom)	400
边界条件	当前时间晚于优惠券的过期时间 (expiresAt)	400

这一步骤的核心价值在于，它将"随便写几个测试"转变为"围绕核心业务规则构建一套结构化的测试清单"，从而系统性地覆盖潜在问题。

三、利用 AI 生成可人工审查的 Jest 测试草稿

当测试点已明确后，再让 AI 生成具体的测试代码会更加稳定和可靠。这里我们使用 Jest 和 Supertest 组合。

提示词示例：生成测试代码

请基于上面列出的测试点，生成 Jest + Supertest 的集成测试代码。
具体要求如下：
1.  测试文件应命名为 `voucher.apply.test.js`。
2.  测试应覆盖以下核心场景：成功领取、请求参数异常、老用户无法领取特定券、重复领取、库存不足。
3.  每个测试用例的名称必须清晰、准确地描述其测试意图。
4.  测试不应依赖于真实的数据库或外部存储，所有状态应在内存中模拟。
5.  如果原始代码存在不易重置内存状态的问题，请在生成代码后，明确指出需要对原始代码进行哪些改造以提高可测试性。
6.  在输出代码后，请列出需要人工重点审查的关键点。

AI 可能会生成如下的测试代码草稿：

const request = require("supertest");
const app = require("../app"); // 假设 app.js 导出了 Express 实例

describe("POST /api/v1/voucher/apply", () => {
  test("新用户首次领取新人券应成功", async () => {
    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_a001", registrationDays: 5, orderCount: 0 },
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(200);
    expect(response.body).toEqual({ success: true, message: "优惠券领取成功" });
  });

  test("缺少用户参数时应返回 400", async () => {
    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(400);
    expect(response.body.message).toBe("无效的请求参数或优惠券ID");
  });

  test("请求不存在的优惠券ID时应返回 400", async () => {
    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_a002", registrationDays: 1, orderCount: 0 },
        voucherId: "NON_EXISTENT_VOUCHER"
      });

    expect(response.status).toBe(400);
    expect(response.body.message).toBe("无效的请求参数或优惠券ID");
  });

  test("老用户领取新人专享券时应返回 403", async () => {
    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_a003", registrationDays: 300, orderCount: 10 }, // 老用户
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(403);
    expect(response.body.message).toBe("无权限领取此优惠券");
  });

  test("用户重复领取同一优惠券时应返回 409", async () => {
    const payload = {
      user: { id: "user_a004", registrationDays: 2, orderCount: 0 },
      voucherId: "WELCOME_DISCOUNT"
    };

    const firstClaimResponse = await request(app)
      .post("/api/v1/voucher/apply")
      .send(payload);

    const secondClaimResponse = await request(app)
      .post("/api/v1/voucher/apply")
      .send(payload);

    expect(firstClaimResponse.status).toBe(200);
    expect(secondClaimResponse.status).toBe(409);
    expect(secondClaimResponse.body.message).toBe("您已领取过此优惠券");
  });
});

这段代码可以作为测试的良好起点，但我们不能直接将其视为"测试已完成"。原因在于：原始代码中的 voucherCatalog 和 userVoucherClaims 都是模块级别的内存变量，不同测试用例之间可能会相互影响，导致测试结果不稳定或不可复现。

四、根据 AI 提示，重构代码以提升可测试性

如果 AI 在输出中能够识别并指出"不方便重置内存状态"的问题，这说明它已经发现了测试隔离的核心挑战。为了解决这个问题，我们可以将状态管理和业务逻辑进行分离，通过依赖注入的方式使其更易于在测试中进行重置和模拟。

例如，我们可以将 Express 应用改造成一个工厂函数，接受外部依赖作为参数：

const express = require("express");

/**
 * 创建优惠券服务 Express 应用实例
 * @param {object} dependencies - 外部依赖，包括优惠券目录、用户领取记录、当前时间获取函数等
 * @returns {express.Application}
 */
function createVoucherServiceApp(dependencies) {
  const app = express();
  app.use(express.json());

  // 从依赖中解构出所需的状态和函数，或使用默认值
  const voucherCatalog = dependencies.voucherCatalog;
  const userVoucherClaims = dependencies.userVoucherClaims;
  const getCurrentTime = dependencies.getCurrentTime || (() => new Date());

  /**
   * 判断用户是否为新用户 (可保持为内部辅助函数)
   * @param {object} userInfo - 用户信息
   * @returns {boolean}
   */
  function checkIfFirstTimeUser(userInfo) {
    return userInfo.registrationDays <= 7 && userInfo.orderCount === 0;
  }

  app.post("/api/v1/voucher/apply", (req, res) => {
    const { user: requestUser, voucherId: requestedVoucherId } = req.body;
    const currentVoucher = voucherCatalog[requestedVoucherId];

    if (!requestUser || !currentVoucher) {
      return res.status(400).json({ message: "无效的请求参数或优惠券ID" });
    }

    const currentTime = getCurrentTime(); // 使用注入的函数获取时间
    const voucherStartTime = new Date(currentVoucher.activeFrom);
    const voucherExpireTime = new Date(currentVoucher.expiresAt);

    if (currentTime < voucherStartTime || currentTime > voucherExpireTime) {
      return res.status(400).json({ message: "优惠券未生效或已过期" });
    }

    if (currentVoucher.type === "NEW_USER_ONLY" && !checkIfFirstTimeUser(requestUser)) {
      return res.status(403).json({ message: "无权限领取此优惠券" });
    }

    const claimIdentifier = `${requestUser.id}:${requestedVoucherId}`;
    if (userVoucherClaims.has(claimIdentifier)) {
      return res.status(409).json({ message: "您已领取过此优惠券" });
    }

    if (currentVoucher.remainingStock <= 0) {
      return res.status(409).json({ message: "优惠券已发放完毕" });
    }

    // 更新状态
    currentVoucher.remainingStock -= 1;
    userVoucherClaims.add(claimIdentifier);

    return res.json({ success: true, message: "优惠券领取成功" });
  });

  return app;
}

module.exports = { createVoucherServiceApp };

经过这样的改造，我们就可以在每个测试用例中创建独立的依赖集合（dependencies），从而确保测试之间的隔离性：

const request = require("supertest");
const { createVoucherServiceApp } = require("../app"); // 引入工厂函数

/**
 * 设置用于测试的模拟依赖
 * @param {object} overrides - 覆盖默认值的配置
 * @returns {object} 模拟的依赖对象
 */
function setupMockDependencies(overrides = {}) {
  const defaultVoucher = {
    id: "WELCOME_DISCOUNT",
    type: "NEW_USER_ONLY",
    remainingStock: 100,
    activeFrom: "2025-01-01T00:00:00Z",
    expiresAt: "2025-12-31T23:59:59Z",
    ...overrides.voucher
  };

  return {
    voucherCatalog: {
      "WELCOME_DISCOUNT": { ...defaultVoucher }
    },
    userVoucherClaims: new Set(),
    getCurrentTime: () => new Date("2025-06-01T12:00:00Z") // 模拟固定时间
  };
}

describe("优惠券领取服务测试", () => {
  test("成功领取后，优惠券库存应减少", async () => {
    const mockDeps = setupMockDependencies();
    const app = createVoucherServiceApp(mockDeps);

    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_b001", registrationDays: 1, orderCount: 0 },
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(200);
    expect(mockDeps.voucherCatalog.WELCOME_DISCOUNT.remainingStock).toBe(99);
    expect(mockDeps.userVoucherClaims.has("user_b001:WELCOME_DISCOUNT")).toBe(true);
  });

  test("库存为零时，用户尝试领取应返回 409", async () => {
    const mockDeps = setupMockDependencies({
      voucher: { remainingStock: 0 } // 模拟库存为零
    });
    const app = createVoucherServiceApp(mockDeps);

    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_b002", registrationDays: 1, orderCount: 0 },
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(409);
    expect(response.body.message).toBe("优惠券已发放完毕");
  });

  test("优惠券未到生效时间时，用户尝试领取应返回 400", async () => {
    const mockDeps = setupMockDependencies({
      voucher: {
        activeFrom: "2025-07-01T00:00:00Z", // 设置为未来时间
        expiresAt: "2025-12-31T23:59:59Z"
      }
    });
    const app = createVoucherServiceApp(mockDeps);

    const response = await request(app)
      .post("/api/v1/voucher/apply")
      .send({
        user: { id: "user_b003", registrationDays: 1, orderCount: 0 },
        voucherId: "WELCOME_DISCOUNT"
      });

    expect(response.status).toBe(400);
    expect(response.body.message).toBe("优惠券未生效或已过期");
  });
});

此项代码改造并非为了"迎合 AI"，而是为了提升业务代码本身的可测试性。良好的可测试性是代码质量的重要组成部分，它使得维护和迭代变得更加容易。

五、大语言模型在测试辅助中的适用性分析

在本次实践中，Grok 4.3 在以下三类任务中表现出了较高的适应性：

1. **理解代码逻辑**：能够将接口的复杂流程转化为一系列清晰的测试点。
2. **补充边界条件**：有效提醒时间、库存状态、重复操作等易被忽视的边界情况。
3. **生成测试草稿**：快速产出基于 Jest + Supertest 的基础测试用例示例。

然而，它并不适合直接做出最终的工程判断。例如：

• 业务规则的合理性，仍需与产品经理或业务负责人确认。
• HTTP 状态码是否符合团队的 API 规范，需要参考现有接口设计文档。
• 测试数据能否覆盖真实的线上场景，需结合线上日志、历史缺陷记录进行分析。
• 并发领取、库存扣减一致性等高并发问题，仅靠单元测试是无法充分验证的。

换言之，大语言模型能显著提高测试设计的效率，但无法替代人类工程师的专业判断和经验。

六、多模型协同策略探讨

不同的模型可以在研发流程的不同环节发挥各自优势，而非简单地相互替代。以下是一些多模型交叉验证的建议：

模型	更适合的任务	在本案例中的具体用法
Grok 4.3	测试点拆解、代码草稿生成、边界场景补充	生成接口测试清单和 Jest 集成测试示例
ChatGPT	通用问题拆解、代码重构建议、设计模式探讨	讨论如何优化代码结构以提高可测试性
Claude	长篇文档理解、需求一致性检查、细致的逻辑比对	对照产品需求文档（PRD）检查测试点是否遗漏或误解
Gemini	表格化整理、多源信息对比分析、数据结构建议	汇总不同模型生成的测试点、接口规则及异常码，进行交叉验证
DeepSeek	中文技术解释、逻辑推理、代码意图分析	解释特定边界条件的业务含义及代码实现细节

多模型交叉验证的意义在于，它们从不同的角度提供了互补的视角，有助于发现单一模型可能存在的盲区。例如，一个模型可能更侧重于代码的功能性，另一个可能更关注需求规范性，还有的模型则可能更擅长识别潜在的异常分支。

七、如何验证 AI 生成测试用例的可靠性？

1. 首先确保测试可运行

最基本的验证步骤是执行测试命令：

npm test

如果 AI 生成了不存在的导入路径、错误的函数名或项目未安装的依赖，都必须优先修正。

2. 检查是否覆盖了"表面成功"以外的逻辑

仅仅测试 HTTP 状态码为 200 的成功路径是远远不够的。对于优惠券领取接口，至少应覆盖以下场景：

• 成功领取（包括库存减少和领取记录）
• 请求参数错误
• 业务规则不满足（如老用户领新人券）
• 重复领取
• 库存不足
• 优惠券未到生效时间
• 优惠券已过期
• 成功领取后，系统内部状态的正确变化。

3. 对照真实缺陷记录进行回归测试

如果项目历史上曾出现过"老用户领到新人券"、"库存扣减为负数"、"重复领取成功"等实际缺陷，应优先将这些缺陷转化为回归测试用例，确保不再重现。

4. 进行一次人工代码审查

在审查 AI 生成的测试代码时，重点关注：

• 测试用例的名称是否清晰地表达了业务意图；
• 测试数据是否相互独立，避免测试间的副作用；
• 测试是否依赖于特定的执行顺序（通常应避免）；
• 是否存在因随机时间或其他非确定性因素导致的不稳定测试（flaky tests）；
• 断言是否足够强大，不仅验证响应，还验证了系统状态的正确变化。

5. 必要时补充集成测试或端到端测试

如果实际项目中优惠券库存、用户记录等数据存储在数据库或 Redis 中，那么仅靠单元测试或控制器层集成测试可能不足。此时，还需要补充更高级别的集成测试，以验证事务处理、并发控制、数据一致性等复杂问题。AI 生成的单元测试只能覆盖一部分风险。

八、多模型工具的评估标准

开发团队在考虑引入多模型辅助工具时，应从实际工作流的角度出发进行评估，而非仅仅关注模型的数量：

1. 是否方便对同一段代码进行多模型的输出对比；
2. 是否支持较长的上下文，能够容纳完整的代码、需求描述和测试说明；
3. 是否能稳定地输出 Markdown 格式、表格和代码块；
4. 是否便于将生成内容复制到 Issue、PR 描述或测试文档中；
5. 是否支持常用提示词的沉淀和管理；
6. 是否方便团队成员统一使用规范；
7. 能否有效减少重复沟通，而非增加新的协作成本。

对于研发团队而言，工具仅仅是辅助手段，真正重要的是建立一套"输入 -> 生成 -> 审查 -> 验证 -> 沉淀"的标准化流程。

九、风险边界：哪些内容不宜直接交给 AI 处理？

在使用 AI 辅助代码和测试工作时，务必警惕并明确安全边界：

• 切勿直接粘贴生产环境的密钥、API Token 或数据库连接字符串等敏感凭证。
• 避免上传包含用户手机号、身份证号、邮箱等个人身份信息的日志或数据。
• 不要暴露公司内部接口域名、内网 IP 或尚未公开的业务规则。
• 不要让 AI 直接对支付、权限管理、风控决策、核心库存扣减等关键业务逻辑做出最终判断。
• AI 生成的代码在未经人工审查前，绝不允许直接合并到主干分支。
• 不能将"AI 生成的测试通过"等同于"业务逻辑完全正确"。

最稳妥的做法是：对输入内容进行脱敏处理，提供最小化且必要的上下文，始终保留人工审查和判断的环节，并将重要的结论和验证结果落实到自动化测试和文档中。

十、常见误区与澄清

1. AI 生成的测试用例可以直接提交吗？

不建议。AI 生成的测试代码更适合作为高质量的草稿。开发者或测试人员仍需仔细检查其依赖关系、数据隔离性、断言强度以及对业务规则的理解是否准确无误。

2. 只使用单一模型就足够了吗？

对于代码解释和简单测试用例生成，单一模型通常可以满足需求。但当面对复杂业务逻辑、关键系统或上线前的严格检查时，多模型交叉验证能够有效帮助发现遗漏点，提供更全面的视角。

3. 如何编写更稳定的提示词 (Prompt)？

编写提示词时，应尽量明确角色设定、提供详细的上下文信息、清晰地列出任务步骤、规定输出格式并设置必要的限制条件。例如，可以先要求模型"列出测试点"，再要求"生成代码"，避免一开始就让 AI 完成所有任务。

4. 如何避免 AI 编造不存在的 API 或功能？

明确要求模型仅使用项目中已有的依赖和功能，并让它在生成代码后列出所有假设条件。在实际应用中，必须通过本地运行、依赖检查和人工代码审查来验证 AI 生成代码的正确性。

5. 技术文档能完全交给 AI 撰写吗？

不建议完全依赖 AI。它可以辅助生成接口说明、测试清单或变更摘要等内容，但最终仍需由熟悉业务的团队成员进行审核和确认，特别是关于状态码定义、边界条件说明和兼容性考量等关键信息。