接口测试遇到大模型：把“登录、下单、支付”拆解为Skills，AI自动编排执行

三个月前一个测试主管给我看他们的自动化代码。登录、加购、下单、支付、退款五个核心流程写了四十多个脚本。不是写错了是排列组合。登录方式三种商品类型四种支付渠道两种再加上优惠券、地址、库存边界——线性的业务步骤变成了爆炸的场景矩阵。他说我们维护的不是脚本是笛卡尔积。我问为什么不动态编排他说太难了。步骤之间有数据依赖每一步的输出是下一步的输入。登录拿token下单拿订单号支付拿支付ID。硬编码还能跑想灵活组合数据链路就断了。上个月我用一套基于Skills大模型的方式把这个场景跑通了。不是写更多脚本是把“登录”“下单”“支付”每个步骤变成独立的Skill然后让AI根据一句话自动编排执行顺序和传参。比如输入“用手机号登录买一件普通商品用微信支付”AI自动调用对应Skills链路自动串起来。换一种组合“用账号密码登录买两件会员商品用余额支付”同样通。本质上我们把测试执行从“代码”上升到了“意图”。目录一、业务流程测试的三种死法二、AI编排不是生成脚本是生成执行计划三、三层模型Skill仓库、调度器、数据总线四、一个下单流程的AI编排实录五、工程落地的四个关键判断六、把最复杂的流程拆成Skills你敢不敢试一、业务流程测试的三种死法先不聊AI。聊一个现实问题。任何一个业务系统核心流程都是有限的几个登录、下单、支付、退款、发货。但每个流程有多个变体。登录有手机号、邮箱、扫码、第三方。下单有普通商品、虚拟商品、预售商品。支付有微信、支付宝、银行卡、余额。当你写自动化用例时通常的做法是针对每一种组合写一个脚本。登录-普通商品-微信支付是一个脚本登录-会员商品-余额支付是另一个脚本。这套做法会导致三种死法。第一种死法组合爆炸。3种登录×4种商品×3种支付 36个脚本。每个脚本里80%的代码都是重复的获取token、解析订单号、等待回调。但这些代码又不敢随便复用因为细微的参数差异会藏在脚本深处。第二种死法变更蔓延。登录接口改了一个字段36个脚本全部要改。不是不能改是没人愿意改。最后结果就是脚本逐渐变红然后没人修然后整个自动化弃用。第三种死法新场景加不进去。产品经理说我们要支持“先下单后登录”的模式。你看着已有的36个脚本发现数据依赖全是基于登录在前。重构数据链路成本够开一个新项目。这三种死法的共同根源是什么本质是我们把业务流程的“骨架”和“血肉”混在一起写了。骨架是步骤之间的顺序与数据传递血肉是每个步骤的具体实现。传统脚本里这两者耦合在代码行里。AI编排想解决的事很单纯把骨架交给AI动态生成血肉做成独立可复用的Skill。二、AI编排不是生成脚本是生成执行计划很多人听到“AI自动编排”第一反应是让大模型直接写测试脚本。然后跑一下发现生成的脚本要么调不通要么断言错要么用了不存在的变量。这条路走不通因为大模型不擅长精确的代码逻辑和运行时状态管理。正确的做法是让大模型输出一个“执行计划”而不是代码。执行计划是一个JSON结构描述了Skill的调用顺序、输入参数如何从上一步的输出中提取、以及预期结果如何校验。举个例子。用户说“用手机号登录买一件普通商品用微信支付”。大模型不需要知道怎么调登录接口不需要知道订单号的JSON Path是什么更不需要知道支付回调的轮询逻辑。它只需要输出{ plan: [ {skill: login_by_phone, inputs: {phone: 13800138000, pwd: xxx}, outputs_as: token}, {skill: create_order, inputs: {token: $token, product_type: normal, quantity: 1}, outputs_as: order_id}, {skill: pay_by_wechat, inputs: {token: $token, order_id: $order_id}, outputs_as: pay_result} ], asserts: [ {step: pay_by_wechat, field: pay_result.status, expected: SUCCESS} ] }这个计划是确定性的可执行的。大模型只负责两件事根据用户自然语言匹配对应的Skill以及推断数据依赖关系比如pay_by_wechat需要order_id而order_id来自上一步。有了执行计划剩下的全交给一个轻量级的执行引擎。引擎负责调用Skill、管理变量作用域、做断言、处理重试和超时。核心在于大模型的输出空间被约束在一个很小的、结构化的执行计划上。这不是代码生成这是决策生成。成功率比直接生成脚本高一个数量级。观点句1AI编排的本质是把测试执行从代码生成转变为计划生成。代码的确定性交给引擎大模型只做它最擅长的语义匹配和依赖推断。三、三层模型Skill仓库、调度器、数据总线要做到上述编排需要三层架构。下图是完整设计。Skill仓库每个Skill是一个独立的功能单元。它有明确的三要素输入规格需要哪些参数类型是什么是否可选输出规格会产出哪些变量如token, order_id, pay_id执行体实际的HTTP请求、数据库查询、等待逻辑等Skill可以用任何语言实现只要暴露统一接口。我们内部用Python函数包装装饰器声明输入输出元数据。登录Skill的定义示例skill( namelogin_by_phone, inputs{phone: str, password: str}, outputs{token: str, user_id: int} ) def login_by_phone(phone, password): resp requests.post(/api/login, json{phone: phone, pwd: password}) return {token: resp.json()[access_token], user_id: resp.json()[uid]}LLM PlannerPlanner收到自然语言指令后首先从Skill仓库拉取所有Skill的名称和输入输出描述不需要实现细节。然后构造一个提示词要求模型输出一个执行计划。提示词的核心是一组约束只能使用仓库里存在的Skill每个Skill的输入必须能从已有变量或用户输入中解析计划必须是有向无环图不能循环依赖最后必须包含断言步骤模型返回JSON后校验器会做类型检查和依赖完整性检查。发现缺失依赖或Skill不存在就拒绝执行并返回错误提示。执行引擎与数据总线执行引擎很简单按顺序遍历计划中的每个Step调用对应Skill将返回的outputs写入数据总线一个字典存储。后续Step中遇到$变量名就从总线中替换。数据总线还支持简单的表达式如$order_id、$token.user_id嵌套取值。这比让大模型处理复杂路径可靠得多。断言引擎在每一步后或整体结束后执行根据plan中的asserts配置做校验。整个架构的核心优势新增一个业务流程不需要写脚本只需要注册一个新的Skill。而Skill的粒度可以很小比如“获取商品详情”“解析优惠券”组合由AI动态完成。观点句2当业务流程被拆解为原子Skill测试维护的成本就从O(场景数)降到了O(Skill数)。后者通常比前者小两个数量级。四、一个下单流程的AI编排实录拿一个真实业务举例。技能仓库里有这些Skilllogin_phone手机号登录输出tokenlogin_email邮箱登录输出tokenselect_product按类型选择商品输出product_id和priceadd_to_cart加购输出cart_idcreate_order下单输出order_idpay_wechat微信支付输出pay_resultpay_balance余额支付输出pay_resultcheck_order_status查询订单状态输出status传统做法写一个test_login_phone_select_normal_add_cart_create_order_pay_wechat脚本大概150行。再写test_login_email_select_vip_add_cart_create_order_pay_balance又一个150行大部分重复。Skills-first做法测试人员输入自然语言用邮箱登录选择会员商品加到购物车下单用余额支付。最后检查订单状态是PAID。LLM Planner输出{ plan: [ {skill: login_email, inputs: {email: testtest.com, pwd: 123}, outputs_as: token}, {skill: select_product, inputs: {type: vip}, outputs_as: product}, {skill: add_to_cart, inputs: {token: $token, product_id: $product.id, quantity: 1}, outputs_as: cart}, {skill: create_order, inputs: {token: $token, cart_id: $cart.id}, outputs_as: order}, {skill: pay_balance, inputs: {token: $token, order_id: $order.id}, outputs_as: pay}, {skill: check_order_status, inputs: {token: $token, order_id: $order.id}, outputs_as: status} ], asserts: [ {step: check_order_status, field: status, expected: PAID} ] }执行引擎跑完全绿。第二天需求变了先登录直接下单不经过购物车用微信支付。测试人员输入手机号登录选普通商品直接下单微信支付检查订单状态。Planner重新生成计划这次跳过了add_to_cartSkill直接create_order接收product_id。不需要改任何代码不需要写新脚本。更极端的情况产品经理说支持“游客先下单后登录”。怎么测输入不登录直接下单商品得到订单号然后用手机号登录再用登录后的token去支付这个订单。Planner分析依赖create_order在不传token的情况下是游客模式输出order_id。然后login产出token最后pay需要tokenorder_id。计划自动生成数据链路自动打通。这在传统脚本里几乎是灾难级的重构。但在Skill模式里只是AI换了几个Skill的串联方式。观点句3当数据依赖由AI推断而非人工编码时业务变更对测试的影响就从“改脚本”变成了“改自然语言”。五、工程落地的四个关键判断这套模式听起来不错但落地时有不少坑。我踩了四个总结成四个判断帮助你决定要不要做、怎么做。判断一你的业务步骤是否足够原子Skill的粒度不能太大否则复用性差。比如“完成下单”本身包含加购、地址验证、库存锁定、生成订单如果做成一个Skill就无法灵活跳过加购或换支付方式。但也不能太小。比如“提取HTTP响应头”这种不值得做成Skill因为太琐碎会爆仓库。我们的经验Skill应该对应一个“用户可感知的业务动作”比如登录、选商品、支付。内部HTTP请求的细节不属于Skill范畴。判断二你的数据依赖是否复杂到AI拼不出如果两个Skill之间的数据依赖不是直接的字段传递而是需要复杂计算比如根据商品价格计算满减后的实付金额AI很难凭空推断。这时需要在Skill的输入规格里声明“计算逻辑由调用方提供”或者单独做一个“金额计算”Skill。更实用的做法允许执行计划中插入一段简单的Python表达式而不是全部交给AI。混排模式往往更稳健。判断三你能接受AI偶尔瞎排吗大模型会出错。比如它可能把pay_wechat和pay_balance都塞进计划而业务上只能二选一。或者它忘记加断言导致执行完不校验结果。解决方式两重第一层是计划校验器写一些规则“支付类Skill只能出现一次”“必须有至少一个断言”。第二层是人工复核界面复杂计划可以展示给测试人员确认后再执行。判断四现有测试资产如何迁移不要推倒重来。我们做了一件事把一个现有的、稳定的登录脚本直接封装成第一个Skill。然后跑通一个最简单的场景。然后逐步把其他脚本里的重复逻辑拆出来注册为新Skill。迁移周期大概两周期间新旧模式并行。等80%的核心Skill都有了旧脚本就可以退休了。六、把最复杂的流程拆成Skills你敢不敢试回到开头那个测试主管的问题。他的四十多个脚本最后被拆成了11个Skill。新增一个支付渠道只需要写一个新Skill然后告诉AI“用新渠道支付”。不需要改其他任何东西。两个月后他团队的脚本维护时间下降了70%。不是因为他们写了更多代码而是因为代码变少了变活了。现在换到你的项目。你手上最复杂的那条业务流程比如涉及到五个系统、十几个步骤、七八种分支。把它拆成Skill你觉得会拆出多少个哪个步骤是最难原子化的不用回答我。在评论区写下来就当是给自己的一次架构推演。如果你已经拆完了再问自己一个问题这个Skill列表AI能在不看代码的情况下仅凭名字和输入输出描述就正确拼出你脑海中那条最复杂的路径吗如果答案是否定的你的Skill设计还需要再调整。我等着看你们的答案。推荐学习软件测试开发快速落地智能化测试公开课从Web/App/接口测试智能体再到业务测试用例生成爱测智能化测试平台手把手带你掌握AI智能体与智能化测试平台 扫码进群报名学习本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。