告别不稳定的测试：每个测试自动化工程师必须掌握的Playwright最佳实践

2025年01月28日 · 3,374 词 · 17 分钟 读完 playwright进阶 翻译

测试用例集就像降落伞——只有在每次都能正常工作时，你才会信任它。如果你的测试今天通过了，但明天却莫名其妙地失败了，那么它们带来的坏处比好处更多。稳定性是测试价值的关键。在本文中，我们将探讨 Playwright 创建稳定、可靠测试的顶级策略，让你能够自信地发布代码，而不用担心测试的不稳定性。

Playwright 测试最佳实践

1. 使用可靠的定位器

   • 目标：确保测试对频繁的 UI 变化具有弹性。
   • 优先使用数据或基于角色的定位器：使用data-testid或getByRole，而不是脆弱的 CSS 类或自动生成的 ID。这种方法关注的是很少变化的稳定属性。
   • 避免动态属性：不要依赖包含时间戳、会话令牌或随机字符串的定位器。这些内容可能会在每次构建或测试运行时发生变化。
   • 处理复杂的 DOM 结构：对于 Shadow DOM 或 iframe，使用page.frame(...)或嵌套的locator(...)。始终确保你指向正确的文档上下文。
   • 强制执行命名标准：保持测试特定属性的一致性。例如，始终使用data-testid="submit-button"或类似的命名模式，以减少混淆。

2. 利用自动等待和显式条件

   • 目标：让 Playwright 智能处理时间问题，消除由于延迟导致的不稳定性。
   • 使用定位器自动等待：使用page.locator('selector')并链接操作，如.click()。Playwright 会自动重试，直到元素准备就绪。
   • 使用基于断言的等待：避免使用waitForTimeout，优先使用expect(locator).toBeVisible()、expect(locator).toHaveText()等。每个断言都包含在默认或配置的超时内的重试机制。
   • 最小化手动暂停：只有在外部服务引入实际延迟时，才使用显式的page.waitForTimeout()。
   • 期望轮询：对于更复杂的条件（如验证列表计数），使用expect.poll(...)。这减少了自定义循环或重复检查的需要。

3. 隔离测试并避免共享状态

   • 目标：使每个测试自包含，确保一个测试的失败或残留数据不会影响下一个测试。
   • 独立的设置和清理：无论是通过 Playwright 的 fixture 还是beforeEach/afterEach钩子，只为每个测试重新创建所需的内容。不要依赖前一个测试的状态。
   • 使用 Playwright 的 fixture 模型：利用内置的 fixture 来初始化页面、上下文或用户状态，确保并行运行的一致性。
   • 参考专用的数据策略：如果你需要临时环境或容器化的数据库，请参阅管理测试数据和数据库文档，了解更深入的策略。

4. 保持测试的原子性和专注性

   • 目标：减少调试复杂性和部分失败的风险。
   • 每个测试只测试一个功能：只测试一个主要场景（例如，“用户可以提交有效表单”）。大型端到端流程更容易出现间歇性中断。
   • 可重用性：对于重复的步骤（如登录），使用辅助函数或 fixture。不要在每个测试中重复复杂的登录流程。
   • 步骤注释：使用test.step(...)来清晰地描述每个阶段的操作。这有助于准确识别测试失败的位置。

5. 正确处理异步操作

   • 目标：消除与网络响应或异步进程相关的竞态条件和时间问题。
   • 等待网络响应：当操作触发 API 调用时，确认 UI 状态或使用page.waitForResponse(...)等待相关响应。
   • 模拟外部服务：使用 Playwright 的请求拦截功能来控制或模拟外部依赖。这避免了由于第三方服务中断或速率限制导致的不稳定性。
   • 超时配置：在playwright.config.ts中设置标准超时。确保它们足够长以适应实际条件，但不要太长以至于失败无法被检测到。

6. 控制测试环境

   • 目标：确保测试在一致的条件下运行，以减少变异性。
   • 容器化/CI：将你的设置容器化（Docker）或标准化你的 CI 环境。不匹配的操作系统或浏览器版本可能会引入难以调试的错误。
   • 稳定的构建：始终在通过 linting、单元测试和集成测试的代码上运行端到端测试。在进入端到端测试之前，尽早发现小问题。
   • 重置快照/日志：在每次运行前清除旧的快照或日志，以避免过时的工件生成误报或混淆。

7. 实施健壮的断言

   • 目标：确保成功条件清晰，并可靠地检测正面和负面条件。
   • 内置匹配器：使用toHaveText、toBeVisible、toHaveCount等。这些断言包含重试机制，有助于减少手动休眠。
   • 负面断言：当期望没有结果时，使用toBeHidden()或toHaveCount(0)。这些断言也包含基于时间的重试，以处理缓慢的 UI 更新。
   • 细粒度检查：如果一个测试检查多个子功能，将它们分解为单独的expect调用。更细粒度的断言会产生更清晰的错误报告。

8. 使用跟踪和调试功能

   • 目标：快速诊断根本原因，尤其是在 CI 或并行化环境中。
   • Playwright 跟踪：对失败的测试使用--trace on或--trace retain-on-failure。在 Trace Viewer 中重放跟踪，查看逐步的截图、日志和网络调用。
   • 截图和视频：在失败时捕获截图或完整视频。这在无头 CI 运行中非常有用，因为你无法实时查看浏览器。
   • 控制台/网络日志：监听page.on('console', ...)或网络事件。了解控制台错误或请求状态可以快速定位不稳定性。

9. 编写清晰且可维护的代码

   • 目标：保持测试代码易于长期演进和调试。
   • 使用页面对象/抽象：将常见的定位器和操作集中在页面对象或辅助模块中。单个更改可以更新所有引用该组件的测试。
   • 避免硬编码字符串：将重复的 URL、凭据或文本存储在配置或常量中。这减少了重复和拼写错误的风险。
   • 描述性命名：为测试命名时明确结果（例如，test('提交有效表单显示成功消息', ...)），以便在报告中清晰可见。

10. 优化并行执行（和性能）

    • 目标：在不引入跨测试干扰的情况下加速测试运行。
    • 独立的浏览器上下文：在每个测试中启动自己的上下文（或页面）。跨测试的共享状态是导致不稳定的常见原因。
    • 明智地设置并发性：在playwright.config.ts中，根据可用的 CPU 和内存调整workers。过载环境可能会减慢或破坏运行。
    • 平衡性能：并行运行数十个测试是快速的，但要注意系统限制。如果测试突然变慢或失败，降低并发性或优化环境资源。

11. 快速监控和分类不稳定的测试

    • 目标：通过解决不稳定的根源，保持对测试用例集的信任。
    • 即时可见性：在 CI 仪表板上及时显示测试结果。不要将不稳定的失败隐藏在静默重试背后。
    • 隔离策略：如果已知不稳定的测试阻塞了构建，暂时将它们移到隔离套件中。但请将此视为短期措施。
    • 根本原因分析：调查并修复根本问题——通常是异步竞态或环境不匹配——而不是仅仅重新运行以获得通过的结果。

12. 其他注意事项

    • 使用 Playwright 测试运行器：依赖 Playwright 的原生运行器，以实现简化的并行化、fixture 和调试工具。
    • 认证流程：如果你的网站需要登录，考虑存储已登录的storageState，以跳过多个测试中的缓慢登录步骤。
    • 测试组织：按功能分组测试（例如，login、profile、checkout）。这使得运行或维护测试子集变得容易。

总结

Playwright 提供了强大的功能来最小化不稳定性并最大化可靠性，但成功取决于：

• 坚实的基础——使用稳定的定位器、利用自动等待和隔离测试。
• 良好的工程实践——页面对象、健壮的断言和正确的并行化。
• 主动调试——跟踪、日志和即时分类不稳定的测试。

管理端到端测试的测试数据和数据库

稳定的测试只有在它们所依赖的数据一致时才有价值。即使是最健壮的测试，如果底层数据或数据库设置不一致或不可靠，也可能失败。这就是为什么管理测试数据和数据库至关重要——它确保你的测试有一个一致的环境，以提供准确的结果。让我们探讨如何有效地做到这一点。

1. 使用专用（且可丢弃的）测试数据库

   • 切勿使用生产或共享数据库：避免污染真实环境或冒数据损坏的风险。专用的测试数据库（例如，myapp_test）确保数据完全在测试控制之下。
   • 启动新环境：使用 Docker 或其他基于容器的解决方案来启动测试数据库。测试后将其拆除。这种方法保证了每次运行都有一个干净的状态。
   • 数据库快照：如果你的模式很大，可以在每次运行前从已知的“干净”快照恢复，以避免从头开始重建。

2. 用脚本创建已知的良好数据

   • 最小化所需的种子数据：只包含绝对必要的记录（用户、产品参考等）。过大的数据集会减慢测试速度并使调试复杂化。
   • 自动化种子脚本：将种子逻辑保存在版本控制中（SQL 文件或 Node 脚本）。这确保了本地和 CI 环境的一致性。
   • 环境特定的种子数据：如果你有多个测试环境（例如，QA、staging），为每个环境维护种子数据，以确保清晰性和可维护性。

3. 隔离并清理每个测试的数据（在可行的情况下）

   • 每个测试的设置/清理：创建每个测试所需的数据，然后删除或回滚。这确保没有残留数据污染后续测试。
   • 事务回滚：一些框架允许你在数据库事务中运行测试，并在完成后回滚。这在端到端设置中可能很棘手，但对于集成级测试非常有效。
   • 唯一标识符：如果你不能完全隔离数据，生成唯一的测试用户信息（例如，test-user-{timestamp}@example.com）以避免冲突。

4. 与并行或 CI 环境协调

   • 多个数据库实例：如果你并行运行测试，每个工作线程可以指向不同的测试数据库（例如，myapp_test_1、myapp_test_2），以防止覆盖。
   • 每个工作线程的专用容器：为了完全隔离，为每个并行工作线程启动一个完整的数据库容器。这可能会消耗大量资源，但几乎消除了跨测试污染。
   • 性能与并发性：监控 CI 资源使用情况。如果你看到巨大的减速或不稳定性，减少并行工作线程或优化数据访问模式。

5. 模拟或存档数据库调用

   • 何时模拟：如果你的测试关注的是 UI 流程而不是实际的数据库验证，模拟数据库层可以减少复杂性和测试时间。
   • 关键端到端测试使用真实数据库：对于真正的端到端覆盖（例如，验证模式约束、索引或复杂的数据库逻辑），避免模拟。真实数据会暴露真实问题。

6. 持续监控数据库健康

   • 迁移：在运行测试之前，始终将测试数据库迁移到最新的模式版本。模式版本不匹配是导致不稳定的主要原因。
   • 定期清理：如果无法使用临时容器，安排定期清理（截断表或删除旧数据），以防止测试环境随着时间的推移膨胀。
   • 性能跟踪：密切关注测试运行时间。如果你注意到逐渐变慢，调查数据膨胀或缺失的索引。

最后思考

测试数据管理和数据库设置的健壮方法可以放大你对Playwright的投资。结合本文涵盖的通用最佳实践（定位器、自动等待、并行执行），你的团队可以实现：

• 最小化不稳定性：即使面对复杂的有状态数据，测试也是可重复且稳定的。
• 增加信心：真实的端到端覆盖确保应用程序从 UI 到数据库都能正常工作。
• 更大的业务价值：更快的反馈循环和更可靠的构建转化为更高的生产力和更少的生产错误。

原文地址