第 16 天：登录态与认证复用

今日目标

• 掌握 storageState。
• 避免每条测试重复登录。
• 理解登录态复用的风险。

学习时间安排（60–120 分钟）

核心概念与词汇

学习材料

• 必读：[Authentication](https://playwright.dev/docs/auth)
• 必读：[Basic: shared account in all tests](https://playwright.dev/docs/auth#basic-shared-account-in-all-tests) 部分
• 选读：[Sign in with API request](https://playwright.dev/docs/auth#signing-in-before-each-test)（对比两种方式）

重点理解

保存登录态：

// auth.setup.ts
import { test as setup } from '@playwright/test';

setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Username').fill(process.env.TEST_USER!);
  await page.getByLabel('Password').fill(process.env.TEST_PASSWORD!);
  await page.getByRole('button', { name: 'Login' }).click();
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

配置中使用：

use: {
  storageState: 'playwright/.auth/user.json',
}

注意：

• 不要把真实账号密码提交到 Git。
• .auth 文件通常不要提交。
• 登录态可能过期，需要刷新机制。
• 不同角色要不同 storageState。

实操步骤

实现：

• setup 登录脚本。
• 复用登录态访问已登录页面。
• 增加 .gitignore 忽略 auth 文件。

示例代码

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: 'setup', testMatch: /auth\.setup\.ts/ },
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],
});

# 环境变量注入密钥
TEST_USER=demo TEST_PASSWORD=secret npx playwright test

常见坑

• 把真实账号密码写死在 auth.setup.ts 里提交到仓库。
• .auth/user.json 提交进 Git，泄露有效会话。
• 登录态过期后所有测试集体失败，报错全是“未登录”，排查半天。
• 多角色共用一份 storageState，权限断言互相污染。
• CI 里忘记配置环境变量，setup 项目静默失败。

今日产出

• 登录态复用方案。
• 至少一个不重复登录的测试。

今日问题

1. 为什么不建议每条测试都 UI 登录？
2. storageState 保存了什么？
3. 登录态复用有什么风险？
4. 多角色测试如何处理？
5. CI 中账号密码应该怎么管理？

复盘要点

• 登录一次、处处复用，是 E2E 提速的第一个杠杆，但代价是“会话过期”这个新故障源。
• 安全底线：密钥进环境变量/CI secrets，auth 文件进 .gitignore，二者缺一不可。
• 多角色项目从第一天就用多份 storageState 命名区分（admin/user），后面不用返工。

AI 时代扩展：AI 辅助 Playwright 测试

新增概念

适用场景

让 AI 对比“全局复用登录态”和“每次 API 登录”两种方案的取舍，或者审查你的 auth.setup.ts 是否存在密钥泄露、过期处理缺失等问题。

可复用表达 / 提示词

请对比 Playwright 中 storageState 复用和每次 API 登录两种认证策略的取舍，各列 3 个适用场景。
请审查我的 auth.setup.ts 和 config，检查密钥管理、会话过期处理、多角色扩展性。

追问加练

• AI 说“把密码直接写进环境变量文件也可以”，你接受吗？
• 会话过期时，AI 能帮你设计什么样的检测机制？
• 多角色登录态，AI 建议每角色一个 setup project，你评估一下。

今日作业

• 完成 auth.setup.ts + storageState 复用，跑通不重复登录的测试。
• 在 .gitignore 中加入 playwright/.auth/，并验证 git status 不显示它。
• 让 AI 审查你的认证方案，重点核对密钥是否可能进入仓库。

自检清单

• 我的测试不再每条都 UI 登录。
• 密钥来自环境变量，代码里没有明文密码。
• auth 文件已被 .gitignore 忽略。
• 我知道登录态过期时的失败表现和排查路径。
• 明天学习 API 测试时，我能用 request fixture 准备数据。