以购物车移除商品为例，把单一验收条件拆成前置状态、用户动作和可观察结果，再生成可维护的 Playwright 测试，适合需要可复现流程与人工复核的团队直接照做。
任务与最终结果
本例把一条验收条件转换为稳定的端到端测试：Given 购物车中只有“基础课程”一件商品，When 用户点击该商品区域内名为“移除”的按钮，Then 页面出现“购物车为空”，商品不再可见。最终交付物包括可执行测试、可访问性定位器、业务结果断言、确定性数据准备和失败截图配置。
适用环境是 Visual Studio Code、GitHub Copilot 和 Playwright 当前稳定版。截至 2026-08-30，应核对 Copilot 扩展模式、组织策略、Playwright 测试运行器配置和浏览器安装状态。GitHub 的Copilot 使用文档用于确认当前可用方式；本文不假设某个聊天入口、命令或代理权限一定存在。
| 前置条件 | 本例要求 | 验收标准 |
|---|---|---|
| 测试站点 | 可在本地或隔离环境启动 | URL 和数据可重复 |
| Playwright | 已按项目方式安装和配置 | 基础示例可运行 |
| 验收条件 | 单一且无歧义 | 结果可由页面状态验证 |
| 测试数据 | 合成账号与固定商品 | 不依赖生产数据 |
把验收条件拆成可自动验证动作
- 前置条件：购物车只包含一件指定商品，且账号、语言和功能开关固定。
- 用户动作：在该商品对应区域点击可访问名称为“移除”的按钮。
- 结果断言：空购物车标题可见，原商品名称不可见。
- 失败证据：由测试运行器在失败时保留截图，并使用可识别但不含敏感数据的文件。
如果页面有多个“移除”按钮，应先定位到包含目标商品的语义区域，再在区域内找按钮。不要让 Copilot通过 nth(0) 或长 CSS 路径掩盖验收条件的歧义。
用结构化提示让 Copilot 生成初稿
请把下面的验收条件转换为 Playwright Test 测试初稿。
Given：购物车中只有“基础课程”一件商品。
When：用户点击该商品区域内名为“移除”的按钮。
Then：页面出现“购物车为空”，且“基础课程”不再可见。
要求：
1. 使用角色、可访问名称或标签等面向用户的定位方式；
2. 不使用固定等待时间、nth、长 CSS 或 XPath；
3. 前置数据通过项目已有 fixture 或 API 辅助建立，若未知就留 TODO；
4. 使用自动重试的网页断言；
5. 失败截图通过当前 Playwright 配置启用；
6. 标出所有需要人工核对的页面名称和测试数据接口。
不要编造真实 URL、账号、按钮名称或项目 fixture。Playwright 的测试编写文档介绍了测试结构、定位器、断言和隔离等基础方式。生成代码后应以项目当前安装版本的官方文档和类型检查结果为准，而不是只接受 Copilot 的语法补全。
把初稿改成可维护测试
import { test, expect } from '@playwright/test';
test('移除唯一商品后显示空购物车', async ({ page }) => {
// TODO：通过项目已有 fixture 或测试 API 创建确定性购物车状态
await page.goto('/cart');
const item = page.getByRole('article', { name: '基础课程' });
await expect(item).toBeVisible();
await item.getByRole('button', { name: '移除' }).click();
await expect(page.getByRole('heading', { name: '购物车为空' })).toBeVisible();
await expect(item).toBeHidden();
});article 是否拥有“基础课程”这一可访问名称，取决于真实页面语义；若没有，应由开发和设计共同选择合适结构，而不是为了通过测试添加错误 ARIA。W3C 的可访问名称与描述实践说明了名称来源和相关原则，可用于复核定位器是否对应用户真正感知的名称。
按可复现顺序运行
- 单独启动测试站点：确认基础 URL、语言、时区和功能开关固定，不连接真实生产服务。
- 建立前置状态：优先使用项目已有 fixture、测试 API 或数据库种子；不要通过一长串 UI 操作重复创建商品，除非创建流程本身就是测试目标。
- 先运行单个测试：确认失败时能看见断言信息和截图，截图中不包含真实个人资料或令牌。
- 重复运行：多次执行并在项目支持时覆盖目标浏览器，检查定位器和数据清理是否稳定。
- 制造一次受控失败：临时修改预期文本或前置数据，确认截图确实产生，再恢复代码。
- 纳入持续集成：保存 Playwright、浏览器和运行环境信息，并根据团队策略管理截图保留期限。
失败诊断
| 现象 | 常见原因 | 处理方式 |
|---|---|---|
| 本地通过、CI 失败 | 数据、语言、时区或启动条件不同 | 固定环境并保存失败证据 |
| 严格模式发现多个元素 | 可访问名称不唯一或范围过大 | 先缩小到目标语义区域 |
| 必须加固定等待才通过 | 断言对象错误或页面缺少可观察状态 | 等待用户可见结果，不猜时间 |
| 商品已移除但断言失败 | 元素被隐藏、替换或名称改变 | 核对真正的验收结果和 DOM 语义 |
| 没有失败截图 | 配置未加载、输出目录错误或被清理 | 制造受控失败并核对当前配置 |
人工复核、隐私与成本边界
- 人工确认测试验证的是业务结果，而不是复制当前实现细节；否则正常重构也会造成大量误报。
- 可访问性定位器能提高用户语义一致性，但单个测试通过不等于页面符合全部无障碍标准。
- 不要向 Copilot提交生产账号、会话 Cookie、支付信息、客户数据或内部测试密钥。
- 失败截图可能包含姓名、邮箱、订单和内部地址，应使用合成数据，并设置访问权限与保留期限。
- 成本包括 Copilot 许可或调用、浏览器运行、CI 分钟、截图存储和不稳定测试的排查时间。不要无目的地增加浏览器矩阵与重试次数。
- 复制第三方测试片段前检查许可证与项目规则，生成代码仍需人工评审和维护。
结论
常见问题
Playwright 测试为什么优先使用可访问性定位器？
因为角色和可访问名称更接近用户理解页面的方式，通常比样式类和深层 DOM 路径更稳定，但前提是页面语义和名称本身正确且唯一。
端到端测试可以使用固定等待时间吗？
不应作为默认做法。固定等待会拖慢测试且仍可能失败，应等待可观察页面状态，并使用 Playwright 支持自动重试的网页断言。
失败截图应该保存多久？
没有统一期限，应根据调试需要、存储成本和数据政策决定。截图若含业务或个人信息，应限制访问、缩短保留期并优先改用合成测试数据。