Cypress自动化测试持续优化：从效率、稳定性到工程化实践

1. 项目概述：为什么我们需要持续优化Cypress？

如果你正在用Cypress做自动化测试，并且感觉脚本越写越多，运行时间越来越长，维护起来也越来越头疼，那说明你正处在一个关键的十字路口。Cypress以其现代化的架构、友好的API和强大的调试能力，在前端E2E测试领域迅速崛起，成为很多团队的首选。但就像任何强大的工具一样，用得好和用得“仅仅能用”之间，差距巨大。很多团队在初期快速搭建起测试套件后，就陷入了“脚本能跑就行”的舒适区，直到某一天，CI/CD流水线因为测试超时而中断，或者一个微小的UI改动导致几十个测试用例失败，大家才开始手忙脚乱地“救火”。

“持续优化Cypress自动化测试”这个项目，正是为了解决这个痛点。它不是一个一次性的任务，而是一个贯穿测试生命周期始终的工程实践。其核心目标，是让自动化测试资产（包括测试用例、脚本、配置、环境）保持高效、稳定、可维护，并能够持续地为产品质量和研发效率提供正向价值，而不是成为团队的负担。简单说，就是让测试跑得更快、更稳、更好维护。

这不仅仅是技术问题，更是工程效率和团队协作问题。一个未经优化的Cypress项目，可能会表现出以下症状：单个测试运行缓慢，整个套件需要几十分钟甚至数小时；测试脆弱，经常因为非功能原因（如网络延迟、动画未完成）而失败（Flaky Tests）；测试代码重复、难以阅读和维护；测试数据管理混乱；测试报告难以解读，无法快速定位问题。持续优化的过程，就是系统地诊断并解决这些问题的过程。

2. 核心优化策略与设计思路拆解

优化Cypress不能头痛医头、脚痛医脚，需要一个系统性的框架。我的思路是将其分为四个相互关联的层面：执行效率层、代码质量层、稳定性与可靠性层、以及工程化与协作层。每一层都有其核心要解决的问题和对应的优化手段。

2.1 执行效率优化：让测试“跑”起来

这是最直观的优化目标。Cypress测试慢，通常有几个瓶颈：浏览器启动、页面加载、网络请求、以及测试指令本身的执行。我们的优化思路是“能并行的不串行，能缓存的不重复，能跳过的别等待”。

并行执行是提升整体套件运行速度最有效的手段。Cypress本身不支持单机多浏览器并行，但可以通过CI/CD工具（如GitHub Actions, GitLab CI, Jenkins）配合cypress-parallel等第三方库，或者直接使用Cypress Cloud的智能并行功能来实现。其原理是将测试文件（spec files）分发到多个运行器（runner）上同时执行。这里的关键是测试隔离：每个测试必须独立，不共享状态（如登录态、数据库数据），否则并行会导致不可预知的失败。通常我们需要为每个并行进程准备独立的测试数据或通过唯一标识来隔离数据。

选择性执行是另一个利器。我们没必要每次代码提交都跑全部测试。可以通过分析代码变更（git diff）来智能选择受影响的测试用例，或者根据测试的标签（如@smoke,@regression）来运行特定套件。Cypress的--spec参数和cypress-grep插件是实现选择性执行的好帮手。

优化等待与断言是微观层面的提速。滥用cy.wait(5000)这种硬等待是性能杀手。应始终使用Cypress的自动重试和断言机制，如cy.get(‘.btn’).should(‘be.visible’)，它会在超时前不断重试，比固定等待更高效。对于确实需要等待异步操作（如API调用）的场景，可以使用cy.intercept()来监听网络请求，在其完成后才继续，这比等待一个固定时间精准得多。

2.2 代码质量与可维护性优化：让测试“活”下去

测试代码也是代码，需要遵循良好的软件工程实践。糟糕的测试代码会迅速腐化，最终无人敢动。

页面对象模式（Page Object Model, POM）是组织UI测试代码的经典模式。它将页面的元素定位器和页面交互操作封装成类。这样，当UI发生变化时，你只需要在一个地方（Page Object）修改定位器，而不是在所有测试用例中搜索替换。在Cypress中，我们可以用ES6模块或TypeScript类来实现POM。更进一步，可以引入组件对象模式（Component Object Model），将可复用的UI组件（如导航栏、模态框）也封装起来。

自定义命令（Custom Commands）是Cypress的一大特色，用于封装重复的、复杂的或业务特定的操作。例如，可以将登录流程cy.login(username, password)封装成一个自定义命令。这极大地提升了测试代码的语义化和可读性。但要注意，自定义命令不宜滥用，过于复杂的命令会隐藏实现细节，不利于调试。我的经验是，将通用的、与业务逻辑强相关的交互封装成命令。

使用 fixtures 管理测试数据。硬编码在测试用例中的数据是维护噩梦。Cypress的fixtures文件夹可以用来存放JSON格式的测试数据。对于更复杂的数据场景，比如需要关联多个实体（用户、订单、商品），可以考虑使用数据工厂（Data Factory）模式，通过JavaScript函数动态生成符合业务规则的数据。

引入静态类型检查（TypeScript）。对于大中型项目，强烈推荐使用TypeScript编写Cypress测试。它能提供智能提示、类型安全，并在编译时捕获许多低级错误（如拼写错误、参数类型不匹配），显著提升开发体验和代码质量。

2.3 稳定性与可靠性优化：让测试“稳”如磐石

脆弱的测试（Flaky Tests）是自动化测试的毒瘤，它们会消耗团队大量的信任和精力去排查非问题。

根治脆弱的根本原因。脆弱的测试通常源于：1) 对时间敏感的硬等待；2) 依赖不稳定的第三方服务或网络；3) 测试间状态污染；4) 对动画或未完全渲染的元素的断言。解决方案包括：用Cypress内置的重试断言替代硬等待；使用cy.intercept()拦截并控制网络请求，返回稳定的模拟数据（Mocking）；确保每个测试完全独立，在beforeEach中清理状态（如清除cookie、localStorage，甚至重置测试数据库）；使用{ force: true }选项或等待动画结束后再与元素交互。

增加测试的重试机制。Cypress支持在测试运行级别和单个测试级别配置重试。对于某些确实因环境偶发问题（如短暂的网络抖动）导致的失败，配置合理的重试次数（如retries: 1）可以自动“愈合”这些临时性问题，避免CI/CD因偶发失败而中断。但这治标不治本，应优先解决根本的脆弱性。

视觉回归测试。对于UI的稳定性，可以引入视觉回归测试工具（如cypress-image-snapshot、@percy/cypress）。它们能捕获UI截图并与基线图对比，发现意料之外的视觉变化。这对于防止CSS改动或组件库升级引入的UI破坏非常有效。

2.4 工程化与协作优化：让测试融入研发流程

自动化测试不是测试工程师的孤岛，它必须融入整个DevOps流程。

CI/CD流水线集成。将Cypress测试作为CI/CD流水线中的一个关键质量门禁。通常安排在构建（Build）成功之后、部署（Deploy）之前。配置合理的并行策略和超时时间，确保测试失败能及时阻断部署并通知相关人员。

测试报告与结果分析。使用mochawesome等报告生成器，生成美观、详细的HTML报告。更重要的是，将测试结果与项目管理工具（如Jira）或沟通工具（如Slack）集成，实现失败通知自动化。对于大型套件，分析测试运行历史，找出那些运行最慢或最常失败的“问题用例”，进行针对性优化。

测试环境管理。确保测试环境（包括后端API、数据库）的稳定性和一致性。使用Docker容器化测试环境是一个好方法，可以保证每次测试运行的环境都是纯净、可预测的。对于前端测试，可以使用cypress.config.js中的baseUrl和环境变量来灵活切换测试环境（如开发、预发、生产）。

3. 核心细节解析与实操要点

3.1 并行化执行的深度配置与陷阱

并行化听起来美好，但配置不当会引入新问题。以使用cypress-parallel和GitHub Actions为例。

首先，你需要一个可靠的方法来分割测试文件。cypress-parallel通常根据文件数量或历史运行时长来分割。我推荐使用基于时长的平衡分割。你需要先通过--reporter json运行一次测试，生成包含每个测试文件时长的报告，然后以此为依据进行分割，确保每个运行器的工作量大致相等，避免“木桶效应”。

其次，状态隔离是重中之重。假设你的测试需要登录，如果所有并行进程都使用同一个测试账号，可能会造成会话冲突。解决方案是为每个CI节点（或进程）生成唯一的测试用户。可以通过环境变量传递一个进程ID，并在测试的before钩子中，调用一个后端API来创建或获取一个专属的测试用户账号和令牌。

// cypress/support/e2e.js 或类似支持文件 before(() => { const nodeIndex = Cypress.env(‘CI_NODE_INDEX’) || ‘0’; // 从CI环境变量获取 cy.request(‘POST’, ‘/api/test-user’, { node: nodeIndex }).then((resp) => { Cypress.env(‘authToken’, resp.body.token); Cypress.env(‘testUserId’, resp.body.userId); }); }); // 在Page Object或测试中 cy.visit(‘/dashboard’, { headers: { ‘Authorization’: `Bearer ${Cypress.env(‘authToken’)}` } });

注意：这种动态创建用户的方式要求你的测试环境后端有相应的支持。如果做不到，退而求其次的方法是使用一批预先创建好的、互不干扰的测试账号池，每个进程从中认领一个。

最后，结果合并。并行运行后，你需要合并所有进程的测试结果报告和视频截图。cypress-parallel等工具通常会处理Mocha报告的合并。确保你的CI配置能正确归档所有运行器的cypress/videos和cypress/screenshots目录，以便于失败时查看。

3.2 高级页面对象模式与依赖注入

基础的POM模式在复杂应用中可能不够用。当页面有大量模态框、抽屉、通知组件时，它们的定位器和方法会散落在多个Page Object中，造成重复。

我倾向于使用一种组合（Composition）模式。将通用的UI组件（如Modal,Toast,Dropdown）抽象成独立的Component类。然后在Page Object中，以属性的方式引入这些组件。

// cypress/support/components/Modal.ts export class Modal { get container() { return cy.get(‘[data-testid=”modal”]’); } get title() { return this.container.find(‘h2’); } close() { this.container.find(‘[aria-label=”Close”]’).click(); } } // cypress/pages/LoginPage.ts import { Modal } from ‘../support/components/Modal’; export class LoginPage { modal = new Modal(); usernameInput = ‘[name=”username”]’; passwordInput = ‘[name=”password”]’; submitButton = ‘button[type=”submit”]’; visit() { cy.visit(‘/login’); } login(username: string, password: string) { cy.get(this.usernameInput).type(username); cy.get(this.passwordInput).type(password); cy.get(this.submitButton).click(); } }

这样，在测试中既可以loginPage.login(...)，也可以loginPage.modal.close()，结构清晰，复用性高。

对于需要在多个测试步骤中共享的复杂业务流（如“创建一个带有特定配置的项目”），可以进一步抽象为业务流程（Business Flow）或任务（Task）模块。这超越了POM，是对业务操作的封装。

3.3 智能等待与网络请求控制实战

这是提升测试稳定性和速度的核心技巧。我们看一个常见场景：提交表单后，页面会跳转，并在新页面上显示一个成功提示。

反面教材：

cy.get(‘form’).submit(); cy.wait(5000); // 魔法数字，糟糕！ cy.get(‘.alert-success’).should(‘contain’, ‘操作成功’);

优化方案1：断言页面跳转（如果跳转到新URL）

cy.get(‘form’).submit(); cy.url().should(‘include’, ‘/success’); // 等待URL变化 cy.get(‘.alert-success’).should(‘be.visible’).and(‘contain’, ‘操作成功’);

优化方案2：拦截API请求（更精准） 假设提交表单会触发一个POST请求到/api/submit，成功后前端再跳转。

// 给这个请求起个别名，并等待它发生 cy.intercept(‘POST’, ‘/api/submit’).as(‘submitRequest’); cy.get(‘form’).submit(); // 等待请求完成，并可断言其状态 cy.wait(‘@submitRequest’).its(‘response.statusCode’).should(‘eq’, 200); // 然后再断言UI cy.get(‘.alert-success’).should(‘be.visible’);

优化方案3：等待元素状态链（通用且推荐） Cypress的命令是链式且自动重试的。我们可以利用这一点，在操作后直接对后续应出现的元素进行断言，Cypress会智能等待。

cy.get(‘form’).submit(); cy.get(‘.alert-success’, { timeout: 10000 }) // 显式设置此元素的等待超时 .should(‘be.visible’) .and(‘contain’, ‘操作成功’);

对于列表加载、表格渲染等场景，可以等待特定数量的元素出现：

cy.get(‘table tbody tr’).should(‘have.length’, 10); // 等待恰好10行数据加载出来

3.4 测试数据管理的进阶模式

fixtures适合静态数据。但对于需要动态关联、符合业务逻辑的数据，我们需要更强大的方案。

方案一：使用测试数据工厂（Factory）库可以引入像@jackfranklin/test-data-bot这样的库，或者自己编写简单的工厂函数。

// cypress/factories/userFactory.js export const buildUser = (overrides = {}) => { const defaults = { name: ‘Test User’, email: `user_${Date.now()}@test.com`, // 确保唯一性 role: ‘member’, }; return { …defaults, …overrides }; }; // 在测试中 const adminUser = buildUser({ role: ‘admin’ }); cy.request(‘POST’, ‘/api/users’, adminUser).then(…);

方案二：直接操作测试数据库（谨慎使用）对于E2E测试，有时需要确保数据库处于一个已知的初始状态。Cypress可以通过cy.task()调用Node.js代码，从而执行数据库操作。

// cypress.config.js const { defineConfig } = require(‘cypress’); module.exports = defineConfig({ e2e: { setupNodeEvents(on, config) { on(‘task’, { async resetDatabase() { // 这里调用你的数据库清理/种子脚本 const { db } = require(‘../../backend/src/db’); await db.sync({ force: true }); await seedTestData(); return null; } }); }, }, }); // 在测试的 before 钩子中 before(() => { cy.task(‘resetDatabase’); });

警告：直接操作生产数据库是极其危险的！这必须仅在专有的、隔离的测试环境中进行。并且要确保操作是幂等的（可重复执行而不产生副作用）。

方案三：利用API准备数据最安全、最推荐的方式是通过应用程序的公开API来创建测试数据。这最接近真实用户行为。可以将常用的数据创建流程封装成自定义命令或API工具函数。

4. 实操过程与核心环节实现

让我们以一个具体的优化任务为例：优化一个已有的大型Cypress测试套件，将其集成到GitLab CI中，并实现并行执行。

4.1 环境分析与基准测试

首先，我们需要了解现状。在项目根目录下运行：

npx cypress run —record —key your-record-key —parallel —ci-build-id `date +%s`

（如果尚未使用Cypress Cloud，可以先不加—record相关参数，仅本地运行全部测试）。

记录下总运行时间，并观察cypress/results（如果使用mochawesome等报告器）或控制台输出，找出运行时间最长的几个spec文件。同时，检查测试日志，留意是否有大量的wait命令或脆弱的失败。

假设我们有一个包含50个spec文件，总运行时长约30分钟的套件。我们的目标是通过并行化，将其缩短到10分钟以内。

4.2 配置GitLab CI/CD流水线

在项目根目录创建或编辑.gitlab-ci.yml文件。

stages: - build - test - deploy # 1. 构建阶段：安装依赖，构建前端应用 build-job: stage: build image: node:18 cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ script: - npm ci # 使用ci命令以获得更可靠的安装 - npm run build # 假设你的前端构建命令 artifacts: paths: - dist/ # 将构建产物传递给后续阶段 expire_in: 1 hour # 2. 测试阶段：并行执行Cypress测试 cypress-e2e: stage: test image: cypress/included:12.0.0 # 使用官方包含Cypress的镜像 variables: # 定义并行任务总数和当前任务索引 CY_PARALLEL_CLI: ‘cypress-parallel’ CY_PARALLEL_MAX: 4 # 假设我们启动4个并行任务 parallel: 4 # GitLab CI的并行关键字，会创建4个相同的作业 needs: [“build-job”] # 依赖构建阶段 artifacts: when: always paths: - cypress/videos/**/*.mp4 - cypress/screenshots/**/*.png - cypress/reports/**/*.json # 合并报告需要 expire_in: 1 week script: # 复制构建产物到Cypress可访问的位置（如果测试针对构建后的应用） - cp -r dist/ cypress/public/ || true # 安装并行工具（如果未在镜像中预装） - npm install -g cypress-parallel # 使用cypress-parallel运行测试，根据CI_NODE_INDEX分割任务 - npx cypress-parallel -s run -t $CY_PARALLEL_MAX -d $CI_NODE_INDEX —record —key $CYPRESS_RECORD_KEY —ci-build-id $CI_PIPELINE_ID rules: - if: $CI_PIPELINE_SOURCE == “merge_request_event” # 仅在合并请求时运行 - if: $CI_COMMIT_BRANCH == “main” # 或在推送到主分支时运行

关键点解析：

1. parallel: 4：GitLab CI会创建4个名为cypress-e2e 1/4,cypress-e2e 2/4…的作业。
2. CI_NODE_INDEX：GitLab CI自动为每个并行作业提供从1开始的索引。cypress-parallel的-d参数用于指定当前节点。
3. CI_PIPELINE_ID：作为—ci-build-id，确保同一流水线的所有并行任务在Cypress Cloud中被归为一组。
4. —record：将结果记录到Cypress Cloud，可以获得更直观的并行运行视图、视频和错误分析。$CYPRESS_RECORD_KEY需要在GitLab CI的项目变量中设置。
5. rules：这里配置了仅在合并请求和主分支推送时触发测试，避免不必要的资源消耗。

4.3 实现测试状态隔离

如前所述，我们需要修改测试代码以支持并行。在cypress/support/e2e.js中：

// 生成一个基于CI节点索引的唯一标识符 const getUniqueId = () => { // GitLab CI 提供 CI_NODE_INDEX， GitHub Actions 提供 GITHUB_RUN_ATTEMPT 等 const nodeIndex = Cypress.env(‘CI_NODE_INDEX’) || ‘0’; const runId = Cypress.env(‘CI_PIPELINE_ID’) || Date.now(); return `node_${nodeIndex}_run_${runId}`; }; // 创建一个全局的、唯一的测试用户 before(() => { const uniqueId = getUniqueId(); const testUser = { username: `autotest_${uniqueId}`, email: `autotest.${uniqueId}@example.com`, password: ‘Password123!’, }; // 尝试通过API创建用户，如果用户已存在则登录 cy.request({ method: ‘POST’, url: ‘/api/test-users/acquire’, body: testUser, failOnStatusCode: false, // 不因409冲突等失败 }).then((response) => { // 假设API成功返回token Cypress.env(‘testUser’, testUser); Cypress.env(‘authToken’, response.body.token); }); }); // 在每个测试前，使用这个唯一用户登录 beforeEach(() => { const { username, password } = Cypress.env(‘testUser’); // 使用封装好的登录命令或页面对象 cy.login(username, password); // 确保登录成功，可以跳转到首页或仪表盘 cy.url().should(‘include’, ‘/dashboard’); }); // 在每个测试后，清理可能产生的测试数据（可选，如果API支持） afterEach(() => { const uniqueId = getUniqueId(); cy.request({ method: ‘POST’, url: ‘/api/test-data/cleanup’, headers: { ‘Authorization’: `Bearer ${Cypress.env(‘authToken’)}` }, body: { scope: `node_${Cypress.env(‘CI_NODE_INDEX’)}` }, failOnStatusCode: false, }); });

这个方案要求后端提供/api/test-users/acquire和/api/test-data/cleanup这样的测试专用接口，这是实现高效、隔离的并行E2E测试的常见协作模式。

4.4 合并测试报告

每个并行任务会生成自己的测试结果（如Mocha的JSON报告）。我们需要在最后合并它们。可以在CI中增加一个单独的“合并报告”作业，或者使用cypress-parallel自带的合并功能（如果它支持你的报告格式）。

一个通用的方法是使用mochawesome-merge和marge（mochawesome-report-generator）：

merge-reports: stage: test image: node:18 needs: - cypress-e2e # 需要所有并行测试作业完成 dependencies: - cypress-e2e # 继承其产物 script: # 安装报告合并工具 - npm install -g mochawesome-merge mochawesome-report-generator # 合并所有JSON报告 - npx mochawesome-merge cypress/reports/*.json > merged-report.json # 生成最终的HTML报告 - npx marge merged-report.json —reportDir ./cypress/reports —inline artifacts: paths: - cypress/reports/*.html expire_in: 1 month when: always # 即使测试失败，也生成报告

这样，在流水线结束后，你就可以下载一个包含了所有并行任务结果的统一HTML报告。

5. 常见问题与排查技巧实录

即使经过精心优化，在实际运行中仍会遇到各种问题。以下是我在实践中积累的一些典型问题及其排查思路。

5.1 测试在CI上失败，但在本地通过

这是最常见也最令人头疼的问题。

可能原因及排查：

1. 环境差异：CI环境与本地环境的API地址、数据库、第三方服务配置不同。
   • 检查：在CI脚本中打印关键环境变量（如BASE_URL,API_ENDPOINT）。确保CI环境变量配置正确。
   • 技巧：使用cy.log(Cypress.env())在测试开始时输出所有环境变量到CI日志。
2. 资源竞争与状态污染：虽然做了隔离，但可能隔离不彻底。例如，多个并行任务操作了同一个全局资源（如一个唯一的配置项、一个全局的消息队列）。
   • 检查：查看失败测试的截图和视频。失败是否发生在与“唯一性”相关的操作上？
   • 技巧：为所有并行操作增加更细粒度的唯一标识，例如在创建资源时，名称中不仅包含节点索引，还包含时间戳和随机字符串。
3. 网络延迟与超时：CI环境的网络可能比本地慢，导致默认的超时时间不够。
   • 检查：失败日志中是否大量出现Timed out retrying...？
   • 解决：在cypress.config.js中全局增加defaultCommandTimeout和pageLoadTimeout。或者，在特定的、耗时的命令上单独设置更长的超时：cy.get(‘.slow-element’, { timeout: 20000 })。
4. 浏览器/操作系统差异：CI可能使用与本地不同的浏览器版本或操作系统（如Headless模式下的Linux）。
   • 检查：在CI配置中明确指定浏览器版本和启动参数。考虑在CI中也启用—headed模式（配合虚拟帧缓冲器如xvfb）运行一次，以排除Headless模式特有的问题。
   • 技巧：使用Docker镜像时，确保镜像中的Cypress和浏览器版本与本地锁定的一致。

5.2 测试运行速度不稳定，时快时慢

可能原因及排查：

1. 外部依赖波动：测试依赖的第三方API或服务响应时间不稳定。
   • 解决：对非核心的、不稳定的外部依赖进行拦截和Mock，返回稳定的模拟数据。使用cy.intercept()。
2. 测试数据膨胀：随着时间推移，测试数据库中的数据量越来越大，导致查询变慢。
   • 解决：在测试套件开始前（before钩子），彻底清理并重新初始化测试数据库，确保每次测试都在一个干净、数据量可控的环境中开始。
3. 前端资源未优化：测试的页面本身加载缓慢，可能因为未压缩的图片、未缓存的静态资源等。
   • 检查：使用Cypress的cy.clock()和cy.tick()来控制时间？不，这对性能测试无效。应该使用浏览器开发者工具的Performance面板分析页面在CI环境下的加载情况（这比较困难）。更实际的方法是，确保你的前端应用在CI构建阶段已经过优化（代码分割、压缩、CDN等）。
4. 存在“长尾”测试：个别测试文件运行时间极长，拖累了整体并行效率。
   • 解决：使用基于历史运行时长的智能分割策略（如前文所述），或者手动将这些重型测试拆分到更小的文件中。

5.3 Cypress命令超时或元素找不到

可能原因及排查：

1. 元素尚未出现在DOM中：这是最常见原因。Cypress在发出命令时会自动重试查找元素，直到超时。
   • 解决：确保你的操作（如点击、跳转）完成后，再断言元素存在。优先使用Cypress的链式断言，而不是独立的cy.get。
   • 错误示例：cy.get(‘button’).click(); cy.get(‘.new-element’);（点击后立即查找，可能新元素还未渲染）。
   • 正确示例：cy.get(‘button’).click(); cy.get(‘.new-element’).should(‘be.visible’);（点击后，等待新元素可见）。
2. 元素在iframe或shadow DOM中：Cypress默认无法直接访问这些元素。
   • 解决：对于iframe，使用cy.iframe(‘iframe-selector’).find(‘.inner-element’)（需要cypress-iframe插件）。对于Shadow DOM，需要使用.shadow()命令链式查找。
3. 应用程序使用了非标准渲染框架或极端优化：某些单页应用框架的渲染方式可能导致Cypress的自动检测机制失效。
   • 解决：尝试增加超时时间。在元素选择器上使用{ force: true }选项绕过Cypress的可操作性检查（谨慎使用，这违背了用户真实交互的模拟）。或者，与开发团队沟通，为关键测试元素添加稳定的>