不是Selenium不行了，是测试的“组织方式”变了
大家好，我是某互联网公司的测试架构师。
上个月，团队里一个做了6年自动化的同事找我聊了一件让他很困惑的事。
他维护着一套跑了三年的接口自动化框架——Python + Requests + Pytest + Allure，1200多条用例，覆盖了核心业务的80%接口。一直挺稳的。但最近他接了一个新项目，发现这套框架“不够用了”。
新项目是AI驱动的，后端会调用大模型做意图识别，再调Agent执行工具链。他的自动化框架测不了——因为传统框架假设“输入A必然输出B”，但AI系统“输入A可能输出B、C或D”。
他问我：“那我这套框架白写了？”
我说：“没白写。但你得换一种方式组织它了。”
一、传统框架的“死循环”，到底卡在哪？
先说说传统自动化框架的真实困境。这个问题不需要回避，它是结构性的。
第一个问题：维护成本在吃掉交付速度。
行业调研数据显示，自动化脚本的维护成本已经超过初始开发成本的2.8倍。其中82%的维护工作量源于UI元素定位失效、API字段变更或环境配置漂移。
什么意思？你花一周写了一套漂亮的Page Object Model，下个版本UI改了一个按钮的文案，三层封装里有两层要改。开发改一行代码，你要改十行脚本。
第二个问题：传统断言测不了“语义正确性”。
JUnit、Pytest、Selenium、TestNG这些框架，被设计出来的目的是验证“明确定义的行为”——特定输入永远产生特定输出。assertContains这种断言方式，无法捕捉AI生成回答的语义正确性。
你没法用assertEquals(expected, actual)来验证“这个回答是不是合理的”。因为“合理”没有唯一的expected值。
第三个问题：框架的“组织方式”跟不上AI系统。
传统框架的组织逻辑是：写脚本 → 执行脚本 → 看报告。每一步都靠测试工程师手动推进。读Swagger、分析场景、写脚本、执行、看报错、改代码、再回归——这个循环里，人永远是瓶颈。
而AI系统的问题，不在“脚本写得好不好”，在“你有没有一套系统能持续验证它的行为”。
二、Agent + MCP + Skills：三层架构到底怎么分工？
很多团队刚开始做AI测试的时候，最常见的做法是：接口一个Agent，UI一个Agent，性能一个Agent。
短期能跑，长期一定混乱。能力重复、逻辑割裂、上下文无法共享、难以治理。
更合理的结构是三层模型。阿里云开发者社区那篇《当Agent开始接管测试体系》把这个架构讲得很清楚：
决策层：Agent
Agent负责规划与调度。你给它一个目标——“帮我测这个接口的异常情况”——它自己决定先做什么、后做什么、调用哪些工具。
能力层：Skills
Skills负责抽象能力模块。测试计划生成、代码生成、错误修复——这些是“能力”，不是“脚本”。Skill的本质不是代码，是方法论。它封装的是“这件事从专业角度应该怎么做”的完整流程。
执行层：MCP Tool
MCP负责标准化执行。API调用、浏览器操作、性能压测——这些底层操作通过MCP协议标准化。Playwright MCP让AI可以直接驱动真实浏览器，而不是通过截图或视觉模型来“猜”页面结构。
关键原则是三条：LLM不直接操作基础设施，执行必须标准化，每一步必须可追溯。
你写一个WebDriverWait等着元素加载，AI直接调用Playwright MCP操作整个浏览器。你维护三层的Page Object Model，AI用一个Skill就能完成测试用例生成和执行。
三、一个真实的工程细节：接口依赖怎么被“结构化”
接口自动化真正的难点从来不是“写断言”，是“处理依赖”。
登录 → 获取Token；创建订单 → 依赖商品ID；支付 → 依赖订单状态。传统框架里，这些依赖关系是靠人在脚本里“写死”的——前置步骤一条条手动拼。
Agent架构下，解决方式是构建接口依赖图谱。图谱参与推理，而不仅仅是存储。它的作用是：自动补全前置接口、构造合法上下文、保证调用顺序。
没有结构化依赖支撑，智能体只能生成孤立脚本。
这个思路的本质变化是：以前依赖关系是“隐性的”，藏在测试工程师的脑子里、写在每个脚本的前置条件里。现在依赖关系是“显性的”，存在图谱里，Agent可以读、可以推理、可以复用。
UI自动化的稳定性控制也是同样的逻辑。真正决定稳定性的，是MCP工具设计质量，而不是Agent本身。所有操作要封装等待机制、支持断点恢复、记录完整操作轨迹。Playwright MCP的做法是“先observe，再act”——AI先读取页面的可访问树，基于结构化快照选择元素，而不是靠猜CSS selector。
四、成本对比：MCP、Skills、传统框架，差在哪？
很多人以为Agent架构肯定更贵。实际数据不是这样的。
有团队做过对比测试，同一批任务分别用CLI+Skills和MCP直接调用来跑：
方案
Token消耗
成本
成功率
CLI + Skills
4,724
~$4.50
100%
MCP直接调用
44,026
~$55.20
72%
差距来自MCP的Schema膨胀问题——每个MCP Server连上AI时，必须把所有工具的定义一次性塞进上下文。一个工具的定义大概500-800 tokens，一个MCP Server通常有10-20个工具。
而Skill采用“渐进式披露”机制——平时只加载名字和描述，等到判断和当前任务相关时，才把完整内容加载进来。
另一个压力测试显示，1000QPS场景下，MCP方案需要额外投入
月
用
于
横
向
扩
展
，
而
方
案
通
过
异
步
处
理
把
成
本
控
制
在
50/月。
但这不是说MCP不行。
准确的关系是：MCP解决的是“能不能连”，Skill解决的是“会不会做”。一个管连接，一个管流程。MCP更适合重型、低频任务（比如部署、数据库迁移），Skill更适合高频、轻量级操作（比如代码解释、测试运行）。
生产级Skills库 = Claude Skills范式 + MCP + DSPy思想。MCP提供手和眼，Skill提供做事方法。
五、迁移的真实案例：两周替代五年计划
有一个案例特别能说明这种转变的工程价值。
Asana的工程团队用OpenAI Codex驱动的AI编码智能体，在约两个日历周内完成了预计需要5年才能完成的前端测试框架迁移——将老旧的Enzyme测试库全面替换为React Testing Library。模型与基础设施总成本约$12。
另一个数据来自Money Forward。引入Cursor之前，使用其他工具时开发者完全没有感受到明显的时间节省，采用进展基本停滞。引入Cursor后，仅一周内，使用编程智能体的工程师人数就增加了30%。
为什么？不是因为“这个AI更聪明”，而是因为它能端到端完成完整的工程任务，而不是只帮你补全一行代码。
六、怎么评估Agent是否“真的有效”？
没有指标，只有演示。建议至少建立四个核心指标：
用例采纳率：人工无需修改即可执行的比例。阿里天猫的案例显示，C端场景AI用例采纳率85%以上，但资金、供应链这类B端场景，采纳率始终没突破40%。
自动修复成功率：首次失败后自动修复成功的比例。这是衡量Agent是否真正“闭环”的关键。
回归稳定率：多次执行一致性。Agent是非确定性的——同样的输入跑10次可能得到10种结果。你需要验证它的行为是否稳定。
上下文命中率：依赖解析正确率。Agent能否准确找到相关的接口依赖、业务规则、历史Bug。
当这些指标稳定后，智能体才具备推广条件。
七、避坑指南
坑一：把Skill当成“高级Prompt”。
Skill不是一段对话模板，是一个可被AI自动发现和加载的完整能力包。SKILL.md只是入口，还有scripts/可执行脚本和references/参考文档。
坑二：一上来就搞“全Agent化”。
传统框架不是没用了。确定性验证的场景（接口幂等测试、数据校验），脚本执行器依然是最可靠的选择。性能测试的高并发压测执行、分布式资源调度，也不适合完全交给智能体。
合理模式是：生成与分析自动化，执行与资源控制人工参与。这是一种工程平衡，而不是技术妥协。
坑三：忽略MCP工具的设计质量。
真正决定UI自动化稳定性的，是MCP工具设计质量，而不是Agent本身。如果MCP工具返回的页面快照不完整、元素定位不准确，再强的Agent也跑不稳。
坑四：不用指标评估，只看Demo效果。
“跑了一遍demo没报错”——这可能是工程领域最危险的五个字。必须建立用例采纳率、自动修复成功率、回归稳定率、上下文命中率四个核心指标。
最后
传统测试框架不会消失。但它正在从“唯一的测试方式”变成“测试体系中的一层”。
Agent负责规划与调度，Skills负责抽象能力模块，MCP负责标准化执行。这三层协同工作，把测试从“脚本编写”推向“架构设计”。
以前自动化测试的核心是写脚本。现在更像是在搭一个能理解任务、能调用工具、能沉淀经验的测试智能体系统。
不是Selenium不行了。是测试的组织方式变了。
你还在写脚本，别人已经在搭能力。
