10 年测试老兵的实战经验：Playwright + AI 辅助开发，脚本编写效率提升 3-4 倍。不谈概念，只聊哪些环节 AI 真的能帮你，哪些环节别指望它。
最近接手了一个监控平台的 E2E 自动化测试项目——12 个功能模块、近 100 个测试用例、覆盖云原生数据接入（Prometheus、InfluxDB、OpenTelemetry、OpenTSDB）等复杂场景。
按以前的做法，一个数据接入流程的测试脚本要写 2-3 个小时。但这次，我全程用 AI 辅助开发（Playwright + Claude Code），单个脚本降到了 30-45 分钟。
这篇文章不谈概念，只聊实战：哪些环节 AI 真的能帮你，哪些环节你别指望它。
背景：这个项目有多复杂
先说挑战，不然效率提升的数字没有体感：
- 多租户 SaaS 架构：登录后还要切租户，级联菜单操作，偶尔还会切换失败
- Ant Design 组件：DOM 层级深、class 名动态变化、选择器定位是噩梦
- 长表单流程：一个数据接入要填 7-8 个字段、选下拉框、切 tab、等异步加载
- 数据源种类多：Prometheus、InfluxDB、OpenTelemetry、OpenTSDB，每种接入流程不一样
以前写这种脚本，大部分时间不是在写逻辑，而是在 DevTools 里反复试选择器、调等待时间、处理异步。
AI 实际帮了什么：四个环节逐个说
环节一：脚本生成（效率提升最大）
这是 AI 最能发力的地方。
我的做法：把操作流程用自然语言描述清楚，让 AI 生成 Playwright 脚本初稿。
比如我会说：
我需要测试 InfluxDB 数据接入，操作流程：
1. 进入云原生数据接入页面
2. 点击"新建接入"
3. 选择数据源类型为 InfluxDB
4. 填写连接信息（地址、数据库名、用户名密码）
5. 点击"测试连接"，等待成功提示
6. 点击"确认创建"
7. 验证列表中出现新创建的接入
页面用 Ant Design，请用 Playwright CommonJS 格式
AI 给出的初稿，80% 以上的代码是直接可用的。我需要做的是：
- 微调几个选择器（AI 猜的 class 名可能不对）
- 补充异步等待（AI 倾向于用
waitForTimeout，实际要用waitForResponse） - 加业务相关的断言
环节二：选择器定位（最烦的活）
做过 Ant Design 项目自动化的人都知道，选择器是最头疼的部分。
以前的流程：打开 DevTools → 找元素 → 试选择器 → 发现不唯一 → 换一个 → 再试……
现在我会直接告诉 AI：
页面上有一个 Ant Design 的级联选择器（Cascader），
我需要选择"租户A"，
请给我 3 种定位策略
AI 会同时给出 XPath、CSS、Role-based 三种方案，我挑一个最稳的用。遇到动态 DOM，它还会主动建议加 waitForSelector 或重试逻辑。
省的不是写代码的时间，是试错的时间。
环节三：调试与修复（最意外的收获）
这个环节我没预期 AI 能帮这么多。
以前用例跑失败了，流程是：看报错 → 猜原因 → 改代码 → 再跑 → 还是挂 → 再猜……
现在我直接把报错贴给 AI：
这个用例报错了：
TimeoutError: locator.click: Timeout 30000ms exceeded.
waiting for locator('.ant-cascader-menu-item').filter({ hasText: '租户A' })
测试代码是：
await page.locator('span', { hasText: "新建接入任务" }).first().click();
const modal = page.locator('.ant-modal-content');
await modal.waitFor({ state: 'visible', timeout: 8000 });
AI 不仅能定位问题（比如"级联菜单可能还没展开就去点了子项"），还能给出修复方案（"先等 .ant-cascader-menus 出现，再操作"）。
尤其是 flaky test——以前处理手段就是加 sleep 然后祈祷。现在 AI 能分析时序问题，建议用 waitForResponse 或 page.waitForFunction 等更优雅的方案。
环节四：基础设施设计
项目里有一个核心认证模块，一行代码搞定登录 + 租户切换：
// 一行代码完成：导航 → 登录 → 租户切换 → 保存登录态
await setup(page, context, { tenant: "租户A" });
这个模块的架构设计，AI 参与了：
- 封装思路（一站式 setup 函数）
- 重试机制（租户切换失败自动重试 3 次）
- 状态管理（登录态持久化，避免重复登录）
架构思路是 AI 给的，具体的登录页判断逻辑和租户切换细节是我根据实际系统调的。
AI 做不好什么：别神化它
用了两个月，也踩了不少坑，这几件事 AI 真的帮不了你：
1. 测试策略——该测什么、不该测什么
AI 可以帮你把 100 个用例都写出来，但它不知道哪 20 个是核心场景，哪些是浪费时间。这个判断需要你了解业务、了解风险分布。
2. 企业内部系统的认证和权限
你的 SSO 登录页长什么样、多租户怎么切换、Cookie 策略是什么——这些 AI 都不知道，必须你来处理。
3. 业务语义
AI 能帮你填表单，但它不知道"数据源名称"该填什么才有测试意义，不知道哪个下拉选项对应什么业务含义。
4. 最终的稳定性调优
AI 能给建议，但稳不稳定得反复跑才知道。这一步没有捷径。
5. 环境差异
多租户、多环境（预发/灰度/生产）的差异，需要你了解环境特点才能处理。
方法论：AI 辅助 E2E 测试的四步法
做完这个项目后，我提炼了一套协作模式：
第一步：需求 → 用例
人：定义测试范围和优先级
AI：辅助生成用例清单，查漏补缺
第二步：用例 → 脚本
人：描述页面交互流程
AI：生成脚本初稿
人：调试通过、补充断言
第三步：失败 → 修复
AI：分析报错，给出修复建议
人：验证修复、判断根因
第四步：维护 → 优化
AI：建议稳定性策略
人：决策是否采纳
一句话总结：AI 做执行层的加速，人做决策层的把控。
三个实用 Prompt 模板（拿去就能用）
生成测试脚本：
我需要测试 [功能名称]，页面 URL 是 [xxx]
操作流程：1. xxx 2. xxx 3. xxx
验证点：xxx
请用 Playwright 生成测试脚本，使用 [你的模块格式]
修复失败用例：
这个测试用例报错了：[贴报错信息]
测试代码是：[贴相关代码]
请分析失败原因，给出修复方案
优化选择器：
这个元素用 [当前选择器] 定位不稳定
页面使用 [UI 框架名]
请给出 3 种更稳定的替代选择器
最终成果
| 指标 | 数据 |
|---|---|
| 功能模块覆盖 | 12 个 |
| 测试用例数 | 96 个 |
| 脚本编写效率 | 提升 3-4 倍 |
| 调试效率 | 提升 2-3 倍 |
| CI/CD | 已集成，自动执行 |
写在最后
AI 不会取代测试工程师，但会取代不会用 AI 的测试工程师。
关键不是 AI 有多强，而是你能不能找到「人机协作」的正确姿势——把重复劳动交给 AI，把判断和决策留给自己。
后续会持续分享 AI + 测试的实战经验、方法论和工具链。如果你也在做类似的探索，欢迎关注交流。
更多 AI + 测试实战，关注公众号「测试进化论」—— 测试不会消失，只会进化。
