E2E 测试对于广大 Web 开发者来讲并不陌生，由于它能贯穿整个应用的使用流程，因而能最大程度地模拟用户的真实操作，从而发现更多潜在的问题。但在实践中，它往往是最被忽视的测试环节，原因也很简单：脆弱且难以维护。
之所以脆弱，是因为它往往跟 UI 是紧耦合，而此部分却是最容易变动的。由此，也造就了它难以维护的特性。Playwright 虽然在一定程度上缓解了这一问题，但由于它依然依靠脚本（其本身的柔韧性天生就不足）来描述测试流程，因而也难以从根本上解决这个问题。
因此，典型的 E2E 测试大多采用以下方式之一：
- 机动性手动测试，大多是临到重要发布时才会进行
- 仅选取若干关键流程的自动化测试
- 以上两者结合：关键流程自动化，其他机动性手动测试
阔是，现在已经是被业内人士称为“agent 元年”的 2025 了，我们是否能够转变一下思路呢？前文提到：将 LLM 视为“人”而非工具，那么我们是否可以考虑直接让 LLM 或 Agent 来执行 E2E 测试呢？如同我们招了一个好使唤的测试小弟。
请注意：这里是让 LLM/Agent 来执行测试，而非生成测试脚本，这是根本区别。为何：
- 生成测试脚本依旧没有摆脱脚本的桎梏，它依旧需要大量的人工参与：检查脚本的正确性、维护脚本、更新脚本等。本质上只是相当于在原有基础上开了 2 倍速。
- 而直接让 LLM/Agent 来执行测试，则完全摆脱了僵化的脚本，转而使用自然语言来描述测试流程。这样一来，测试流程的编写和维护就变得非常简单，甚至可以直接由产品经理或测试人员来完成，而不需要开发人员的参与。
如此一来，自然语言成了新的测试脚本，你甚至可以直接将其纳入你的版本库，待成熟之后，集成进入 CI/CD 流程中。
从技术上来讲，目前已经完全没有问题：agent + playwright mcp server 便可以轻松实现这一目标。
整个流程大致如下：
- 编写生成测试计划的 prompt。
- review 生成的测试计划，它本身也相当于一个 prompt，未来要传给 agent 执行。
- 运行测试计划得到测试报告。
整个过程就是传说中的左脚踩右脚神功：“纵云梯”，用 prompt 生成 prompt，然后再用 prompt 来驱动 agent。
实践演示
以下是一个生成测试计划的 prompt：
生成一个 Web 的测试计划，这个计划将用于指导 AI 使用 Playwright MCP Server 完成测试，即这个测试计划本身就是一个要提供给 AI 的 prompt。
## 测试网站的基本功能
1. **网站地址**： http://localhost:4321
2. 它是一个基于 Astro 的项目，能够展示 Articles、Cards 同时在首页右上方还有搜索功能。
3. Articles、Cards 都有自己的 tag，可以通过点击 tag 进行筛选。
4. Cards 有翻转功能，点击 Card 可以翻转查看背面内容。并且，Cards的详情页会列出随机的相似卡片。
基于这些信息，生成一个测试计划保存在项目目录下，文件名格式： `test-plan-${yyyy-MM-dd-hh-mm}.md`。其格式如下：
---
# 测试计划 - ${yyyy-MM-dd-hh-mm}
## 测试指令
{此处填写测试指令，告诉 agent 使用 playwright mcp server 进行测试}
## 测试用例
{基于上面的功能描述，生成测试用例。按照任务项目组织，方便 agent 跟踪，每个测试用例都要有明确的预期结果}
## 测试报告
{告诉 agent 如何生成测试报告，对于每个测试用例，成功与否都要记录结果，失败的测试用例记录截图和日志}
---
生成的测试计划示例（注意：需要 review ！！！只有在 前面的 prompt 非常成熟稳定之后，此步骤才能减弱）：
# 测试计划 - 2025-09-30-17-05
## 测试指令
你是一个专业的 Web 测试工程师，需要使用 Playwright MCP Server 对网站进行自动化测试。
**测试目标网站**：http://localhost:4321
**测试要求**：
1. 使用 Playwright MCP Server 提供的工具进行测试
2. 按照测试用例顺序执行每个测试
3. 对每个测试用例记录执行结果（成功/失败）
4. 失败的测试用例需要截图并记录详细错误信息
5. 在测试过程中使用 `browser_snapshot` 获取页面状态，使用 `browser_click`、`browser_type`、`browser_navigate` 等工具进行交互
6. 每个测试用例执行前先导航到相应页面
7. 测试完成后生成完整的测试报告
**工具使用指南**：
- `browser_navigate`: 导航到指定 URL
- `browser_snapshot`: 获取页面的可访问性快照，用于查看页面元素
- `browser_click`: 点击页面元素
- `browser_type`: 在输入框中输入文本
- `browser_take_screenshot`: 截图保存（失败时使用）
- `browser_wait_for`: 等待页面元素出现或消失
## 测试用例
### 任务 1：首页基本功能测试
#### 测试用例 1.1：验证首页加载
- **描述**：访问首页并验证页面正常加载
- **步骤**：
1. 导航到 http://localhost:4321
2. 获取页面快照
3. 验证页面标题或主要内容元素存在
- **预期结果**：页面成功加载，显示首页内容，包含 Articles 和 Cards 相关内容
...
## 测试报告
### 报告生成要求
在完成所有测试用例后，请生成一份详细的测试报告，包含以下内容：
#### 1. 测试概览
- 测试执行时间
- 测试总数
- 通过的测试数量
- 失败的测试数量
- 通过率
#### 2. 测试结果详情
对于**每个测试用例**，记录以下信息：
**成功的测试用例**：
- 测试用例编号和名称
- 状态：✅ 通过
- 执行时间
- 简要说明
**失败的测试用例**：
- 测试用例编号和名称
- 状态：❌ 失败
- 失败原因（详细错误信息）
- 失败时的截图文件路径
- 相关日志信息
- 建议修复方案
#### 3. 测试环境信息
- 测试网站 URL
- 浏览器类型和版本
- 测试执行时间
- 操作系统
#### 4. 总结和建议
- 主要发现的问题汇总
- 严重程度分类（严重/中等/轻微）
- 改进建议
- 下一步测试计划建议
#### 5. 截图管理
- 所有失败测试的截图保存在项目目录下的 `test-screenshots/` 文件夹中
- 截图命名格式：`test-case-{编号}-{时间戳}.png`
- 在报告中提供截图的相对路径引用
### 报告格式
测试报告以 Markdown 格式保存，文件名：`test-report-2025-09-30-17-05.md`
报告模板结构：
...生成的测试报告示例：
完整演示视频
