用 AI 做测试设计 ·三先说结论等价类和边界值测的是一个个点场景法测的是一条条路。点都对不代表路能走通。而路上总有几个岔路口——走哪条分支由好几个条件共同决定会员满减有券超限购条件一多顺着流程想就漏组合。这一篇把两件事一次讲清用场景法把链路串起来遇到多条件岔路口用判定表把组合理清。一、为什么单点全过链路还是会崩一个字段的合法/非法、一个按钮的可点/不可点都是孤立的正确性。但真实业务是一连串有状态、有时序、有数据依赖的动作状态依赖上一步没成功下一步能不能做没支付成功能发货吗时序问题并发、超时、重复点击、消息延迟支付回调比页面跳转晚到 3 秒数据流转前一步写入的数据后一步读到的是不是同一份、有没有被改写跨系统边界支付网关、库存服务、券系统各自都正常但协议对不上这对应工程上的流程图 / 状态机路径覆盖——要保证从起点到终点的每条有意义路径都走过而不是每个节点都点过。链路走到岔路口又会撞上第二类问题分支由多条件组合决定。比如这笔订单能不能用券、按什么价成交取决于是否会员、是否满减、有没有券、是否超限购。四五个条件顺着路径脑补必然出现漏组合、或把互相矛盾的规则当成可并存。这时候要靠判定表条件桩 动作桩 规则列把这个岔路口的组合一次性穷举、再合并去重。AI 的强项和死穴强项见过大量典型业务能很快铺出主流程处理规则组合也很擅长列表格。死穴不知道你系统真实的状态、分支和规则于是①容易写成第一步点这、第二步点那的操作说明书②异常分支靠猜③默认一切顺利最不愿写失败、回滚、补偿④判定表里会偷偷加上需求里没有的条件或规则。下面用对比说话。二、正 vs 反同一个在线购课需求需求用户在 App 内选课程 → 下单系统按会员/满减/券/限购算价→ 调起支付 → 支付成功 → 开通课程权限 → 发新人券。❌ 反面一句帮我设计测试场景得到功能清单帮我为在线购课这个功能设计测试场景尽量全面。AI 给的多半长这样节选序号测试场景1进入课程详情页页面正常展示2点击立即购买能正常下单3调起支付能正常支付4支付成功后课程能正常开通5优惠券能正常发放…再补一堆页面能不能打开“按钮能不能点”三个硬伤是功能点列表不是场景——没有一个用户带着目标从头走到尾的完整链路只有 Happy Path没有分支——支付失败、取消、超时、重复支付、售罄全没有算价这个多条件岔路口被一句能正常下单带过——会员/满减/券/限购的组合一种都没展开。这种清单十几条真上线该崩的链路、该错的价格一条没压住。✅ 正面给业务目标和流让 AI 补分支复杂岔路口单独上判定表你是资深测试架构师。针对下面业务用场景法设计端到端测试场景 不要罗列单个功能点要按一个用户完成业务目标的完整链路来组织。 【业务目标】用户购买一门课程、按正确价格成交并成功获得学习权限、收到新人券 【主流程】选课 → 下单算价 → 支付 → 开通权限 → 发券 【关键规则】 - 算价岔路口条件是否会员、是否满足满减、是否有可用券、是否超限购 - 限购同一用户同一课程只能买 1 次超限购直接不可下单 - 支付超时 30 分钟关单名额有限 【已有资料】没有就留空不要替我编 - 流程图 / 状态机 / 泳道图____若为空请先只画主流程图给我确认确认后再展开不要直接生成全部用例 - 真实订单 / 工单 / 埋点漏斗____用户实际高频路径与流失步骤优先覆盖 - 计价 / 校验规则文档____ 请按下面结构输出 1. 基本流主路径每步标注前置条件、输入、预期结果、后置状态 2. 备选流用户主动选择、系统正常处理的分支取消后重付、组合支付不要和异常流混 3. 异常流对每一个环节逐类覆盖 ①下游失败 ②超时/延迟 ③重复/并发 ④数据/资源不足 以及系统处理——报错、订单状态、回滚或补偿、幂等每个异常在主路径上独立触发 4. 对下单算价这个多条件岔路口单独给一张判定表 先用一票否决/前置条件剔除无关规则如超限购直接拒再列剩余组合 条件桩会员/满减/有券/超限购动作桩能否下单/最终成交方式 列出全部规则列再把动作相同、条件可合并的规则合并 不得新增需求外的条件或动作存疑标【待确认】 5. 场景矩阵基本流 关键分支/异常每个异常独立触发一次 异常两两组合只挑真实可能同时发生的列入必测其余标注不必穷举 6. 需求疑点规则没写清、要找产品确认的点 7. 最终用例输出可直接入库的表格每条含 编号 | 前置条件 | 步骤 | 测试数据 | 预期结果 | 后置状态 | 优先级 判定表每条规则也要落成一条或合并后的用例 所有异常和规则必须对得上一条真实系统处理对不上标【疑似脑补】。这一版AI 会给你完全不同的东西。基本流主路径步骤前置条件动作预期结果后置状态选课已登录、课程在售进入详情点购买生成待支付订单订单待支付、锁定名额算价订单待支付系统按判定表算价价格与优惠计算正确订单记录成交价支付订单待支付完成微信支付支付成功回调订单已支付、流水入账开通收到支付成功系统开通权限用户可学习订单已完成发券订单已完成发新人券券到账可查券未使用算价岔路口·判定表关键武器只在这一个节点用条件C1 会员C2 满减金额达标 Y / 不达标 NC3 有可用券C4 超限购动作A1 允许下单A2 成交方式规则R1R2R3R4R5R6C1 会员YYNNN—C2 满减YNYNN—C3 有券N/YNNYN—C4 超限购NNNNNYA1 允许下单YYYYYNA2 成交方式会员价满减会员价满减券抵扣原价拒绝并提示读表要点先把超限购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 提效实战 · 测试设计三」。如果这篇对你有用欢迎转给那个功能都测了、上线链路却挂了的同事。