前言
团队将 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 框架可自动清理，确保资源隔离；自动关联已存在资源和自动启动需要的资源。