前言
团队将 UI 自动化从 Selenium 迁移至 Playwright,在 AI 大模型加持下,脚本质量与编写效率得到明显提升。本文从 Playwright 与 Selenium 对比出发,分享思路与设计经验。
一、Playwright 与 Selenium 对比
- Selenium 使用'代理'webdriver 协议统一接口对接不同浏览器
- Playwright 直接与浏览器原生底层调试协议通信,如 CDP(Chrome Devtools Protocol)
Selenium 采用'套一层'方式解决自动化问题,无法获取浏览器原生底层数据(如网络请求参数、控制台信息),执行速度也天然慢于 Playwright。在 AI 时代,Selenium 因底层原理限制,相关 AI 应用成果有限。Playwright 结合 AI 应用则有不少亮点,适合驱动 UI 自动化重构。
二、AI-Playwright MCP
利用 MCP 让 AI 模型分析页面 DOM 元素,驱动浏览器并抓取页面情况,帮助分析元素结构和交互过程,辅助编写 UI 自动化测试脚本。
目前 LLM 百花齐放,对于普通用户差异不大,建议根据顺手程度选择。AI 模型会犯错,需遵循 AI 辅助原则:
- 半自动配合工作,不要偷懒不 Review AI 生成的代码
- 有错误必须反馈,积累有效 Prompt
- AI 生成代码无逻辑时立即停止,手动 Coding 教会它
- 复杂情况下手动拆分模式加入合理设计模型
安装 Playwright MCP 请参考 Node 环境的 MCP Server 安装文档。
调研过 TestCraft、Testim.ai、applitools 等工具,封闭式管理封装性强且收费,难适合大多数业务需求。以下演示如何使用 Playwright MCP。


试运行生成的脚本。

实际业务中仍需修改,Demo 展示的是 AI 分析页面并输出脚本的能力。
三、Playwright 封装设计建议
分层设计指导下,考虑可维护性和可扩展性,主要封装思路如下:
- 基于 Playwright 原生操作能力(click、input 等),封装业务层的 XxxPlayWright
- 在 XxxPlayWright 基础上组件化,将告警框、下拉框等控件代码模块化,可使用 Mixin 等结构型设计模式
- 基于模块组件化代码,封装业务关键字层,提供 UI 操作能力
- Case 上层只调用 UI 业务代码关键字
RobotFramework-Browser 介绍
使用的自动化测试框架是 RobotFramework,针对 RF 简单介绍相关知识。若使用 pytest 原理类似。
Browser library powered by Playwright。关键点:new browser、new page 等无需关心资源清理,RF 框架可自动清理,确保资源隔离;自动关联已存在资源和自动启动需要的资源。

