用 Playwright + Claude Code 做自动化测试:一套从0到1跑通的实战流程

11 阅读5分钟

最近有同学问我一个问题: “现在越来越多公司的校招测开岗开始关注 AI 使用能力,我需要准备到什么程度?”

先说一个更现实的结论:
AI 使用能力正在成为加分项,但还远没到“不会就没机会”的程度。

企业更看重的,依然是你对测试的理解,以及把事情做成的能力。

这篇文章不讲概念,我把自己最近一套跑通的流程分享出来:
用 AI 辅助写自动化测试,从能生成代码,到能稳定跑起来,中间到底经历了什么。

为什么是 Playwright + Claude Code

不是因为它们“最先进”,而是更适合当前阶段的实践

Playwright 的特点是接口设计比较语义化,比如点击、输入、等待这些操作本身就比较直观,这对 AI 生成代码是有帮助的。

Claude Code 的优势在于,它不仅依赖 prompt,还可以读取项目中的代码结构。这一点很关键—— 相比只基于描述生成代码,有上下文的生成更接近真实项目

不过需要注意: 它并不能“完全理解你的业务”,关键约束仍然需要你补充。

第一步:先让 AI 理解你的项目(很多人会忽略)

一开始我直接让 AI 写脚本,结果基本不可用。 后来补了一步:在项目里加一个说明文件,让 AI 知道基本约束。

比如在根目录放一个 CLAUDE.md,写清楚:

## 项目信息
- 前端:React + TypeScript
- 测试框架:Playwright
- 测试目录:tests/e2e/
- Base URL:http://localhost:3000

## 测试规范
- 使用 Page Object 模式
- 优先使用 data-testid
- 每个测试文件对应一个功能

这一步不复杂,但效果很明显: 后面生成的代码,结构和风格都会更接近你的项目。

第二步:把测试场景说清楚,而不是让 AI 猜

一个常见问题是,描述太模糊,比如:

“写一个登录测试”

这种输入,AI 只能生成“看起来像测试”的代码,但很难直接用。

如果换成这样:

  • 访问登录页
  • 输入用户名和密码
  • 点击登录
  • 校验跳转结果
  • 再补充异常情况(密码错误、空提交)

你会发现生成结果明显更可用。

本质上,这一步不是在“写 prompt”, 而是在做测试用例设计

第三步:代码生成之后,一定要做 Review

AI 可以帮你写初稿,但质量控制还是要靠人。

我自己主要会看这几块:

选择器是否稳定
AI 常用 class 或 id,但这些容易随样式变化失效。
更推荐 data-testid 或 Playwright 提供的定位方式。

等待策略是否合理
如果看到固定时间等待(比如 waitForTimeout),基本需要调整。

断言是否完整
不仅要判断元素是否存在,还要验证内容和状态。

测试是否独立
避免用例之间存在隐式依赖(例如默认已登录)。

第四步:运行和调试(这是必经过程)

第一次执行失败是正常的。

常见问题包括:

  • 选择器不匹配
  • 页面未加载完成就开始操作
  • 测试数据不符合预期

一个比较实用的做法是: 把报错信息交给 Claude Code,让它一起参与修改。

通常几轮下来,可以把用例稳定下来。

第五步:接入 CI,让测试真正有价值

当脚本可以稳定运行后,可以考虑接入 CI 流程,例如:

e2e-tests:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npx playwright install --with-deps
    - run: npx playwright test

需要说明的是:
CI 中的测试不一定“永远稳定”,
实际项目中会存在波动(flaky test),目标是逐步提高稳定性,而不是追求绝对 100%。

三个常见问题(踩坑总结)

1. 选择器过于脆弱
使用 class 或 id 容易受页面改动影响,建议统一规范。

2. 测试之间有依赖
应保证每个测试可以独立执行,通过 beforeEach 处理前置条件。

3. 忽略加载时序
操作前应确认关键元素已渲染完成,否则在 CI 环境容易失败。

效率上的变化(更客观的说法)

以常见场景为例:

  • 登录测试:从数小时缩短到几十分钟
  • 完整页面 E2E:从 1~2 天缩短到数小时

整体来看,在结构清晰的场景下,效率通常可以提升 2~3 倍。

但需要强调:
AI 并不会减少你的判断工作,只是减少了重复编码的时间。

对校招生更重要的一点

企业关注的,不只是你“用了 AI”,而是你是否理解:

  • 测试场景如何设计
  • 为什么这么设计
  • AI 在哪里帮助了你
  • 哪些地方需要人工介入

如果你能把这些讲清楚,比单纯展示工具更有价值。

最后

AI 确实在改变自动化测试的方式,但它更像一个加速器,而不是替代者。

更合理的分工是:

  • 人负责设计与判断
  • AI 负责提高实现效率

如果你还没开始尝试,可以从一个简单场景入手,比如登录流程,完整跑一遍“生成—调试—稳定”的过程。

这比单纯看教程,更能建立你的真实能力。

霍格沃兹测试开发学社,是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区