从去年开始我明显感觉到自己带新人写接口用例、业务用例的效率在往下掉不是新人不行是项目复杂度上来了哪怕一个“改密码”功能都能牵扯出账户状态、设备会话、验证策略、风控规则一长串东西。手动去列用例写着写着就变成“按需求条目翻译”漏掉的全是需求文档里没写但系统里真实存在的逻辑。后来我把重心从“写用例”慢慢挪到“教AI怎么思考”上——不是扔给它一个功能名让它自动生成几十条用例而是把我脑子里的业务模型、质量风险点、评审习惯一点点转成它能持续复用的提示词和评估标准。这篇文章就把我这大半年折腾出来的思路、踩过的坑、还有可以直接照抄的模板整理出来给正在做测试设计转型的同学一个参考。1. 为什么说“手动写用例”已经走到瓶颈1.1 用例规模膨胀与维护成本失控很多测试团队都有过这样的经历一个中大型项目跑了一年多用例库里躺着上万条用例真正在回归里跑得动的可能不到一半。我见过最夸张的情况一个订单模块的用例有两千多条其中两百多条标注的是“临时逻辑”对应的临时活动早就下线了用例还挂在那边每次回归消耗十几分钟没人敢删因为“当时评审过的”。这种规模之下手动写用例的成本已经不是写的那一下而是后面无穷无尽的维护。每一轮需求变更影响的用例少则十几条多则上百条。如果是手动维护你只能靠用例标题里的关键词去筛、去猜、去一条条点开看。这个动作非常吃经验新人根本判断不了这个状态的改动会不会影响那条流程的路径。结果就是要么漏改导致回归误报要么过度改导致用例失真。这个问题的根源不在责任心而在用例本身是“被写出来的结果”不是“被推理出来的结论”。1.2 手动写的瓶颈不在手而在脑子说得更直白一点手动写用例真正卡住你的不是打字速度而是你的“思考链路”太短。很多人写用例是这样一个状态拿到需求文档通读一遍按主流程写一条“正常路径”然后顺着每个输入框去写“为空、超长、格式错”再补几条权限、状态字段的用例完事。这条链路里真正发挥测试设计能力的地方非常有限大部分时间在“抄需求”和“模板化”。而一个资深测试做设计的时候脑子里的链路其实是很长的先建立系统模型这个功能依赖什么、它改了会波及谁、再列业务规则哪些规则是显性的、哪些是系统隐含的、再做风险排布哪个规则最容易错、哪个改动面最大、最后才落到用例步骤。问题在于这条长链路你很难每次都完整跑一遍精力不够、时间更不够。AI天然适合干这件事它不会累也不会因为写第二百条用例开始走神。关键是你得把那条“长链路”从你脑子里抽出来喂给AI这比让它直接吐用例重要得多。2. 测试设计的真正变化从“产出用例”到“教会AI思考”2.1 教AI思考的本质把你的质量决策框架显性化我先纠正一个特别流行的误解——很多人以为AI测试设计就是把需求文档拖进对话框然后说一句“帮我生成测试用例”。出来的东西乍一看像模像样实际上稍微跑一下就能发现全是在抄需求表面逻辑稍微隐蔽一点的状态流转和异常分支完全没有。原因很简单你只给了AI“原料”没给“加工方法”。你的测试经验体现在哪体现在你看到“改密码成功后要踢掉其他设备会话”这句话时会本能地追问——如果踢会话失败怎么办如果用户当前登录的正好是那个被踢的会话怎么办如果并发两个设备同时改密码怎么办这些追问才是测试设计的价值。所以所谓“教AI思考”核心是把你这套追问逻辑显性化。我实践下来的做法是把测试设计拆成四层信息全部喂给AI一是系统模型它是个什么系统有哪些模块和交互二是业务规则它被要求做到什么三是质量关切你心里在担心什么四是约束条件什么东西不允许AI自己编。AI有了这四层信息之后生成的用例质量会完全不一样。2.2 测试设计者需要补上的四种新能力这个转变对测试人的要求其实变高了不是变低了。原来你只需要对需求负责现在你要对你“喂给AI的那套思维”负责。我会建议想转型的同学刻意练四种能力。第一是“需求建模能力”。你要能把一段业务描述压缩成“角色-动作-状态-规则”的结构化描述这是AI能理解的基本盘。第二是“风险联想能力”你的价值逐渐转移到“你能指出哪些环节容易翻车”上AI负责把这些风险铺成用例。第三是“提示词工程能力”说得接地气一点你要会“问问题”知道怎么引导AI分步骤推理而不是一次给个答案。第四是“评审校准能力”AI给的用例你拿什么标准去评靠的还是你脑子里的测试基本功。别小看这四条任何一个环节缺了AI生成的用例质量就会明显塌方。我自己最深的感受是以前评审别人写的用例是在挑毛病现在评审AI出的用例是在校准一套“思维方式”这个转变很有意思也从根上逼着你把经验往深里挖。3. 手把手怎么“教AI”做一套像样的测试设计3.1 第一步给AI建一个“系统模型”我强烈建议不要一上来就让AI出用例先花时间把“系统模型”喂给它。系统模型就是回答几个问题这是一个什么系统当前要测的这个功能处于系统的哪一层它跟前端、后端、消息中间件、外部依赖怎么交互它涉及哪些核心数据和状态举个例子我之前带的一个模拟项目X里有个“会员积分过期提醒”功能如果我直接让AI测“积分过期提醒”它的输出基本就是“过期后发短信、发推送、文案对不对”这种表象用例。但当我在系统模型里补充“积分账户表按日批次扫描、过期状态由定时任务写入、用户可能在扫描期间兑换积分导致状态竞争、通知服务有独立的重试队列”之后AI生成的用例马上就开始覆盖“定时任务执行中途用户兑换积分的竞争场景”“通知重试导致重复提醒”这类真正有价值的场景。这就是系统模型的威力。它不增加AI的“智商”但大幅增加AI的“上下文”而测试用例的质量恰恰是上下文密度决定的。3.2 第二步给AI一张“质量关切清单”很多提示词的问题在于只有“功能正确性”一个维度。你让AI测一个登录框它给你列的正常用例和格式校验用例能占到八成剩下的全是鸡肋。我后来总结出一个固定动作在提示词里显式声明你需要AI覆盖哪些质量维度。我会给一份默认清单包括功能正确性、接口契约、数据一致性、状态流转、异常恢复、并发冲突、权限边界、性能影响、兼容稳定性、安全防护一共十个维度。别全堆在一条提示词里让AI一次答完那样每条维度都只会得到一两条蜻蜓点水的用例。更好的做法是把维度拆开针对一个高风险维度专门做一次深入的测试设计比如“这次我们只关注状态流转和并发冲突请给我穷尽这两个维度的场景”。这样调整之后AI输出的颗粒度会有质的提升因为它知道你关心什么而不是在猜测你关心什么。3.3 第三步用提示词模板“组装”思考链路下面这套提示词模板是我实际用的改了无数版现在基本稳定。它不算炫酷但非常管用核心逻辑是逼着AI先分析、再列风险、然后才产出用例。你是一名资深测试架构师请基于以下信息完成测试设计。 【系统模型】 - 系统名称会员积分账户系统 - 被测功能积分过期提醒 - 相关模块账户模块、定时任务模块、通知模块、用户触达模块 - 关键交互定时任务每日扫描过期积分更新账户状态产生待办通知通知模块异步推送 【业务规则】 - 积分有效期为12个月逐笔计算过期时间 - 过期前30天提醒一次过期当天提醒一次 - 用户兑换积分后被兑换部分不接受过期处理 【质量关切】 - 本轮重点状态流转的正确性、定时任务与用户操作的并发冲突、通知的幂等性 - 请先梳理出至少5个风险点再针对风险点设计用例 【硬性约束】 - 只能基于上述规则推理禁止自行假设业务规则 - 用例必须包含前置条件、操作步骤、预期结果、优先级 - 前置条件里必须写清楚数据准备状态这套模板的关键不在最后生成用例的那一步而在于中间那句“请先梳理出至少5个风险点”。这一步等于强制AI进入“思考模式”把推理过程显性化。我后面会专门讲一个实际案例展示这样设计的AI输出长什么样。4. 用一个真实业务场景拆解全过程4.1 业务场景优惠券叠加结算为了让你直观看到“教AI思考”前后输出的差异我拿一个很多人都遇过的业务来演示商城下单结算时支持多张优惠券叠加。需求文档里只写了一句“用户可以在结算页选择多张优惠券系统按最优组合自动计算优惠金额”。如果是直接“帮我生成用例”AI大概率会给你选一张券下单成功、选两张券下单成功、不选券下单成功然后没了。这种用例的价值几乎为零因为“最优组合”这四个字背后藏了一堆逻辑冲突。我在系统模型里补充了这些信息优惠券分为商品券和店铺券、两种券可叠加但同类券互斥、券的使用门槛结合商品金额计算、部分券有“不可与其他促销同享”的标签、系统按先店铺后商品的顺序试算优惠、若最优组合计算失败则降级为按用户手动选择顺序执行。这几个信息一补AI的风险识别方向完全变了。4.2 我用到的提示词与AI的输出我的提示词基本就是沿用上面那套模板只是在业务规则里把优惠券的叠加约束写细了一点并在质量关切里特别加了“金额精度”和“降级路径”。AI先输出的风险点是商品券与店铺券叠加顺序是否影响最终金额、单价为小数时精度的舍入规则、同品类券互斥规则在商品退换货后是否重新计算、计算失败后的降级路径是否会重复发放优惠、多张券门槛校验是否使用同一基准金额。看完这五个风险点我就知道这轮设计没有白做因为其中至少有三个是需求文档里写不清楚的是真正需要人工去确认或者用用例去约束的点。后续生成的用例里有一条让我印象很深给两张商品券设置不同门槛其中一张券的门槛刚好等于商品折后价验证边界值下该券是否能参与叠加计算。这种用例放在以前我只能靠自己去翻优惠计算代码才能想起来。4.3 人工评审的价值别让AI的“最优组合”变成黑盒AI给的方案再漂亮我也不会直接采纳。特别是涉及降级策略的地方我会要求AI反推“为什么设计这条用例”然后把它的推理过程和实际的业务规则比对一遍。在那次案例里AI设计了一条“最优组合计算失败后按用户自主选择顺序计算”的用例但它的预期结果是“订单仍可使用用户手动选择的优惠券”。我一看就发现这里有个产品歧义需求文档并没有明确降级后是否仍然允许用户手动选券。如果降级意味着“放弃优惠计算、恢复原价”那这条用例的预期结果就是反的。我最后是拿着这条用例去找产品当面确认的产品也承认这个场景内部讨论过但是没有写进文档。这就是AI辅助人工的一个典型价值它把你没想到或者需求没写清的问题具象成一条可以直接拿去跟人对质的用例而不是让你自己凭感觉去猜。5. AI生成用例的常见翻车现场与排查实录5.1 幻觉式功能设计AI补出了不存在的规则用得多了你会发现AI特别喜欢“补全”。你告诉它超时时间是30秒它给你设计用例的时候可能会在预期结果里写“超过30秒后系统提示等待超时并保留用户已填写的信息”然后限定条件里根本没有“保留已填写信息”这条。这就是幻觉式设计看着合理但实际上系统行为完全不是这样。我的排查办法是提示词里加一条“硬性约束禁止新增任何给定信息之外的系统行为描述”。如果AI仍然在预期结果里加入了你没给过的逻辑那就在评审时直接删掉并标注“信息来源缺失”顺手反馈到提示词里形成负面样例约束。这比跟AI辩论“你怎么能这么设计”管用得多。5.2 边界值只靠猜不靠需求AI在没有得到明确边界定义时会默认挑一些整数当成边界比如金额边界取100、1000数量边界取1、10。这跟系统真实边界经常不符在优惠券、额度、超时时间等场景里尤其致命。我现在的做法是在系统模型里专门加一个“关键边界数据表”把我能明确的边界值提前输入。比如“优惠券门槛临界值为199.99与200.00”“同一个订单号最多支持5张优惠券”“最小支付金额为0.01元”。如果脑子里不确定的边界我会让AI把边界策略标成“待确认”而不是替产品做决定。这条习惯帮我挡掉了不少“看起来很对跑起来必错”的废用例。5.3 冗余用例泛滥一个场景被拆成五个重复步骤AI在你给的质量维度多的时候容易出现一种情况同一个业务场景被拆成五条步骤几乎一样的用例只是换了个前置条件里的数据值。我见过AI为了覆盖“用户未登录”“用户包邮会员”“用户黑名单用户”三种身份把一条完整下单流程复制了三遍每遍两百多字。这种冗余在旧用例评审里看着头大也很难彻底清理。我的办法是在提示词里加一条“用例合并规则”要求AI将仅有数据差异的用例合并为同一条用例下的数据表格用参数化的形式列出来。这样本来要铺五条的用例能压缩成一条用例加载一组数据变体。最近几次跑下来AI对这个指令的遵循度还不错冗余率明显下降。5.4 断言太弱预期结果写成“系统正常处理”还有一个特别普遍的质量问题AI的预期结果写得太泛。比如前置条件是“会员账户已过期”步骤是“提交兑换请求”预期结果就一句话“系统正常处理兑换”。这种断言不给任何可观察的细节跑测试的时候根本不知道应该看什么回读用例的人也不清楚是针对哪个风险的。我要求预期结果必须以“可观察现象数据状态变化”的方式描述。继续用这个例子我会改成“接口返回兑换成功码积分账户余额减少对应数值账户状态从未过期流转为已过期同时积分扣除兑换流水表新增一条记录”。这个改造动作做完之后整套用例的可执行性明显提升了一个档次可以被自动化脚本直接读取校验点执行。6. 落地建议从个人技巧变成团队资产6.1 把“教AI思考”沉淀成提示词库说实话一套好的提示词价值一点都不比一套测试用例低。提示词里封装的是你们的业务规则、质量模型和踩坑历史。以前老测试离职最痛苦的是他脑子里的隐性知识全带走了现在如果他愿意可以把一部分思考逻辑沉淀成团队可复用的提示词模板后面进项目的人直接站在他的推理框架上继续迭代。我建议团队里建一个“测试设计提示词库”按业务线分类存放每套提示词配一份使用说明和典型输出样例。维护提示词库的频率可以和用例评审绑定每次评审如果发现AI漏掉了一类场景先回头改提示词再补用例。这不只是一种工具沉淀其实是在逼着团队把“为什么这么测”这件事变成一个可以积累的资产。6.2 建立“AI初稿人工评审”的协作流程最后讲一下我目前最推荐的落地方案它不是全自动也不是全手动而是分四步走的协作流程。第一步“喂料”把系统模型、业务规则、质量关切、硬性约束整理好给AI。第二步“生成初稿”AI按风险点先行分析再产出用例这个初稿不是直接用而是当成“专家给的参考草案”。第三步“人工评审”测试人员重点审查三条线——AI有没有引入幻觉规则、有没有切中质量关切、预期结果是否可观察。第四步“反馈回流”把评审中发现的漏测和误判转化成提示词的修正指令让这套“思考方式”越来越贴近你们的系统。这套流程跑顺之后最大的变化是测试人员把重复性的“写”都丢给AI了自己专注在“想”上。我个人的体感是工作量并没有暴减但质量上限变得不一样了——以前用例评审能看到的问题、能挖掘的边界受限于当天自己的精力状态现在AI相当于给了我一个永远精力充沛的初稿写手我所有经验都在做更高杠杆的事情。最后分享一个小心得别一上来就追求AI输出满分用例更现实的目标是先让AI帮你把“没想到”的场景补出来再靠你的评审把“不对”的场景砍掉。来回几次之后你喂给它的不是一堆命令而是一套真正属于你们团队的系统认知这才是测试设计未来几年最值得投入的方向。
