用 AI 做测试设计 ·（三）
先说结论：等价类和边界值，测的是一个个"点"；场景法测的是一条条"路"。 点都对，不代表路能走通。而路上总有几个"岔路口"------走哪条分支由好几个条件共同决定（会员？满减？有券？超限购？），条件一多，顺着流程想就漏组合。
这一篇把两件事一次讲清：用场景法把链路串起来，遇到多条件岔路口，用判定表把组合理清。
一、为什么单点全过，链路还是会崩
一个字段的合法/非法、一个按钮的可点/不可点，都是孤立的正确性 。但真实业务是一连串有状态、有时序、有数据依赖的动作：
- 状态依赖：上一步没成功，下一步能不能做？（没支付成功，能发货吗）
- 时序问题：并发、超时、重复点击、消息延迟（支付回调比页面跳转晚到 3 秒）
- 数据流转：前一步写入的数据，后一步读到的是不是同一份、有没有被改写
- 跨系统边界：支付网关、库存服务、券系统各自都"正常"，但协议对不上
这对应工程上的流程图 / 状态机路径覆盖------要保证"从起点到终点的每条有意义路径都走过"，而不是"每个节点都点过"。
链路走到岔路口，又会撞上第二类问题：分支由多条件组合决定 。比如"这笔订单能不能用券、按什么价成交"，取决于：是否会员、是否满减、有没有券、是否超限购。四五个条件，顺着路径脑补，必然出现漏组合、或把互相矛盾的规则当成可并存。这时候要靠判定表（条件桩 + 动作桩 + 规则列）把这个岔路口的组合一次性穷举、再合并去重。
AI 的强项和死穴：
- 强项：见过大量典型业务，能很快铺出主流程；处理规则组合也很擅长列表格。
- 死穴：不知道你系统真实的状态、分支和规则 ，于是①容易写成"第一步点这、第二步点那"的操作说明书；②异常分支靠猜；③默认一切顺利，最不愿写"失败、回滚、补偿"；④判定表里会偷偷加上需求里没有的条件或规则。
下面用对比说话。
二、正 vs 反：同一个"在线购课"需求
需求：用户在 App 内选课程 → 下单（系统按"会员/满减/券/限购"算价）→ 调起支付 → 支付成功 → 开通课程权限 → 发新人券。
❌ 反面：一句"帮我设计测试场景"，得到功能清单
arduino
帮我为"在线购课"这个功能设计测试场景，尽量全面。AI 给的多半长这样（节选）：
| 序号 | 测试场景 |
|---|---|
| 1 | 进入课程详情页，页面正常展示 |
| 2 | 点击"立即购买"，能正常下单 |
| 3 | 调起支付，能正常支付 |
| 4 | 支付成功后，课程能正常开通 |
| 5 | 优惠券能正常发放 |
| ... | （再补一堆"页面能不能打开""按钮能不能点"） |
三个硬伤：
- 是"功能点列表"，不是"场景"------没有"一个用户带着目标从头走到尾"的完整链路；
- 只有 Happy Path，没有分支------支付失败、取消、超时、重复支付、售罄全没有；
- 算价这个多条件岔路口被一句"能正常下单"带过------会员/满减/券/限购的组合一种都没展开。
这种清单十几条，真上线该崩的链路、该错的价格，一条没压住。
✅ 正面：给业务目标和流，让 AI 补分支，复杂岔路口单独上判定表
text
你是资深测试架构师。针对下面业务，用"场景法"设计端到端测试场景，
不要罗列单个功能点，要按"一个用户完成业务目标"的完整链路来组织。
【业务目标】用户购买一门课程、按正确价格成交，并成功获得学习权限、收到新人券
【主流程】选课 → 下单算价 → 支付 → 开通权限 → 发券
【关键规则】
- 算价岔路口条件：是否会员、是否满足满减、是否有可用券、是否超限购
- 限购：同一用户同一课程只能买 1 次；超限购直接不可下单
- 支付超时 30 分钟关单；名额有限
【已有资料】（没有就留空，不要替我编）
- 流程图 / 状态机 / 泳道图：____（若为空，请先只画主流程图给我确认，确认后再展开，不要直接生成全部用例）
- 真实订单 / 工单 / 埋点漏斗：____（用户实际高频路径与流失步骤，优先覆盖）
- 计价 / 校验规则文档：____
请按下面结构输出：
1. 基本流：主路径，每步标注前置条件、输入、预期结果、后置状态
2. 备选流：用户主动选择、系统正常处理的分支（取消后重付、组合支付），不要和异常流混
3. 异常流：对每一个环节，逐类覆盖 ①下游失败 ②超时/延迟 ③重复/并发 ④数据/资源不足，
以及系统处理------报错、订单状态、回滚或补偿、幂等；每个异常在主路径上独立触发
4. 对"下单算价"这个多条件岔路口，单独给一张判定表：
先用一票否决/前置条件剔除无关规则（如"超限购直接拒"），再列剩余组合；
条件桩=会员/满减/有券/超限购，动作桩=能否下单/最终成交方式，
列出全部规则列，再把动作相同、条件可合并的规则合并；
不得新增需求外的条件或动作，存疑标【待确认】
5. 场景矩阵：基本流 + 关键分支/异常；每个异常独立触发一次，
异常两两组合只挑"真实可能同时发生"的列入必测，其余标注不必穷举
6. 需求疑点：规则没写清、要找产品确认的点
7. 最终用例：输出可直接入库的表格，每条含
编号 | 前置条件 | 步骤 | 测试数据 | 预期结果 | 后置状态 | 优先级；
判定表每条规则也要落成一条或合并后的用例
所有异常和规则必须对得上一条真实系统处理，对不上标【疑似脑补】。这一版，AI 会给你完全不同的东西。
基本流（主路径）
| 步骤 | 前置条件 | 动作 | 预期结果 | 后置状态 |
|---|---|---|---|---|
| 选课 | 已登录、课程在售 | 进入详情点购买 | 生成待支付订单 | 订单=待支付、锁定名额 |
| 算价 | 订单待支付 | 系统按判定表算价 | 价格与优惠计算正确 | 订单记录成交价 |
| 支付 | 订单待支付 | 完成微信支付 | 支付成功回调 | 订单=已支付、流水入账 |
| 开通 | 收到支付成功 | 系统开通权限 | 用户可学习 | 订单=已完成 |
| 发券 | 订单已完成 | 发新人券 | 券到账可查 | 券=未使用 |
算价岔路口·判定表（关键武器，只在这一个节点用）
条件：C1 会员｜C2 满减（金额达标 Y / 不达标 N）｜C3 有可用券｜C4 超限购 动作：A1 允许下单？｜A2 成交方式
| 规则 | R1 | R2 | R3 | R4 | R5 | R6 |
|---|---|---|---|---|---|---|
| C1 会员 | Y | Y | N | N | N | --- |
| C2 满减 | Y | N | Y | N | N | --- |
| C3 有券 | N/Y | N | N | Y | N | --- |
| C4 超限购 | N | N | N | N | N | Y |
| A1 允许下单 | Y | Y | Y | Y | Y | N |
| A2 成交方式 | 会员价+满减 | 会员价 | 满减 | 券抵扣 | 原价 | 拒绝并提示 |
读表要点：先把"超限购=Y"单独拎出来------它一票否决，和其他条件无关（R6） ；剩下的才是会员/满减/券的组合。AI 若给你十几列没合并的表，让它把"动作结果相同、条件可合并"的规则合并（如 R1 里有没有券不影响"会员价+满减"成立的情形），避免冗余用例。每个动作都要能对得上一条真实计价规则，对不上就是它编的。
备选流 / 异常流（拉开差距的部分，节选）
| 流 | 触发 | 系统应处理 | 状态/补偿 |
|---|---|---|---|
| 备选 | 下单后取消 | 释放锁定名额 | 订单=已取消 |
| 备选 | 组合支付（余额+微信） | 两笔都成功才算完成 | 任一失败整体不生效 |
| 异常 | 支付失败 | 提示、可重试 | 订单仍待支付 |
| 异常 | 回调超时/延迟 | 主动查支付结果，不重复开通 | 幂等 |
| 异常 | 支付平台重复回调 | 同一流水只处理一次 | 不多发券 |
| 异常 | 支付成功但发券失败 | 主流程成功 + 券异步补发 | 不回滚已购课程 |
| 异常 | 并发抢最后名额 | 仅成功者下单，余提示售罄 | 不超卖 |
| 异常 | 30 分钟未支付 | 自动关单、释放名额 | 订单=已关闭 |
反面那份测的是"按钮好不好用"，正面这份测的是"价格算得对不对、生意能不能做成、出了岔子怎么收场"。
三、把它做到更好（6 个做法）
做法 1：先喂"图"，再让 AI 补路 有流程图/状态机/泳道图直接喂，AI 基于真实流转补分支；没有就先让它画主流程图给你确认，再展开。
做法 2：用真实单据/埋点还原"真实的路" 找一条真实订单 走一遍，或看埋点漏斗用户实际在哪步流失，优先覆盖高频真实路径。
做法 3：异常流按"环节 × 失败类型"扫 每步系统过四类：下游失败、超时/延迟、重复/并发、数据/资源不足，逼出 AI 默认省略的"失败、回滚、补偿、幂等"。
做法 4：多条件岔路口，判定表只在节点用，别全程铺开
- 先用一票否决/前置条件把规则砍一批（如"超限购直接拒"），再列剩余组合，列数立刻减半；
- 分清条件桩 （输入状态）和动作桩（系统结果），别把结果当条件；
- 让 AI 合并"动作相同、条件可合并"的规则，并逐条核对是否对得上真实计价/校验规则，新增需求外条件一律打回。
做法 5：分清备选流和异常流，组合矩阵防漏防爆 备选流=用户主动选、系统正常处理；异常流=非预期、系统兜底。每个异常在主路径独立触发一次；异常两两组合只挑真实可能同时发生的测，避免组合爆炸。
做法 6：交付可执行 最终输出可入库的表，每条带：编号、前置条件、步骤、测试数据、预期结果、后置状态、优先级。判定表的每条规则也要能落成一条或合并后的用例。
四、一张"场景 + 判定表"自检清单
- 有一条从业务起点到成功终点的完整基本流，而不是功能点列表？
- 有没有先喂流程图？没有图时，是否先让 AI 只画主流程图、确认后再展开？
- 主路径是否参考了真实订单/埋点的高频路径与流失步骤，而不是纯想象？
- 每步写清前置条件和后置状态？
- 备选流 / 异常流 都覆盖且没混？每个关键环节是否逐类过了下游失败/超时延迟/重复并发/资源不足？
- 每个异常是否在主路径独立触发一次？异常两两组合是否只保留了真实可能同时发生的？
- 涉及钱和库存，验证了幂等、回滚、补偿、不超卖？
- 多条件岔路口是否用判定表理清：一票否决先剔除？条件桩/动作桩分清？规则做了合并？
- 判定表里有没有被 AI 偷偷加进来的、需求外的条件或规则？
- 最终是否输出了含编号/前置/步骤/数据/预期/后置状态/优先级的可入库用例，判定规则也落成了用例？
- 所有异常和规则是否都对得上真实系统处理，说不上的标了【疑似脑补/待确认】？
五、比 prompt 更重要的（非提示词能力）
- 输入质量决定上限：流程图/状态机、真实订单、埋点、计价规则文档------"真实的路和规则"越具体，AI 补得越准。
- 裁决在你：哪些异常真会发生、补偿对不对、价格规则优先级（券和满减能不能叠加），是业务判断，不能外包。
- 验证要落地 ：异常不只看"提示了报错"，要核对订单状态、价格金额、数据一致性、有没有重复扣款/超卖，必要时查日志和链路追踪。
- 工程化沉淀 ：把稳定核心链路做成端到端自动化回归 ；判定表驱动的算价规则，适合做成参数化的数据驱动测试，AI 给的规则列就是数据源。
总结：我的固定动作
拿到业务 → 先确认目标和主流程，能给流程图/真实单据先喂 → AI 按基本流/备选流/异常流展开，每步带前置后置 → 用"环节×失败类型"补异常，盯幂等/回滚/补偿 → 走到多条件岔路口，用判定表：先剔一票否决、列规则、再合并，逐条对真实规则、抓出脑补条件 → 场景矩阵定必测组合 → 输出可执行用例，核心链路沉淀为自动化回归。
单点保证"零件没坏"，场景保证"机器能转、坏了能收"，判定表保证"每个岔路口没走错"。 别让 AI 给一份好看的功能清单就收工。
这是「AI for Testing 提效实战 · 测试设计（三）」。
如果这篇对你有用，欢迎转给那个"功能都测了、上线链路却挂了"的同事。