Skip to content
Original
Playwright实战教程· 欢乐马·· 14 days agoAI score71

Playwright Agent 实战教程：让 AI 把测试计划变成能跑的代码

The title and summary in the selected language are awaiting translation.

AI overview

Playwright 官方 Generator 工具可以按已评审的测试计划逐条生成可运行的 Playwright 用例，作者用演示站 jiucaiquan.com 走了一遍完整流程。

Full text

正文配图

正文配图

Playwright Agent 官方 Generator 实战演示：拿着测试计划生成能跑的用例，附一份"审生成代码"验收清单，零基础可跟做。
测试计划评审完了，10 个场景还得一行行敲成代码？让 AI 照着计划逐条写，你只负责验收。

一、计划评审完，代码还在一行行敲

测试计划写完——specs/jiucaiquan-condition-order-plan.md

这 10 条场景，还得自己翻译成代码。

本篇讲第二个：Generator。全程你不用手敲用例，只管给上下文、验收产出。

先快速对一下流水线（第 1 篇讲过三个官方 AI 工具）：

  • • 🎭 Planner —— 自己逛网站，把"测什么"列成测试计划

  • • 🎭 Generator —— 照计划逐条做一遍，写出能跑的代码

  • • 🎭 Healer —— 用例挂了自动诊断、修复、重跑

它跟"直接让 AI 写用例"最大的区别，一句话说死：先计划后生成。计划是你审过、签过字的地图，Generator 只负责把地图翻译成路。地图错了才轮到代码错——而不是让 AI 自己猜你要测什么。

二、跟着做完，你能拿到

  • • 一条可直接复制的指令，让 Generator 按计划产出 tests/*.spec.ts

  • • 一份 「审生成代码」验收清单（4 条）：AI 一秒写 200 行，你得在 10 分钟内判断它有没有自由发挥

  • • 配套源码包：seed + 已修好的配置 + 10 场景计划 + 生成出来的 10 条用例 + 验收清单 + FAQ

演示站：jiucaiquan.com（韭菜圈 · A 股条件单工具箱），真实在迭代的中文站，免登录。

三、准备：确认两样东西（1 分钟）

前置：Node.js 18+、VS Code、GitHub Copilot Chat 已登录（怎么装见第 1 篇第 3 节）。

Generator 是流水线的第 2 段，它只认两样输入：

  1. 1. seed.spec.ts 已跑绿 —— 它决定"从哪个页面状态出发"

  2. 2. specs/jiucaiquan-condition-order-plan.md 在位 —— 它决定"要生成哪些场景"

npx playwright test seed.spec.ts --reporter=list
# ✅ seed passed — jiucaiquan.com 首页就绪

💡 没跟过第 1 篇也能接上：源码包里已经把这两样都备好了，复制进项目即可（README.md 第 2 步）。seed 红着别往下走——起点不对，生成出来的代码全是歪的。

四、关键动作：叫 Generator 干活

四步走：

  1. 1. VS Code 打开项目，Copilot Chat 切到 Agent Mode（代理模式）

  2. 2. 选代理 @playwright-test-generator

  3. 3. 把 seed.spec.ts 和计划文件都加进上下文（少了哪个它都得靠猜）

  4. 4. 贴下面这条指令（指令决定产出质量，可直接复制）

请按 specs/jiucaiquan-condition-order-plan.md 生成 Playwright 测试代码。
要求：
1. 以 seed.spec.ts 为起点，沿用它的页面与标题校验；
2. 每个场景一条 test，测试名与计划里的场景标题一致；
3. 只写计划里有的场景，不要自己扩展；
4. 定位优先用 getByRole / getByLabel / getByText，不要用 nth-child、xpath、深层 CSS；
5. 断言用 expect(...).toBeVisible() 这类可重试写法，不要用 waitForTimeout；
6. 生成到 tests/condition-order.spec.ts，生成完自己跑一遍。

指令里第 3、4、5 条是故意写死的：这三条分别对应后面验收清单里最容易出问题的三条。你少写一句，就多半要在审的时候把它打回去重写。

它会自己走完一整轮：读计划 → 打开页面核对真实文案和元素 → 写代码 → 跑一遍。终端节奏长这样（真实以你本机为准）：

[读计划]    ✓ 3 个场景组 / 10 个场景，起始状态取自 seed
[逐条生成]  ✓ 1.1–1.3 → ✓ 2.1–2.5 → ✓ 3.1–3.2
[写文件]    ✓ tests/condition-order.spec.ts（10 条用例，与计划一一对应）
[自跑]      ✓ 10 passed

五、看它交出的代码：审什么（本篇最值钱）

节选 2.2 一条（完整 10 条在源码包 tests/condition-order.spec.ts）：

test('2.2 正常输入并生成次日条件单参考', async ({ page }) => {
  await page.getByLabel('代码').fill('600519');
  await page.getByLabel('名称').fill('贵州茅台');
  await page.getByLabel('开盘价').fill('1700.00');
  await page.getByLabel(/收盘|最新价/).fill('1710.00');
  await page.getByLabel('最高价').fill('1720.00');
  await page.getByLabel('最低价').fill('1690.00');
  const result = page.getByText('次日条件单参考').first();
  await expect(result).toBeVisible();
  // 低吸价 / 高抛价 / 观察价 三行都要有值（非空）  for (const label of ['低吸价', '高抛价', '观察价']) {
    const row = page.getByText(new RegExp(label)).first();
    await expect(row).toBeVisible();
    await expect(row).not.toHaveText(/^[\s\-—]*$/);
  }
  await expect(page.getByRole('button', { name: '复制条件单文案' })).toBeEnabled();
});

这段有两个细节值得抄进自己项目：

  • • 定位全走用户看得见的东西：getByLabel('最高价')、getByRole('button', { name: '复制条件单文案' })，没有一条 nth-child——页面改版时它们大概率还活着

  • • 断言校验的是业务结果，不是"点完了"：循环确认低吸价 / 高抛价 / 观察价三行都非空，计划里写的预期结果一条没落

但别急着 commit。 AI 生成的代码最大的风险不是"跑不起来"，而是"跑得起来但没人复核过"。拿下面 4 条过一遍，10 分钟足够：

① 场景齐不齐

计划里 10 个场景，生成的就该有 10 条 test()，不多不少。名称对得上，别自己加戏。

② 选择器稳不稳

getByRole('button', { name: '加入自选' }) 好过 div:nth-child(3) > button。
判断标准只有一句：页面改版时会不会挂。

③ 断言在不在

点了就完事的用例是假用例。每条 test() 至少一个 expect(...)，否则绿了也说明不了任何问题。

④ 有没有硬等

waitForTimeout(2000) 一律打回。改 await expect(...).toBeVisible()——自带轮询重试，机器快慢都稳。

这 4 条建议直接存下来，每次生成新用例都拿出来对一遍。源码包里的 REVIEW.md 是它的可打印版，还附了这次生成被"打回"的真实记录：2.4 用了硬等、3.2 多生成了一个计划里没有的场景。

审完再跑，不算完，跑稳才算：

npx playwright test tests/condition-order.spec.ts --repeat-each=3

一次绿不算绿，连跑 3 次全绿才叫修好。

六、最常见的 4 个坑

坑 1｜它不按计划写，自由发挥。
上下文里必须同时给 seed.spec.ts 和计划文件；指令里加死"只写计划里有的场景"。

坑 2｜生成的选择器全是 nth-child 和 xpath。
指令第 4 条写死"优先 getByRole / getByLabel"；已经生成完了就把那几条贴回对话让它重写。

坑 3｜生成完一条都没跑起来。
先确认文件在 testDir 范围内（本项目 testDir: '.'），再 npx playwright test --list 自检；macOS 12/13 装不上 Chromium 就加 PW_CHANNEL=chrome。

坑 4｜跑完发现多了一条计划里没有的场景。
删掉。计划是你签过字的地图，多出来的场景没人评审过，留着就是负债。

七、3 条心法，照做少踩坑

  1. 1. 计划是输入，不是参考 —— 别让 Generator 自由发挥，它该干的只是翻译

  2. 2. 生成完必对着计划逐条打勾 —— AI 最容易的两件事就是漏场景和加戏

  3. 3. 一次绿不算绿 —— --repeat-each=3 是成本最低的防偶发红手段

八、新手最常问的 3 个问题

Q1：它会不会改我的计划文件？
不会，它只读。但要确认计划文件真的加进了上下文——没加，它就只能靠猜页面。

Q2：生成完还要人工改吗？这不就白自动化了？
要，但改的是判断，不是敲键盘。它一分钟写 200 行，你花 10 分钟审：省下的是打字时间，留下的是"哪些场景值得测""这样断言对不对"。

Q3：能生成 API 测试或别的语言的用例吗？
官方围绕 TypeScript（@playwright/test）支持得最完整。但"计划 → 生成"这套思路不绑语言，先用 TS 工程把流程跑通验证价值。

选择器不稳、出现硬等、生成的文件跑不起来——更多问题见源码包里的 FAQ.md（开头有 30 秒踩坑速查）。

九、小结 & 下一篇

  • • Generator = 读计划 + 核对页面 + 写代码，把"测什么"变成"能跑"

  • • 你的角色：给足上下文 + 审产出——4 条验收清单，10 分钟过一遍

  • • 下一篇：Healer 跑测试、诊故障、改代码、重跑 —— 用例挂了让 AI 自己修

Source: Playwright实战教程 · mp.weixin.qq.com

#Tutorials/practice#Agent#Testing/verification#IDE/editors#OpenAI