Playwright AI智能体：Web自动化测试自写自修自断言

一、很多人已经开始慌了：测试脚本还没写稳，AI就能自己修了
二、本质变化：从“人写脚本”变成“人定目标，AI执行闭环”
三、核心机制拆解：Agent怎么感知、推理、操作、修复
四、典型案例对比：一个登录框，暴露了两个时代
五、工程落地启示：你的角色不再是写代码的人
六、留给你的一个问题

一、很多人已经开始慌了：测试脚本还没写稳，AI就能自己修了

过去三个月，至少被问了二十次同一个问题。

“你搞自动化的同行，有没有感觉到AI在逼近？”

不是问会不会被取代，而是问——已经开始疼了没有。

疼在哪？
以前写Playwright脚本，最耗时的不是断言，是定位器。今天这个按钮的id还是loginBtn，明天上线就变成了el-button-66。你还没跑完一轮回归，UI已经改了两次。维护成本高到团队里没人愿意碰老旧用例。

而今年，AI Agent这个概念从ChatGPT插件一路烧到了测试领域。

不是那种“帮你生成几行样板代码”的玩具。
是真正的：你说一句“测试登录失败场景”，Agent自己去打开页面、输入账号、点按钮、捕获错误、断言提示文案——并且，如果定位器失效，它会自己重新分析DOM，自己修。

很多人开始意识到：
我们过去引以为傲的“脚本编写能力”，可能不是未来的护城河。

二、本质变化：从“人写脚本”变成“人定目标，AI执行闭环”

这件事的本质，不是多了一个代码生成器。

核心在于反馈闭环的所有权发生了转移。

传统自动化测试的闭环是这样的：

人看需求 → 人写脚本 → 人运行 → 人看报错 → 人改定位器 → 人维护

每一个反馈节点，都要人介入。

而AI Agent模式下的闭环变成了：

人给目标 → Agent执行 → Agent发现定位失效 → Agent重新分析DOM → Agent生成新定位器 → Agent重试 → Agent断言结果 → Agent继续下一步

中间不需要人停下来。

什么叫“自己写、自己修、自己断言”？

自己写：根据自然语言指令，自动生成Playwright操作序列。
自己修：执行时报NoSuchElementError，Agent拿到页面快照，重新推理正确选择器。
自己断言：不靠硬编码预期文本，而是根据上下文语义判断是否符合目标。

这是三层能力的叠加。

能做到这一点的前提，不是某个大模型足够强，而是Playwright提供了足够可靠的底层控制能力 + Agent架构把“感知-决策-执行”串成了闭环。

三、核心机制拆解：Agent怎么感知、推理、操作、修复

直接给代码前，先讲清楚架构。

下图是这个Agent的核心工作流：

拆开讲三个关键机制。

机制一：感知层不是只看页面，而是看结构

Agent拿到的不是截图，是Playwright返回的DOM元素可交互性快照。
哪个元素可点击、哪个输入框当前focused、哪个button被disabled——这些信息比视觉更重要。

本质上，Agent在做的事情是：把页面的结构状态，压缩成一个大模型可以推理的中间表示。

机制二：修复不是瞎猜，是基于失败信息的定向重推理

传统脚本失败，你看到的是TimeoutError: waiting for selector "button:has-text("登录")"。

Agent看到的是：

1. 定位器失败
2. 当前页面里还有哪些文本接近“登录”的按钮
3. 重新构建选择器，比如button >> text=Sign in或[data-testid=login]
4. 验证新定位器是否唯一且可交互

这不叫“智能”。这叫把工程师的排错流程显式编码进了循环。

机制三：断言从“文本匹配”升级为“目标达成判断”

传统断言：expect(page.locator('.error')).toHa veText('密码错误')

AI断言：执行完操作后，问自己——“当前页面状态，是否符合用户原本说的‘登录失败’这个目标？”

实现方式不是让大模型读整个页面，而是提取关键语义节点：错误提示、URL变化、弹窗出现、输入框高亮等。把这些作为证据链，交给模型判断。

四、典型案例对比：一个登录框，暴露了两个时代

拿最常见的登录测试说事。

传统Playwright脚本写法

await page.goto('https://example.com/login')
await page.fill('#username', 'test')
await page.fill('#password', 'wrong')
await page.click('button:has-text("登录")')
await expect(page.locator('.error-message')).toHa veText('用户名或密码错误')

问题在哪？
一周后，开发把#username改成了input[name="user"]，把.error-message改成了.el-message--error。
脚本全崩。你花十五分钟定位，十分钟改完，还要提PR。

Agent驱动的方式

你只给一句指令：

测试登录失败场景：用test账号，错误密码，确认看到错误提示。

Agent内部自动完成：

# Agent自动生成的第一版
page.goto("/login")
page.fill("#username", "test")
page.fill("#password", "wrong")
page.click("button:has-text('登录')")
# 断言失败：未找到.error-message

# 修复阶段
dom = page.content()
新定位器 = llm.推理(dom, "找一个显示错误信息的元素，可能是el-message、alert、或红色文本")
page.wait_for(新定位器)
assert "错误" in page.text_content(新定位器)

整个过程，你不用改一行代码。
即使UI变了，只要错误提示的语义没变，Agent就能自适应。

这就是两个时代的区别：
一个依赖选择器稳定性。一个依赖语义稳定性。

五、工程落地启示：你的角色不再是写代码的人

看到这里，如果你是一个中级工程师，最应该问的不是“这个Agent怎么写”，而是我的工作内容会变成什么。

给出三个判断。

判断一：定位器知识正在贬值

过去会写复杂XPath、会调CSS选择器，是一项硬技能。
未来，这项技能会变成Agent的基础能力，就像现在的排序算法不需要你手写快排一样。

你真正要掌握的，是如何描述目标、如何设计验证闭环、如何处理边缘情况。

判断二：自动化的瓶颈从“写脚本”变成了“定规则”

Agent很强，但它不知道什么场景该断言、什么错误可以忽略、什么操作顺序业务上不允许。

这些规则，需要你以“测试策略”的方式注入。

举个例子：
不是告诉Agent“点那个按钮”。
而是告诉它“在提交订单前，如果库存不足，应该停在当前页并显示提示”。

你从编写者，变成了设计者。

判断三：在校生和初级工程师，现在是最好的上车时机

因为老一代工程师的经验（各种定位器技巧、等待策略的细微差别）不再是壁垒。
新的壁垒是：你会不会使用Agent框架、会不会设计LLM的上下文、会不会评估模型输出的可靠性。

这些东西，学校和培训班还没教。
谁先摸清楚，谁就是下一批“资深”。

六、留给你的一个问题

看完这篇文章，不问学会没有。

问一个更实际、更扎心的问题：

你现在的自动化测试体系，如果去掉所有硬编码选择器，改为让Agent在运行时动态推理定位——它能存活超过三个迭代版本吗？

如果答案是“不能”，那问题不在Agent，不在Playwright。
在你当前的测试设计里，有没有真正的反馈闭环。