企业官网建设流程全解析

1. 项目概述：为什么是Cypress？

如果你正在开发一个Web应用，无论是前端主导的单页应用，还是传统的服务端渲染页面，最终都需要回答一个问题：“它真的能用吗？”这里的“能用”，不是指某个按钮能点击，而是指从用户打开浏览器，到完成一个完整业务流程（比如登录、搜索、下单），整个链条是否顺畅无阻。这就是端到端测试（E2E Testing）要解决的问题。过去几年，我和团队尝试过Selenium、Puppeteer、TestCafé等一系列工具，直到遇到Cypress，才感觉找到了那个“对的人”。它不仅仅是一个测试运行器，更像是一个为现代Web开发量身定制的、开箱即用的测试工作台。

Cypress的核心魅力在于它的设计哲学：一切为了开发者的体验和测试的可靠性。它运行在与应用相同的运行循环中，可以直接访问DOM元素、网络请求和浏览器上下文，这带来了无与伦比的执行速度和稳定性。对于前端开发者、测试工程师或者全栈工程师来说，Cypress降低了编写和维护E2E测试的门槛，让测试不再是项目后期的负担，而成为开发流程中自然的一环。本文将基于一次真实的项目实战，拆解如何从零开始，用Cypress为你的Web应用构建一套可靠、可维护的E2E测试体系。

2. 核心设计思路：Cypress的独特优势与架构选型

在决定引入Cypress之前，我们需要理解它解决了哪些传统E2E测试工具的痛点，以及我们的项目架构如何与之匹配。

2.1 传统E2E测试的常见痛点

在Cypress出现之前，我们使用Selenium WebDriver时经常遇到这些问题：

1. 脆弱的测试：测试因元素加载慢、动画未完成等时序问题而失败，需要大量sleep或显式等待。
2. 复杂的异步处理：需要手动处理Promise、回调，测试代码充斥着.then()链，可读性差。
3. 调试困难：错误信息模糊，难以定位是测试脚本问题还是应用本身问题。重现失败场景需要重新运行整个测试套件。
4. 环境配置繁琐：需要单独安装浏览器驱动，并确保驱动版本与浏览器版本匹配，CI/CD环境中尤其麻烦。
5. 无法窥探和控制网络：难以对特定的XHR或Fetch请求进行断言或打桩（Stub）。

2.2 Cypress的破局之道

Cypress通过其独特的架构从根本上改变了游戏规则：

• 同域运行：Cypress测试代码与应用程序运行在同一个超级域下，绕过了同源策略限制，可以直接同步操作DOM和Window对象，无需通过网络序列化命令。
• 自动等待：Cypress内置了智能重试机制，对于断言和大多数命令，它会自动等待元素出现、变得可见、不再被禁用等状态，基本告别了手动添加等待。
• 实时重载和时间旅行：Cypress Test Runner提供了一个强大的GUI界面。当您修改测试代码时，测试会实时重新运行。同时，它记录了每一个命令的快照，您可以像使用调试器一样回溯到任何一步，查看当时的应用状态。
• 网络流量控制：可以轻松地cy.intercept()任何HTTP请求，用于断言请求是否发生，或者直接返回一个模拟响应（Mock），实现测试的隔离和加速。
• 一致的测试结果：由于Cypress控制了整个自动化过程，从启动浏览器到执行命令，它提供了极高的一致性，大大减少了“在我机器上是好的”这类问题。

2.3 项目适配与选型考量

在为我们的中大型React单页应用引入Cypress时，我们主要考虑了以下几点：

• 技术栈匹配：Cypress对现代JavaScript框架（React, Vue, Angular）有极好的支持，能理解组件生命周期，方便定位元素。
• 测试金字塔定位：我们遵循测试金字塔模型，单元测试和集成测试（使用React Testing Library）覆盖了大部分业务逻辑和组件交互。Cypress负责顶层的、关键用户旅程的E2E测试，数量控制在可维护范围内（约50-100个）。
• CI/CD集成：Cypress提供了官方的Docker镜像和丰富的CI服务（如GitHub Actions, GitLab CI, Jenkins）集成方案，能够无头（Headless）模式运行并生成视频、截图，这对于自动化流水线至关重要。
• 维护成本：我们评估了测试代码的编写难度、阅读友好度和调试效率，Cypress的链式API和出色的调试工具显著降低了长期维护成本。

基于以上分析，我们决定采用Cypress + JavaScript作为E2E测试框架，并计划将其集成到现有的GitLab CI流水线中，在每次合并请求（Merge Request）时自动运行。

3. 环境搭建与核心配置详解

纸上得来终觉浅，绝知此事要躬行。让我们从零开始，一步步搭建Cypress测试环境。

3.1 初始化与安装

假设你的项目已经使用npm或yarn进行包管理。在项目根目录下执行：

npm install cypress --save-dev # 或 yarn add cypress -D

安装完成后，你可以通过npx来打开Cypress：

npx cypress open

第一次运行此命令时，Cypress会完成初始化工作：在项目根目录创建cypress文件夹（包含fixtures,integration,plugins,support等子目录）和一个默认的cypress.json配置文件。这个GUI界面会引导你选择测试类型（如E2E Testing）并启动浏览器。

注意：对于新项目，Cypress推荐使用npm init cypress命令，它会以更交互式的方式完成初始化。但对于现有项目，直接安装并打开是更常见的做法。

3.2 关键配置文件解析

Cypress的行为主要由cypress.json（Cypress < 10版本）或cypress.config.js（Cypress >= 10版本）控制。我们以较新的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:3000', // 视口大小 viewportWidth: 1280, viewportHeight: 720, // 默认命令超时时间（毫秒） defaultCommandTimeout: 10000, // 任务超时时间 taskTimeout: 60000, // 实验性功能（如组件测试） experimentalStudio: true, // 允许录制测试 // 在每个测试文件中运行之前加载的文件 setupNodeEvents(on, config) { // 可以在这里注册任务（task）或修改配置 // 例如，读取环境变量 const env = process.env.NODE_ENV || 'development' config.env.environment = env return config }, }, // 文件夹配置 downloadsFolder: 'cypress/downloads', fixturesFolder: 'cypress/fixtures', screenshotsFolder: 'cypress/screenshots', videosFolder: 'cypress/videos', })

关键配置项解读：

• baseUrl: 这是最重要的配置之一。设置后，你可以使用cy.visit('/login')来访问http://localhost:3000/login。这使测试代码更简洁，且便于在不同环境（开发、预生产）间切换。
• defaultCommandTimeout: 默认命令超时。Cypress会不断重试命令直到成功或超时。对于较慢的网络或复杂应用，可能需要适当调高。
• setupNodeEvents: 这是一个强大的钩子，允许你与Node进程交互。常用场景包括：读取文件、连接数据库、自定义报告生成等。

3.3 目录结构规划

一个清晰、可维护的目录结构是测试代码健康的基石。这是我们推荐的布局：

cypress/ ├── e2e/ # 所有E2E测试用例文件 │ ├── smoke/ # 冒烟测试（核心流程） │ │ └── app_smoke.cy.js │ ├── features/ # 按功能模块组织 │ │ ├── auth/ # 认证相关测试 │ │ │ ├── login.cy.js │ │ │ └── logout.cy.js │ │ └── dashboard/ # 仪表盘相关测试 │ │ └── widgets.cy.js │ └── api/ # 专门测试API或包含API交互的场景 │ └── user_api.cy.js ├── fixtures/ # 静态测试数据（JSON格式） │ └── test_user.json ├── support/ # 支持文件 │ ├── commands.js # 自定义命令（复用逻辑） │ ├── e2e.js # 测试运行前加载的文件（旧版本是index.js） │ └── utils.js # 工具函数 ├── downloads/ # 测试运行时下载的文件（自动生成） ├── screenshots/ # 测试失败时的截图（自动生成） ├── videos/ # 测试运行录像（自动生成） └── plugins/ # 插件文件（Cypress < 10）或已整合到config中

设计思路：按功能模块组织测试用例，将公共操作（如登录、数据准备）抽象为自定义命令或工具函数，保持每个测试文件的单一职责和可读性。

4. 编写第一个E2E测试：用户登录场景

让我们从一个最常见的场景开始：测试用户登录功能。我们将创建一个文件cypress/e2e/features/auth/login.cy.js。

4.1 测试用例设计与描述

一个好的测试用例应该清晰描述其预期行为。Cypress使用Mocha的BDD（行为驱动开发）语法，结合Chai断言库，让测试读起来像自然语言。

describe('用户登录功能', () => { beforeEach(() => { // 每个测试用例运行前，都访问登录页 // 因为配置了baseUrl，这里只需相对路径 cy.visit('/login') }) it('使用正确的邮箱和密码应成功登录并跳转到仪表盘', () => { // 测试步骤与断言 }) it('使用错误密码应显示错误提示信息', () => { // 测试步骤与断言 }) it('邮箱格式不正确时应实时验证并提示', () => { // 测试步骤与断言 }) })

• describe和it：用于组织测试套件和用例。describe块可以嵌套。
• beforeEach：这是一个生命周期钩子，在每个it测试用例执行前运行。非常适合用于重置状态或导航到特定页面。

4.2 元素定位与交互操作

Cypress提供了多种定位元素的方式，最佳实践是使用><input type="email">it('使用正确的邮箱和密码应成功登录并跳转到仪表盘', () => { // 1. 定位邮箱输入框并输入文本 cy.get('[data-cy=email-input]') .type('test.user@example.com') .should('have.value', 'test.user@example.com') // 断言输入值正确 // 2. 定位密码输入框并输入 cy.get('[data-cy=password-input]') .type('MySecurePass123') .should('have.value', 'MySecurePass123') // 3. 点击登录按钮 cy.get('[data-cy=login-submit-btn]') .click() // 4. 断言登录成功后的行为 // 4.1 验证URL跳转到了仪表盘页 cy.url() .should('include', '/dashboard') // 4.2 验证页面中包含用户欢迎信息（假设存在一个元素） cy.get('[data-cy=user-greeting]') .should('be.visible') .and('contain', '欢迎回来') })

关键点解析：

• cy.get(selector): 这是Cypress中最核心的命令，用于获取一个或多个DOM元素。它内置了自动重试和超时机制。
• .type(text): 在输入框或可编辑元素中输入文本。Cypress会模拟真实的键盘事件。
• .click(): 点击元素。
• .should(chainers): 断言。Cypress的断言是自动重试的，它会等待直到断言通过或超时。.and()是.should()的别名，用于连接多个断言，使代码更可读。
• cy.url(): 获取当前页面的URL。

实操心得：尽量避免使用cy.wait(毫秒数)进行固定等待。优先使用Cypress的自动等待（如.should('be.visible')）或等待特定网络请求完成（cy.intercept）。固定等待会使测试变慢且不稳定。

4.3 处理网络请求：拦截与模拟

现代应用大量依赖API。为了测试的独立性和速度，我们经常需要拦截（Stub）网络请求。例如，在登录测试中，我们不想依赖真实的后端，而是模拟一个成功的登录响应。

it('使用正确的邮箱和密码应成功登录并跳转到仪表盘（模拟API）', () => { // 在用户操作之前，拦截登录的POST请求 cy.intercept('POST', '/api/v1/auth/login', { statusCode: 200, body: { success: true, token: 'fake-jwt-token-12345', user: { id: 1, name: '测试用户', email: 'test.user@example.com' } }, delay: 500 // 模拟网络延迟，测试UI加载状态 }).as('loginRequest') // 给这个拦截起个别名，方便后续引用 // 执行UI操作 cy.get('[data-cy=email-input]').type('test.user@example.com') cy.get('[data-cy=password-input]').type('MySecurePass123') cy.get('[data-cy=login-submit-btn]').click() // 等待特定的拦截请求完成，并对其断言 cy.wait('@loginRequest') .its('request.body') // 获取请求体 .should('deep.equal', { email: 'test.user@example.com', password: 'MySecurePass123' }) // 断言UI响应 cy.url().should('include', '/dashboard') })

• cy.intercept(): 用于监听和修改HTTP请求。你可以匹配URL、方法，并决定是让其通过、返回模拟响应还是返回错误。
• .as(): 为拦截、路由或元素起一个别名，后续可以用@别名来引用它。
• cy.wait('@alias'): 等待一个被别名的请求完成。这是同步测试异步操作的强大工具。
• .its(): 获取前面主题（subject）的某个属性。

使用场景：

1. 测试加载状态：拦截请求并添加delay，可以测试按钮是否在请求期间变为禁用状态、是否显示加载动画。
2. 测试错误处理：拦截请求并返回statusCode: 401，测试UI是否正确地显示了错误信息。
3. 加速测试：避免调用缓慢或不稳定的第三方API。
4. 测试边缘情况：轻松模拟后端返回的各种边界数据。

5. 高级模式与最佳实践

当测试套件增长后，如何保持代码的可维护性和可读性就变得至关重要。

5.1 自定义命令：封装重复逻辑

如果多个测试都需要先登录，那么在每个测试文件中复制粘贴登录代码是糟糕的。我们可以将登录操作封装成一个自定义命令。

在cypress/support/commands.js中添加：

// 登录命令 Cypress.Commands.add('login', (email, password) => { cy.session([email, password], () => { // 使用cy.session缓存会话，加速测试 cy.visit('/login') cy.get('[data-cy=email-input]').type(email) cy.get('[data-cy=password-input]').type(password) cy.get('[data-cy=login-submit-btn]').click() // 确保登录成功，跳转到首页或仪表盘 cy.url().should('include', '/dashboard') }) }) // 快速以默认测试用户登录 Cypress.Commands.add('loginAsTestUser', () => { const testUser = Cypress.env('TEST_USER') || { email: 'test@example.com', password: 'test123' } cy.login(testUser.email, testUser.password) })

在测试文件中，你就可以像使用内置命令一样使用它：

describe('仪表盘功能', () => { beforeEach(() => { cy.loginAsTestUser() // 一行代码完成登录 cy.visit('/dashboard') }) it('应显示用户的核心数据指标', () => { // ... 直接开始测试仪表盘内容 }) })

cy.session的威力：这是Cypress 12.0+引入的实验性（现已稳定）功能。它可以将登录后的浏览器状态（cookies, localStorage等）缓存起来。在同一个测试运行中，后续需要登录的测试可以直接复用这个缓存，跳过重复的登录流程，极大提升测试速度。

5.2 使用Fixtures管理测试数据

硬编码的测试数据散落在各个测试文件中难以管理。我们可以使用fixtures。

在cypress/fixtures/test_users.json中：

{ "admin": { "email": "admin@company.com", "password": "AdminPass!123", "role": "admin" }, "standardUser": { "email": "user@company.com", "password": "UserPass!456", "role": "user" } }

在测试中加载和使用：

beforeEach(() => { cy.fixture('test_users').as('users') // 加载fixture并起别名 }) it('管理员可以访问用户管理页面', function() { // 使用function以便访问`this` const admin = this.users.admin // 通过this访问别名数据 cy.login(admin.email, admin.password) cy.visit('/admin/users') // ... 进行断言 })

5.3 页面对象模式（Page Object Pattern）

对于复杂的页面，将页面元素定位器和常用操作封装成“页面对象”类，可以显著提高代码复用性和可维护性。

创建cypress/support/pages/LoginPage.js：

class LoginPage { elements = { emailInput: () => cy.get('[data-cy=email-input]'), passwordInput: () => cy.get('[data-cy=password-input]'), submitButton: () => cy.get('[data-cy=login-submit-btn]'), errorMessage: () => cy.get('[data-cy=error-message]') } visit() { cy.visit('/login') } typeEmail(email) { this.elements.emailInput().clear().type(email) } typePassword(password) { this.elements.passwordInput().clear().type(password) } submit() { this.elements.submitButton().click() } // 一个完整的登录流程封装 login(email, password) { this.visit() this.typeEmail(email) this.typePassword(password) this.submit() } } export default LoginPage

在测试文件中使用：

import LoginPage from '../support/pages/LoginPage' describe('使用页面对象登录', () => { const loginPage = new LoginPage() it('登录成功', () => { loginPage.login('user@example.com', 'password') cy.url().should('include', '/dashboard') }) })

这种方式让测试脚本更专注于“做什么”（业务逻辑），而不是“怎么做”（元素定位细节）。当页面UI变化时，你只需要更新对应的页面对象文件。

6. CI/CD集成与无头模式运行

自动化测试的价值在持续集成/持续部署（CI/CD）流水线中才能最大化体现。我们需要让Cypress在服务器上无界面运行。

6.1 命令行运行与参数配置

Cypress提供了强大的命令行接口（CLI）。最基本的运行命令是：

npx cypress run

这条命令会以无头模式运行所有测试。但通常我们需要更精细的控制：

# 指定浏览器（默认为Electron） npx cypress run --browser chrome # 运行特定测试文件 npx cypress run --spec "cypress/e2e/features/auth/login.cy.js" # 运行匹配某个模式的测试文件 npx cypress run --spec "cypress/e2e/features/**/*.cy.js" # 分组运行，结合标签（需要插件支持，如cypress-grep） npx cypress run --env grepTags="@smoke" # 指定配置，如使用不同的baseUrl npx cypress run --config baseUrl=https://staging.example.com # 设置环境变量 npx cypress run --env apiUrl=https://api.staging.example.com

6.2 集成到GitHub Actions

以下是一个简单的GitHub Actions工作流配置示例（.github/workflows/cypress-tests.yml），它在每次推送到主分支或打开Pull Request时运行E2E测试。

name: Cypress E2E Tests on: [push, pull_request] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - name: Install dependencies run: npm ci # 使用ci命令确保依赖锁一致 - name: Start development server (if needed) run: npm run start & # 后台启动你的开发服务器 env: NODE_ENV: test PORT: 3000 - name: Wait for server to be ready run: npx wait-on http://localhost:3000 # 等待服务器启动 - name: Run Cypress tests uses: cypress-io/github-action@v5 with: start: npm start # Action可以帮你启动服务器 wait-on: 'http://localhost:3000' # 使用官方Cypress Docker镜像，内置了浏览器 browser: chrome record: true # 可选：将测试结果记录到Cypress Cloud仪表板 env: CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }} # 记录所需的密钥 CYPRESS_baseUrl: http://localhost:3000 - name: Upload test artifacts (on failure) if: failure() uses: actions/upload-artifact@v3 with: name: cypress-artifacts path: | cypress/screenshots cypress/videos

关键步骤说明：

1. 启动测试服务器：在运行测试前，需要确保你的应用正在运行。可以通过后台进程（&）启动，也可以利用cypress-io/github-action的start参数。
2. 等待服务就绪：使用wait-on工具等待服务器的特定端口或URL可访问。
3. 使用官方Action：cypress-io/github-action封装了最佳实践，包括并行测试、缓存、结果记录等。
4. 记录与归档：record: true可以将运行详情、视频、截图上传到Cypress Cloud（商业功能），便于团队协作分析。失败时上传本地产物（截图和视频）到GitHub，方便下载查看。

6.3 测试数据与环境隔离

在CI环境中，测试需要完全独立，不能污染生产或彼此的数据。

• 使用测试数据库：为CI流水线配置一个独立的测试数据库。在测试运行前，通过脚本或API重置数据库到已知状态（例如，运行种子脚本）。
• 环境变量：使用CYPRESS_*前缀的环境变量或cypress.config.js中的env配置，来区分不同环境的API地址、认证密钥等。
• API拦截：在E2E测试中，尽量拦截所有对外部服务的调用，返回模拟数据。这保证了测试的独立性和速度。

7. 常见问题排查与调试技巧实录

即使有了Cypress这样优秀的工具，在实际编写和运行测试时，你依然会遇到各种问题。以下是我在实践中积累的一些常见问题与解决思路。

7.1 元素定位失败：最常见的“坑”

问题：cy.get(...)超时，找不到元素。排查思路：

1. 检查选择器：打开Cypress Test Runner，使用内置的Selector Playground工具（顶部搜索图标）验证你的选择器是否能唯一匹配到元素。
2. 确认页面已加载：在操作元素前，添加一个断言确保包含该元素的父级容器或页面本身已加载完成。例如：cy.get('body').should('be.visible')或等待某个特定标志性元素。
3. 处理动态内容/SPA路由：对于单页应用，cy.visit()只保证HTML页面加载完毕，不保证前端JavaScript框架已完成渲染和路由切换。可以使用cy.intercept()等待特定的API请求完成，或者使用cy.contains()等待某个预期文本出现。
4. 处理iframe：如果元素在<iframe>内，你需要先用cy.frameLoaded()和cy.iframe()命令进入iframe上下文。
5. 禁用CSS或动画：有时CSS动画（如淡入、滑动）会影响Cypress对元素“可见”状态的判断。可以在测试配置中全局禁用动画，或在测试中通过JavaScript直接移除相关CSS类。

7.2 测试在CI中通过，本地却失败（或反之）

问题：环境不一致导致测试结果不稳定。解决策略：

1. 统一浏览器和版本：在cypress.config.js中指定明确的浏览器和版本，确保CI和本地使用相同的环境。CI中通常使用Docker镜像。
2. 检查视口大小：本地开发时浏览器窗口可能很大，而CI无头模式的默认视口可能较小。确保在配置中设置一致的viewportWidth和viewportHeight，或者在测试开始时用cy.viewport()设置。
3. 处理时间差异：CI服务器的性能可能比本地机器差。适当增加defaultCommandTimeout和pageLoadTimeout的全局配置。
4. 清理状态：确保每个测试都是独立的。使用beforeEach钩子清理cookies、localStorage，或者使用cy.session()来管理登录状态，避免测试间相互影响。
5. 查看CI日志和产物：务必配置CI在测试失败时保存并上传cypress/screenshots和cypress/videos。视频回放是诊断CI失败原因的利器。

7.3 处理棘手的异步操作

问题：应用中有setTimeout、WebSocket、文件上传等操作，测试时序难以控制。高级技巧：

• 等待多个请求：使用Promise.all结合cy.wait()。

  cy.intercept('GET', '/api/data1').as('req1') cy.intercept('GET', '/api/data2').as('req2') // ... 触发请求的操作 cy.wait(['@req1', '@req2']) // 等待所有别名请求完成

• 轮询（Polling）：对于无法拦截的操作（如第三方SDK），可以使用cy.waitUntil插件或自己写递归重试逻辑。

  const checkStatus = () => { return cy.get('[data-status]').invoke('text').then((text) => { return text === '完成' ? true : checkStatus() // 递归直到条件满足 }) } checkStatus()

• 文件上传：不要尝试模拟点击文件选择对话框（浏览器安全限制）。而是直接用.selectFile()命令或将文件内容作为Fixture读取后通过cy.intercept()模拟响应。

7.4 性能优化：让测试跑得更快

当测试套件超过100个时，运行时间会成为问题。

1. 启用测试并行化：在Cypress Cloud或使用第三方CI服务（如CircleCI, Jenkins）时，可以将测试套件分割到多个机器上并行运行。这需要购买Cypress Cloud服务或自行编排CI任务。
2. 使用cy.session()：如前所述，缓存登录会话可以跳过重复的登录流程，这是提升速度最有效的方法之一。
3. 智能选择测试：在开发阶段，只运行与修改代码相关的测试。可以使用cypress-grep插件给测试打标签（如@smoke,@regression），然后通过环境变量选择运行。
4. 减少cy.visit：每个cy.visit都会刷新页面，成本很高。在测试一个功能模块内的多个场景时，尽量通过页面内导航（点击链接、按钮）来切换，而不是每次都从首页开始。
5. Mock外部依赖：将所有第三方API、地图服务、支付网关等外部调用全部拦截并返回轻量级的模拟数据，可以消除网络延迟的不确定性，让测试速度飞起。

8. 测试策略与维护心法

最后，我想分享一些超越具体工具和代码的、关于E2E测试策略和团队协作的思考。

E2E测试的定位：它应该是你测试金字塔的塔尖，数量少而精。不要试图用E2E测试覆盖所有边界情况，那是单元测试和集成测试的职责。E2E测试应该聚焦于核心用户旅程和关键业务功能。例如：新用户注册流程、核心交易流程、关键的管理员操作。

测试的“读”比“写”更重要：测试代码也是代码，需要被团队成员阅读和维护。使用清晰的描述（describe,it）、有意义的变量名、以及我们前面提到的页面对象和自定义命令，都是为了提升可读性。一个同事应该能在不看应用代码的情况下，大致理解测试在验证什么。

拥抱失败，但要有策略：E2E测试因为涉及整个系统，天生比单元测试更脆弱。不要追求100%的通过率，那会导致测试变得过度复杂或不敢断言。建立一个清晰的测试分级制度和失败处理流程。例如：

• P0级（阻塞性）：核心流程失败，阻塞发布，必须立即修复。
• P1级（高优先级）：重要功能问题，应在当前迭代内修复。
• P2级（一般）：非核心功能或UI细节问题，可以安排后续迭代修复。
• Flaky Tests（不稳定测试）：单独标记并定期清理。如果某个测试时好时坏，要么修复其不稳定性（通常是时序或状态问题），要么考虑将其降级或删除，因为它会消耗团队的信任。

将测试作为活文档：你的E2E测试套件，特别是那些描述核心业务流程的测试，可以成为新成员了解系统功能的绝佳文档。配合Cypress Cloud的记录视频，可以直观地展示功能的正确行为。

引入Cypress做E2E测试，不仅仅是为项目增加了一个自动化工具，更是引入了一种更可靠、更高效、更以开发者为中心的测试文化。它让编写测试从一项繁琐的任务，变成一种可以即时获得正反馈的、甚至有点乐趣的开发活动。从一个小场景开始，逐步构建你的测试防护网，你会发现，它给予你重构代码和快速交付的信心，是任何手动测试都无法比拟的。