有段时间我在帮团队搭建AI辅助测试流程。第一版方案跑通的时候AI每天能生成上百条测试用例格式规整、步骤清晰、断言也齐全看起来非常专业。结果一个迭代之后需求稍微变了两个字段这批用例几乎全废。重跑一遍生成流程出来的又是另一套东西根本没法跟之前的资产沉淀、对比、继承。后来我们复盘才发现问题不是AI生成得不够多、不够快而是生成出来的东西根本没法复用。这个问题比生成效率本身严重得多。标题里说的一个用例多个场景听着像一句口号实际上是测试用例设计里最值钱、也最难做的一件事。下面我花点篇幅把为什么多数AI生成的测试用例活不过一个迭代讲透再把怎么设计才能让同一个用例在不同场景里复用的完整思路和落地方法分享出来。这中间的经验都是我们团队从实际项目里一条一条踩出来的。1. 为什么AI生成的测试用例大多活不过一个迭代1.1 用完即焚的用例到底长什么样先看看最典型的一次性用例长什么样。你把需求描述扔给大模型让它生成功能测试用例它通常会给你这种输出用例编号TC_LOGIN_001 前置条件用户已注册 步骤 1. 打开登录页面 2. 输入用户名 zhangsanexample.com 3. 输入密码 123456 4. 点击登录按钮 预期结果 - 登录成功跳转到首页 - 右上角显示用户头像单看这条用例写得很规范没毛病。但你把它放到真实项目里试一下马上会碰到一连串问题测试环境变了登录入口URL换了用户数据被清掉了跳转到首页这个断言没写清楚到底是验证URL、验证标题还是验证某一个元素AI也没说。更麻烦的是如果这条用例是用体系化的Prompt一次性生成几百条那你面临的是一堆结构相同、细节却各不相同的用例每条都像独立设计出来的连公共的页面元素名都没统一。这种用例本质上就是一次性快照。它描述的是某一个时刻、某一个环境、某一个账号数据下的具体操作而不是一个可推广、可变化的测试意图。生成的时候快作废的时候更快需求一变全部作废。1.2 三个让用例写死的元凶我复盘了大量这类用例发现导致不可复用的根源基本集中在三个点上数据内联。用户名、密码、订单号、金额、商品ID这类数据直接被写死在了步骤里。用例跟测试数据死死地耦合在一起一旦造数环境变了、数据结构变了用例就得跟着改。可复用的第一前提就是数据和方法分离AI默认不会帮你干这件事你不约束它它就往里面塞硬编码。步骤编排太具体。一个登录用例AI经常会把打开浏览器→输入URL→点击登录按钮→输入账号→输入密码→点击确认→等待页面加载→断言跳转一步一步全部写出来。这看起来很完整但仔细想想打开浏览器和输入URL属于环境准备点击登录才是被测动作这两层混在一条用例里等于把用例和实现绑死了。换个环境从Web端换成移动端整条用例都动不了。断言跟场景强绑定。AI生成预期结果时默认只写最顺利路径的断言登录成功、跳转首页、页面显示用户名。但同一个登录动作在不同场景下的预期结果完全不同弱网环境下可能应该弹出重试提示账号被锁定时应该显示锁定文案多语言环境下应该显示对应语言的提示信息。AI没有场景这个概念它就默认给你写一个标准答案而这个标准答案恰恰是你最不需要的。1.3 代码复用的思路可以借鉴但不能照搬做开发的同学可能会立刻想起封装抽象DRY原则觉得测试用例复用不就是写一个公共函数到处调用吗这个思路方向没错但注意测试用例不是代码。代码复用的是逻辑测试用例要复用的是场景应用能力。一段登录代码封装好了所有依赖登录的用例都能调它但一条登录测试用例的复用不是把步骤抽成函数就能解决的因为它面对的是不同的业务场景、不同的数据状态、不同的预期结果。你可以把可复用的测试用例理解成一个可配置的测试动作模板而不是一段被调用的代码。它需要同时具备三种能力能接受不同参数、能适配不同环境、能挂接不同断言。只有这样它才能做到一个用例多个场景。2. 可复用测试用例的设计核心把场景和用例拆成两个东西2.1 可复用的最小逻辑单元是测试动作不是测试用例想通了上面那个点之后我做的第一个关键转变是把AI生成的单位从完整用例改成测试动作。什么叫测试动作就是完成一个单一业务目标的最短操作序列。拿登录来说测试动作是用指定账号执行登录操作它不包括打开浏览器、不包括输入URL、不包括等待首页加载完成的那些公共准备步骤。一个测试动作的粒度大概相当于代码里的一个函数入参明确、行为聚焦、返回结果可验证。在实践中我会把常见的测试动作都单独抽出来作为一个可以独立维护的资产。比如登录动作入参账号、密码、期望会话状态搜索动作入参搜索关键词、搜索引擎入口下单动作入参商品ID、数量、收货地址支付动作入参订单号、支付渠道、支付结果模拟文件上传动作入参文件路径、上传入口注册动作入参邮箱、验证码来源、期望注册结果AI生成的一条用例被拆成最小单位之后就不再是一个完整场景的说明书而是一个可以拼装的积木。完整的业务场景反而是由多个动作根据条件组合出来的。2.2 参数化是复用的地基参数从哪来、怎么传测试动作要复用第一件事是参数化。你检查一条AI生成的用例好不好用最简单的方法是把用例里的所有值都圈出来看哪些是固定的、哪些是可变的可变的是否作为参数暴露出来了。合理的设计应该是这样的测试动作登录 入参 - username: 默认使用环境变量 TEST_USER - password: 默认使用环境变量 TEST_USER_PASSWORD - login_url: 默认使用环境配置的 LOGIN_URL - user_role: 可选参数支持 admin / regular / guest / locked - locale: 可选参数影响登录页的多语言断言 返回状态 - 登录成功埋点/页面跳转/会话信息可用 - 登录失败错误提示文案注意默认使用环境变量这层设计。它的意思是动作用例本身不保存具体数据数据由执行环境提供。这么一来同一条用例在测试环境、预发布环境、生产冒烟环境都能跑只要环境变量配置不同就行同一个环境里也可以传不同用户角色去跑权限相关的场景而不需要每个角色单独写一条用例。这个设计对应到实现层就是测试数据与用例脚本分离。AI生成的时候也要遵循这个原则你可以在Prompt里明确写生成的用例不得包含具体测试数据数据统一用参数占位。这句约束能救回一大半本来会废掉的用例。2.3 预期结果断言怎么处理才能适配不同场景参数化解决的是输入问题断言解决的是输出问题。一条复用性强的用例不应该只有一个标准预期结果而应该根据场景切换不同的断言逻辑。举个例子。同一个登录动作在下面的场景里预期结果完全不同场景输入参数特点预期结果正常登录有效账号正确密码跳转到首页会话cookie生成用户信息接口返回200密码错误有效账号错误密码停留在登录页显示账号或密码错误无会话cookie账号被锁定已触发锁定策略的账号提示账号已被锁定请稍后再试锁定剩余时间文案弱网环境有效账号正确密码弱网模拟可能提示网络连接超时可点击重试重试后登录成功多语言环境有效账号localeja_JP错误提示文案为日文UI语言切换正确AI生成用例时如果只让你写正确路径的断言它给出的东西就是一条单调的快乐路径用例根本无法支撑这些变化。正确做法是每个测试动作用例都附带多套断言模板由上层场景来选择用哪套。你甚至可以要求AI对每个操作步骤都给出正常断言和异常分支断言两套候选让负责编排场景的人自己去组合。2.4 三层分离用例、场景、数据各管各的把上面的思路整合起来我建议在项目里建立这样一个三层结构这也是一个用例多个场景最落地的组织方式第一层测试动作库。存放最小可复用逻辑单元每个动作都有定义好的入参、返回、断言模板和异常分支。这是最容易用AI大批量生成、也最适合做质量审查的一层。第二层场景编排层。定义什么条件下、按什么顺序、组合哪些动作、用哪套断言。这里的产物是业务场景用例比如新用户首次登录并完成下单老用户密码过期后重置再登录。AI在这一层的任务是组合积木而不是发明积木。第三层数据配置层。存放具体的账号、商品、地址、环境参数等测试数据。这一层是改动最频繁的但它不应该牵扯到前两层的修改。这三层职责一旦分清场景的增删就变成了配置问题而不是重写用例问题。我之前遇到过项目上线前需要紧急扩展多语言回归场景当时只需要在数据配置层加几个locale参数场景编排层复用原有的正常登录购物流程整套用例的改动量从原来的几十条用例全部重写缩短到只改一个配置文件、加三行参数那个效率差距给人的印象非常深。2.5 一个容易被忽略的关键能力上下文自适配参数化、断言模板、分层结构都做了还有一件事AI生成用例时特别容易忽略就是上下文自适配。同一个登录动作在Web端、移动端H5、桌面客户端里控件名称、跳转方式、等待策略、埋点事件都不相同。如果动作用例里写死了任何一个端特有的细节它就丧失了多端复用的能力。我的做法是在动作定义里增加一个目标载体字段明确标注支持Web/移动端H5/桌面端/API并把UI定位器、网络请求断言这类端特有信息拆成适配器而不是写进动作主体。AI生成用例时也要抽样检查凡是看到它把点击登录按钮写成某个特定CSS选择器或者把跳转地址写成一个固定URL的我都会打回重写。这不是苛求而是复用的问题必须在这个阶段解决等到用例进到场景层再改成本已经高了10倍不止。3. 一个登录用例如何覆盖Web端、移动端、多语言、弱网四个场景3.1 从建模开始让AI理解可复用要求只讲理论比较虚我拿登录这个最常见的动作用例来实际跑一遍。整个流程分四步建模、生成、评审、挂接场景。建模的Prompt大致长这样你可以直接参考你正在为测试平台设计一个可复用的登录测试动作要求如下 1. 动作只包含打开登录入口、输入账号、输入密码、点击登录、级联断言这五个必要步骤不得包含环境准备步骤 2. 所有测试数据用参数占位包括用户名、密码、登录入口地址、目标环境 3. 输出三套断言模板正常登录成功、账号密码错误、账号被锁定每套断言需要区分页面显示断言、接口状态断言、会话状态断言 4. 对Web端、移动端H5、桌面客户端三种载体分别列出适配差异提醒 5. 额外输出该动作在弱网、多语言两种场景下的注意事项。这个Prompt跟一次性生成几十条用例的Prompt相比核心差异在于它要求AI面向可复用来进行设计而不是面向某个具体功能点验证来编写。生成出来的内容是一个动作规格说明书断言模板适配说明的组合而不是一条写死所有细节的TestCase。3.2 四个场景的复用过程逐个拆开看场景一正常登录功能回归Web端这是最基础的场景。动作库里的登录动作传入默认参数环境变量里的测试账号、预置URL启用正常登录成功断言模板。这条用例覆盖的验证点包括页面跳转、会话状态、用户信息接口返回数据。如果需求只改了登录页的UI样式这个场景一条用例就能完成回归不需要额外写新的用例。场景二移动端H5登录移动端H5跟Web端复用同一个登录动作但适配器要切换成移动端的元素定位方式和页面加载等待策略URL也要换成移动网关地址。因为动作主体的步骤结构没变只是载体适配不同你不需要重新设计登录用例只需要在动作的参数里增加一个platformmobile_h5的环境标签。这里的关键是登录动作设计时就必须预留载体参数否则这一步就要复制一份动作出来而复制的动作很快就变形变成一个维护负担。场景三多语言环境登录多语言场景下登录动作主体仍然不变变化的是断言模板。如果用户进入的登录页语言是日语那断言账号或密码错误就不再是中文文案而是日语文案。我们会把断言模板做成断言文案字典每个支持的语言放一套翻译动作执行时根据locale参数自动选择。这个设计漏掉的话多语言测试就做不成一个用例跑多个场景只能一个语言写一套最后变成几十条几乎一样、互相没啥关联的用例堆在那里。场景四弱网环境登录弱网环境下的登录用例复用的是同一个登录动作但在执行前注入弱网模拟参数在断言模板里打开网络异常分支此时同一个用例允许出现两种结果之一要么网络超时提示并且能重试、要么登录成功。这个场景在传统写法里是要单独写一条弱网登录用例因为步骤和预期跟正常登录完全不同。但基于可复用的动作设计它只是同一个动作的另一种断言策略和数据组合不需要新增用例。3.3 复用带来的测试效率变化四类场景跑完感受最明显的是新增场景的边际成本直线下降。早期我们团队在没做复用设计之前每个新场景基本都要从零写2到5条用例碰上多端、多语言、异常流一起变写用例写到怀疑人生。做成动作库场景编排之后新场景的搭建时间从以小时计缩短到分钟级绝大多数情况下就是选动作、配数据、选断言模板用例本身根本不用动。这里要补充一句可复用不是一刀切复用一切。比如某些移动端特有的登录生物认证指纹、人脸它就不是登录动作的变体而是一个单独的测试动作。我见过团队为了追求复用率把指纹登录也硬塞进登录动作的适配器里结果每次改动都要小心翼翼生怕影响其他端的用例。复用是为了省事不是为了给自己上锁该分开的就要分开。3.4 AI在其中一个场景里的实际角色这个流程里AI到底做了什么我分得很清AI负责两件事一是批量生成动作库的第一版草稿提供90%的覆盖度二是根据已有的动作库自动生成场景编排建议比如你选了这个动作历史上还有这些场景常跟它搭配。它不负责在每次需求变化时重新生成一堆新用例那样会让测试资产失去连续性。换句话说AI是动作库的生成者和维护者的助手而不是业务用例的替代者。这一点在整个可复用方案里非常重要你用AI的方式决定了你的用例资产是越积越厚还是每次从零开始。4. 让AI生成的东西真正可复用的Prompt方法4.1 两种Prompt写法的差距大到惊人同样让AI生成登录用例两种Prompt写法出来的东西可复用性差距是云泥之别。第一种是功能清单式也是大家最常用的请生成登录功能测试用例覆盖正常登录、密码错误、账号锁定等场景这种写法AI会给你20条用例用例之间是平铺的每一条都包含了完整的步骤和固定数据。数据写死、步骤冗余、场景之间没有关联基本就是一次性资产。第二种是资产建设式也就是上面说的建模方法。它跟第一种的核心区别是你告诉AI的不是帮我写功能用例而是帮我设计可复用的测试资产。要求它在生成过程中考虑参数化、断言模板、载体适配、场景拆分并且不要包含任何具体数据值。如果你一开始就用第二种方式给AI下指令生成出来的动作质量会高很多。从测试资产建设角度看第一版动作库的覆盖广度和抽象合理度直接决定了后续一两个季度里所有场景编写的工作量这一块非常值得多花一点时间在Prompt上。4.2 把团队已有的测试基线喂给AI效果会大幅提升如果团队里已经有一套稳定的手工测试用例或者老版本的自动化脚本千万不要浪费。把脱敏后的老用例作为基线样本喂给AI让它学习你们团队的动词习惯、断言风格、字段命名规范然后基于这些风格去生成新的可复用动作。这样生成出来的东西跟团队原有资产能够无缝衔接而不是AI自己发明一套新话术。实际操作中我会在Prompt里附加几条参考样例以下是团队已有的可复用测试动作的参考示例 【示例1】 动作注册用户 入参邮箱、密码、注册渠道 断言模板1注册成功邮箱已接收激活链接 断言模板2邮箱已被占用提示文案可配置 请参照上述示例的结构、用语、粒度为以下功能设计可复用测试动作登录这个方法在LangChain的工具链里也可以做成检索增强生成的流程把沉淀好的动作库切成向量切片建立索引库每次生成新动作或场景时先从索引库里检索出最相似的历史资产作为上下文再让大模型基于这些上下文续写。实测下来的效果是生成的用例在格式一致性上几乎可以做到以假乱真团队新老用例混排在一起外人根本看不出哪些是AI生成的哪些是手写的。4.3 AI生成完必须要过一遍可复用性评审我在团队里推行了一个用例评审清单每条AI生成的用例进入资产库之前必须过一遍这个清单参数化检查是否有超过一个具体值被硬编码这些值是否都需要在多种场景下变动步骤粒度检查是否混入了环境准备类步骤是否能独立执行断言模板检查是否包含至少一套成功断言和一套异常断言断言是否覆盖页面、接口、数据三层载体适配检查是否有端特有的细节混在动作主体里是否预留了载体参数场景可编排性检查这个动作能否被至少两个不同场景复用如果暂时只有一个场景未来有没有潜在复用空间如果超过两项不通过我会打回让AI基于这些约束重新生成。虽然这一步增加了不少工作量但它保证了资产库里的每一份用例都不是累计负债。4.4 让AI自己给自己挑错是免费的质检员还有一个技巧在动作库沉淀到一定规模后把已有的动作定义和一批新增的由AI生成的动作混在一起让大模型做一致性审查。Prompt可以这样写以下是系统里现有的可复用动作资产定义以及AI新生成的一组动作定义。 请找出新生成内容中与现有资产在命名、参数、结构、断言风格上不一致的地方并给出修改建议。 重点关注参数命名冲突、断言模板风格不一致、动作粒度差异过大、载体适配信息遗漏等问题。这个做法本质上是用AI做一次资产入库前的代码Review成本几乎为零但能拦住大量低水平重复资产流进库里。我们团队上线这个机制之后资产库里的重复度明显下降动作数量增长变慢但每个动作的复用频率上来了这才是资产库健康的状态。5. 可复用设计的另一面这几点比生成本身更值得注意5.1 过度抽象是最大的坑没有之一可复用设计最大的陷阱是抽象过度。你为了一个用例多个场景把参数越设计越多断言模板越做越全载体适配越铺越开——最后这个可复用动作本身变成了一台复杂的机器每次调用都要传十几个参数配置断言逻辑比直接写一条新用例还要费劲那么复用就失去了意义变成了自娱自乐式的架构洁癖。我判断一个动作的抽象是否过度的标准很简单如果这个动作80%以上的调用场景都用不到它的某两个参数那两个参数就应该拆出去或者砍掉。可复用性不是把所有可能性都塞进去而是让最常见的场景足够简单让次常见的场景不至于重写。5.2 可读性比结构完美更重要测试用例还有一个特殊的属性它会被人反复读。开发要看产品要看新来的测试同事更要看。一个为了复用而层层抽象的用例如果可读性差阅读它的人根本搞不清楚这条用例到底在测什么那它在团队里就是个摆设再可复用也白搭。我见过一份AI生成的可复用动作为了满足抽象要求把登录步骤里的每一步都做成了条件判断动作本身像是被挖空了一样全是看情况执行A、否则执行B、如果状态为C再执行D的分支逻辑。这种万能用例看着强大实际上对每个场景都调试困难断言失败时定位也困难。我的原则是动作主体保持线性简单复杂分支留在场景编排层去体现。这样既有复用性又能保证任何人打开动作定义一眼就能明白它在干什么。5.3 用例之间的依赖关系要尽量拆干净可复用动作组合成场景之后最容易出现的问题是依赖关系的不可控。一个场景里登录动作可能会依赖前置的注册动作或者密码重置动作。如果场景编排层把这种依赖关系藏在了用例步骤里面一旦前置动作的数据变动后面所有依赖它的场景都会挂掉而且排查起来像大海捞针。解决办法是把依赖关系显式声明出来做成前置条件某个动作某类数据的结构。AI生成场景时也要让它明确标注依赖关系而不是隐含在步骤描述里。这样至少可以做到前置动作失败时报告里会直接标注因前置动作失败被跳过而不是抛一堆让人摸不着头脑的断言错误。有一条执行经验如果AI生成的场景编排里用例之间的依赖超过两层就先把中间层抽成一个独立动作避免串联过深。5.4 维护成本的账要提前算清楚做可复用设计不是免费午餐。动作库是资产同时也是负债因为里面的每个动作都需要维护。需求变了被10个场景复用的动作需要更新一次但它影响的场景有10个回归的范围也是10个。如果动作库一致性好这一个改动是可控的集中改动如果动作库本身设计混乱同一个功能散落在三个动作里那一次需求变化就可能要改三处遗漏一处就出线上问题停止测试。所以在团队里推行可复用测试资产时我建议设定一个动作健康度指标动作数量、每个动作被多少场景引用、最近一次更新时间、失败率、变更频率。定期审视这些指标把那些长期零引用、低引用、改动频繁的动作清理掉或者合并。AI可以辅助做这种健康度分析把哪几个动作应该合并哪几个动作已经偏离原始设计这类建议提出来再让人来决策。6. 落地路径如何一步步把一次性用例升级成可复用资产库6.1 第一步盘家底找到第一批值得复用的候选功能不是所有功能都适合做可复用动作。一个只会在特定营销活动中出现一次的独家功能你给它设计五个参数、三套断言模板纯属浪费。真正值得做成可复用资产的是那些横跨多个业务场景、多个端、多个数据状态的基础功能比如登录、注册、搜索、下单、支付、文件上传、消息通知、权限校验。第一个月我只选了登录、搜索、下单这三个最高频的动作做试点。做完之后把效果摆到团队面前新来的同学用动作库搭一个新场景只需要10分钟而之前手写至少需要1个小时。有了这个样板之后其他模块的同事自然会主动提出来想给自己的核心流程也建一套后面推进就顺畅多了。一开始铺太大反而容易失控。6.2 第二步定规范让AI有章可循可复用动作库要长期运转必须有一套显式的规范文档。我们团队的规范文件里包含了动作命名规则、入参定义格式、断言模板的最低数量要求、载体适配的标准字段、场景编排的依赖声明方式、资产入库前的评审流程。这套规范本身也是AI生成Prompt的底料每次让AI生成新动作的时候把这套规范直接粘贴进Prompt里它产出的内容就会很规矩。6.3 第三步把AI嵌进流程里而不只是用一下我见到很多团队用AI生成测试用例属于锦标赛式用法某次赶工拉个工具生成一堆用例用完就完事儿AI和测试资产之间没有建立持续的联系。真正让可复用资产库滚起来的做法是把AI嵌到日常流转的每个节点里——动作库新增时有AI草稿和建议场景编排时有AI组合方案用例变更时有AI检查影响面资产清理时有AI分析健康度。比如我们把动作库和场景库全部用向量化方式存起来每次开发提了一个新的需求变更先用RAG流程检索哪些动作和场景会受这个变更影响自动生成一版变更影响分析报告标注出可能挂掉的用例和需要调整的参数然后由测试同学去确认和修改。这个流程跑起来之后AI就不是一个生成用例的工具而是测试资产库的维护引擎用例的复用率和使用粘性都高了很多。6.4 第四步量化效果让数据说话最后一条经验是可复用性这件事不量化就没法持续改进。我们每周会看几个核心指标——动作复用率每个动作被多少场景引用、场景搭建耗时、用例维护耗时、需求变更导致的用例改动行数。这几个指标在推行可复用设计前后的对比非常明显用例维护耗时从平均每次2小时降到20分钟左右需求变更导致的用例全量重写比例下降了七成。每个季度末我会把这些数据整理成一份简短报告发给团队。不用多复杂的图表就是几张简单的趋势线已经足够说明问题。很多人一听到可复用设计觉得是虚的但把这些数据摆出来他们很快就意识到这事儿不是好听是真的能省时间、降成本。测试团队在项目里的价值感也会因为用例资产越积越厚而不是每次从零开始而明显不一样。最后再分享一个当年让我印象最深的小细节。我们把登录动作升级成可复用结构之后有一次新项目直接复用了整套动作库只用了一天时间就搭建完了原本预计一周才能完成的冒烟测试集。那天晚上回来的路上我一直在想测试用例的真正价值从来不在它被AI生成出来的那一刻而在它被不同项目、不同场景反复使用的那一年。这才是一个用例多个场景这句话背后真正想说的意思。