技术选型其实主要看架构师的偏好，此文主要写给非技术负责人看，给一个方案让他确认。文章的大部分内容来源于 Vue 测试，部分内容参考 从一次故障聊聊前端 UI 自动化测试。如有侵权请联系删除。
虽然单元测试为所写的代码提供了一定程度的验证，但单元测试和组件测试在部署到生产时，对应用程序整体覆盖的能力有限。因此，端到端（E2E）测试针对的可以说是应用程序最重要的方面：当用户实际使用你的应用程序时发生了什么。
换句话说，E2E 测试验证了你的应用程序中的所有层级。这不仅包括你的前端代码，还包括所有相关的后端服务和基础设施，它们更能代表你的用户将身处的环境。通过测试用户行为如何影响你的应用程序，E2E 测试往往是应用程序是否能够如预期运行的关键。
E2E 测试解决方案
由于不可靠且拖慢了开发过程，导致大家对 Web 上的端到端（E2E）测试的评价并不好，但现代 E2E 工具已经在创建更可靠、更有用和交互性更好的测试方面取得了很大进步。在选择测试框架时通常需要结合应用程序的一些注意事项，常见的诉求如下：
跨浏览器测试
E2E 测试的一个最基本的收益就是你可以了解你的应用程序在多个不同浏览器上运行的情况。尽管理想情况应该是 100% 的跨浏览器覆盖率，但重要的是要注意跨浏览器测试对团队资源的回报是递减的，因为需要额外的时间和机器能力来持续运行它们。因此，在选择应用程序所需的跨浏览器测试量时，注意权衡是很有必要的。
更快的反馈
E2E 测试和相应开发过程的主要问题之一是，运行整个套件需要很长的时间。通常情况下，这只在持续集成和部署（CI/CD）管道中进行。现代的 E2E 测试框架通过增加并行化等功能来帮助解决这个问题，这使得 CI/CD 管道的运行速度往往比以前快了几倍。此外，在本地开发时，能够有选择地运行你正在工作的页面的单个测试，同时还提供测试的热重载，大大提高了开发人员的工作流程和生产力。
第一优先级的调试体验
传统上，开发人员依靠扫描终端窗口中的日志来帮助确定测试中出现的问题，而现代 E2E 测试框架允许开发人员利用他们已经熟悉的工具，例如浏览器开发工具。
无头模式下的可见性
当 E2E 测试在 CI/CD 管道中运行时，它们通常在无头浏览器（即不带界面的浏览器）中运行。因此，当错误发生时，现代 E2E 测试框架能够在不同的测试阶段看到应用程序的快照和/或视频，对此类关键功能会提供第一优先级的支持，这保证了对错误发生原因更有迹可循。而在很早以前，要手动维护这些集成是非常繁琐的。
推荐
-
Cypress 提供了最完整的 E2E 解决方案，具有信息丰富的图形界面、出色的调试性、内置断言和存储、并行化和快照等诸多特性。它还提供对 组件测试 的支持。不过，它只支持测试基于 Chromium 的浏览器和 Firefox
一个非常好的 E2E 测试解决方案，支持测试范围更广的浏览器品类Chromium, Firefox 和 WebKit
一个基于 Selenium WebDriver 的 E2E 测试解决方案。它的浏览器品类支持范围是最广的
-
一个 Node 库，由 Chrome 官方团队进行维护。提供了一组用来操纵 Chrome 的 API，和 Chrome 天生适配。Chrome 新版本内置的 Recorder 功能能导出 Puppeteer 脚本
一款基于 Node.js 的端到端 Web 自动化测试框架，支持 TypeScript 或 JavaScript 。兼容 Windows、MacOS 和 Linux 系统，同时也支持桌面、移动端所有的浏览器，并且无需安装浏览器对应的 WebDriver。支持多角色无缝切换，默认支持。
推荐结论
以上所有的测试库、方案均满足无头模式、快速反馈的诉求。从开发体验上 Nightwatch 被排除；从方案完整性看 Cypress 的使用者最多、场景最全；从编写、后期维护的成本（免费）出发，Puppeteer 理论上由于 Chrome Recorder功能的内置应是优选。但它们都需要下载 WebDriver，由于网络问题，大概率下载失败，无 WebDriver 的 TestCafe 成为首选（官方提供的 IDE TestCafe Studio 支持录制和断言，上手几乎0成本，收费，免费体验30天）。
推荐 TestCafe。
价值
使用 E2E 的收益价值可按照自动化测试公式计算：
自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
简而言之，迭代越频繁，维护成本越高的项目，添加自动化测试的价值越高。在基建项目或频繁迭代项目中引入前端 UI 自动化测试，可以大大减少每次迭代后手动测试的时间。比起手动测试，前端 UI 自动化测试测试的更快也更彻底。
另一个方面，随着前端技术的高速发展，各个公司的前端开发、监控体系已经很完善了，但是缺少前端在测试方向上的延伸。而前端 UI 自动化测试最大的价值，就是在前端部分，弥补开发和监控之间的空白区域，形成一个完整的闭环，三管齐下，极大地保障了项目的质量。
展望
E2E 方向：
-
针对单个项目，进行一系列关键功能的测试，。不过如果需要追求测试覆盖率的话，比较耗费时间，算是一种比较常规、精细的测试方案，所以比较适合一些长期维护的基建项目或者大型业务项目，缺点在于活动页基本覆盖不了。
-
针对所有项目，添加一个自动化测试的脚手架（或者平台化），能够通过配置项，自动访问目标页面，并进行一系列的 E2E 测试，根据不同的结果采取截图、生成 pdf、报警等不同处理方案。
针对所有项目建设通用平台也是众多 E2E 开源方案的收费点，如 Cypress 的面板、TestCafe 的 IDE。也正是带着商业性质，也让它们能快速迭代，比其他纯开源方案要完善的很多。如果需要完善相关基建，可以从此处入手。
近期大火的 API 文档、API 调试、API Mock、API 自动化测试工具 Apifox 也走了类似路线。
