案例背景
某团队上线新功能前需要测试用例。传统流程：
- 测试工程师 1 人，写 200 条用例
- 单条用例平均 6 分钟（读需求 + 想场景 + 写步骤 + 预期）
- 200 条 × 6 分钟 = 20 小时 = 约 3 天
- 而且手写容易遗漏边界场景
目标：用 AI 把 200 条用例的初稿压到 30 分钟，让人只做复核和补充。
工具链
- Claude：批量生成用例
- Notion MCP：读取需求文档、回写用例
- Cursor：脚本编写与执行
工作流程
Phase 1：需求文档读取（2 分钟）
Prompt：
用 Notion MCP 读取"需求-订单退款"页面的完整内容
拆解出：功能模块、功能点、输入字段、业务规则
AI 自动：
- 调 Notion MCP 搜索需求文档
- 读取页面内容
- 结构化拆解：
模块：订单退款
功能点：
1. 申请退款（用户发起）
2. 审核退款（管理员处理）
3. 执行退款（财务打款）
输入字段：
- 订单号、退款金额、退款原因、退款方式
业务规则：
- 金额 ≤ 原订单金额
- 状态为"已支付"才能退
- 7 天内可退，超期需审批
Phase 2：批量生成用例（30 分钟）
这是核心。按测试设计方法批量生成，覆盖全面。
用例生成模板
你是资深测试工程师。请基于以下需求生成测试用例：
## 功能点
{{feature}}
## 输入字段
{{fields}}
## 业务规则
{{rules}}
## 生成方法（每种方法都要覆盖）
1. 等价类划分：有效/无效等价类各取代表
2. 边界值分析：每个数值字段取 min/min+1/正常/max-1/max
3. 场景法：正常流程 + 异常流程 + 中断恢复
4. 错误推测：常见错误（空值/超长/特殊字符/SQL注入）
5. 正交实验：多字段组合
## 输出格式（每条）
| ID | 模块 | 用例标题 | 前置条件 | 步骤 | 输入 | 预期结果 | 优先级 | 方法 |
{{feature}} 和 {{fields}} 参数化，不同功能点复用同一模板——这是 模板复用 的直接应用。
批量执行
import json
from pathlib import Path
# 从需求拆解结果读功能点
features = json.loads(Path("features.json").read_text())
all_cases = []
for feature in features:
# 参数化调用用例生成模板
cases = call_llm(
template="test-case-generator-v2",
feature=feature["name"],
fields=feature["fields"],
rules=feature["rules"]
)
all_cases.extend(cases)
# 按优先级排序
all_cases.sort(key=lambda x: {"P0":0, "P1":1, "P2":2}[x["priority"]])
Path("test_cases.json").write_text(json.dumps(all_cases, ensure_ascii=False, indent=2))
3 个功能点 × 约 70 条/点 = 200+ 条，约 30 分钟。
生成结果（部分）
| ID | 模块 | 用例标题 | 方法 | 优先级 |
|---|---|---|---|---|
| TC001 | 申请退款 | 正常申请退款（全额） | 场景法 | P0 |
| TC002 | 申请退款 | 退款金额=订单金额（边界） | 边界值 | P0 |
| TC003 | 申请退款 | 退款金额=订单金额+0.01（越界） | 边界值 | P0 |
| TC004 | 申请退款 | 退款金额=0（无效） | 等价类 | P1 |
| TC005 | 申请退款 | 退款金额为负数（无效） | 等价类 | P1 |
| TC006 | 申请退款 | 订单状态=未支付（前置不符） | 场景法 | P0 |
| TC007 | 申请退款 | 退款原因含 SQL 注入字符 | 错误推测 | P1 |
| TC008 | 申请退款 | 7 天内退款（边界正常） | 边界值 | P0 |
| TC009 | 申请退款 | 第 8 天退款（需审批） | 边界值 | P0 |
| ... | ... | ... | ... | ... |
Phase 3：人工复核（1 小时）
测试工程师只复核 P0/P1 用例。
AI 辅助复核
对每条 P0 用例，AI 不只给步骤，还标注：
TC001：正常申请退款（全额）
前置：订单状态=已支付，金额=¥100
步骤：
1. 进入订单详情
2. 点"申请退款"
3. 选退款方式=原路
4. 输入金额=100
5. 提交
预期：
- 退款单状态=待审核
- 退款金额=¥100
- 订单状态=退款中
方法：场景法（正常流程）
依据：需求规则"已支付订单可申请退款"
工程师：
- 查预期是否与需求一致 → 确认
- 查步骤是否可执行 → 确认
- 补充 AI 漏掉的：多终端兼容、性能场景
- 删除重复：AI 偶尔生成近似用例
复核 60 条 P0/P1，约 1 小时。
Phase 4：回写 Notion（2 分钟）
Prompt：
把 test_cases.json 回写到 Notion 的"测试用例"数据库
按模块分组，P0 置顶
属性：模块/优先级/方法/状态=待执行
AI 调 Notion MCP 批量创建页面，200 条 2 分钟入库。
关键 Prompt 复盘
Prompt 1：五种方法全覆盖
等价类、边界值、场景法、错误推测、正交实验
每种方法都生成，不要只选一种
为什么有效：强制多方法覆盖，避免 AI 只用场景法生成"正常流程"漏掉边界。
Prompt 2：边界值明确取点
每个数值字段：min/min+1/正常/max-1/max
为什么有效：AI 容易只写"正常值"跳过边界。明确取点规则强制覆盖边界。
Prompt 3：每条带方法标注
输出含"方法"列：等价类/边界值/场景法/错误推测/正交
为什么有效：方法标注让覆盖率可统计——"边界值覆盖了 100%，正交实验为 0，需补"。
Prompt 4：优先级量化
P0：核心流程 + 必测边界
P1：异常场景 + 错误推测
P2：兼容/性能/极端
为什么有效：优先级让复核聚焦——人只看 P0/P1，P2 自动通过。
踩过的坑
坑 1：AI 编造业务规则
需求写"7 天内可退"
AI 生成"30 天内可退"的用例 → 编造
解决：每条用例必须标注"依据"列（来自需求哪条规则）。无依据的标记"推测"待确认。
坑 2：重复用例
"退款金额=0"生成 3 条（等价类、错误推测、边界值各 1 条）
→ 重复
解决：生成后去重脚本——按"输入+预期"哈希，重复的合并保留方法标注全的。
坑 3：预期结果模糊
AI 写预期："退款成功" → 太模糊，无法判断通过与否
解决：模板要求预期含具体可观测值——状态码/数据库记录/UI 提示文案。
坑 4：漏跨功能影响
退款功能影响：订单状态、库存回滚、积分扣减
AI 只测退款单功能 → 漏了联动
解决：模板加一步"识别关联功能"，配合 Notion MCP 读其他模块需求，生成联动用例。
坑 5：性能/安全场景缺位
AI 生成的都是功能用例
缺：100 人并发退款、退款金额 SQL 注入
解决：用例模板分功能/性能/安全三类，强制每类都有。
效率对比
| 环节 | 传统 | AI 辅助 | 提速 |
|---|---|---|---|
| 需求拆解 | 1 小时 | 2 分钟 | 30x |
| 用例生成 200 条 | 18 小时 | 30 分钟 | 36x |
| 复核 P0/P1 | - | 1 小时 | - |
| 入库整理 | 1 小时 | 2 分钟 | 30x |
| 合计 | 20 小时 | 1.6 小时 | 12x |
覆盖率对比
| 维度 | 传统（手写） | AI 辅助 |
|---|---|---|
| 等价类覆盖 | 70% | 95% |
| 边界值覆盖 | 55% | 98% |
| 异常场景 | 60% | 90% |
| 错误推测 | 40% | 85% |
| 综合 | 65% | 92% |
AI 在边界值和错误推测上优势明显——人不耐烦枚举边界，AI 不怕繁琐。
哪些环节 AI 真省时间
- ✅ 批量枚举：边界值/等价类的机械枚举，AI 不疲劳
- ✅ 方法覆盖：五种方法强制覆盖，比人想得全
- ✅ 格式统一：每条用例结构一致，便于入库统计
哪些环节还得靠人
- ⚠️ 业务正确性：AI 不懂真实业务规则，需人确认预期
- ⚠️ 跨功能联动：AI 看不到系统全局，联动用例人更准
- ⚠️ 探索性测试：非预期路径的 bug，靠人经验探索
- ⚠️ 性能/兼容：AI 生成的性能场景较粗，需人细化
质量保障
发布前必查：
- P0 用例 100% 人工复核
- 每条用例有"依据"标注（需求规则编号）
- 预期结果含具体可观测值（非"成功"模糊词）
- 边界值用例覆盖所有数值字段
- 抽 10% P2 用例复核，确认无重大遗漏
小结
这个案例最大的启示：测试用例的瓶颈不是"写"，而是"想全"。AI 把"五种方法 × 每个字段枚举"的繁琐工作自动化了，人只做业务正确性确认。
下次写测试用例别从头手写——用 参数化模板 + Notion MCP 读需求，30 分钟出 200 条初稿，你会发现真正需要人细想的可能就 60 条 P0。