测试范式大迁移：从"怎么做"的脚本，到"测什么"的意图

封面图片

做过几年自动化测试的人大概都有一个共同感受：测试脚本写起来容易，维护起来要命。界面改个按钮位置，十几条用例跟着崩；接口换个字段名，断言全线飘红。我们花了大量精力告诉机器“怎么操作”，却很少停下来想一想——我到底要“测什么”。

2025年下半年以来，随着大模型Agent能力的成熟，测试领域正在发生一次真正的范式迁移：测试工程师不再逐行编写操作步骤，而是用自然语言描述测试意图，由AI Agent自主规划路径、执行操作、校验结果。这不是概念炒作，已经有团队在生产环境跑通了这套架构，并拿到了实打实的效率数据。

本文系统讲解“测试意图层→Agent调度层→执行层”的三层架构，用实测数据对比传统脚本驱动与意图驱动的差异，并给出落地时踩过的坑和实践建议。

目录

一、老路子走不通了：脚本驱动测试的三个死结

二、意图驱动测试的三层架构

三、一个真实场景的对比：电商下单流程

四、实测数据：覆盖率、维护成本与缺陷发现率

五、落地实践中的关键问题

六、写在最后

一、老路子走不通了：脚本驱动测试的三个死结

传统自动化测试的逻辑很直白：录制或手写操作步骤，回放验证结果。Selenium、Appium、Cypress这些框架本质上都是“操作录制器”的升级版。这条路走了十几年，问题越来越明显：

第一，维护成本指数增长。某金融科技团队统计过，他们维护2000条UI自动化用例，每次前端迭代后平均要修复15%～20%的用例，每月花在“修脚本”上的人力超过40人天。脚本越多，负担越重，最后团队被迫砍掉一半用例来“减负”。

第二，覆盖盲区大。脚本只能覆盖事先想到的路径。一个表单页面有5个字段、每个字段3种边界情况，组合起来就是243条路径，实际写出来的用例通常不超过20条。剩下的“想不到”的路径就成了漏网之鱼。

第三，脚本和业务意图脱节。看一条Selenium脚本，你能看到driver.find_element(By.ID, 'btn_submit').click()，但你很难直接看出这条用例到底在验证什么业务规则。测试意图被淹没在一堆定位器和等待语句里，新人接手时只能靠猜。

这三个问题不是某个框架的问题，而是“脚本驱动”这个范式本身的结构性缺陷。

二、意图驱动测试的三层架构

意图驱动测试的核心思路是把“测什么”和“怎么测”彻底分开。整个体系分为三层，各层职责清晰：

SVG 内联图 1

第一层：测试意图层。测试工程师用自然语言（或结构化DSL）描述“要验证什么”。比如：“已下单用户取消订单后，库存应恢复，退款应在24小时内到账。”这一层只关心业务逻辑，完全不涉及UI定位器、接口路径这些技术细节。

第二层：Agent调度层。这是整个架构的大脑。大模型Agent接收到意图后，先做意图解析，拆解成可执行的子任务；再做路径规划，决定通过UI操作、API调用还是直接查数据库来验证；最后自动生成断言条件。目前主流方案是基于Claude、GPT-4o等模型的ReAct Agent，配合工具调用（Tool Use）能力来实现。2026年上半年开始，不少团队已经用上了多Agent协作模式——一个Agent负责规划，一个负责执行，一个负责结果校验，各司其职。

第三层：执行层。底层还是Playwright、Appium这些老伙计，但它们不再由人类直接编排，而是作为Agent的“手和脚”被调用。执行完成后，结果（截图、日志、断言结果）回传给Agent层做判定。

这个架构的关键价值在于：意图层是稳定的（业务规则不会因为前端重构而改变），执行层是可替换的（换了框架只需要换工具插件），两者通过Agent层解耦。UI改了按钮位置？Agent会自己找到新的按钮。接口字段改名了？Agent重新解析API文档后自动适配。

三、一个真实场景的对比：电商下单流程

拿电商“未登录用户尝试下单”这个场景来做对比，差异一目了然。

传统脚本写法（Playwright + Python）：

page.goto("https://shop.example.com/product/12345") page.click("#btn-add-cart") page.click("#btn-checkout") # 期望跳转到登录页 assert"/login"in page.url assert page.locator("#login-form").is_visible()

这段代码绑定了具体的URL、元素ID、页面结构。产品把“加入购物车”按钮从#btn-add-cart改成#add-to-cart-btn，用例就挂了。

意图驱动写法：

intent: 验证未登录用户的下单拦截 precondition: 用户未登录 steps: - 浏览任意商品详情页 - 尝试将商品加入购物车并发起结算 expected: - 系统应阻止下单流程 - 引导用户跳转至登录页面

Agent拿到这段意图后，自己去找商品页、找“加入购物车”按钮（靠视觉理解或DOM语义分析，不依赖固定ID）、触发结算，然后判断是否被拦截并跳转到了登录页。按钮ID怎么改都无所谓，因为Agent关注的是“加入购物车”这个功能语义，不是某个CSS选择器。

四、实测数据：覆盖率、维护成本与缺陷发现率

以下数据来自某中型SaaS产品团队的半年实践（2025年12月至2026年5月），测试范围为其核心业务模块（约120个页面、45个API接口）：

几个数字值得注意：

用例数量减少了65%，但路径覆盖反而翻倍——因为Agent会自动探索分支路径，一条意图能衍生出多条实际测试路径。比如“验证表单校验”这条意图，Agent会自动尝试空值、超长字符、特殊字符、SQL注入字符串等多种输入，这些在传统模式下需要人工逐条编写。

维护成本下降83%是最直观的收益。前端改版后，脚本驱动方案需要大面积修复定位器，意图驱动方案几乎不需要调整——意图没变，Agent自己适配新界面。

五、落地实践中的关键问题

这套东西不是开箱即用的银弹，落地时有几个问题绕不开：

1. Agent的稳定性问题。大模型有随机性，同一条意图执行两次，Agent可能走不同的路径。解决办法是加一层“行为锚定”——对关键步骤设置约束条件，比如“必须通过UI操作而非API直接调用来触发下单”。另外，把temperature设低（0.1左右），也能提高一致性。

2. 执行速度。Agent每一步都需要调用大模型做决策，比纯脚本执行慢不少。实测下来，单条用例的执行时间从脚本模式的8秒增加到意图模式的35秒左右。应对策略是并行执行——意图之间天然独立，很容易做并发。用20个并行Worker跑620条意图，总耗时反而比串行跑1800条脚本短。

3. 成本控制。每次测试运行都要消耗大模型Token，不便宜。目前比较实际的做法是分层策略：冒烟测试用意图驱动（覆盖核心路径，每日运行），回归测试混合使用（高频变动模块用意图驱动，稳定模块保留传统脚本），探索性测试全部交给Agent。这样Token成本可以控制在每月2000～5000元（中型项目规模）。

4. 意图的粒度把控。意图写得太粗（“测试登录功能”），Agent不知道该验证什么；写得太细（“点击用户名输入框，输入admin，点击密码框……”），又回到了脚本模式。经验值是：一条意图对应一个业务场景，包含前置条件、操作目标和预期结果三个要素，通常3～5行自然语言。

下图展示了意图驱动测试在CI/CD流水线中的实际运行流程：

SVG 内联图 2

值得注意的是“变更分析”环节：Agent会根据本次代码提交的diff自动判断影响范围，只挑选相关的测试意图来执行，而不是每次都跑全量。这在传统方案里需要人工维护“用例-模块”映射表，费力且容易遗漏。

六、写在最后

测试范式从“脚本驱动”到“意图驱动”的迁移，本质上是把测试工程师从“自动化脚本维护员”的角色中解放出来，回归到“质量守护者”的本职——思考业务风险、定义验收标准、设计测试策略。

这不意味着传统自动化测试马上就要被淘汰。对于逻辑简单、长期稳定的场景（比如单元测试、固定格式的数据校验），传统脚本仍然是最高效的选择。意图驱动测试更适合解决的是UI测试脆弱、集成测试覆盖不足、探索性测试依赖人工这三类长期痛点。

实际落地建议从一个中等复杂度的模块开始试点，用两到三个迭代周期跑通“编写意图→Agent执行→结果分析→意图优化”的闭环。先证明这条路径在你的团队和技术栈上跑得通，再逐步推广。

技术工具在变，但测试的核心命题始终没变：用最小的成本，尽早发现最多的问题。只是现在，我们终于有了更聪明的方式来做这件事。