Web E2E自动化测试，我们为什么从Jest-playwright转到Playwright框架？

2024软件测试面试刷题，这个小程序（永久刷题），靠它快速找到工作了！（刷题APP的天花板）-CSDN博客文章浏览阅读2k次，点赞85次，收藏11次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题，web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题，还有互动交流板块……https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5501以下为作者观点：

在Mercari团队，QA工程师不仅在开发周期中协助开发团队进行测试，还应对所有平台（iOS、Android、Web和API）上的自动化E2E测试。

最近，我们对 Web 平台的自动化端到端 (E2E) 测试系统进行了更新。在旧系统中，我们遇到了几个问题，包括远程浏览器连接问题、某些情况下的重试机制有问题以及报告中缺少测试用例。在下面的部分中，我将介绍所做的更改并解释其背后的原因。

关于改造，我们对Web E2E测试系统做了两个重大改变。首先，我们将测试框架从Jest-playwright（https://github.com/playwright-community/jest-playwright）转换为Playwright。其次，我们改变了远程浏览器和 CI 平台的架构。它从使用Moon（https://aerokube.com/moon/） 部署的远程浏览器在 CircleCI 上运行回归测试，更改为使用 Playwright 支持的浏览器二进制文件部署在内部 kubernetes 集群中的 Github Actions 自托管运行器。

一 关于旧E2E测试系统

原来的E2E系统架构图

最初，我们使用Jest-playwright并在 CircleCI 上运行。为了连接到我们的 Web 开发环境，我们需要允许外部 CircleCI IP 的访问，但出于安全考虑，我们无法将所有 CircleCI 的 IP 列入白名单。因此，我们找到了一个使用 Moon的解决方案，该服务有助于在 Kubernetes 集群中部署浏览器。所以CircleCI只负责运行E2E代码，它连接到内部集群中的远程浏览器，因此浏览器可以访问我们的Web开发环境。

二 老E2E系统存在的问题

我们已经使用旧的 E2E 系统三年了，在将新版本的 Mercari Web 投入生产之前运行回归测试非常有用。此外，该报告还可以帮助我们跟踪和分析每次测试运行中的不稳定测试。然而，随着时间的推移，测试用例的增多，我们逐渐发现了各种问题。

1.Jest-playwright已经过时了

这些年来，Playwright这些年已经变得成熟了。然而，Jest-playwright 已经放慢了对添加新功能的支持，现在宣布他们建议使用原生 Playwright 作为测试框架。

当我们开始构建旧的E2E系统时，我们选择了Jest-playwright，因为当时Playwright对编写测试用例的功能支持有限。此外，我们的开发人员已经熟悉流行的测试框架Jest，这使得使用 Jest-playwright 更快地构建类似 Jest 的 UI 测试。不过，Playwright融入了更多常用的测试功能和特性，用于UI E2E测试。我们需要更改框架，以便为我们的 E2E 测试获得更大的灵活性和优化的功能。

2. 远程浏览器连接问题

我们遇到的另一个问题是 Moon 提供的远程浏览器。

由于浏览器由集群内的另一个服务控制，因此通常不会大量启动浏览器。但对于大量用例的端到端测试，往往需要并行执行，从而导致连接数较多。优化 Pod 资源以有效地处理此问题并不简单。

此外，每个测试用例都需要等待浏览器连接才能开始执行，这最终降低了单个E2E测试的整体执行速度。有些情况甚至无法执行，因为在给定的超时时间内无法建立浏览器连接。

3.某些情况下有问题的重试机制

在旧的 E2E 系统中，我们希望使用 jest.retryTimes 重试失败测试的选项，但我们使用的名为“ Jest-allure ”（https://github.com/zaqqaz/jest-allure）的报告库仅适用于“ Jest-Jasmine2 ”（https://github.com/jestjs/jest/tree/main/packages/jest-jasmine2）测试运行程序，而该测试运行程序又不支持该 jest.retryTimes 选项。相反，它提供了一个名为 onlyFailures 的命令行选项，该选项允许根据状态缓存仅执行上次运行中的失败案例。

例如：

npm run test || npm run test --onlyFailures || npm run test --onlyFailures

此选项似乎是重试的可行替代方案。然而，至关重要的是，如果测试用例由于远程浏览器连接问题而失败，Jest 不会将这些测试记录在状态缓存中。因此，这些测试用例将不会在使用命令行选项的后续运行中重试。

4. 报告中缺少一些测试用例

如前所述，我们使用名为“Jest-allure”的报告库，它根据最新的测试运行生成报告。这意味着，如果在测试运行期间存在远程浏览器连接问题，这些测试用例将永远不会出现在报告中。在检查报告时，这可能会非常令人困惑。在最坏的情况下，当moon环境不稳定时，单次端到端运行有可能丢失超过 50% 的测试。这种不稳定性会极大地影响测试结果的可靠性和完整性。

测试报告中缺少测试记录示例

三 主要挑战和解决方案

最具挑战性的部分不是更新框架或重构代码。它实际上使我们旧的E2E系统保持运行，因为这是发布前的重要检查，工程师还通过运行E2E测试来确认回归。迁移需要几天的时间，所以我们不能就停止我们的端到端测试，让大家等到框架迁移完成。此外，网络开发正在进行中，因此我们还需要在迁移期间保持页面对象元素和测试用例保持最新。

由于每周都会大量使用 E2E 测试来确保每个版本中 Web 应用程序的稳定性，因此我们决定创建一个新的 E2E 存储库。在迁移期间，我们需要更新新旧存储库的元素和测试用例以维持其功能。这一决定使我们能够更加灵活地在新存储库中实现所有所需的更改，而不会影响 E2E 测试的当前使用。

第一个问题的解决方案相对简单。我们只需要更新样式和功能即可使用 Playwright。一旦我们完成了必要的配置设置，我们就可以开始将测试用例分配给我们的团队成员。他们的任务将涉及进行所需的更改并确保所有测试用例都可以使用 Playwright 的新样式成功执行。

关于第二个问题，我们的 CI/CD 团队已开始提供在我们的网络中构建的自托管运行器。这意味着我们现在可以使用 Playwright 内置浏览器二进制文件，而不再局限于使用 Moon。因此，我们只需创建一些 GitHub Actions 工作流程即可使我们的 E2E 测试在自托管运行器上运行。

至于第三个问题，由于我们最近开始使用Playwright，我们可以轻松切换到使用其内置的重试机制。我们可以通过在相应的配置文件中应用必要的配置更改来实现这一点。

示例playwright.config​​​​​​​

 const config: PlaywrightTestConfig = {   retries: 2,}

最后，对于报告中缺少的测试用例，我们实际上可以通过在自托管运行器上使用 Playwright 的内置浏览器二进制文件来解决它。由于不再有与月球的连接问题，报告问题中缺少的测试用例已自动解决。不过，我们仍然计划利用 Playwright 提供的 HTML 报告来提高测试结果的可见性。作为该计划的一部分，我们还创建了一个 CI 工作流程，将报告存储在云存储中并将其托管为静态页面。这样，每个人都可以更轻松地查看报告并跟踪测试结果。

结果，我们不仅成功迁移了我们的库，而且还解决了旧的端到端测试系统中存在的问题。性能得到了提高，我们甚至通过消除对月球许可证的需求来降低成本。

迁移后的架构图

结论

整个迁移过程历时半年左右。因为QA团队需要主要帮助其他团队进行开发测试，并利用其余时间进行自动化改进。

虽然系统更新并未涉及使用任何最新的新技术，但有效解决了长期存在的问题。借助Playwright提供的增强功能，我们预计E2E测试系统的使用将变得更加灵活。我们希望未来有机会分享端到端测试系统的进一步改进和新举措。此外，还要感谢CI/CD团队提供的内部自托管运行器服务。这极大地促进了通常需要仔细考虑安全问题的CI流程。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。