Playwright：测试结构（微小的部分却带来巨大影响）

Source: Dev.to

介绍

嗨，大家好 👋！这是我加入 dev.to 以来的第一篇帖子。

我是一个刚从客服转岗到 QA 的初级 QA 工程师。虽然我的经验还不多——尤其是在深入讨论自动化测试方面——但我在日常工作中注意到一件重要的事：

许多 QA 工程师编写自动化测试，但并非所有人真正理解测试结构。如果没有清晰且经过深思熟虑的测试结构，自动化测试很快就会变得：

• 难以维护
• 测试失败时难以调试
• 随着产品增长而扩展风险大

一个简单但常被忽视的改进是 我们如何组织自动化测试。虽然测试结构听起来很基础，但许多 QA 工程师——尤其是那些刚接触自动化或在真实项目中实践经验有限的人——可能没有充分意识到它的重要性。

在本文中，我将分享一些关于管理测试结构的简单技巧，基于我迄今为止的学习。这可能是一个小话题，但影响却很大。

📂 默认 Playwright 测试结构（起点）

tests/
 ├── example.spec.ts
 ├── another-test.spec.ts
playwright.config.ts

这种布局在演示、教程或非常小的项目中运行良好。但随着测试套件的增长，结构很快会带来不便。

默认结构的常见问题

• 选择器在多个测试文件中重复
• 测试变得冗长且难以阅读
• UI 变更需要修改大量测试文件
• 调试失败的测试耗时更长

正因如此，我在项目中决定尽早摆脱默认结构。

🧱 仓库中使用的自定义测试结构

与其把所有内容直接放在 *.spec.ts 文件中，我将关注点明确地分离开来。

高层结构（简化版）

tests/
 ├── pages/
 ├── fixtures/
 ├── utils/
 ├── ai/
 │   └── ai-movie.spec.ts

📄 1. 页面对象模型 (POM)

pages/ 文件夹包含处理以下内容的页面类：

• 选择器
• 页面操作（点击、填写、提交等）

测试通过以下方法与页面交互：

• searchMovie()
• submitPrompt()
• readAIResponse()

为什么这很重要

• UI 更改仅影响页面文件
• 测试文件保持简洁易读
• 减少选择器重复

与默认的 Playwright 方法相比，这大幅降低了维护成本。

🔁 2. 共享设置的 Fixtures

fixtures/ 文件夹包含可重用的设置逻辑，例如：

• 导航到应用
• 准备测试状态
• 共享测试配置

相较于默认结构的优势

• 测试关注行为，而非设置
• 更容易标准化测试流程
• 减少复制粘贴错误

🧰 3. 复杂逻辑的工具

在 AI 相关的测试中，一些验证并非简单（例如，检查响应格式、验证内容规则、一致地处理异步行为）。这些逻辑代码位于 utils/ 中。

为什么它优于默认结构

• 断言保持可复用
• 测试文件不会变得臃肿
• 可以在不触及测试的情况下改进逻辑

📁 4. 基于特性的测试分组

而不是随机的规范文件，测试按特性进行分组。例如：

• 与 AI 相关的测试放在自己的文件夹中（tests/ai/）
• 将来的特性可以遵循相同的模式

与默认结构相比

• 更易于导航
• 所有权更清晰
• 随着特性增长，扩展性更好

🧠 最后思考

即使作为一名初级 QA 工程师，我也了解到良好的结构是一种技能，而不是奢侈。

你不需要

• 一个庞大的项目
• 多年的经验
• 完美的架构

你真正需要的是这样的思维方式： 自动化测试是长期资产，而不是一次性脚本。

通过超越 Playwright 的默认结构并有意地组织测试，你可以：

• 减少未来的痛点
• 改善协作
• 及早养成更好的测试习惯

希望这篇文章能帮助其他初级 QA 避免我仍在学习的错误 🚀

随意查看我的项目并将其作为参考。