Playwright + AI：新一代自动化测试框架实战指南-平芜编程栈

1. 为什么 2026 年测试工程师都在学 Playwright + AI

先聊聊我最近的真实感受。传统 UI 自动化测试绕不开 Selenium，但在实际项目里，Selenium 的等待策略、浏览器驱动管理、多标签页处理、网络请求拦截这些环节，写起来繁琐，跑起来不稳定，维护成本还高。尤其到了动态渲染、微前端、多 iframe 这类场景，脚本一多，维护工作量几乎是呈指数级上涨。

这也是 Playwright 能在近几年快速抢占自动化测试市场的原因。

Playwright 是微软开源的新一代自动化测试框架，支持 Chromium、Firefox、WebKit 三大内核，也支持所有基于 Chromium 的现代浏览器。它最大的特点是“面向真实用户场景设计”，把等待机制、移动端模拟、网络拦截、多页面管理等原本需要大量样板代码的能力，内置到框架底层。这意味着你不需要到处写sleep(10)去“猜”页面加载时间，Playwright 会自动等待元素可操作，测试稳定性提升非常明显。

而到了 2026 年，AI 技术对自动化测试的渗透已经不再是概念阶段。Playwright 生态里已经出现了 AI Agent、MCP（Model Context Protocol）等结合方式，AI 可以根据页面结构直接生成测试步骤，或者根据自然语言描述自动生成、修复、执行测试脚本。换句话说，自动化测试的门槛正在进一步降低。

如果你需要快速验证某个 Web 页面的核心流程，又暂时不想写大量代码，Playwright 自带的 Codegen 录制功能几乎就是“零代码”方案。这篇文章会从零开始，带你完成：

Playwright 的完整安装与配置；
使用codegen录制并回放测试，体验零代码生成用例；
Python 与 JavaScript 两种方式编写可维护的自动化脚本；
打通 AI 工具与 Playwright 的调用链路；
梳理常见的报错、坑点以及工程级最佳实践。

本文适合完全没接触过 Playwright 的新手，也适合有 Selenium 经验、想迁移到新框架的测试开发工程师。

2. 环境准备与版本说明

在开始之前，先明确一下本文使用的环境。版本不需要和我的完全一致，关键是搞清楚每个组件的作用。

2.1 基础环境要求

组件	推荐版本/说明
操作系统	Windows 10/11，macOS，或主流 Linux 发行版
Node.js	18.0 及以上（如果使用 JavaScript/TypeScript）
Python	3.9 及以上（如果使用 Python 编写脚本）
浏览器	Playwright 会自动下载 Chromium、Firefox、WebKit
IDE	VS Code 即可，最好安装 Playwright 官方插件

这里需要特别说明一下，Playwright 安装时会默认下载浏览器到本地缓存目录，不需要你手动去装 Chromium。下载可能需要一些时间，如果网络较慢，可以考虑配置国内镜像，后续我会给出具体的配置方式。

2.2 安装 Playwright

安装其实非常简单，核心就两个步骤。如果你更熟悉 Python，可以直接用 pip 安装：

pip install playwright

安装完成后，还需要执行一行命令来下载浏览器内核：

playwright install

这会下载 Chromium、Firefox 和 WebKit 对应的内核。当然，你也可以只下载需要的浏览器，例如只下载 Chromium：

playwright install chromium

如果你使用 JavaScript 技术栈，则在项目目录下初始化 package.json：

npm init -y npm install -D @playwright/test npx playwright install

安装完成后，建议先跑一下版本命令，确认环境没问题：

playwright --version

正常情况下会输出类似Version 1.46.0的内容。如果你的版本比这个新或者旧，不影响本文的实战流程。

2.3 验证安装

验证安装是否成功有很多方式，最简单的就是用 Python 打开一个空白页面并打印标题。先创建项目目录和脚本文件：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto("https://www.baidu.com") print(page.title()) browser.close()

如果环境内部网络策略限制访问国内站点，可以换成任意可访问的测试页面。正常输出类似：

百度一下，你就知道

看到这个输出，就说明 Playwright 已经可以正常驱动浏览器了。

2.4 使用国内镜像加速（可选）

如果你在执行playwright install时下载浏览器非常慢，可以配置环境变量使用国内镜像源：

# Windows PowerShell 临时设置 $env:PLAYWRIGHT_DOWNLOAD_HOST="https://npmmirror.com/mirrors/playwright" # Linux / macOS export PLAYWRIGHT_DOWNLOAD_HOST="https://npmmirror.com/mirrors/playwright"

设置之后再执行playwright install，速度会快很多。

3. Playwright 核心概念与基础用法

很多刚从 Selenium 迁移过来的同学，最容易踩的坑就是把 Playwright 当成 Selenium 的“改进版”来用，最后写出来的代码还是老一套：找元素、加等待、做断言。实际上 Playwright 的使用逻辑完全不同，它把很多浏览器底层能力抽象成了简单 API，代码表达更贴近“用户操作”。

3.1 同步 API 与异步 API

Playwright 提供了sync_playwright和async_playwright两套 API。同步 API 适合大多数测试场景和脚本工具，代码简单易读；异步 API 适合需要并发操作的场景，例如同时监控多个页面。

下面是同步 API 的最小示例：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://example.com") print(page.title()) browser.close()

注意sync_playwright()是一个上下文管理器，它负责管理 Playwright 驱动进程的启动和关闭。用with语句是标准写法，不要自己手动启动后忘记清理。

3.2 定位器（Locator）机制

这是 Playwright 和 Selenium 最核心的区别之一。

Selenium 的经典写法是driver.find_element(By.ID, "kw").send_keys("hello")，你定位到的是一个具体元素。但在 Playwright 中，定位器是一个“指向元素的方式”，元素是否已经渲染、是否可操作，都由框架在操作时自动等待。

来看一个典型的搜索场景：

page.goto("https://www.baidu.com") page.locator("#kw").fill("Playwright 自动化测试") page.locator("#su").click() page.wait_for_timeout(2000) print(page.title())

这里page.locator("#kw")返回一个定位器，.fill()是向输入框填入文本，.click()是点击按钮。整个过程不需要显式等待，Playwright 会在动作执行前自动等待元素出现、可见、稳定。

Playwright 定位器支持多种方式：

定位方式	示例	适用场景
CSS 选择器	`page.locator("#login-btn")`	元素有稳定的 id、class
文本定位	`page.get_by_text("登录")`	按钮、链接等文本内容
角色定位	`page.get_by_role("button", name="提交")`	无障碍语义明确的元素
标签定位	`page.get_by_label("用户名")`	表单输入框
XPath	`page.locator("xpath=//input[@name='user']")`	兼容旧用例

实际项目里，我比较推荐优先使用get_by_role和get_by_text，这类定位方式对页面结构和样式变化不敏感。比如前端把class从btn-primary改成btn-secondary，CSS 定位器就会失效，而文本和语义定位完全不受影响。

3.3 自动等待机制

自动等待是 Playwright 最大的优势，也是很多新手容易忽略的点。

Selenium 需要你手动配置implicitly_wait和WebDriverWait，但 Playwright 的动作执行前会自动执行以下等待逻辑：

元素已附加到 DOM；
元素可见（有尺寸且非display: none）；
元素处于稳定状态（不动画、未过渡）；
元素可接收事件（未被遮挡）；
元素可编辑、可勾选（根据具体动作）。

这意味着，你写的page.locator(".loading-done").click()会自动等待加载完成。但这不代表你的代码完全放弃等待，如果页面上只有一个“加载中”的 spinner，你需要用expect或wait_for_selector等机制等待特定条件出现。

page.wait_for_selector(".data-table", timeout=10000)

这行代码会等待 10 秒钟，直到页面上出现.data-table元素。超时抛出TimeoutError，报错信息里会附上页面当前截图和 DOM 快照，排错非常方便。

3.4 零代码录制：Codegen 的引擎原理

这个工具本质上是 Playwright 内置的浏览器操作录制器和代码生成器。它在你操作页面的同时，把操作翻译成脚本代码。很多人以为它只是“自动生成代码的小工具”，但在 2026 年的视角下，它的价值更值得重新理解：Codegen 其实是为 AI 驱动自动化测试提供了真实的浏览器操作轨迹数据源。

启动 Codegen 只需要一条命令：

playwright codegen https://www.baidu.com

命令执行后会弹出一个浏览器窗口，同时打开一个 Inspector 面板：

上半部分是页面的实时操作预览；
下半部分是自动生成的代码；
你可以选择生成 Python 同步代码、Python 异步代码、JavaScript 代码或 TypeScript 代码；
点击操作页面元素，代码会自动更新。

我强烈建议，即使你打算使用 AI 生成测试脚本，也先花几分钟手工录制一遍核心流程。这样你能直观理解 Playwright 期望的操作粒度：什么时候点击、什么时候填值、什么时候等待。

3.5 录制结果与获取测试代码

假设我录制了以下操作：

打开百度首页；
输入“Playwright 自动化测试”；
点击“百度一下”按钮。

Inspector 面板会生成类似这样的 Python 代码：

from playwright.sync_api import Playwright, sync_playwright def run(playwright: Playwright) -> None: browser = playwright.chromium.launch(headless=False) context = browser.new_context() page = context.new_page() page.goto("https://www.baidu.com") page.locator("#kw").click() page.locator("#kw").fill("Playwright 自动化测试") page.locator("#su").click() page.wait_for_timeout(3000) # --------------------- context.close() browser.close() with sync_playwright() as playwright: run(playwright)

这就是所谓的“零代码”体验。你不需要了解任何 Playwright API 的细节，只需要跑一遍流程，代码就自动生成了。

4. 完整实战：从零搭建自动化测试项目

这一节我们做一个完整的实战练习：使用 Python 构建一个可维护的自动化测试项目，测试一个简单的 Web 页面登录流程。为了避免演示依赖外部环境的稳定性，我会使用 Playwright 官方提供的在线测试站点来演示核心流程。

4.1 创建项目结构

在开始写代码之前，先按工程化的思路规划目录结构。一个整洁的项目结构可以让后续维护容易很多。

ai_playwright_demo/ ├── config/ │ └── settings.py # 配置文件 ├── pages/ │ └── login_page.py # 页面对象模型 ├── tests/ │ └── test_login.py # 测试用例 └── requirements.txt # 依赖管理

这里用到了页面对象模型（Page Object Model, POM），它的核心思想是把页面的选择器和操作封装成类，测试用例只关注业务逻辑，不暴露具体元素。后续页面结构变了，只需要修改对应的页面类，测试用例不用动。

4.2 准备依赖

先创建requirements.txt，内容如下：

playwright==1.46.0 pytest==8.3.2 pytest-playwright==0.5.1

然后安装依赖：

pip install -r requirements.txt playwright install chromium

pytest-playwright是官方插件，它提供了page、browser、context等 pytest fixture，可以直接把浏览器对象注入测试函数，省去自己写启动和清理的逻辑。

4.3 编写配置文件

配置文件的作用是集中管理环境地址、超时时间、测试浏览器类型等参数。config/settings.py内容如下：

# 文件路径：config/settings.py BASE_URL = "https://practicetestautomation.com/practice-test-login/" # 测试账号（仅用于演示环境） USERNAME = "student" PASSWORD = "Password123" # 全局超时时间（毫秒） TIMEOUT = 10000

在这个演示站点上，账号student和密码Password123是可以正常使用的，登录成功后页面会出现 “Logged In Successfully” 的成功提示。实际项目中，你应该把账号密码放到环境变量或专门的配置中心，不要硬编码在代码里。

4.4 编写页面对象

pages/login_page.py封装登录页面相关操作：

# 文件路径：pages/login_page.py from playwright.sync_api import Page class LoginPage: def __init__(self, page: Page): self.page = page @property def username_input(self): return self.page.locator("#username") @property def password_input(self): return self.page.locator("#password") @property def submit_button(self): return self.page.locator("#submit") def goto(self, url: str): self.page.goto(url) def login(self, username: str, password: str): self.username_input.fill(username) self.password_input.fill(password) self.submit_button.click() def is_login_success(self) -> bool: return self.page.get_by_text("Logged In Successfully").is_visible()

这里把定位器封装成类的属性，测试代码调用login_page.login()时不需要关心页面上是#username还是input[name=username]。

4.5 编写测试用例

tests/test_login.py使用 pytest 编写两条测试用例：

# 文件路径：tests/test_login.py import pytest from pages.login_page import LoginPage from config import settings @pytest.fixture def login_page(page) -> LoginPage: login_page = LoginPage(page) login_page.goto(settings.BASE_URL) return login_page def test_login_success(login_page): login_page.login(settings.USERNAME, settings.PASSWORD) assert login_page.is_login_success() is True def test_login_failed(login_page): login_page.login("wrong_user", "wrong_password") assert login_page.is_login_success() is False

第二条约等于是个负向用例，验证错误账号密码登录会失败。为了让断言有实际意义，打开错误提示的文本定位也可以加进去，但考虑到不同站点的提示文案差异较大，这里用成功标识是否可见来判断即可。

4.6 运行与验证

使用pytest-playwright插件运行测试：

cd ai_playwright_demo pytest tests/test_login.py -v

预期输出：

============================= test session starts ============================= platform darwin -- Python 3.10.12, pytest-8.3.2, pluggy-1.5.0 rootdir: .../ai_playwright_demo plugins: playwright-0.5.1 collected 2 items test_login.py::test_login_success PASSED test_login.py::test_login_failed PASSED ============================== 2 passed in 4.3s ===============================

如果你在执行中遇到浏览器闪退、元素定位失败、超时问题，不要急着改代码逻辑。先用 headed 模式跑一遍：

pytest tests/test_login.py -v --headed

匹配关键字运行单条用例：

pytest tests/test_login.py -v -k "login_success"

这样能看到浏览器实际动作，定位问题会非常快。

5. AI 驱动 Playwright：从自然语言到自动化脚本

前面我们完成了 Playwright 的基础实战。接下来进入本文的重头戏：AI 如何与 Playwright 结合。

5.1 AI 自动化测试的几种形态

在 2026 年的技术生态里，AI 与自动化测试结合已经演进出几种比较成熟的方向：

AI 代码生成：根据页面截图或自然语言描述，直接生成 Playwright 脚本；
AI 元素定位增强：在传统定位器不稳定时，通过 AI 识别页面元素并动态修正选择器；
AI 脚本修复：用例失败时，AI 分析失败原因并自动调整定位器或等待策略；
MCP 协议集成：通过 Model Context Protocol，让 AI 直接读取浏览器控制节点、元素上下文，实现更接近人手的操作。

其中，MCP 是目前和 Playwright 结合最紧密的方向。简单理解，MCP 提供了一种标准化的方式，让 AI 模型可以“看到”浏览器里的页面结构、可以操作浏览器控件、可以读取控制台日志，而不是像传统方式那样通过截图给 AI 猜。这相当于给 AI 装上了一双操作浏览器的手。

5.2 Playwright MCP 的接入方式

Playwright 官方已经提供了 MCP 服务端支持。你可以在 Node.js 环境中安装官方 MCP 包：

npm install -D @playwright/mcp

启动 MCP 服务：

npx @playwright/mcp@latest

启动后，该服务会成为一个 MCP Server。Claude Desktop、Cline、或其他支持 MCP 的 AI 编程工具都可以连接它，从而获得以下能力：

打开浏览器页面；
读取页面的可访问性快照（a11y snapshot）或 DOM 快照；
点击、输入、滚动、键盘操作；
读取网络请求和响应；
执行 Playwright 定位器查询。

需要注意的是，MCP 相关包和协议版本迭代非常快，上面的命令和用法需要以官方文档为准。但整体思路是不变的：通过标准协议让 AI 模型具备操作真实浏览器的能力。

5.3 利用 AI 工具生成 Playwright 脚本的通用思路

就算暂时不方便接入 MCP，你同样可以用现有 AI 编程助手来提高写 Playwright 脚本的效率。我的经验是遵循下面这个流程：

先手工用 Codegen 录制一遍目标流程，拿到一份可靠的基础脚本；
将页面结构的关键信息（比如表单元素的 id 或 name）提交给 AI，让它生成更结构化的代码；
用页面对象模式组织 AI 生成的结果，而不是让 AI 把整个流程写成一个大的脚本函数；
把 AI 生成的脚本接入 pytest 运行，根据报错信息回到第 1 步继续修正。

这个流程的核心思想是“AI 负责生成，你负责结构”。AI 可能会给出 80% 正确的代码，但剩下的 20%，包括超时处理、异常分支、数据清理，必须由人来把关。

5.4 一个 AI 辅助生成的示例

假设我向 AI 描述需求：

“帮我写一个 Playwright 脚本，打开演示登录页面，输入用户 student，密码 Password123，点击登录，断言页面出现 Logged In Successfully 文本。”

AI 可能会生成类似下面的代码：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://practicetestautomation.com/practice-test-login/") page.fill("#username", "student") page.fill("#password", "Password123") page.click("#submit") page.get_by_text("Logged In Successfully").wait_for(timeout=10000) print("登录成功") browser.close()

这段代码的质量已经介于“能跑”和“工程可用”之间，但缺少异常处理、资源释放、日志记录和参数化配置。所以我的建议是，让 AI 生成“核心逻辑片段”，再由你按照工程规范组织成完整项目。

5.5 企业级 AI 自动化测试平台搭建趋势

从热词和数据趋势来看，2026 年很多测试团队已经不满足于“用 AI 生成脚本”，而是开始搭建企业内部的 AI 自动化测试平台。常见的架构可以简化为三层：

层级	职责	常用技术
管理层	用例管理、调度、报告、告警	TestOps 平台、自研 Web 系统
AI 层	自然语言生成脚本、失败智能分析、自动化修复	大模型 API、MCP、向量检索
执行层	浏览器自动化执行、沙箱环境	Playwright、Docker、K8s

如果你所在团队准备往这个方向探索，我建议不要一开始就追求大而全的平台，而是先跑通一条核心链路：

测试人员用 Codegen 或 AI 快速录制用例；
用例自动保存到 Git 仓库；
CI 环境使用 Docker 拉取 Playwright 镜像并执行；
失败任务自动收集截图、视频和日志，喂给 AI 分析失败原因；
AI 给出修复建议或直接生成修复后的代码，测试人员人工确认。

这条链路覆盖了一个自动化项目运行的核心环节，每一步的技术难度都可控，值得作为团队起步的路线图。

6. 常见问题与排查思路

任何自动化框架在落地过程中都会遇到各种问题。这里整理了我自己用 Playwright 时碰到的高频问题，以及排查思路。

6.1 常见报错表格

问题现象	常见原因	解决思路
`Executable doesn't exist`	Playwright 浏览器未安装	执行`playwright install chromium`
`TimeoutError`	元素未出现或选择器错误	检查选择器，适当调大 timeout，用 headed 模式观察
`Element is not attached to the DOM`	页面跳转或元素被重新渲染	重新获取定位器，避免保存过期元素引用
`Page.goto: net::ERR_CONNECTION_REFUSED`	地址不可访问或服务未启动	确认被测服务已启动，检查网络策略
`Target page, context or browser has been closed`	浏览器被提前关闭	检查上下文管理器内的代码缩进
中文输入乱码或丢失	输入法干扰	尽量通过 Playwright 的`fill`方法，避免系统级输入事件；必要时设置`headless=True`运行
测试脚本在 CI 中闪退	Docker 缺少系统依赖	使用官方镜像`mcr.microsoft.com/playwright`

6.2 定位元素失败的排查步骤

如果你点击或填充元素时一直报超时，可以按下面顺序排查：

手动在浏览器控制台验证选择器：document.querySelector("#id")是否为 null；
使用 Codegen 重新录制，确认实际选择器；
打开浏览器调试模式，用page.locator("...").count()查看匹配个数；
确认元素是否在 iframe 内，如果在 iframe 内需要使用frame_locator；
确认页面无遮挡层（比如 loading 遮罩、Cookie 弹窗），必要时先关闭弹窗；
检查是否存在多个相似元素，使用.first()或.nth(index)精确匹配。

6.3 关于动态加密与反自动化检测

这部分要特别谨慎，也是一个最容易走偏的话题。在搜索热词中，和“过瑞数”“反检测”相关的内容出现过，但我想明确一下工程实践中的正确边界。

真正的企业级自动化测试，不应当把“绕过反爬机制”当作核心技术目标。如果你的被测系统是自己的业务系统，那么反自动化检测通常不会成为主要障碍；如果被测系统是第三方站点，那自动化测试本身可能需要考虑合规性。

更值得做的事，是在自己的测试环境中关注以下方向：

使用 CDP（Chrome DevTools Protocol）协议处理复杂的网络请求拦截和模拟；
使用 Playwright 的context.add_init_script在页面加载前注入测试需要的环境变量或 mock 数据；
处理验证码和滑动验证时，优先与开发沟通加测试后门，而不是费时费力地破解。

把精力投入到测试数据管理、环境稳定性和用例可维护性上，对团队的长期价值远大于研究如何绕过反爬机制。

7. 最佳实践与工程化建议

自动化测试真正带来价值，靠的不是写几个能跑的脚本，而是建立一套稳定、易维护、可扩展的工程体系。下面几条建议来自我多个项目的实际经验，希望对你有参考价值。

7.1 在自动化测试中关注动态内容与条件渲染

自动化测试项目最怕的就是“测试环境太完美”。很多团队在测试环境从不做埋点假上报、关注用户协议弹窗、低频活动页浮层校验、登录态有效期模拟，于是自动化用例跑得很好，一上生产/灰度环境就大面积失败。

建议在测试数据构造层面主动覆盖这些动态内容：

构造不同的服务端返回状态码；
模拟登录态过期、Token 失效、会话被踢；
生产或类生产环境，主动注入 A/B 实验参数和灰度开关配置；
用条件化用例编写方式，做到“同一套用例，多种环境可跑”。

7.2 使用 Trace Viewer 与可视化排查

Playwright 提供了强大的 Trace Viewer。你可以在测试中开启 trace 记录，失败时自动保存整个操作过程：

context = browser.new_context( record_video_dir="videos/", trace="retain-on-failure" )

或者通过 pytest-playwright 插件的配置：

pytest tests/test_login.py --tracing=retain-on-failure --video=retain-on-failure

这样失败用例会自动生成操作录屏和 trace 文件，排错时可以精确看到每一步的执行时间和 DOM 状态。

7.3 测试数据与用例隔离

自动化用例之间必须相互独立，不依赖执行顺序。每个用例启动前，都应该有明确的前置数据构造方案。最稳妥的做法是使用 API 直接创建测试账号或测试数据，而不是通过 UI 一步步操作前置流程，这既浪费执行时间，也让用例耦合严重。

def test_order_flow(page): # 通过 API 创建测试订单，返回订单号 order_id = create_order_via_api() # 通过 UI 执行操作 page.goto(f"/orders/{order_id}") # 断言页面内容 expect(page.locator(".order-status")).to_have_text("已支付")

7.4 失败重试与告警

稳定性是自动化测试的生命线。建议在 CI 中配置一级重试和智能跳过：

pytest tests/test_login.py --reruns=1 --only-rerun="TimeoutError"

这里的--reruns需要安装pytest-rerunfailures插件。重试策略要谨慎，只对超时等环境类错误重试，而断言失败必须直接暴露，否则会掩盖真实的业务问题。

7.5 安全边界与最小权限

在企业落地自动化测试时，需要注意账号权限的最小化。给自动化测试配置的登录账号，只授予测试环境所需的最小权限，不要使用管理员账号执行普通用户用例。涉及敏感数据的用例，不要在无痕模式下随意存储页面截图，尤其是包含用户个人信息、手机号、身份证号信息时，需要脱敏后再上传到 CI 报告系统。

7.6 从 DevOps 角度看待 Playwright 的集成

Playwright 团队目前提供的官方 Docker 镜像已经非常成熟，建议直接使用：

FROM mcr.microsoft.com/playwright:v1.46.0-jammy WORKDIR /app COPY . /app RUN pip install -r requirements.txt CMD ["pytest", "tests/", "--headed", "--browser=chromium"]

这个镜像中自带所有浏览器依赖和系统库，可以显著减少 Dockerfile 的维护工作量。在 CI 平台上，只需要拉取镜像、挂载代码目录、执行测试命令即可完成一次测试任务。

7.7 使用`/auth`或存储状态的方式处理登录态

如果大量用例都需要登录后才能执行，每次都走一次 UI 登录流程会非常浪费执行时间。这时可以用存储状态（storage state）的方式：

# 第一次登录并保存状态 context.storage_state(path="state.json") # 后续用例直接使用 context = browser.new_context(storage_state="state.json")

这个技巧可以减少大量登录耗时，但要注意 token 过期问题，需要配合合理的有效期控制机制。

8. 常见 AI + Playwright 组合的落地框架

如果你所在的团队已经有 AI Agent 或类似系统，可以考虑将 Playwright 定位为 Agent 的“浏览器双手”。这里给一个简化的架构说明：

自然语言需求（测试人员） ↓ AI Agent（负责意图理解、代码生成、失败修复） ↓ Playwright Test Runner（负责实际浏览器执行） ↓ 浏览器渲染与网络请求（被测系统） ↓ 测试报告与失败数据（返回 AI Agent 分析）

这套架构中的每个环节都可以逐步替换成更成熟的组件。例如 AI Agent 可以从简单的 OpenAI API 调用，逐步演进为具备工具调用能力、上下文检索能力的完整 Agent 系统；执行层也可以从单机运行演进为 Docker Swarm 或 Kubernetes 集群执行。

但无论架构如何演进，核心思想是一致的：AI 负责降低自动化用例编写和排查的门槛，Playwright 负责提供稳定、跨浏览器、可观测的执行底座。

9. 总结与下一步行动

从最早的 Selenium 手动定位元素，到 Playwright 的自动等待和 Codegen，再到 MCP 协议下 AI Agent 直接操作浏览器，自动化测试的门槛一直在快速下降。本文我们完成了 Playwright 的安装、零代码录制、Python 工程化项目搭建、AI 层的接入思路，以及常见问题和工程最佳实践。

你可以按照自己的方向选择下一步行动：

如果完全没接触过 Playwright，先打开终端执行playwright codegen，录制自己的两个核心业务用例；
如果想往 AI 方向深耕，研究 MCP 协议以及 Playwright MCP 的接入方式，尝试让 AI 帮你完成一次端到端测试；
如果关注团队效能提升，优先把 Codegen + Trace Viewer + CI 报告这条链路跑通，这是投入产出比最高的一步。

写自动化测试的真正价值，不是为了替代人工，而是把重复、机械、易出错的验证工作交给机器，让人把精力集中在业务理解、异常分析和系统质量提升上。Playwright 是完成这个目标的优秀工具，值得每一个测试开发工程师掌握。