Vibe Tutorial
功能测试流程与自动化脚本

8.5 Playwright完整指南

Tip

自动化测试最怕什么?最怕你改了个 CSS 类名,测试就挂了。学会**“用户视角”**,你的测试代码将坚如磐石。


1. 核心概念:三大法宝

Playwright 的 API 设计其实就是在模拟人的感官。把它想象成你在教一个机器人用电脑

1. Locator (机器人之眼):怎么找到元素?

早期测试工具喜欢用 CSS 选择器 (div > span.btn)。这是错的。 用户看不见 CSS 类名,用户只看字。

  • page.locator('.submit-btn') (开发视角的写法,脆弱)
  • page.getByRole('button', { name: '登录' }) (用户视角的写法,强壮)

Vibe 推荐优先顺序

  1. getByRole: 找按钮、链接、输入框(最稳)。
  2. getByPlaceholder: 找输入框(如“请输入手机号”)。
  3. getByText: 找纯文本。
  4. getByTestId: 实在找不到时,让开发加个 data-testid="my-box"

2. Action (机器人之手):怎么操作?

  • fill('hello'): 打字。
  • click(): 点击。
  • check(): 勾选复选框。
  • press('Enter'): 按回车键。

3. Assertion (机器人之脑):怎么判断对错?

机器人操作完了,得判断结果对不对。这就叫断言 (Assert)

  • expect(locator).toBeVisible(): “我应该能看见它”。
  • expect(page).toHaveURL('/home'): “网址应该变了”。

2. 解决方案:Codegen (作弊神器)

如果你懒得查 API,Playwright 提供了一个王炸功能:录制。 你只管在浏览器里点点点,它自动帮你写代码。

操作步骤

  1. 终端运行:
    npx playwright codegen localhost:3000
    
  2. 浏览器自动打开。你去点击“登录”、输入密码。
  3. 观察右边的控制台,代码已经自动生成好了!
  4. 直接复制粘贴到你的测试文件里。

这是 AI 时代之前最强的自动化辅助,能帮你省去 80% 写测试的时间。


3. 代码实战:教机器人登录

假设我们要测登录功能。在 tests/login.spec.ts 里:

import { test, expect } from '@playwright/test';

test('用户应该能登录', async ({ page }) => {
  // 1. 来到门口 (访问页面)
  await page.goto('http://localhost:3000/login');

  // 2. 睁眼找框,动手填表 (Locate + Action)
  // 不依赖 class,只依赖用户能看到的 Label
  await page.getByLabel('邮箱').fill('test@example.com');
  await page.getByLabel('密码').fill('123456');

  // 3. 找按钮,点击
  // 哪怕这个按钮从 <button> 变成了 <div role="button">,只要它叫“登录”,就能点
  await page.getByRole('button', { name: '登录' }).click();

  // 4. 动脑判断 (Assert)
  // 期待网址变成 /dashboard
  await expect(page).toHaveURL(/.*dashboard/);
  // 期待看到“欢迎”字样
  await expect(page.getByText('欢迎回来')).toBeVisible();
});

4. 真实案例

Story

XPath 的“结构性”灾难

某老牌金融系统的自动化测试代码里,充斥着这样的路径: page.click('/html/body/div[2]/div[5]/form/div[3]/button') 这叫 XPath。意思是“点击第 2 个 div 下面的第 5 个 div 下面的...”。

后果: 有一天,前端开发仅仅是在页面顶部加了一个 <Alert> 提示框 (多了一个 div)。 整个页面的 DOM 结构全部下移了一层。所有的 div[2] 都变成了 div[3]一夜之间,3000 个测试用例全部变红。QA 团队被迫加班一周,手动修复这几千个路径。

Vibe 心法:永远不要测试 DOM 结构,要测试用户意图。用户不知道什么是 div[5],用户只知道那里有个按钮叫“提交”。使用 getByRole,让你的测试像用户一样思考。


5. 本章小结

  1. 用户视角:用 getByRole 代替 CSS 选择器,测试更健壮。
  2. 录制代码:遇事不决 codegen,让脚本自己写自己。
  3. 断言:每做一步操作,都要 expect 一下结果,否则测试就没有意义。