第 27 天：可访问性与用户行为测试

今日目标

• 理解 role-based locator 与可访问性的关系。
• 学会从用户行为角度写测试。

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

核心概念与词汇

学习材料

• 必读：[Accessibility testing](https://playwright.dev/docs/accessibility-testing)（了解 Playwright 的能力边界）
• 必读：[Keyboard](https://playwright.dev/docs/api/class-keyboard) 的 press/Tab 部分
• 选读：[aria snapshot](https://playwright.dev/docs/aria-snapshots)（了解结构断言新能力）

重点理解

重点：

• getByRole() 依赖页面语义。
• 好的可访问性结构会让测试更稳定。
• 测试应该验证用户看得见、点得到、理解得到的行为。
• 不要过度测试实现细节。

可扩展工具：

• axe-core。
• aria snapshot。
• 可访问性断言。
• 键盘导航测试。

实操步骤

为一个表单页面写测试：

1. 使用 label 定位输入框。
2. 使用 role 定位按钮。
3. 使用键盘 Tab 操作。
4. 验证错误提示。
5. 检查必填字段。

示例代码

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

test('form is operable by keyboard', async ({ page }) => {
  await page.goto('/signup');

  // Tab 依次聚焦表单字段
  await page.keyboard.press('Tab');
  await expect(page.getByLabel('Email')).toBeFocused();
  await page.keyboard.press('Tab');
  await expect(page.getByLabel('Password')).toBeFocused();
  await page.keyboard.press('Tab');
  await expect(page.getByRole('button', { name: 'Sign up' })).toBeFocused();

  // 必填校验：直接提交应显示错误
  await page.keyboard.press('Enter');
  await expect(page.getByText('Email is required')).toBeVisible();
});

常见坑

• 测试 class 名和内部函数名，UI 一改全红，且与用户行为无关。
• 按钮没有 accessible name（只有图标），getByRole 定位不到——这本身就是可访问性缺陷。
• 用 page.locator('body').click() 代替真实交互，绕过焦点和键盘行为。
• 忽略键盘路径：鼠标能点的流程，键盘用户可能卡住。
• 把 axe 扫描当成可访问性测试的全部，忽略人工判断的部分。

今日产出

• 一个更贴近用户行为的表单测试。
• 一份“用户视角测试原则”。

今日问题

1. 为什么 role-based locator 能提升测试质量？
2. 自动化测试和可访问性有什么关系？
3. 为什么不推荐测试内部函数名或 CSS class？
4. 键盘操作能发现什么问题？
5. 用户行为测试和实现细节测试的边界在哪里？

复盘要点

• 一条铁律：测试能看到的东西，用户也能看到；测试在验证的东西，用户也在意。
• role 定位不到元素，往往不是测试的问题，而是页面语义的问题——顺手提一个可访问性缺陷。
• 键盘路径是被忽略的高价值测试：低成本，却能发现真实用户卡点。

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

新增概念

适用场景

让 AI 审查测试是否在验证用户行为而非实现细节，或者根据页面描述生成键盘导航测试草稿。

可复用表达 / 提示词

请审查我的测试，指出哪些断言在验证实现细节（class、内部结构）而非用户可见行为，并给出替代方案。
我的注册表单有 3 个字段和 1 个按钮，请生成键盘导航测试草稿，覆盖 Tab 顺序和必填校验。

追问加练

• AI 说“断言 button 的 class 更稳定”，为什么这是错的？
• 键盘路径和鼠标路径的测试结果不一致时，意味着什么？
• AI 能帮你发现哪些可访问性缺陷？哪些它发现不了？

今日作业

• 完成表单页 5 项用户视角测试并跑通。
• 完成“用户视角测试原则”笔记：至少 5 条。
• 让 AI 审查你的测试集，找出验证实现细节的地方并修改。

自检清单

• 我的测试全部使用 role/label 等语义定位。
• 我写过键盘导航测试并跑通。
• 我能说出测试实现细节的 3 个坏处。
• 我知道 axe-core 和 aria snapshot 的用途。
• 明天学习数据管理时，我能保证数据可重复、可清理。