1. 项目概述从“黑盒”到“白盒”的测试思维跃迁最近在团队内部做技术分享聊到前端质量保障体系时发现很多同学对单元测试、集成测试还能说上几句但一提到E2E端到端测试反应大多是“知道很重要但没怎么写过”、“感觉配置起来很麻烦”、“跑起来太慢了不如手动点点”。这让我想起几年前我刚接触E2E测试时的状态完全一样。我们往往陷在“写代码-手动验证-提测”的循环里对于如何用代码模拟真实用户操作来保障核心流程既感到必要又觉得无从下手。这个项目就是想把我这几年从零开始摸索E2E测试特别是深度使用Cypress这套工具的心得进行一次系统性的梳理和输出。它不仅仅是一个工具的使用教程更是一次测试思维的升级我们如何从一个功能的“实现者”转变为核心业务流程的“守护者”E2E测试就是连接开发与真实用户场景的那座桥梁。通过它我们可以把“用户登录-浏览商品-加入购物车-下单支付”这一系列关键路径用自动化的脚本固化下来确保每次代码变更都不会破坏这些“生命线”。无论你是前端开发想提升代码的健壮性还是测试同学希望引入更高效的自动化手段甚至是团队负责人关注交付质量与效率理解并实践E2E测试都至关重要。接下来我会从E2E的核心概念破题然后手把手带你用Cypress实现第一个测试案例并深入那些官方文档不会细讲但实际工作中一定会踩到的“坑”。我们的目标很明确让你不仅能看懂更能立刻动手为自己的项目添上一套可靠的自动化守护屏障。2. E2E测试核心价值与适用场景剖析2.1 什么是真正的“端到端”测试很多人对E2E测试有个误解认为它就是“用代码模拟点击和输入”。这个定义只对了一半而且忽略了最精髓的部分。E2E测试的完整定义是模拟真实用户的操作场景从用户界面UI发起遍历整个应用的所有层级前端、网络、后端、数据库等最终验证完整业务流程是否正确的测试方法。关键在于“所有层级”和“真实用户场景”。举个例子一个“用户登录”的单元测试可能只验证一个login(username, password)函数能否返回正确的token。但一个E2E测试会这样进行打开浏览器访问登录页。在邮箱输入框输入测试账号。在密码框输入密码甚至处理验证码。点击“登录”按钮。等待页面跳转或状态更新。断言浏览器地址栏是否跳转到首页或用户中心并且页面上是否显示了正确的用户名。这个过程涉及了前端渲染、事件处理、HTTP网络请求、后端身份验证、会话管理、数据库查询、最终响应返回和前端状态更新。它测试的不是一个孤立的函数而是整个系统作为一个黑盒其输入用户操作和输出UI反馈是否符合预期。这就像你不是在检查汽车的每一个零件单元测试而是亲自坐进驾驶座完成一次从家到公司的完整驾驶来验证这辆车能否正常工作。2.2 为什么你的项目需要E2E测试在敏捷开发和持续交付的背景下E2E测试的价值被无限放大。我总结为以下四个核心价值点第一捕获跨模块的集成缺陷。这是E2E测试最无可替代的作用。开发A修改了用户信息接口的返回字段开发B的前端组件依赖了这个字段进行展示。单元测试和集成测试可能各自都通过但组合在一起页面就可能崩溃或显示异常。E2E测试站在用户视角能第一时间发现这类“接口契约”破坏或数据流不一致的问题。第二守护核心业务流建立发布信心。每个产品都有几条绝对不能出错的核心流程比如电商的下单支付、社交应用的发布与互动、SaaS产品的注册与订阅。将这些流程编写成E2E测试用例并集成到CI/CD流水线中每次代码合并或发布前自动运行。只要测试通过你就能有极高的信心保证这次改动没有“炸掉”主流程。这相当于给核心业务上了一道自动化的保险。第三替代大量重复、枯燥的回归测试。想象一下每次发版前测试同学都要手动把主流程走一遍耗时耗力且容易因疲劳出错。E2E自动化脚本可以7x24小时无怨无悔地执行这些任务释放人力去进行更有价值的探索性测试。从团队效率来看这是一笔非常划算的投资。第四提供可复现的缺陷场景。当测试或用户报出一个Bug时描述往往是“我点了哪里哪里然后好像就出错了”。开发重现起来非常困难。如果这个Bug场景已经被E2E测试覆盖或者我们可以立即为其编写一个对应的E2E测试用例那么这个用例本身就是一份完美、可自动执行的Bug报告。它清晰定义了操作步骤和预期结果开发修复后该用例也就成了防止回归的守护者。注意E2E测试不是银弹它运行较慢、维护成本较高。因此正确的策略是将其用于覆盖“少而精”的核心用户旅程User Journey而非所有功能点。它与单元测试快速、覆盖底层逻辑、集成测试验证模块间协作共同构成一个健康的测试金字塔。2.3 Cypress为何成为现代E2E测试的首选工欲善其事必先利其器。在E2E测试领域Cypress几乎重塑了开发者的体验。在它之前Selenium是事实标准但配置复杂、运行不稳定、调试困难等问题广为诟病。Cypress的出现带来了几个革命性的改进1. 架构革新运行在浏览器内部。这是与Selenium最根本的不同。Selenium通过WebDriver协议远程控制浏览器命令通过网络传输天生有延迟和异步问题。而Cypress直接运行在浏览器内部与你的应用共享同一个运行环境。这意味着它的执行命令和操作DOM的速度极快且能直接访问window、document等对象甚至可以cy.debug()来使用浏览器开发者工具。2. 自动等待与实时重载。“元素找不到”是传统E2E测试最常见的报错通常需要手动添加各种sleep等待。Cypress内置了智能的重试和等待机制。当你写cy.get(‘.btn’).click()时Cypress会自动等待直到.btn元素在DOM中存在、可见、且不再被动画覆盖时才会执行点击。这大大减少了脆弱的“等待”代码。此外其测试运行器支持实时重载你修改测试代码后浏览器和测试会自动重新运行体验如同前端热更新。3. 时间旅行与可视化调试。Cypress Test Runner提供了一个无与伦比的调试界面。它记录下测试执行的每一个步骤你可以像看视频回放一样随时点击之前的任何一个命令查看当时的应用程序状态、DOM结构、网络请求和Console日志。这使定位问题变得异常直观。4. 对现代前端框架的友好支持。Cypress天生对React、Vue、Angular等框架的单页应用SPA有很好的支持能正确处理前端路由、状态管理带来的异步更新问题。其社区也有丰富的插件例如cypress/react可以直接挂载React组件进行测试。正是这些特性让Cypress的学习曲线更平缓开发体验更愉悦测试也更为稳定可靠。接下来我们就进入实战环节。3. Cypress环境搭建与核心概念解析3.1 从零开始初始化一个Cypress项目假设我们有一个基于Vite的React项目其他类型项目流程类似让我们一步步集成Cypress。第一步安装Cypress。在你的项目根目录下通过npm或yarn安装Cypress。作为开发依赖安装是最佳实践。npm install cypress --save-dev # 或 yarn add cypress -D第二步打开Cypress。首次安装后可以通过npx来启动Cypress的交互式界面。这个命令会完成Cypress的二进制文件下载和初始化。npx cypress open执行后Cypress会做两件事1. 在你的项目根目录下创建一个cypress文件夹里面包含了默认的目录结构和示例文件。2. 打开Cypress Test Runner图形化界面。第三步理解项目结构。初始化后你的cypress文件夹结构如下cypress/ ├── e2e/ # 测试用例文件存放目录旧版本可能是 integration/ │ └── example.cy.js # Cypress提供的示例测试文件 ├── fixtures/ # 固定测试数据文件目录如静态JSON │ └── example.json ├── support/ # 支持文件目录 │ ├── commands.js # 自定义命令文件 │ └── e2e.js # 测试运行前的全局配置和导入 └── downloads/ # 测试中下载文件的存储目录默认不存在需要时创建 └── screenshots/ # 测试失败时的截图目录运行后生成 └── videos/ # 测试录屏目录需配置后生成对于新项目我建议先删除e2e/下的example.cy.js并从自己的第一个测试用例开始写起避免被示例干扰。第四步选择测试类型。在Cypress Test Runner打开的界面中它会让你选择测试类型。对于E2E测试我们选择“E2E Testing”。然后它会让你选择一个浏览器如Chrome, Edge, Electron并为你创建cypress.config.js配置文件。这个文件是Cypress的核心配置。一个基础的cypress.config.js配置如下const { defineConfig } require(cypress) module.exports defineConfig({ e2e: { // 设置测试文件匹配模式 specPattern: cypress/e2e/**/*.cy.{js,jsx,ts,tsx}, // 设置基础URL你的测试中 cy.visit(‘/‘) 就会访问这个地址 baseUrl: http://localhost:5173, // 假设你的开发服务器运行在5173端口 // 每个测试用例执行前的钩子函数 setupNodeEvents(on, config) { // 可以在这里配置插件任务例如截图、录屏、报告生成等 }, }, })3.2 Cypress的核心命令与交互模式Cypress的API设计非常语义化其核心是链式调用。几乎所有操作都从cy这个全局对象开始。1. 访问与导航cy.visit()与cy.go()cy.visit()用于加载一个页面是测试的起点。cy.visit(/login) // 访问 baseUrl ‘/login’ cy.visit(https://www.example.com) // 访问外部绝对URLcy.go()用于在浏览器历史中前进或后退。cy.go(back) // 相当于点击浏览器后退按钮 cy.go(forward)2. 查询元素cy.get()与cy.contains()这是与页面交互的基础。cy.get()使用选择器同CSS选择器查找元素。cy.get(input[typeemail]) // 通过属性选择器查找邮箱输入框 cy.get(.submit-btn) // 通过类名查找提交按钮 cy.get(#username) // 通过ID查找用户名输入框cy.contains()用于查找包含特定文本内容的元素这在测试中非常实用。cy.contains(登录) // 找到页面上第一个包含“登录”二字的元素可能是按钮或链接 cy.get(nav).contains(首页) // 在nav元素内查找包含“首页”的元素范围更精确。3. 用户交互cy.click(),cy.type(),cy.clear()模拟用户点击、输入和清空操作。cy.get(.login-btn).click() // 点击登录按钮 cy.get(#email).type(testexample.com) // 在邮箱框输入内容 cy.get(#email).type(testexample.com{enter}) // 输入后按回车键 cy.get(#search).clear().type(new keyword) // 先清空搜索框再输入新内容4. 断言should()与and()断言是验证测试结果的关键。Cypress基于Chai断言库语法非常直观。cy.get(.welcome-msg).should(contain, 欢迎回来张三) // 元素应包含某文本 cy.get(table tr).should(have.length, 10) // 表格应有10行 cy.get(.modal).should(be.visible) // 模态框应可见 cy.get(input#agree).should(be.checked) // 复选框应被选中 // 链式多个断言 cy.get(.alert) .should(have.class, success) // 应有success类 .and(be.visible) // 并且应可见 .and(contain, 操作成功) // 并且包含“操作成功”文本5. 网络请求控制cy.intercept()与cy.wait()这是实现稳定测试和测试边缘案例的利器。你可以拦截、存根stub或监听应用发出的HTTP请求。// 监听一个GET请求并断言其状态码和响应体 cy.intercept(GET, /api/user/profile).as(getProfile) // 给这个请求起个别名 // ...执行某些操作触发请求 cy.wait(getProfile).its(response.statusCode).should(eq, 200) // 存根Stub一个请求直接返回模拟数据不依赖真实后端 cy.intercept(POST, /api/login, { statusCode: 200, body: { token: fake-jwt-token, username: mockUser } }).as(loginStub) cy.get(#login-btn).click() cy.wait(loginStub) // 等待这个被存根的请求完成理解这些核心命令后你已经具备了编写大多数E2E测试用例的能力。接下来我们通过一个完整的案例来串联这些知识。4. 实战编写一个用户登录流程的E2E测试案例让我们为一个假设的Web应用编写一个完整的登录流程测试。这个测试将覆盖访问页面、输入凭证、提交表单、验证登录成功后的跳转和状态展示。4.1 测试用例设计与文件创建首先在cypress/e2e目录下创建一个新的测试文件例如login.cy.js。Cypress推荐使用.cy.{js,ts}作为测试文件后缀。一个完整的测试用例通常包含多个it块测试用例它们被组织在一个describe块测试套件中。我们为“用户登录”功能创建一个套件。// cypress/e2e/login.cy.js describe(用户登录流程, () { // 在每个测试用例(it)运行前执行常用于准备测试环境 beforeEach(() { // 访问登录页面。baseUrl已在配置中设置为开发服务器地址 cy.visit(/login) // 确保页面已加载完成通常通过等待某个关键元素出现来判断 cy.get(form#login-form).should(be.visible) }) it(使用正确的邮箱和密码可以成功登录, () { // 测试步骤将写在这里 }) it(输入错误的密码应显示错误提示, () { // 另一个测试用例 }) // ... 更多测试用例 })4.2 实现“成功登录”测试用例现在填充第一个测试用例的具体步骤。我们将模拟用户输入正确的账号密码并验证登录后的状态。it(使用正确的邮箱和密码可以成功登录, () { // 1. 输入邮箱 // 假设登录表单中邮箱输入框的id是‘email’ cy.get(input#email) .type(valid_userexample.com) // 输入有效邮箱 .should(have.value, valid_userexample.com) // 断言输入框的值已更新 // 2. 输入密码 cy.get(input#password) .type(CorrectPassword123) // 输入有效密码 .should(have.value, CorrectPassword123) // 3. 点击登录按钮 // 假设按钮的类名是‘.login-submit-btn’ cy.get(button.login-submit-btn) .click() // 4. 验证登录成功后的行为 // 行为1页面URL应跳转到首页‘/dashboard’ cy.url().should(include, /dashboard) // 行为2页面应显示欢迎用户的提示信息 // 假设登录成功后页面顶部有一个显示用户名的元素类名为‘.user-greeting’ cy.get(.user-greeting) .should(be.visible) .and(contain, valid_userexample.com) // 包含用户名 // 行为3登录表单应消失 cy.get(form#login-form).should(not.exist) // 可选行为4验证是否发起了正确的API请求 // 如果你知道登录成功的API端点可以监听它 // cy.intercept(POST, /api/auth/login).as(loginRequest) // cy.get(button.login-submit-btn).click() // cy.wait(loginRequest).its(response.statusCode).should(eq, 200) })这个测试用例清晰地定义了一个“快乐路径”Happy Path。Cypress会严格按照这个顺序执行命令并在每个should断言处自动等待条件满足。4.3 实现“失败登录”测试用例一个健壮的测试套件不仅要测成功情况更要测失败和边界情况。我们来测试密码错误的情况。it(输入错误的密码应显示错误提示, () { // 输入正确的邮箱 cy.get(input#email).type(valid_userexample.com) // 输入错误的密码 cy.get(input#password).type(WrongPassword) // 点击登录按钮 cy.get(button.login-submit-btn).click() // 验证错误提示出现 // 假设应用会在一个类名为‘.error-message’的元素中显示错误信息 cy.get(.error-message) .should(be.visible) // 元素应可见 .and(have.css, color, rgb(255, 0, 0)) // 并且颜色是红色可选验证样式 .and(contain, 密码错误) // 并且包含特定的错误文本 // 验证页面没有跳转仍然停留在登录页 cy.url().should(include, /login) // 验证登录表单仍然存在 cy.get(form#login-form).should(be.visible) })4.4 使用Fixture管理测试数据将测试数据如用户凭证硬编码在测试文件中不是好习惯。Cypress提供了fixtures目录来存放静态的测试数据。我们可以创建一个users.json文件。// cypress/fixtures/users.json { validUser: { email: testmyapp.com, password: MySecurePass123, username: 测试用户 }, invalidUser: { email: testmyapp.com, password: wrong } }然后在测试用例中加载并使用它it(使用Fixture数据成功登录, () { // 加载fixture文件 cy.fixture(users).then((userData) { const user userData.validUser cy.get(input#email).type(user.email) cy.get(input#password).type(user.password) cy.get(button.login-submit-btn).click() cy.url().should(include, /dashboard) cy.get(.user-greeting).should(contain, user.username) }) })使用Fixture的好处是数据与代码分离便于统一管理和修改。例如当测试环境改变时只需更新一个JSON文件。至此一个基础但完整的登录E2E测试套件就完成了。你可以运行npx cypress open在图形化界面中选择这个测试文件来运行并观察整个过程。5. 高级技巧与最佳实践让测试更稳定、更高效编写能运行的测试只是第一步编写稳定、可维护、高效的测试才是终极目标。下面分享一些从实战中总结出的核心经验。5.1 编写稳定、不脆弱的测试选择器测试失败最常见的原因之一是“元素找不到”而这往往是因为使用了糟糕的选择器。避免使用以下脆弱的选择器基于样式或位置的选择器如.btn-primary、:nth-child(3)。一旦UI改版样式类名或结构顺序变化测试就挂了。自动生成的动态ID或类名如id”ember123”。它们每次渲染都可能变化。过于复杂或冗长的CSS路径如div div main section:nth-child(2) div button。任何中间节点的变动都会导致断裂。推荐使用以下策略优先使用>!-- 前端代码 -- button>// 测试代码 - 极其稳定 cy.get([data-testidlogin-submit-btn]).click()这种方式将测试与UI样式和结构完全解耦只要业务功能不变这个属性就可以一直存在。使用语义化的ID或类名如果无法添加>// 不推荐可能在页面上找到多个“保存”按钮 cy.contains(保存).click() // 推荐限定在特定的工具栏或表单内 cy.get(.editor-toolbar).contains(保存).click()5.2 利用自定义命令封装重复逻辑如果你发现多组测试都在重复执行相同的操作序列例如登录、进入某个页面就应该将其封装为自定义命令。这能极大提升代码的复用性和可读性。在cypress/support/commands.js文件中添加自定义命令// cypress/support/commands.js // 自定义登录命令 Cypress.Commands.add(login, (email, password) { cy.visit(/login) cy.get(input#email).type(email) cy.get(input#password).type(password) cy.get(button[data-testidlogin-submit]).click() // 可以在这里添加一个通用断言确保登录成功比如跳转到了首页 cy.url().should(include, /dashboard) }) // 使用Fixture数据的快捷登录命令 Cypress.Commands.add(loginByFixture, (userKey) { cy.fixture(users).then((users) { const user users[userKey] cy.login(user.email, user.password) }) })然后在任何测试文件中你就可以像使用内置命令一样使用它们// 在你的测试用例中 beforeEach(() { // 每次测试前用一个有效用户登录 cy.loginByFixture(validUser) }) it(登录后可以访问个人中心, () { // 此时已经处于登录状态 cy.visit(/profile) // ... 进行个人中心的测试断言 })5.3 配置管理与环境变量不同环境开发、测试、预生产的测试配置如baseUrl、API密钥、测试账号通常不同。硬编码在cypress.config.js里是不可维护的。Cypress支持通过cypress.config.js和Cypress.env()来管理环境变量。方法一在cypress.config.js中配置// cypress.config.js const { defineConfig } require(cypress) module.exports defineConfig({ e2e: { baseUrl: process.env.CYPRESS_BASE_URL || http://localhost:5173, // 从环境变量读取默认本地 env: { // 定义一些项目级的环境变量 apiUrl: https://api.staging.myapp.com, adminEmail: admintest.com }, setupNodeEvents(on, config) { // 可以在这里根据环境动态修改config.env const env process.env.NODE_ENV || development if (env staging) { config.env.apiUrl https://api.staging.myapp.com } else if (env production) { config.env.apiUrl https://api.myapp.com } return config }, }, })方法二使用cypress.env.json文件不推荐提交到版本库创建一个cypress.env.json文件存放敏感信息。{ secret_api_key: your-secret-key-here, test_user_password: env-password }在测试中通过Cypress.env(‘key’)访问。方法三通过命令行传递npx cypress run --env baseUrlhttps://staging.myapp.com,apiKeyabc123在测试中统一使用Cypress.env(‘baseUrl’)来获取这样就能轻松实现多环境切换。5.4 测试数据清理与保持独立E2E测试可能会在系统中创建数据如新建一个订单。为了保证测试的独立性和可重复性必须在测试前后清理数据。策略一通过API清理推荐如果后端提供了API可以在beforeEach或afterEach钩子中调用。describe(订单测试, () { beforeEach(() { // 测试前通过API清理该测试用户的旧订单 cy.request({ method: DELETE, url: ${Cypress.env(apiUrl)}/test-cleanup/orders, headers: { Authorization: Bearer ${testToken} } }) // 然后登录 cy.loginByFixture(validUser) }) it(可以创建新订单, () { // 测试创建订单... // 这个测试可以安全运行多次因为每次运行前数据都被清理了 }) })策略二使用测试隔离账号为自动化测试专门准备一套独立的测试账号和数据集与开发、手动测试的数据隔离开。这样即使测试数据没有被完美清理也不会影响其他环境。策略三利用数据库种子Seed在测试套件开始前运行一个脚本将数据库重置到一个已知的干净状态。这通常在CI/CD流水线中与docker-compose配合完成。6. 常见问题排查与调试技巧实录即使遵循了最佳实践在实际编写和运行测试时你依然会遇到各种问题。下面是我遇到的一些典型问题及其解决方案。6.1 “元素未找到”或“超时”错误这是Cypress新手遇到最多的问题。可能原因及解决方案问题现象可能原因解决方案cy.get(...).click()超时1. 元素真的不存在。2. 元素被隐藏display: none或visibility: hidden。3. 元素被其他元素覆盖如弹窗、遮罩层。4. 页面尚未加载完成或动态内容未渲染。1. 使用cy.get(...).should(‘exist’)先断言存在。2. 使用.should(‘be.visible’)断言可见。3. 检查是否有覆盖物或使用{force: true}选项强制点击慎用。4. 在访问页面或操作后等待某个标志性元素出现如cy.get(‘.loaded-indicator’).should(‘be.visible’)。cy.contains(...)找不到文本1. 文本有空格或大小写不匹配。2. 文本是动态加载的尚未出现。3. 文本在Shadow DOM内Cypress默认不支持。1. 检查文本精确匹配或使用正则表达式cy.contains(/some text/i)。2. 增加等待或等待父元素出现。3. 需要开启实验性Shadow DOM支持或通过JavaScript直接访问Shadow Root。异步操作后元素状态未更新点击按钮后触发了API请求UI在请求成功后更新。测试代码执行太快。不要用cy.wait(5000)这种固定等待应等待一个明确的“完成”信号。最佳实践是1.等待网络请求cy.intercept(...).as(‘req’)-cy.wait(‘req’)。2.等待UI状态cy.get(‘.loading’).should(‘not.exist’)或cy.get(‘.success-message’).should(‘be.visible’)。调试技巧使用cy.pause()在测试执行中暂停然后使用Cypress命令日志和浏览器开发者工具检查当前DOM。使用cy.debug()暂停测试并进入一个类似debugger的REPL环境可以执行JavaScript来检查当前上下文。在Test Runner中点击出错的命令查看“快照”。Cypress会保存每个命令执行时的页面状态你可以像看照片一样检查当时的DOM、Console和网络请求。6.2 处理第三方登录、支付网关等外部依赖测试涉及OAuth登录如微信、GitHub登录或支付回调时你不能也不应该去调用真实的外部服务。解决方案使用cy.intercept()进行存根Stub和模拟Mock。describe(第三方GitHub登录, () { it(模拟GitHub授权成功回调, () { // 1. 拦截前端跳转到GitHub的请求通常是 /auth/github cy.intercept(GET, /auth/github, (req) { // 阻止真实跳转并直接重定向到我们模拟的回调URL并带上模拟的code req.redirect(/auth/github/callback?codefake_github_auth_code) }).as(githubAuth) // 2. 点击页面上的“使用GitHub登录”按钮 cy.get([data-testidgithub-login-btn]).click() // 3. 等待拦截发生 cy.wait(githubAuth) // 4. 拦截后端用code换token的API并返回模拟的成功响应 cy.intercept(POST, /api/auth/github/token, { statusCode: 200, body: { access_token: fake_access_token_123, user: { name: Mock GitHub User } } }).as(tokenExchange) // 5. 此时应用应自动处理回调并跳转到登录成功页面 cy.url().should(include, /dashboard) cy.get(.user-name).should(contain, Mock GitHub User) }) })通过这种方式你将测试范围完全控制在你的应用内部测试不再依赖不稳定的外部服务运行速度也更快。6.3 在CI/CD流水线中无头运行与生成报告在本地开发时我们使用cypress open打开GUI运行测试。但在CI/CD服务器如GitHub Actions, Jenkins, GitLab CI上我们需要以无头Headless模式运行测试。基本运行命令npx cypress run --browser chrome --headless--browser指定浏览器chrome, electron, edge等。--headless表示无头模式。你还可以用--spec指定运行某个测试文件或用--record将运行结果上传到Cypress Dashboard服务。集成到CI脚本中以GitHub Actions为例# .github/workflows/cypress-tests.yml name: E2E Tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Install dependencies run: npm ci - name: Start development server run: npm run dev # 在后台启动你的应用服务器 - name: Wait for server run: npx wait-on http://localhost:5173 # 等待服务器就绪 - name: Run Cypress tests run: npx cypress run --browser chrome --headless - name: Upload screenshots (on failure) if: failure() uses: actions/upload-artifactv3 with: name: cypress-screenshots path: cypress/screenshots - name: Upload videos uses: actions/upload-artifactv3 with: name: cypress-videos path: cypress/videos生成测试报告Cypress本身不直接生成漂亮的HTML报告但可以通过插件如mochawesome来实现。npm install --save-dev mochawesome mochawesome-merge mochawesome-report-generator在cypress.config.js中配置module.exports defineConfig({ e2e: { // ... 其他配置 reporter: mochawesome, reporterOptions: { reportDir: cypress/reports, overwrite: false, html: true, json: true, }, }, })运行测试后会在cypress/reports目录下生成美观的HTML报告包含通过率、耗时、错误详情等非常适合在CI中归档或发送通知。从理解E2E测试的核心价值到选择Cypress作为利器再到一步步搭建环境、编写测试用例、封装最佳实践最后解决那些令人头疼的疑难杂症这套组合拳打下来你应该已经具备了为真实项目保驾护航的能力。记住E2E测试的投入是一个“慢热”但回报巨大的过程。从覆盖最重要的那一条用户路径开始逐步积累你会发现自己和团队对产品的信心以及应对变更的敏捷性都会得到质的提升。