集成测试写了三百家门店数据才发现 - 我让AI直接生成用例，全错了

一个典型的失败开场

去年我接手一个连锁门店管理系统的小项目。订单模块改完，我想着用AI补一套集成测试。于是打开对话框，敲下了一段当时觉得很自然的话：

> “帮我给订单模块写一套集成测试用例，用 Python + pytest。”

AI很配合，几秒钟就吐出了二十多个用例：创建订单、取消订单、修改收货地址、查询订单列表……格式工整，断言齐全。我复制进项目，跑了三天，覆盖率报告确实好看了。

然后上线，当天就炸了。

问题出在“库存锁定”这个环节：下单时要先锁库存，锁失败要回滚，回滚过程中如果用户并发重复提交，会产生脏数据。这件事在需求文档里写了，在我的脑子里也存在，但AI不知道——因为我从来没告诉过它。它生成的用例全是“理想路径 + 单独的异常分支”，没有一条覆盖真实业务里那些环环相扣的状态流转。

这次翻车让我明白一件事：AI不是用例生成器，它是上下文的搬运工。你喂给它什么业务现实，它就能设计出什么质量的场景；你只喂给它一个模块名，它就只能给你教科书式的空壳。

常见的三种错误用法，你可能正在犯

在重新梳理方法论的过程中，我复盘了自己和身边几个独立开发者朋友的用法，失败模式高度集中：

错误一：把AI当测试用例生成按钮。 输入“给XX功能写测试”，得到的是通用模板。这类用例的典型特征是：单接口测试多、跨模块链路少，happy path 多、业务异常少。跑起来全绿，绿得毫无信息量。

错误二：不给AI任何系统上下文。 集成测试的本质是验证模块之间的协作，但很多人只贴一段接口定义。AI不知道订单和库存之间有锁定关系，不知道支付回调是异步的，它当然设计不出“支付回调晚到时订单已被取消”这种场景。

错误三：AI生成什么就收什么，不做评审。 AI给出的用例看似专业，但可能包含业务上根本不存在的分支（比如它给门店系统设计了“游客下单”用例，而系统根本要求登录）。直接采纳的结果是维护一堆永远不会发生的测试。

正确路径：把AI从“写用例的”升级为“陪你设计场景的”

转变做法后，我把流程改成四步，AI的角色彻底变了：

第一步：先喂上下文，不提“写测试”。 我把需求文档关键段落、核心表结构、模块间调用关系（哪怕是几行文字描述）全部贴给AI，先让它复述一遍系统行为，确认它理解无误。

第二步：让AI提问，而不是直接输出。 这是最关键的一步。我要求AI扮演测试设计师，针对业务流程提出它认为有风险的疑点。这次它问出了：“库存锁定和订单创建是否在一个事务里？”“支付回调超时后订单状态如何流转？”“门店库存不足时是否允许跨门店调货？”——这些问题逼着我把脑子里隐含的业务规则全部写了下来。

第三步：基于确认后的规则，设计场景矩阵。 让AI按“正常链路 / 异常分支 / 并发与时序 / 边界数据”四个维度输出场景，每个场景标注覆盖的业务规则编号。这样生成的用例是有据可查的，不是凭空想象的。

第四步：人工评审，砍掉不存在的分支，补充AI想不到的坑。 AI不了解线上真实环境，比如我知道某个第三方物流接口偶尔超时，这类“本地知识”要由人补进去。

可复制的提示词模板

以下是我迭代了多个版本后沉淀下来的场景设计提示词，直接替换方括号内容即可使用：

你是一位资深测试架构师，帮我设计集成测试场景。请严格按以下流程执行，不要跳步：

【系统背景】
- 系统简介：[一段话描述系统是做什么的]
- 技术栈：[语言/框架/数据库/消息队列等]

【业务规则】
- 规则1：[例：下单时先锁库存，锁失败则订单创建失败]
- 规则2：[例：支付回调为异步消息，可能晚于用户取消操作到达]
- 规则3：[补充你所有的隐含业务规则，越多越好]

【模块与依赖关系】
- [例：订单模块 → 依赖库存模块（锁定/释放）、支付模块（回调）、通知模块（发短信）]

【你的任务】
第一步：用你自己的话复述上述业务规则和模块关系，
如果发现模糊、矛盾或缺失之处，先向我提问，等我回答后再继续。
第二步：等我确认后，输出集成测试场景矩阵，按四个维度组织：
1. 正常链路（跨模块完整流程）
2. 异常分支（每个依赖点失败时的行为）
3. 并发与时序（竞态、乱序、重复请求、超时）
4. 边界数据（数量、金额、状态枚举的临界值）
每个场景需包含：场景编号、前置条件、触发操作、
跨模块交互点、预期结果、对应的业务规则编号。
第三步：标注你认为风险最高、必须优先覆盖的5个场景，并说明理由。

这个模板的精髓在于“先提问再设计”和“场景关联业务规则编号”——这两点直接决定了输出是教科书还是你的系统。

用AI前后对比：一次真实的体感差异

时间上也有变化：之前“生成用例”只花5分钟，但返工修Bug花了两天；现在前期准备上下文和来回问答要花40分钟，但后续几乎是直通的。总账算下来，省下的不是写代码的时间，而是排查线上事故的时间。

写在最后

AI辅助写集成测试，价值的分水岭不在模型能力，而在你给它的输入质量。它读不到你脑子里的业务规则，也看不见线上环境的坑——但它极其擅长在你给出完整上下文后，穷举组合、发现遗漏、质疑模糊之处。把AI当质疑者而非生成器，是用好它的第一步。

如果你还没有稳定的AI接口可用，推荐试试 ThisToken（https://api.thistoken.ai/register），一个聚合多种主流模型的API平台，注册即用，按量计费（以官网价格页为准），适合独立开发者和小团队把这条“场景共创”流水线跑起来。

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。