Playwright生成测试实战：从codegen录制到数据驱动用例工厂

很多刚开始接触Playwright的朋友，都会在同一个地方卡住——不是不会写断言，而是不知道第一条测试脚本该怎么起步。Playwright入门的核心能力之一就是“生成测试”，表面上说的是内置的codegen命令可以录下你的操作并自动翻译成测试代码，实际用起来还会把“测试数据生成、用例批量生成、登录态生成”这一整套流程都带起来。这篇文章就围绕Playwright的生成测试能力，从codegen实操、脚本升级到数据驱动的用例工厂，把我自己觉得能落地的步骤和踩过的坑一起整理出来，适合刚入门自动化测试的开发者、想快速搭建回归用例的测试工程师，也适合想给已有项目补充批量验证脚本的人。

1. 生成测试的两层含义，先搞懂再动手

1.1 codegen并不是“录屏回放”

很多教程把codegen叫“录制回放”，这个说法其实不够准确。Playwright的codegen在录制时并不是记录鼠标坐标、像素位置，而是监听真实的DOM事件、浏览器上下文和页面状态，然后在后台根据你每一步操作去推断“用户到底想对这个页面做什么”，再生成对应的语义化代码。比如我点击“加入购物车”按钮，它生成的通常不是某个坐标上的click，而是：

await page.getByRole('button', { name: '加入购物车' }).click();

这有什么区别？区别非常大。坐标会随视口大小、浏览器窗口尺寸变化而失效，但getByRole这种语义定位器在桌面端、移动端、不同浏览器下都能稳定命中。Playwright在生成时还会默认遵循可访问性最佳实践，优先给你role、text这类人类可读的定位策略，其次才是css、xpath。这件事我当时是有点意外的——我原本以为生成出来的代码会很“脏”，结果比很多手写的测试代码还干净。这也是“生成测试”能作为入门路径的根本原因：它不只是采集操作，而是在采集的同时做了一层智能翻译。

1.2 用例生成是“数据工厂”思路

理解了codegen之后，还要理解“生成测试”的第二层含义：用有限的代码去生成覆盖更大的用例集。这在数据驱动测试里尤其重要。比如我想验证一个商城页面上10个商品的价格显示，手写10个test()非常机械，但如果把商品数据放到一个数组里，用一个for循环遍历数组，Playwright会为每个数据项动态生成一条独立测试用例。运行时你在报告中就能看到10条用例各自执行、各自失败、各自定位问题。

这种“数据工厂”思路，比单纯录制操作更接近“生成测试”的本质。录制代码只是生成测试的入门形态，数据驱动的参数化用例才是让测试产出覆盖率的进阶手段。后面第3节我会拿真实代码演示这个循环怎么搭，第4节还会扩展到批量生成商品详情访问用例。

2. 录制生成一条真实用例：从命令行到可跑的测试

2.1 初始化工程并启动录制：三条命令就够了

想自己复现的话，建议先准备一个本地可控的演示项目，比如一个内部商城页面。为什么要用本地页面而不是随便找一个公网站点？因为公网页面的结构随时可能变，录到一半元素被改掉，脚本就废了；而且本地页面你可以加>mkdir playwright-demo && cd playwright-demo npm init -y npm install -D @playwright/test npx playwright install chromium

然后启动codegen，标准命令是这样：

npx playwright codegen --target=javascript -o tests/generated.spec.js http://demo.local

这里的--target=javascript是指定生成JavaScript代码，也可以用python、java、csharp对应不同语言的测试代码；-o参数告诉它把生成结果直接写到文件里，不加的话代码会打印在控制台，手动复制也行。启动之后会同时打开两个窗口：左边是浏览器操作区，右边是Playwright Inspector，界面里实时显示生成的步骤和代码。

如果是移动端场景，还可以加--device="iPhone 13"模拟手机，生成的代码里会自动带上devices配置和对应的userAgent。我第一次用这个功能给团队做移动端回归时，就在这个阶段省了不少事。

2.2 录制的正确姿势：先加断言再走流程

很多人第一次用codegen，都是打开页面就开始一顿操作：点商品、加购物车、进结算页，全程一个断言都没加。结果生成的脚本虽然能跑，但等于是“光操作不检查”，页面出了错也不会被发现。正确姿势是把“断言”当作录制的一部分，和操作同步进行。

下面是一个标准的录制流程，我以“购物车结账”为例：

打开首页后，先在左侧页面右键断言标题或关键元素。比如我想验证顶部标题存在，就右键“Assert text”，检查文字“Demo Shop”可见。接着点进商品详情页，再在商品价格区域右键“Assert visible”，确保价格展示出来。然后点“加入购物车”，在购物车角标上右键“Assert text”，验证数量变成1。最后走结算流程，每一步都补一个业务关键断言。

生成的脚本大致长这样：

import { test, expect } from '@playwright/test'; test('checkout flow', async ({ page }) => { await page.goto('http://demo.local/'); await expect(page.getByRole('heading', { name: 'Demo Shop' })).toBeVisible(); await page.getByRole('link', { name: 'Coffee Beans 250g' }).click(); await expect(page.getByTestId('product-price')).toBeVisible(); await page.getByRole('button', { name: '加入购物车' }).click(); await expect(page.getByTestId('cart-count')).toHaveText('1'); });

注意生成的代码里每个test都自己创建page和context，用例之间天然隔离，这是Playwright的一个优点，我不会把多个页面操作塞进一个test里。

如果你的被测功能需要登录，还有个小技巧：先用浏览器把登录态保存成文件，再让codegen加载它。保存登录态用：

npx playwright open --save-storage=state.json http://demo.local

等登录流程走完后，状态会写进state.json。之后的录制命令带上加载参数：

npx playwright codegen --load-storage=state.json -o tests/shop.spec.js http://demo.local

这样生成的代码不会每次从头走一遍登录，录制过程也能跳过登录页面，直接录业务核心路径。

2.3 生成的脚本能不能直接跑：先做一次心检

生成的代码不长，也基本能跑，但你要是直接把它丢进CI，大概率会在第二周就开始怀疑人生。因为codegen生成的脚本本质上是“骨架”，很多工程化细节它不会替你考虑。

我的建议是生成完之后，用5分钟做一次心检，检查下面几项：

• 项目里是否配了baseURL。没有的话，把page.goto('http://demo.local/')改成page.goto('/')更好，环境切来切去不用改脚本。
• 定位器是否足够稳定。录出来如果用了很长一串CSS路径，比如#main > div:nth-child(2) > button，建议手动改成getByTestId或者getByRole，后面我会展开讲。
• 断言是否覆盖关键业务路径。如果全程只有一个toBeVisible，那说明录得太随意，起码价格、数量、成功提示这些关键节点得有确认。
• 有没有录制过程中的误操作。有时手滑点了一下无关区域、页面还没加载完就点下一步，这些都会生成多余代码，直接删掉。

这一轮检查不会花太久，但能避免“生成5分钟，调试2小时”的窘境。

3. 把生成脚本升级成可维护用例：三件套

3.1 定位器提炼：从高频操作到稳定locator

codegen默认会给语义化定位器，但在复杂页面上，它也可能生成一长串CSS路径。我遇到过最夸张的一次，一个按钮的css定位器有6层嵌套，中间还带:nth-child(3)，结果页面加了个推荐位，这个定位器直接把整条用例带崩。从那以后我给自己定了规矩：凡是生成的脚本里出现超过一层的CSS路径，一律手动改掉。

最稳的方案是引入><button>await page.getByTestId('add-to-cart').click();

为什么>[ { "product": "Coffee Beans 250g", "expectedPrice": "¥88.00" }, { "product": "Glass Cup", "expectedPrice": "¥59.00" }, { "product": "Milk Frother", "expectedPrice": "¥299.00" } ]

然后写测试文件：

import { test, expect } from '@playwright/test'; import data from '../fixtures/pricing.json'; for (const item of data) { test(`价格校验：${item.product}`, async ({ page }) => { await page.goto(`/products`); await page.getByRole('link', { name: item.product }).click(); await expect(page.getByTestId('product-price')).toHaveText(item.expectedPrice); }); }

重点是：测试代码只写了一遍，Playwright在收集测试时看到for循环，就会根据data数组长度动态生成对应数量的test()。以后新增商品，只需往JSON里加一条数据，测试代码一行都不用改。

注意：循环生成测试时，测试名里最好带上数据项的标识字段，比如商品名。否则一旦某条数据跑挂了，报告里全叫“价格校验”，你都分不清是哪条商品出了问题。

3.3 测试前置：用API造数据，再走UI

生成测试用例之后，还有一个容易被忽略的问题：测试数据从哪来。如果每条用例都从UI层面创建前置数据，比如先注册用户、再创建订单、再走业务，那么用例会非常慢，而且UI每一步都可能失败，很难判断是不是被测功能本身出了问题。

更符合工程实践的做法是：把数据准备从UI剥离，用接口直接造。Playwright内置了requestfixture，在beforeEach里调用就行：

test.beforeEach(async ({ request }) => { const response = await request.post('http://demo.local/api/orders', { data: { productId: 'sku-001', quantity: 2, email: 'customer@example.com' } }); expect(response.ok()).toBeTruthy(); });

这样每条用例开始时，订单数据已经通过API在服务端存在了，UI层只需要走核心流程验证展示逻辑。执行速度比UI创建数据快一个数量级，稳定性也高出很多。

当然，这个方案的前提是接口可调、环境可控。如果项目没有对外暴露API，或者测试环境与开发环境共用一份数据，那就退回UI前置，但要记住给每条用例做好数据隔离，避免并行时互相覆盖。

4. 进阶形态：批量生成与并行策略

4.1 用工厂函数批量生成用例

数据驱动不仅能从数组生成测试，还能用工厂函数动态构造大量用例。有一次我们要求验证20个商品详情页至少能正常打开、标题可见，我就没手写20个test()，而是用了循环：

const productIds = Array.from({ length: 20 }, (_, i) => `sku-${i + 1}`); test.describe('商品详情批量验证', () => { for (const sku of productIds) { test(`访问商品 ${sku} 详情页`, async ({ page }) => { await page.goto(`/products/${sku}`); await expect(page.getByTestId('product-title')).toBeVisible(); }); } });

这个模式跑起来后，报告里会出现20条独立用例，名字清晰到可以直接按sku定位问题。这种“批量验证型”用例覆盖面不深，但广度极好，很适合在发版前当烟雾测试跑一遍。你也可以把逻辑扩展一下：在每个详情页断言完再记录响应时间，就成了一个简单的性能冒烟检查。

批量生成要注意一个问题：不要在循环里构造百万级数据。Playwright收集测试时会把所有用例展开，用例过多会拖慢启动时间。几十条、几百条都没问题，但上千条时建议换个思路，比如抽样或者在运行时过滤。

4.2 trace与报告：让生成的东西可复盘

批量生成的用例一旦失败，要快速定位问题，单靠日志是不够的。Playwright的trace功能可以把页面每一步的操作、网络请求、DOM快照、控制台日志全部记录下来，然后通过Trace Viewer逐帧回放。

我通常直接在配置文件里把trace打开，并且只在失败时保留，避免每个用例都留一份大文件：

export default { use: { trace: 'retain-on-failure', screenshot: 'only-on-failure', video: 'retain-on-failure' } };

跑完测试后执行：

npx playwright test --reporter=html

打开HTML报告，失败用例旁边会直接出现“Trace”入口，点进去就能看到失败前那一刻的页面是什么样、点了哪些元素、最后一个网络请求是什么。这一步对于排查那种“测试环境偶发、本地跑不出来”的老大难问题，价值巨大。

4.3 并行执行与分片，别让用例互相干扰

Playwright的每一个test()默认在独立浏览器上下文中运行，这意味着生成出来的大量用例天然适合并行。命令行加个参数就能控制并发数：

npx playwright test --workers=4

如果只是本地调试，建议先固定单worker跑通一遍，再开并行，避免一股脑冲进去然后被各种环境问题淹没。

并行时最坑的点是用例之间共享状态。比如批量生成的用例依赖同一个数据库，A用例改了数据，B用例就挂了。这种情况要么保证每条用例只读自己创建的数据，要么在beforeEach里用唯一前缀隔离数据。全局配置里的storageState也要谨慎，如果所有worker都加载同一个登录态文件，而登录态又会被并发刷新，就可能互相踢下线。看到“context destroyed”这类报错时，先怀疑并行下的共享问题，再回头看代码逻辑。

5. 常见问题与避坑指南

5.1 常见报错速查表

下面这几个报错是我在实际使用生成测试以及维护生成出来的脚本时最常遇到的，整理成表格方便对照：

这些报错里，“strict mode violation”是生成脚本最容易被忽视的一个。录制时可能有两个按钮文案一样，codegen会生成一个命中多个元素的locator，运行时会立刻报错。改法就是给按钮加>