Playwright Test Agents 与 GUI 自动化测试适用性分析

这次调研围绕一个具体问题展开：已有的截图识别式 GUI Agent、通用 Computer Use、Playwright CLI 和 Playwright Test Agents，哪一种更适合作为 Web 自动化测试项目的基础？

一、研究对象

调研涉及四类方案。它们都能驱动浏览器，但定位并不相同。

方案	核心输入与执行方式	主要定位	在本项目中的角色
视觉 GUI Agent	截图、多模态模型、鼠标键盘操作	模拟真实用户操作	前期方案与视觉兜底能力
Codex Computer Use	截图、界面信息、模型决策、系统输入	通用计算机操作	验证通用视觉执行路线
Playwright CLI	自然语言任务、结构化页面信息、浏览器命令	面向编码 Agent 的浏览器控制	提供稳定且低开销的执行层
Playwright Test Agents	Planner、Generator、Healer 协作	测试规划、生成、执行与修复	更贴合自动化测试完整生命周期

从项目适配度看，Playwright CLI 提供了较完整的浏览器操作能力；Playwright Test Agents 则进一步覆盖测试设计、代码生成和失败修复，更接近最终需要的测试系统。

二、前期方案：视觉 GUI Agent

前期项目 GUIAutoTest_2.0.7 采用截图、多模态模型与 Selenium/Playwright 结合的方式：先让模型理解当前页面，再生成鼠标点击、键盘输入或浏览器操作。

优点

• 操作过程接近真实用户，可以直接处理点击、输入和页面跳转；
• 能覆盖部分难以通过 DOM 或无障碍树稳定定位的界面；
• 适合验证真实桌面环境中的 GUI 行为。

局限

• 依赖持续截图和多模态推理，单步成本与等待时间较高；
• 视觉定位容易受到分辨率、窗口位置和页面变化影响；
• 主要解决“如何执行”，没有自然覆盖测试计划、用例生成、断言和失败修复；
• 需要真实桌面与浏览器环境，不利于批量、并发和 CI 执行。

因此，这条路线更适合作为特殊页面的补充执行能力，而不是 Web 自动化测试主链路。

三、Codex Computer Use：通用视觉操作

Codex Computer Use 的基本循环可以概括为：

1. 接收自然语言任务；
2. 获取截图和可用的界面信息；
3. 由模型判断下一步操作；
4. 使用 UI Automation 或系统输入完成点击、输入等动作；
5. 再次截图并验证结果，必要时继续修正。

这类方案的优势是通用性强，能够用一句自然语言指令驱动浏览器甚至桌面应用，并通过连续观察进行自我纠正。浏览器场景中，也可以根据按钮名称、文本、角色、标签或 CSS 信息定位元素。

但它仍然更像一个通用操作 Agent：模型调用、截图理解和上下文维护会带来额外开销，测试过程也不天然产生规范的测试代码、断言、Trace 和报告。对需要专用领域规则、本地模型或国产化适配的项目，定制成本同样需要单独评估。

可复用的不是某个特定实现，而是“观察—决策—执行—验证”的闭环思路。

四、Playwright CLI：面向 Agent 的浏览器执行层

Playwright CLI 将浏览器能力包装为适合编码 Agent 调用的命令。一次任务可以形成下面的链路：

自然语言测试任务
  → Agent 制订步骤
  → CLI 执行 open / snapshot / click / fill 等操作
  → 返回页面引用、截图、日志、请求和退出状态
  → 生成 Playwright Test、断言、Trace 与测试报告

与持续发送整张截图相比，结构化页面状态能够减少无关视觉信息，通常更适合高频浏览器操作。CLI 返回的日志、退出码、截图和 Trace 也让每一步更容易验证，并可以最终沉淀为可重复执行的测试文件。

它的局限主要位于上层：CLI 本身是执行工具，测试目标是否合理、断言是否充分、失败后如何判断和修复，仍依赖 Agent 的规划与代码能力。如果只观察最终命令，模型的中间判断过程也不一定完全透明。

五、Playwright Test Agents：覆盖测试生命周期

Playwright Test Agents 将任务拆分给三类代理：

Agent	输入	主要产物	职责
Planner	需求、站点和种子测试	specs/*.md	浏览页面、拆分场景、编写测试计划
Generator	测试计划与页面状态	tests/*.spec.ts	生成可执行测试与断言，并实时校验定位器
Healer	失败日志、Trace、现有测试	修复后的测试代码	分析失败原因、修改代码并重新执行

以 163 邮箱登录页为例，工作流可以表示为：

自然语言需求
  → Planner 生成 specs/163-login.md
  → Generator 生成 tests/163-login.spec.ts
  → Playwright 执行并输出 Trace / Report
  → 失败时交给 Healer 分析、修复和重跑

这种拆分降低了模块之间的耦合：测试计划可以人工审阅，生成的 TypeScript 测试可以纳入版本管理，失败修复也只在需要时触发。执行可选择有头或无头浏览器，并有机会接入不同的上层模型。

当前边界也很明确：它主要面向浏览器测试，不等同于能够操作任意桌面软件的视觉 Agent；遇到 Canvas、远程桌面或缺少语义信息的界面时，仍可能需要视觉定位方案补充。

六、建议的完整工作流

完整流程可以拆成四个阶段：

1. 测试规划

输入 Web 应用、需求文档或种子测试，由 Planner 浏览产品并生成结构化测试计划。此阶段重点确认测试范围、前置条件、步骤和预期结果，而不是直接堆叠操作脚本。

2. 代码生成

Generator 根据计划生成 .spec.ts 文件，同时在真实页面中校验定位器和关键交互。生成结果应包含明确断言，而不只是“点击后没有报错”。

3. 执行与修复

运行测试并保存日志、截图、Trace 与 HTML 报告。失败时由 Healer 区分环境问题、定位器失效、等待条件不足和产品缺陷，再决定是否修改测试代码。修复后重新执行，直到通过或确认需要人工处理。

4. 结果沉淀

将稳定的测试代码、计划和报告纳入项目，后续接入 CI/CD。这样得到的是可重复运行的测试资产，而不是一次性的 Agent 操作记录。

七、实际操作记录

调研中对大连理工大学软件学院官网进行了分层测试：

• 第一轮整理 50 条人工测试用例，覆盖页面、导航、搜索、内容、响应式和安全相关检查，共涉及 12 个功能模块；
• 第二轮记录 15 步点击流，并保存 22 张截图与操作日志，用于逐页验证主要导航路径；
• 第三轮构建路由地图与 3 条 E2E 闭环，覆盖搜索、浏览跳转和三种分辨率对比；
• 最终整理出 29 个结果文件，约 27 MB。

另一组实验使用 163 邮箱登录页验证 Agent 产物：Planner 先生成测试计划，Generator 再生成 TypeScript 测试代码；软院官网测试则在有头 Chromium 中执行，并保留浏览器截图日志。

163 邮箱示例的报告显示共执行 10 条测试，10 条通过，未出现失败、波动或跳过项，总用时约 1.1 分钟。截图中可见的场景包括：

• 登录页面加载和基础结构检查；
• 登录容器与关键元素可见性；
• iframe 中的邮箱、密码输入；
• 登录方式切换；
• 表单提交与校验等后续用例。

这些结果能够说明工作流可以跑通，但还不能单独证明它在所有网站、网络环境和业务规则下都同样稳定。后续仍需要扩大样本，并专门统计误修复率、用例有效性、Token 消耗和维护成本。