用 AI 做测试设计 ·（四）· 本篇是一次真实的「复盘」
前三篇把方法拆完了：脑暴铺点、等价类 + 边界值、场景法 + 判定表。但有读者问我："真到一个需求砸过来，这些到底怎么配合？是一次问完，还是分几轮？AI 给的东西我信哪句？"
这篇我把上周做的一个真实需求——外卖下单——从头到尾复盘一遍：我是怎么把它拆给 AI 的、AI 在哪些地方翻车、我又是怎么把它拉回来的。你会看到的不是"标准答案"，而是一次有返工、有判断的真实协作。
开头：先说需求和我手里有什么
需求（简化但真实）： 用户在外卖 App 选门店 → 加商品到购物车 → 下单（系统按满减、红包、配送费算价）→ 支付 → 商家接单 → 骑手配送；支持超时取消、申请退款。
我手里的资料：
- 一份产品 PRD（规则写得不全）；
- 接口文档（能看到部分字段长度和类型）；
- 一张手绘的下单流程图（拍照，比较草）；
- 线上一个真实订单的截图（含费用明细）。
- 以及一个老测试的直觉：算价、库存、退款状态这三块最容易出事。
我没有一上来就把全部资料丢给 AI 说"帮我设计用例"。原因后面你会看到——那是最容易得到一份"看起来很全、其实没压到点"的清单的做法。 我把它拆成了四轮。
第一轮：先让 AI 脑暴"测什么"，但我先把背景喂足
我做了什么： 我没有让它凭空脑暴，而是先把 PRD 里的业务目标、主流程、以及我能确认的字段类型整理成一段背景，再让它铺测试点。
你是资深测试工程师。先不要写详细用例，只帮我"脑暴测试点"，越全越好。
【业务】用户外卖下单：选门店 → 加购 → 算价(满减/红包/配送费) → 支付 →
商家接单 → 骑手配送；支持超时取消、退款。
【我已知的字段】手机号11位、收货地址必填、商品数量为正整数、订单金额单位分。
请按模块分组输出测试点，并把你"不确定、需要我确认"的点单独列出来。
AI 给的东西： 购物车、算价、支付、履约、售后几大块，铺了七八十个点，确实比我一个人想得快。
但我立刻发现两个问题（这是复盘的重点）：
- 它把"功能存在"当成了"测试点"。 比如"购物车能打开""能点结算"——这不是测试点，这是废话。我让它只保留"可能出错的点"。
- 它"不确定"那一栏，几乎是空的。 一个没见过我系统的 AI，表现得什么都懂——这反而是危险信号。我追问了一句，它才补出真问题：满减和红包能不能叠加？起送价是按商品原价还是折后价判？这些 PRD 确实没写，是我要去找产品的，不是 AI 能替我定的。
📌 复盘结论 1： 第一轮只要"广度"和"疑点清单"，别要成品。AI 铺得快，但会把功能点冒充测试点、用自信掩盖未知。逼它单列"待确认"，比让它多列 20 个点更值钱。
为了防止"只盯着功能"，我还做了两件小事： 一是让它切换视角再补——攻击者（改价、越权看别人订单、重放支付）和老人误操作（地址错填、误触）这两类最容易出线上事；二是让它按 ISO/IEC 25010 的八大质量特性当"防漏网"过一遍，而不是只在功能里打转。
| 质量特性 | 外卖这个需求，对应测什么 |
|---|---|
| 功能适合性 | 选品、算价、下单、接单正确（前四轮的主体） |
| 性能效率 | 午高峰下单/算价耗时、大购物车、支付回调吞吐 |
| 兼容性 | 机型系统分辨率、微信版本、弱网 |
| 易用性 | 算价明细看不看得懂、地址错填提示、键盘遮挡、误触取消 |
| 可靠性 | 超时重试、回调重复、支付与下单状态一致（幂等） |
| 安全性 | 越权看他人订单/改价、支付参数篡改与重放、手机号等隐私 |
| 可维护性 | 满减活动能否配置、新增活动是否伤主干——偏白盒，确认研发负责 |
| 可移植性 | 是否规划 H5/小程序多端——本阶段多为不适用，确认归属即可 |
读表要点：功能适合性是主战场；性能、兼容、安全、可靠靠专项 + 异常流覆盖；可维护、可移植不写功能用例，但必须确认"有没有人负责"，不能让它成为没人管的空白。 八大特性是查漏的维度，不是让你每条都硬凑用例。
我拿着"待确认清单"去找产品，补回三条关键规则：满减和红包可叠加、起送价按折后判、超时 5 分钟商家未接单自动退款。 这三条，后来都成了必测项。
第二轮：对具体字段，让 AI 做等价类 + 边界值，并强制标注边界来源
脑暴是"面"，接下来我挑出输入字段，用第二篇的方法做"点"。这次我特意加了一个要求——每个边界必须写清楚从哪来的。
针对下列字段，用等价类+边界值设计用例。
【字段】手机号、收货地址、商品数量、订单备注、支付金额。
【硬性要求】每个边界值必须标注来源：[需求明示]/[技术推断]/[待确认]，三选一；
凡是"待确认"，不得直接当成真实边界写进用例。
有效类用最少用例覆盖，无效类一条只覆盖一个无效点。
AI 这轮翻了两个很典型的车：
翻车 1：它又给我塞了"高频数字"。 备注长度它写了 100、101、255、256——这是它从训练数据里回忆出来的常见值，不是我系统的真实边界。我去翻接口文档和数据库，真实是 varchar(64)。如果我没核，就会把一堆测假边界的用例当宝贝。
翻车 2：它漏了"隐性边界"。 商品数量它只测了数字大小，没想到：数量是不是有库存上限（点 100 份但店里只有 20 份）？手机号的 Emoji、全角数字；备注里的 Emoji 占的是字符还是字节。这些是我追问"还有没有非数字、非长度类的边界"才逼出来的。
核对完真实定义，以"购买份数"为例，我最终入库的等价类 / 边界用例是这样（一类一代表、无效类一例一点）：
| 用例编号 | 输入：购买份数 | 所属等价类 | 预期 | 边界位置 |
|---|---|---|---|---|
| TC_num_01 | 1 | 有效：1 ≤ n ≤ 库存 | 加入购物车成功 | 合法下边界 |
| TC_num_02 | 10 | 有效 | 加入成功 | 有效类代表（2~19 不逐个展开） |
| TC_num_03 | 20 | 有效（该商家库存/限购 = 20） | 加入成功 | 合法上边界 |
| TC_num_04 | 0 | 无效：n < 1 | 拒绝，提示份数非法 | 越界 |
| TC_num_05 | -1 | 无效：非正整数 | 拒绝（前端拦截或后端报错） | 越界 |
| TC_num_06 | 21 | 无效：超库存/限购 | 拒绝，提示库存不足 | 越界 |
| TC_num_07 | 2.5、abc、空格 | 无效：非整数/非数字 | 拒绝 | 越界 |
这张表对照前面能看出三件事：① 上边界用的是查回来的真实库存 20（[需求明示]），不是它最初张口报的 255；② 有效区间 1~20 只取 1、10、20，不会把 2~19 每个数都列一遍——三点法 + 一类一代表，用例不灌水；③ 0/-1 和"超库存"是两类不同无效（份数非法 vs 库存不足），各给一例、预期分开，因为它们触发的是不同校验。
📌 复盘结论 2： 等价类这一轮，边界来源标签是命门。AI 最大的坏毛病是用"记忆里的常见值"冒充"你的真实边界"，并且默认只看显式的长度/数值，漏库存、字符编码、状态这类隐性边界。真实边界，一定从接口注解、数据库、前端校验里自己核一遍。 落点时长度用三点法、金额用五点法，并记住业务边界 ≠ 系统边界——比如单笔限额 5 万是业务规则，但金额字段本身能存更大，两个边界都要测；另外警惕它把多个有效类两两组合、"笛卡尔积"式刷数量——有效类只要求覆盖到，不要求组合穷尽，看到用例成片增加，先问一句"这是覆盖了新逻辑，还是只换了个排列"。
第三轮：把点串成路，让 AI 用场景法补异常
字段是"点"，生意是"路"。第三轮我让它用场景法，把下单链路串起来，重点补我最不放心的异常。
在让它补异常前，我先把手绘流程图拍照喂进去，让它只复述、确认主流程，对齐后再展开——免得它基于"外卖一般长这样"脑补节点。主路径我又拿那个真实订单核了一遍（用真实单据代替埋点漏斗），保证铺的是用户真在走的路。
用场景法，把外卖下单串成端到端链路，按基本流/备选流/异常流组织。
【已确认规则】满减与红包可叠加；起送价按折后判；商家5分钟未接单自动退款。
【异常要求】对每个环节逐类覆盖：①下游失败 ②超时/延迟 ③重复/并发 ④资源不足。
每个异常必须写清系统怎么处理（订单状态/回滚补偿/幂等），写不出就标【待确认】。
这一轮 AI 的表现最能说明问题——它默认只写"一切顺利"。 我不提要求，它给的就是一条 Happy Path。被我逼着按四类扫，才冒出真正要命的场景：
| 场景 | 为什么必须测 |
|---|---|
| 支付成功、商家超时未接单，自动退款 | 钱退了，但支付手续费谁担、库存要不要回补 |
| 用户连点两次"支付" | 同一订单只能扣一次款（幂等） |
| 支付成功但 push/回调延迟 | App 显示"待支付"，不能让用户重复付 |
| 最后一份商品被两人同时下单 | 不能超卖，失败方要能退款 |
| 退款中又申请退款 | 同一笔不能重复退 |
📌 复盘结论 3： AI 天生不爱写"失败、回滚、补偿"，因为它见过的文本里 Happy Path 最多。"环节 × 四类失败"这个扫法，是把它从"说明书模式"拉回"测试模式"的关键。 而且异常不能只看"提示了报错"，要落到订单状态、金额、库存对不对。
最后用一张场景矩阵收口，防止又漏又爆： 每个异常都在主路径上独立触发一次（保证单故障被压住）；异常两两组合不穷举，只挑"真实可能同时发生"的列入必测——比如"支付回调延迟"撞上"用户重复点击支付"是真场景，而"退款中"撞上"骑手车祸"基本不会同时发生，标注不必测即可。
第四轮：多条件岔路口，判定表单独上
下单链路走到"算价"这个岔路口，条件一多，顺流程想必漏。我让它单独上判定表。
条件桩：C1 是否会员｜C2 是否达满减门槛｜C3 是否有可用红包｜C4 是否满足起送价
动作桩：A1 能否下单｜A2 成交计算方式
AI 给了一张 11 列的表。我做了两件事：
- 先剔一票否决。 C4 不满足起送价，直接不可下单，跟会员/满减无关——把这一类单独拎走，表立刻小一半。
- 抓它偷偷加的条件。 表里冒出一列"新用户立减"，可我的需求里根本没有这个活动。这是 AI 凭"外卖一般都有新人优惠"自己加的。 我把它打回，并逐条核对剩余规则的成交方式对不对得上已确认的计价规则。
处理完，最终是下面这 9 条（AI 初稿 11 列里，把"未达起送价"与会员/满减/红包组合的冗余列合并成了 R1、删掉了私加的新人立减）：
| 规则 | C1 会员 | C2 满减 | C3 红包 | C4 起送价 | A1 能否下单 | A2 成交方式 |
|---|---|---|---|---|---|---|
| R1 | — | — | — | N | 否 | 拒绝，提示未达起送价 |
| R2 | N | N | N | Y | 是 | 原价 |
| R3 | N | N | Y | Y | 是 | 红包抵扣 |
| R4 | N | Y | N | Y | 是 | 满减 |
| R5 | N | Y | Y | Y | 是 | 满减 + 红包 |
| R6 | Y | N | N | Y | 是 | 会员价 |
| R7 | Y | N | Y | Y | 是 | 会员价 + 红包 |
| R8 | Y | Y | N | Y | 是 | 会员价 + 满减 |
| R9 | Y | Y | Y | Y | 是 | 会员价 + 满减 + 红包 |
读表要点：R1 是被"一票否决"单独拎到最前的——C4=N 时其他条件全部"不关心（—）"，AI 初稿却把它和会员/满减组合展开成了好几列，这正是要合并掉的冗余。 R5、R9 体现已确认的"满减与红包可叠加"；每一条成交方式都对得上一条真实计价规则，对不上就是它编的。9 条各落成一条算价用例。注意 R8/R9 里"会员价 + 满减"我按"可叠加"示例，但这是个要找产品确认的点——有的平台会员折扣与满减互斥，若互斥，R8/R9 的动作要改成"取优惠力度更大的一个"。表的结构照抄，规则以你自己系统为准。
📌 复盘结论 4： 判定表这一步，"剔一票否决"和"抓私加条件"比"列得全"更重要。 AI 很擅长把表填满，但会用你系统里不存在的规则把它填满。
四轮走完：我实际怎么分工的
把整个复盘收成一张"人机分工"表，这是比任何单句提示词都重要的东西：
| 环节 | AI 负责 | 我负责（绝不外包） |
|---|---|---|
| 脑暴 | 快速铺广度 | 删废话、追出"待确认"、找产品定规则 |
| 等价类 | 列表、给思路 | 核真实边界、补隐性边界 |
| 场景 | 补异常分支 | 判断异常是否真会发生、核对状态/金额/库存 |
| 判定表 | 列规则、合并 | 剔一票否决、抓私加条件 |
| 收口 | 整理成表 | 定优先级、对真实系统逐条验收 |
一句话：AI 出广度，我出裁决。 这四轮里真正防住事故的，没有一个是"因为我提示词写得华丽"，全是"我没盲信它、拿着真实资料核了一遍"。
一个能直接复用的整合提示词
如果你也想这么走，可以用这版把四轮串起来（建议仍然分批对话，别一次要求全部产出）：
你是资深测试工程师，分阶段陪我做测试设计，每阶段等我确认再进入下一步。
【需求】____
【已确认规则】____（没有就写空，不要替我编）
【已有资料】流程图/接口文档/真实订单：____（为空就明确说需要我补；
若给了流程图，先只复述确认主流程，对齐后再展开）
阶段1：只脑暴测试点，按模块分组，并单列【待确认】清单；
再分别从攻击者、老人误操作视角补点；并按 ISO/IEC 25010 八大质量特性
过一遍查漏，标注每条对应哪个特性（功能/性能/兼容/易用/可靠/安全/
可维护/可移植），可维护、可移植只需确认归属，不硬凑用例；
阶段2：对字段做等价类+边界值，每个边界标[需求明示/技术推断/待确认]，
有效类最少覆盖、无效类一例一点，补隐性边界；
阶段3：用场景法串基本流/备选流/异常流，每个环节逐类过
下游失败/超时延迟/重复并发/资源不足，写清状态与回滚补偿幂等；
输出场景矩阵：每个异常在主路径独立触发一次，异常两两组合
只保留真实可能同时发生的，其余标注不必穷举；
阶段4：对多条件岔路口给判定表，先剔一票否决、列规则、再合并，
不得新增需求外条件；
最后：输出可入库用例（编号|前置条件及数据构造方式|步骤|测试数据|
可判定的预期|后置状态|优先级|来源）。
输出前，请先自查并在文末给出自查结果（任一条不满足要明确指出）：
【约定】金额单位、时区、数据隔离方式、删除方式，以及是否存在灰度双写/
存量旧链路——未确认的列入【待确认】，不要默认；
【自洽】前置/步骤/预期互不矛盾；判定表条件桩里没有混进结果；
每条预期都能判"过/不过"，不写"显示正常"；金额各分项之和=总价；
【覆盖】四大方法 + 八大特性逐格落到，异常含并发/时序，并补关键操作的
可观测性（有无日志、监控、告警）；
【风险】优先级按"真实发生概率 × 损失"排；有效类只覆盖、不做笛卡尔积，
处理相同的不拆成两类；
【可执行】每条前置数据写清如何构造、用例之间独立不互相污染、
错误码对齐真实接口；若你在长对话中遗忘了早期约束，先复述再继续。
凡是对不上真实系统处理的，一律标【疑似脑补】，不得当成结论。
每条用例注明来源：[需求明示]/[技术推断]/[待确认]。
注意：以上自查只能提高初稿质量，不能替代你拿到真实环境逐条验收。
AI 做测试设计的坑：四类病根，和我的六步验收法
坑的表象有几十种，但病根只有四类。看懂病根，你能自己识别它下一个新坑；只背清单，遇到没见过的还是会中招。
病根一：它不懂"你系统里那些没写出来的东西"
它所有知识来自语料，而你系统里最关键的规则恰恰没写进任何文档、也不在网上。
-
拿"业界常见值"冒充你的真实约束：张口就是
255/256（第二轮）、"新用户立减"（第四轮），我都被它这么坑过。 - 对历史包袱和灰度中的链路毫无感知：你们正在新旧接口双写、某个老逻辑只对三年前的存量订单生效——它会把"正在废弃的旧路径"当成主流程来测，真正在跑的新链路反而漏了。
- 默认"不隔离"：多租户、多门店的数据权限是配置出来的，需求往往一句"按门店隔离"带过，它不会主动去测"A 门店能不能看到 B 门店的订单"。
- 把业务约定当技术必然：金额单位是"分"还是"元"、时间存 UTC 还是本地、删除是物理删还是软删——它全靠猜，猜错了整条用例的预期都是错的。
病根二：它在"生成像用例的文本"，不是在做严密推理，会逻辑自洽地错
它能让一段话读起来非常顺，但"顺"不等于"对"。
- 自相矛盾而不自知：前置条件写"用户未登录"，操作步骤却让你进"我的订单"；判定表里两列条件完全相同、动作却相反。
- 把结果当成条件：判定表的条件桩里混进"下单成功"这种本应是动作结果的项，整张表的逻辑就塌了。
- 预期不可判定：给你写"系统显示正常""功能符合预期"——这种预期没法判过还是不过，等于没写。
- 数字自己加不平：满减、红包、配送费一叠加，它给的最终金额常常和各分项对不上；临界满减（刚好差一分）最容易错。
病根三：它天然乐观，且没有"风险和取舍"的概念
它倾向于生成一个"一切顺利、样样都测"的理想世界，但测试的本质是取舍。
- 默认只有 Happy Path：失败、回滚、补偿、幂等，你不逼它就不写。
- 不主动碰时序和状态翻转：并发抢库存、支付回调晚到、订单在两状态间反复跳，这些真实事故高发区，除非你点名，否则缺席。
- 没有优先级、不区分"会不会真发生"：它会把"用户在手机号里塞 null 字节"和"主流程正常支付"排得一样重，看着很全，执行时根本跑不完。
- 不测"可观测性"：它只关心功能结果对不对，不管出了事有没有日志、监控、告警——而线上排查靠的恰恰是这些。
病根四：它没有"环境"概念，产出无法自证
它给的是纸面用例，但用例最终要在一个具体环境里、由具体的人或脚本跑起来。
- 前置状态不可造：写"准备一个已退款、且发券失败的订单"——这个数据怎么构造、能不能构造，它不管，用例拿到手根本没法执行。
- 用例不独立、不可重复：几条用例共享同一份数据、跑完互相污染，第二次跑结果就不一样。
- 对真实接口字段、错误码、第三方依赖一无所知：所以"看着对、一跑就崩"——预期的错误码真实系统里根本不返回。
- 长对话里"遗忘"：聊到后面它会丢掉你最早给的约束，前后口径漂移，需要你反复让它复述。
对应的六步验收法
这六步每步堵住一类病根，合起来把四类病根全覆盖。AI 给的永远只是"待验证草稿"：
- 查来源（堵病根一）：每条用例对得上一条真实规则/校验吗？金额单位、隔离方式、删除方式这些约定确认过吗？说不清的进核实清单，不入库。
- 反推边界（堵病根一）：数字别信，回到接口注解、数据库字段、前端 maxlength 自己核；存量/灰度链路要找研发确认哪条才是真在跑的。
- 查一致性与可判定（堵病根二）：前置、步骤、预期是否自洽？条件桩里有没有混进结果？预期能不能判过/不过？涉及金额把分项重新加一遍。
- 查覆盖（堵病根三）：用「四大方法 + 八大质量特性」两张网逐格打钩；异常、并发/时序、可观测性（日志监控告警）有没有人覆盖。
- 查风险与冗余（堵病根三）：优先级是否按"真实发生概率 × 损失"排？有没有笛卡尔积式刷量、处理相同却拆两类？问一句"这条覆盖了新逻辑，还是只换了排列"。
- 查可执行（堵病根四）：前置数据能不能造、用例是否独立可重复？高风险（钱、库存、权限）抽样真跑，核对订单状态、金额、库存、数据一致；复杂需求换一个模型各问一遍对比差异。
一句话标准：每条用例都要答得出"它为什么存在、验证的是哪条真实规则、预期落到哪个可核对的状态、在我的环境里怎么跑起来"。答不出，就不是可交付的用例。
写在最后
这次复盘我最深的感受是：用 AI 做测试设计，省的是"体力"，不是"判断"。 它能把我要花大半天铺的点、列的表几分钟给我，但"哪些是真边界、异常会不会发生、规则是不是被它编出来的"——这些只能我自己扛。
而这恰恰是测试工程师的价值没被替代、反而被放大的地方：工具越强，越需要一个能对结果负责的人。 🌊
这是「AI for Testing 提效实战 · 测试设计（四）」。到这一篇，测试设计的方法和一次完整实战就走完了——从脑暴、等价类边界、场景判定表，到四轮配合、人机分工。
下一部分我们进入「执行自动化」：怎么让 AI 帮你把这些设计出来的用例，真正变成能跑、能回归的自动化脚本。
如果这篇对你有用，欢迎转给那个"用了 AI 却总不放心它产出"的同事。