[Playwright][07] E2E 自动化测试项目实战：从框架搭建到 CI/CD

最近，我使用 Playwright + TypeScript 为一个 HPC Dashboard Web 应用开发了一套端到端（E2E）自动化测试。

之前的工作中，我主要使用 JavaScript + Puppeteer 进行 Web UI 自动化测试。这次选择 Playwright，一方面是为了熟悉新的测试工具，另一方面也希望独立完成一次从测试用例设计、框架组织、测试数据管理到 CI/CD 集成的完整实践。

项目最初只打算覆盖 Upload 模块。随着测试逐步扩展，我遇到了元素定位、异步等待、重复代码、数据依赖和 CI 环境搭建等问题，也开始重新思考如何让自动化测试不仅能够运行，而且更容易维护和复现。

这篇文章先介绍项目的整体情况，后续再按照实际开发顺序，逐篇记录具体的实现过程和踩坑经验。

1. 项目背景

被测系统是一个本地运行的 HPC Dashboard Web 应用，主要用于管理和分析高性能计算任务。

HPC（High Performance Computing）即高性能计算，可以简单理解为：利用高性能服务器或计算机集群，处理普通计算机难以快速完成的大型计算任务。

例如，科研人员使用计算集群完成一次科学模拟后，除了关心计算结果，还可能想知道：

• 这个任务运行了多久？
• 任务是否成功完成？
• 运行过程中使用了多少 CPU 和内存？
• 是否存在资源使用不合理的情况？

HPC Dashboard 就是帮助用户查看、管理和分析这些计算任务信息的 Web 应用。

在 Upload 页面中，用户可以上传两类文件：

• PBS Log（任务运行日志）：类似任务的运行记录，用于了解任务的执行情况。
• Metrics JSON（性能指标文件）：类似任务的性能报告，提供 CPU、内存等资源使用数据。

简单来说，一个关注任务的执行情况，另一个关注任务运行时的性能表现。

上传数据后，用户可以通过其他模块管理任务、查看分析结果和查询相关记录。

项目仓库

项目采用两个独立仓库：

• Private Repository：保存 HPC Dashboard 应用源码。
• Public Repository：保存我独立编写的 Playwright 自动化测试代码。

被测应用的源码不公开，自动化测试代码则单独维护，方便展示测试设计和工程实践。

GitHub 项目地址： [在这里添加公开测试仓库链接]

2. 技术栈

目前项目以 UI E2E 自动化测试为主，后续计划增加 API + UI 混合测试。

3. 自动化测试覆盖范围

目前，自动化测试覆盖 HPC Dashboard 的四个主要模块。

3.1 Upload

Upload 是我最先实现自动化测试的模块。

目前包含五条测试用例，主要覆盖：

• 文件上传
• Job 提交
• Recurring Job（周期性任务）相关流程

3.2 Profile

主要验证任务管理功能，包括：

• 重命名 Job
• 删除 Job
• 通过 Job 名称或 ID 搜索记录

3.3 Recurring Analysis

主要验证分析页面中的交互功能，例如切换不同的分析图表、查看相关结果。

3.4 Job Explorer

主要验证任务查询和结果导出功能，包括：

• 查看 Job 详细信息
• 导出 PDF 和 JSON 文件
• 根据日期范围筛选任务
• 重置筛选条件

以上是目前已经实现的自动化测试范围，并不代表系统所有功能都已覆盖。

4. 开发过程中遇到的问题

项目最开始只是为 Upload 模块编写几条自动化测试，但随着测试逐渐扩展到其他模块，我发现：让测试成功运行只是第一步。

开发过程中，我主要遇到了以下几类问题。

1. 元素定位

页面中存在多个名称相同的按钮或相似的组件，如何准确找到需要操作的元素？

2. 异步等待与测试稳定性

部分页面元素需要异步加载，如何正确等待预期状态，并减少测试中的偶发失败？

3. 代码复用与维护

不同测试文件中存在重复的导航和搜索操作，如何合理组织公共逻辑？

4. 测试执行顺序

部分测试依赖其他测试产生的数据，如何安排不同模块之间的执行流程？

5. 测试数据管理

自动化测试会创建 Job 和 Recurring Job，如何避免测试数据残留影响后续执行？

6. CI/CD 集成

本地测试已经通过，如何在 GitHub Actions 中自动启动被测应用，并完成整个 E2E 测试流程？

这些问题也是我在开发过程中逐步学习和改进的重点。

后续文章会结合实际代码、报错和测试结果，分别记录这些问题的分析过程与解决方法。

5. 当前成果与下一步计划

成果

目前，项目已经完成：

• 四个业务模块的 UI 自动化测试。
• 公共导航和搜索逻辑的重构。
• 基于 Playwright Project Dependencies 的测试执行组织。
• 测试数据命名与自动清理。
• GitHub Actions + Docker Compose 的 E2E 集成。

其中，GitHub Actions 已成功完成一次完整的 E2E 工作流，执行耗时 2 分 55 秒。

这说明项目已经能够在配置好的 CI 环境中完成自动化执行。不过，一次成功运行并不能证明测试长期稳定，后续还需要进一步评估。

下一步计划

完成当前阶段的开发记录后，我计划继续从三个方向完善项目。

API + UI 自动化

在现有 UI 测试基础上，增加后端接口测试，并探索使用 API 辅助准备和清理测试数据。

测试质量评估

通过重复执行、稳定性分析和可控缺陷实验，评估自动化测试的可靠性和缺陷检测能力。

AI Testing

探索使用大语言模型（LLM）辅助生成测试用例，并与人工编写的测试进行对比，分析生成测试的质量与实际可用性。

以上是后续计划，目前还没有作为已实现的功能。

6. 开发日记系列

接下来，我会按照项目的实际开发顺序，记录从编写第一批测试用例，到代码重构、测试数据管理和 CI/CD 集成的过程。

每篇尽量聚焦一个实际开发问题，结合真实代码、报错和测试结果，记录问题产生的原因、解决过程，以及从中学到的东西。

写在最后

这次实践让我重新走了一遍从编写测试用例，到组织测试代码、管理测试数据，再到搭建 CI/CD 环境的完整过程。

项目还不算完善，但我希望通过持续记录，把开发中遇到的问题和解决思路整理下来。

先把测试跑起来，再让它变得更可靠、更容易维护。