用 Playwright 端到端测试注册与登录流程

本文依据官方文档整理，未执行运行验证或性能基准。代码片段展示局部用法，业务函数、数据和环境需按项目补齐；版本与配置以所引文档为准。

直接回答：注册与登录是任何网站的命门——它们挂了，一切都挂。用 Playwright 把认证流程编成自动化测试（未登录跳转、表单校验、注册成功、登录登出），并在 CI 中持续运行，是最直接的保障手段；进一步把这套脚本定时跑在生产环境，就升级成了主动式合成监测。

为什么要专门测认证流程

合成监测（Synthetic Monitoring）的思路是用浏览器自动化模拟真实用户行为——填写注册表单、点验证邮件、进入控制台——持续验证关键流程。认证链路恰好是这类测试的第一候选：业务关键，但常依赖邮件、验证码、MFA及风控等外部环节、出问题影响面最大。

准备演示项目

一个带注册登录的演示应用（任意技术栈均可），确保本地可跑，且测试环境有可丢弃的测试数据库——注册测试会产生真实数据记录。

示例文件需导入 test、expect（来自 @playwright/test），配置 use.baseURL。以下是应用契约示例而非通用可直接运行套件，页面文案、路由、准备和清理接口均须与你的应用匹配。

用例 1：未登录用户重定向

test("未登录访问控制台应跳转登录页", async ({ page }) => {
  await page.goto("/dashboard");
  await expect(page).toHaveURL(/\/login/);
});

这是最便宜的冒烟用例，认证中间件失效时立刻暴露。

用例 2：注册表单校验

test("密码不匹配应提示错误", async ({ page }) => {
  await page.goto("/signup");
  await page.getByLabel("邮箱").fill("new@example.com");
  await page.getByLabel("密码", { exact: true }).fill("abc12345");
  await page.getByLabel("确认密码").fill("different");
  await page.getByRole("button", { name: "注册" }).click();

  await expect(page.getByText("两次输入的密码不一致")).toBeVisible();
});

把必填项、邮箱格式、密码强度等校验各写一条，表单逻辑回归就有底了。

用例 3：注册提交与下一步页面

import { randomUUID } from "node:crypto";

test("新用户提交注册后进入验证页", async ({ page }) => {
  const email = `e2e-${randomUUID()}@example.test`;

  await page.goto("/signup");
  await page.getByLabel("邮箱").fill(email);
  await page.getByLabel("密码", { exact: true }).fill("Passw0rd!");
  await page.getByLabel("确认密码").fill("Passw0rd!");
  await page.getByRole("button", { name: "注册" }).click();

  await expect(page).toHaveURL(/\/verify(?:[?#].*)?$/);
});

用例 4：登录与登出

test("登录后能登出", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("邮箱").fill("e2e-fixed@example.com");
  await page.getByLabel("密码").fill("Passw0rd!");
  await page.getByRole("button", { name: "登录" }).click();
  await expect(page).toHaveURL(/\/dashboard/);

  await page.getByRole("button", { name: "退出登录" }).click();
  await expect(page).toHaveURL(/\/login(?:[?#].*)?$/);
});

固定一个专用测试账号用于登录用例；注册用例则每次造新账号，两条路线互不干扰。

接入 GitHub Actions

- uses: actions/setup-node@v4
- run: npm ci && npx playwright install --with-deps
- run: npx playwright test

以上只是 workflow 的测试步骤，还需 checkout、明确Node版本、测试应用/数据库准备、受限 secrets、trace收集与失败时上传artifact。只有配置仓库必需状态检查，测试失败才阻止合并。认证状态、截图和trace可能含令牌，须控制权限和保留期。

从 CI 测试到生产合成监测

CI 为发布前已覆盖的行为提供检查，但生产环境有自己的变数：依赖服务抖动、证书过期、配置漂移。生产合成监测需要单独设计低频、安全的脚本：使用专用最小权限账号、隔离租户、可识别数据及清理机制，不直接把CI中可破坏数据的套件复制过去。测试失败可能先于部分用户暴露问题，但没有保证。

定时运行登录流程时，使用专门的测试账户，检查凭证有效期、测试数据清理和失败截图是否含敏感信息。先让一轮失败用例走完整条通知链，再逐步增加运行频率，避免测试账户失效后连续制造无效告警。

常见问题（FAQ）

Q：生产环境跑注册测试不会堆垃圾数据吗？
A：用约定前缀的专用测试账号，配合后端定时清理任务；或者测试最后一步调用清理 API 自毁。关键是把数据生命周期设计成闭环。

Q：短信/邮件验证码环节怎么自动化？
A：隔离测试环境使用邮件/短信沙箱或供应商测试凭据，必要的测试接口必须鉴权且只存在于该环境。生产不设置万能验证码或绕过MFA的白名单；无法安全自动化时缩小探测范围，并明确未验证的步骤。

Q：第三方登录（OAuth）怎么测？
A：不要测第三方本身。隔离测试通过受控的测试IdP或应用依赖替身覆盖回调处理，并另用提供商允许的沙箱进行契约验证；不要在生产放开任意OAuth回调或跳过state/nonce/PKCE验证；你要验证的是自己代码对各种回调结果的处理。

官方参考

• 官方文档 1
• 官方文档 2
• 官方文档 3
• 官方文档 4

资料核对日期：2026-09-29。

延伸阅读

• Playwright Python 测试入门
• 自动化 Playwright 拨测：持续保障注册与登录可用