1. 项目概述为什么Cypress测试总让人又爱又恨干了这么多年前端从手动点点点到引入自动化测试踩过的坑比写过的测试用例还多。Cypress这个框架刚出来的时候真是让人眼前一亮号称“下一代前端测试工具”解决了Selenium时代很多让人头疼的问题比如异步等待、调试困难。但真用起来尤其是在复杂的业务项目里落地你会发现它远不是“开箱即用”那么简单。很多团队兴冲冲地引入结果被各种稀奇古怪的问题卡住最后测试代码写得比业务代码还复杂维护成本高到让人想放弃。这篇文章我就结合自己带团队趟过的无数坑来聊聊Cypress测试中那些最常见的“拦路虎”。这些问题官方文档要么一笔带过要么藏在某个不起眼的角落但恰恰是它们决定了你的测试是“稳定可靠的守护神”还是“间歇性抽风的负担”。我们会从元素定位这个最基础的痛点开始一路深入到异步操作、文件处理、CI/CD集成这些高阶难题不仅告诉你问题是什么更重要的是拆解背后的原理并给出经过实战检验的、可直接抄作业的解决方案。无论你是刚开始接触Cypress还是正在为团队的测试稳定性头疼相信都能在这里找到答案。2. 核心问题一元素定位的“玄学”与稳定性保障写Cypress测试第一道坎就是元素定位。你看着浏览器里明明存在的按钮Cypress却告诉你Timed out retrying after 4000ms: Expected to find element: .btn-submit, but never found it.。这种错误太常见了其根源往往不在于Cypress本身而在于我们对现代前端应用渲染机制的理解不足。2.1 动态内容与加载状态等待的艺术现代前端应用React, Vue, Angular大量使用组件化和状态管理元素的出现、消失、更新都是异步的。直接使用cy.get(‘.btn’)就像在黑暗中摸索你无法确定元素是否已经就绪。解决方案的核心是“等待”但不是用cy.wait(固定时间)这种糟糕的方式。固定等待是测试脆弱的万恶之源。正确的做法是让Cypress“感知”应用的状态。第一招利用Cypress内置的重试与断言机制。Cypress的所有命令如get,click,type都自带重试逻辑直到元素满足条件如存在、可见、未被禁用或超时。你应该将断言链在命令之后形成“命令-断言”的防御性编程风格。// 反例脆弱的定位 cy.get(‘.data-table’); // 如果表格还在加载直接失败 cy.get(‘.submit-btn’).click(); // 正例稳健的定位 cy.get(‘.data-table’, { timeout: 10000 }) // 显示设置一个较长的超时 .should(‘be.visible’) // 等待表格可见 .find(‘tr’) // 在可见的表格中查找行 .should(‘have.length.gt’, 0); // 确保有数据行 cy.get(‘.submit-btn’) .should(‘be.visible’) // 等待按钮可见 .and(‘not.be.disabled’) // 同时确保按钮未被禁用 .click(); // 然后点击第二招等待网络请求。很多元素的内容依赖于API返回的数据。Cypress 的cy.intercept()和cy.wait()是黄金组合。// 1. 在访问页面或触发动作前监听特定的API请求 cy.intercept(‘GET’, ‘/api/users’).as(‘getUsers’); // 2. 触发会发送该请求的动作如访问页面、点击筛选按钮 cy.visit(‘/user-management’); // 或者 cy.get(‘.filter-btn’).click(); // 3. 等待这个请求完成 cy.wait(‘getUsers’).its(‘response.statusCode’).should(‘eq’, 200); // 4. 此时再断言或操作依赖于该API数据的DOM元素 cy.get(‘.user-list’).should(‘be.visible’);第三招等待应用特定状态。对于更复杂的场景比如一个Vue组件内部的数据加载完成可能需要自定义等待条件。你可以利用cy.window()访问应用实例或者让开发同学暴露一个全局状态标志。// 假设你的Vue应用在数据加载完成后会在window上设置一个标志 // 在组件中window.APP_STATE { dataLoaded: true }; cy.window().then((win) { // 轮询检查状态最多等待10秒 const checkState () win.APP_STATE win.APP_STATE.dataLoaded; cy.waitUntil(() checkState(), { timeout: 10000, interval: 500, errorMsg: ‘应用数据加载超时’ }); }).then(() { // 状态满足后继续测试 cy.get(‘.content’).should(‘contain’, ‘加载完成的数据’); });实操心得永远不要相信页面会“立即”准备好。把“等待”思维植入你的测试编写习惯。优先使用cy.intercept()等待网络请求这是最可靠的方式。其次是用.should()断言元素状态。万不得已时再考虑使用cy.wait(时间)并且要写下注释说明为什么这里必须用固定等待例如等待一个第三方动画完成且无其他可观测状态。2.2 Iframe、Shadow DOM与复杂组件库如果你的应用嵌入了第三方iframe如支付页面、地图或者使用了Web ComponentsShadow DOM或者复杂的UI组件库如Material-UI, Ant Design内部结构复杂常规选择器就会失效。对于iframeCypress需要你显式地进入iframe的文档上下文。// 假设有一个 id 为 ‘payment-iframe’ 的 iframe cy.get(‘#payment-iframe’) .its(‘0.contentDocument.body’) // 获取iframe内部的body元素 .should(‘not.be.empty’) // 确保iframe已加载 .then(cy.wrap) // 将获取到的body包装成Cypress可操作的对象 .find(‘#card-number’) // 现在可以在iframe内部查找元素了 .type(‘4111111111111111’);更优雅的方式是封装一个自定义命令// 在 cypress/support/commands.js 中 Cypress.Commands.add(‘getWithinIframe’, (iframeSelector, targetSelector) { return cy.get(iframeSelector) .its(‘0.contentDocument.body’) .should(‘not.be.empty’) .then(cy.wrap) .find(targetSelector); }); // 使用 cy.getWithinIframe(‘#payment-iframe’, ‘#card-number’).type(‘4111111111111111’);对于Shadow DOM你需要使用.shadow()命令来穿透阴影边界。cy.get(‘my-custom-element’) .shadow() // 进入Shadow Root .find(‘.internal-button’) .click();对于复杂组件库问题在于它们生成的DOM结构可能非常深且动态类名可能随机化。最佳实践是与开发团队约定为关键的可交互元素如按钮、输入框添加稳定的>// React 组件中 Button>// Cypress 测试中 cy.get(‘[data-testid“submit-login”]’).click();使用组件库提供的测试选择器有些库如 Material-UI 提供了>// selectors.js export const LOGIN_PAGE { usernameInput: ‘[data-testid“username”]’, passwordInput: ‘[data-testid“password”]’, submitButton: ‘[data-testid“submit-login”]’, errorMessage: ‘.alert-error’ }; export const DASHBOARD_PAGE { welcomeMessage: ‘h1’, userMenu: ‘[data-testid“user-avatar”]’ };在测试文件中导入并使用import { LOGIN_PAGE, DASHBOARD_PAGE } from ‘../support/selectors’; describe(‘登录流程’, () { it(‘应能成功登录’, () { cy.visit(‘/login’); cy.get(LOGIN_PAGE.usernameInput).type(‘testuser’); cy.get(LOGIN_PAGE.passwordInput).type(‘password123’); cy.get(LOGIN_PAGE.submitButton).click(); cy.get(DASHBOARD_PAGE.welcomeMessage).should(‘contain’, ‘欢迎回来’); }); });这样做的好处是显而易见的当登录页的>it(‘测试带延迟的提示消息’, () { // 1. 安装时钟并指定一个初始时间如Date.now() const now new Date(2023, 0, 1).getTime(); // 固定一个时间点使测试更确定 cy.clock(now); // 2. 触发会调用setTimeout的动作例如点击一个“保存”按钮该按钮在保存成功后设置一个2秒后消失的提示 cy.get(‘.save-btn’).click(); // 3. 断言提示立即出现因为点击触发了它的显示 cy.get(‘.success-toast’).should(‘be.visible’); // 4. 将时间快进2000毫秒2秒 cy.tick(2000); // 5. 断言提示已经消失因为2秒的setTimeout回调被执行了 cy.get(‘.success-toast’).should(‘not.exist’); // 6. 恢复时钟可选但建议在每个测试结束后恢复避免影响其他测试 cy.clock().then((clock) { clock.restore(); }); });对于setInterval如轮询请求同样可以用cy.tick()来模拟间隔。但更常见的做法是在测试中直接cy.intercept()轮询的API请求并控制其返回这样更直接。注意事项使用cy.clock()后所有基于Date.now(),setTimeout,setInterval,new Date()的代码都会受到影响。确保在测试结束后恢复时钟或者将相关测试用例放在独立的describe块中并在beforeEach中安装时钟在afterEach中恢复避免测试间污染。3.2 Promise与第三方库异步回调有时你需要在Cypress命令中处理非Cypress管理的Promise。Cypress命令不能直接放在Promise的.then()里否则会失去重试和错误处理能力。错误做法// 假设 getDataFromAPI 返回一个Promise getDataFromAPI().then((data) { cy.get(‘.result’).should(‘contain’, data.expectedText); // 这个cy.get可能不会正确重试 });正确做法是使用cy.wrap()将Promise包装成Cypress链式调用的一部分或者使用cy.then()但确保在其中返回新的Cypress命令链。// 方法1: 使用 cy.wrap() cy.wrap(getDataFromAPI()).then((data) { cy.get(‘.result’).should(‘contain’, data.expectedText); }); // 方法2: 在 cy.then() 中返回命令链确保可重试 cy.then(() getDataFromAPI()) .then((data) { return cy.get(‘.result’).should(‘contain’, data.expectedText); });对于第三方库如图表库初始化完成后的回调如果它提供了可观测的状态如触发一个自定义事件最好监听那个事件。如果没有可能需要让开发同学在组件上暴露一个标志如window.chartReady true然后使用前面提到的cy.waitUntil或轮询检查这个标志。3.3 网络请求的稳定性与Mock策略E2E测试是否应该Mock网络请求这是一个策略问题。纯E2E测试主张尽可能真实包括后端。但对于前端测试尤其是CI环境中后端的不稳定、数据污染、测试速度都是大问题。我的建议是采用分层策略集成测试Component Testing大量使用Mock关注前端组件与模拟数据的交互逻辑。端到端测试E2E Testing区分核心业务流程和边缘情况。核心业务流程如用户登录、下单支付尽量使用真实的、隔离的测试环境后端。这能验证前后端集成的正确性。你需要有一套独立的数据准备和清理机制。边缘情况、错误处理如网络超时、服务器错误必须使用Mockcy.intercept()。你无法也不应该为了测试一个404页面而去破坏生产或测试环境的服务器。使用cy.intercept()进行Mock// Mock一个成功的用户列表请求 cy.intercept(‘GET’, ‘/api/users’, { statusCode: 200, body: [ { id: 1, name: ‘张三’ }, { id: 2, name: ‘李四’ } ] }).as(‘getUsers’); // Mock一个登录失败的请求 cy.intercept(‘POST’, ‘/api/login’, { statusCode: 401, body: { message: ‘用户名或密码错误’ } }).as(‘loginFail’); // 在测试中你可以等待这些被Mock的请求 cy.wait(‘getUsers’); // 等待并断言这个请求被发出了管理Mock数据不要将庞大的JSON直接写在测试文件里。将它们放在cypress/fixtures目录下。// cypress/fixtures/users.json [ { “id”: 1, “name”: “张三” }, { “id”: 2, “name”: “李四” } ] // 在测试中 cy.intercept(‘GET’, ‘/api/users’, { fixture: ‘users.json’ }).as(‘getUsers’);经验之谈Mock数据的维护本身也是一种成本。我们团队建立了一个“Mock合约”机制前端和后端在开发初期就定义好关键API的响应格式使用JSON Schema或TypeScript类型测试中使用的Mock数据严格遵循这个合约。这样一旦后端API格式变更TypeScript编译或JSON Schema校验就会报错迫使测试数据同步更新避免了因数据格式不一致导致的测试误报。4. 核心问题三文件上传、下载与数据库操作文件处理和与后端数据库的联动是自动化测试中的高级话题也是容易出错的环节。4.1 文件上传的几种实战方案Cypress本身不直接支持与原生文件选择对话框input type“file”的交互因为这是操作系统级别的控件。但有几种成熟的解决方案。方案A使用cypress-file-upload插件最常用这是社区最流行的方案适用于大多数情况。安装npm install --save-dev cypress-file-upload配置在cypress/support/commands.js中引入import ‘cypress-file-upload’;使用// 将测试文件放在 cypress/fixtures 目录下例如 ‘test-image.jpg’ const fileName ‘test-image.jpg’; cy.get(‘input[type“file”]’).attachFile(fileName); // 插件添加的 attachFile 命令 // 之后可以断言文件上传成功后的UI反馈 cy.get(‘.upload-status’).should(‘contain’, ‘上传成功’);这个插件原理是触发DOM的change事件并将文件内容以Base64等形式注入到input元素绕过了原生对话框。方案B直接使用cy.selectFile()Cypress 9.3.0 原生支持新版本的Cypress内置了文件选择支持更简单。cy.get(‘input[type“file”]’).selectFile(‘cypress/fixtures/test-image.jpg’); // 或者选择多个文件 cy.get(‘input[type“file”]’).selectFile([ ‘cypress/fixtures/file1.jpg’, ‘cypress/fixtures/file2.pdf’ ]); // 甚至可以直接用文件内容 cy.get(‘input[type“file”]’).selectFile({ contents: Cypress.Buffer.from(‘file content’), fileName: ‘test.txt’, mimeType: ‘text/plain’ });方案C处理隐藏的File Input有时文件输入框被样式隐藏display: none或visibility: hidden。cypress-file-upload插件可能无法直接工作。你需要先让Cypress“看到”它。// 使用 { force: true } 选项 cy.get(‘input[type“file”]’).attachFile(fileName, { force: true }); // 或者使用原生的 .selectFile() cy.get(‘input[type“file”]’).selectFile(‘cypress/fixtures/test.jpg’, { force: true });{ force: true }会跳过Cypress的可见性检查直接执行操作。慎用因为它模拟了用户无法进行的操作。4.2 文件下载的验证策略验证文件下载比上传更棘手因为涉及到浏览器行为、文件系统和可能的弹窗。Cypress无法直接与“另存为”对话框交互。核心思路是拦截下载请求验证其响应并可能阻止实际下载到磁盘。拦截并验证下载请求推荐// 拦截对下载链接的请求 cy.intercept(‘GET’, ‘/api/report/export*’).as(‘downloadReport’); // * 匹配URL模式 // 触发下载动作点击按钮或链接 cy.get(‘.export-btn’).click(); // 等待拦截的请求完成并验证响应 cy.wait(‘downloadReport’).then((interception) { // 验证状态码 expect(interception.response.statusCode).to.eq(200); // 验证响应头确认是文件下载 expect(interception.response.headers[‘content-type’]).to.include(‘application/vnd.ms-excel’); // 例如Excel expect(interception.response.headers[‘content-disposition’]).to.include(‘attachment’); // 你甚至可以验证响应体对于文本文件如CSV // const csvData interception.response.body; // expect(csvData).to.contain(‘Expected,Header’); });这种方法不会产生实际文件速度快且不依赖文件系统。但它只验证了“服务器正确响应了下载请求”并未验证文件内容。验证文件内容如果需要 如果必须验证文件内容你需要让文件下载到Cypress控制的一个已知目录然后读取它。在cypress.config.js中配置下载目录const { defineConfig } require(‘cypress’); module.exports defineConfig({ e2e: { downloadsFolder: ‘cypress/downloads’, // 可选设置任务在测试运行后清理下载文件夹 setupNodeEvents(on, config) { on(‘task’, { deleteDownloadsFolder() { const fs require(‘fs’); const path require(‘path’); const downloadsFolder path.join(__dirname, ‘..’, ‘cypress’, ‘downloads’); if (fs.existsSync(downloadsFolder)) { fs.rmSync(downloadsFolder, { recursive: true, force: true }); } return null; } }); } } });在测试中触发下载后使用cy.readFile()读取文件。注意cy.readFile()会等待文件出现。// 假设下载的文件名为 ‘report.csv’ cy.readFile(‘cypress/downloads/report.csv’).then((content) { expect(content).to.contain(‘Expected,Data’); });在beforeEach或afterEach中清理下载文件夹避免测试间干扰。beforeEach(() { // 调用在setupNodeEvents中定义的任务 cy.task(‘deleteDownloadsFolder’); });踩坑实录文件下载测试在CI如GitHub Actions, Jenkins上很容易失败因为CI环境可能没有图形界面或者浏览器配置不同。确保在CI配置中为Cypress设置了--headless模式下的正确浏览器参数并且下载目录有写入权限。使用cy.intercept()验证下载请求是CI环境中更稳定的方案。4.3 测试数据准备与清理涉及数据库真正的E2E测试往往需要特定的测试数据。直接在测试中通过UI创建数据如填写表单提交效率低下且容易受UI流程变化影响。最佳实践是通过API或直接操作数据库来准备和清理数据。Cypress 的cy.request()或cy.task()是得力工具。方案A使用cy.request()调用后端API推荐前提是你的测试环境有对应的、可公开访问的API用于数据管理如/api/test/setup。beforeEach(() { // 登录获取token如果需要 cy.request(‘POST’, ‘/api/auth/login’, { username: ‘test-admin’, password: ‘test-pass’ }).then((response) { const token response.body.token; // 将token存入localStorage或设置请求头供后续请求使用 window.localStorage.setItem(‘authToken’, token); }); // 创建测试所需的数据 cy.request({ method: ‘POST’, url: ‘/api/test/create-user’, headers: { Authorization: Bearer ${window.localStorage.getItem(‘authToken’)} }, body: { name: ‘E2E Test User’, email: ‘e2etest.com’ } }).as(‘createUser’); }); afterEach(() { // 清理测试数据 cy.request({ method: ‘DELETE’, url: ‘/api/test/cleanup-users’, headers: { Authorization: Bearer ${window.localStorage.getItem(‘authToken’)} }, qs: { email: ‘e2etest.com’ } // 删除刚创建的用户 }); });方案B使用cy.task()运行Node.js代码直接操作数据库当没有现成的API时可以通过Cypress的Node环境直接连接数据库。在cypress.config.js的setupNodeEvents中定义任务const { defineConfig } require(‘cypress’); const { MongoClient } require(‘mongodb’); // 以MongoDB为例 module.exports defineConfig({ e2e: { setupNodeEvents(on, config) { on(‘task’, { async createUserInDB(userData) { const client new MongoClient(process.env.TEST_DB_URI); await client.connect(); const db client.db(‘test’); const result await db.collection(‘users’).insertOne(userData); await client.close(); return result.insertedId; // 返回新用户的ID可在测试中使用 }, async deleteUserFromDB(email) { const client new MongoClient(process.env.TEST_DB_URI); await client.connect(); const db client.db(‘test’); const result await db.collection(‘users’).deleteOne({ email }); await client.close(); return result.deletedCount; } }); } } });在测试中使用任务beforeEach(() { cy.task(‘createUserInDB’, { name: ‘DB User’, email: ‘dbtest.com’ }).then((userId) { Cypress.env(‘testUserId’, userId); // 存储ID供后续使用 }); }); afterEach(() { cy.task(‘deleteUserFromDB’, ‘dbtest.com’); });重要安全提示永远不要在测试代码中硬编码数据库密码或其他敏感信息。使用环境变量如process.env.TEST_DB_URI来管理连接字符串并在CI/CD系统中安全地配置这些变量。确保测试数据库是与生产、开发隔离的独立实例避免数据污染。5. 核心问题四CI/CD集成、性能与测试报告将Cypress测试集成到持续集成/持续部署流水线中是发挥其价值的最终环节。但这里同样布满了陷阱环境差异、运行速度、测试报告可视化。5.1 CI环境下的浏览器与依赖问题在本地跑得好好的测试一上CI就失败最常见的原因是环境差异。浏览器问题CI服务器通常没有图形界面需要以无头模式运行。Cypress默认使用Electron浏览器但在CI中你可能需要或想要使用Chrome。方案1使用Cypress Docker镜像。这是最推荐的方式它提供了一个包含所有依赖包括Chrome的稳定环境。在GitHub Actions中示例jobs: cypress-run: runs-on: ubuntu-latest container: cypress/included:12.0.0 # 指定Cypress官方镜像 steps: - uses: actions/checkoutv3 - run: npm ci - run: npx cypress run --browser chrome # 在容器内运行方案2在CI机器上安装浏览器。如果你不使用Docker需要在CI步骤中显式安装Chrome。jobs: cypress-run: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: cypress-io/github-actionv5 # 使用Cypress官方Action它会处理浏览器安装 with: browser: chrome依赖问题确保CI环境与本地环境的Node版本、npm包版本一致。使用package-lock.json或yarn.lock文件锁定依赖版本。在CI脚本中使用npm ci而不是npm install来确保安装的依赖与锁文件完全一致。环境变量与配置测试环境如API基础URL、数据库连接在CI中需要通过环境变量注入。使用cypress.config.js中的config对象或Cypress.env()来访问。// cypress.config.js module.exports defineConfig({ e2e: { baseUrl: process.env.CYPRESS_BASE_URL || ‘http://localhost:3000’, env: { apiUrl: process.env.CYPRESS_API_URL } } }); // 在测试中 const apiUrl Cypress.env(‘apiUrl’); cy.request(‘GET’, ${apiUrl}/users);5.2 测试并行化与运行优化当测试套件增长到几百个用例时串行运行可能耗时几十分钟严重影响反馈速度。Cypress官方付费方案Dashboard Service提供了最完善的并行化和负载均衡。但开源方案也有办法使用cypress-split等社区插件这些插件可以手动将测试文件列表分割成多个组然后在不同的CI机器上并行运行。你需要结合CI的矩阵策略Matrix Strategy。GitHub Actions 示例jobs: cypress-parallel: runs-on: ubuntu-latest strategy: fail-fast: false # 一组失败不影响其他组 matrix: containers: [1, 2, 3] # 定义3个并行容器 steps: - uses: actions/checkoutv3 - uses: cypress-io/github-actionv5 with: browser: chrome parallel: true group: “UI Tests - Container ${{ matrix.containers }}“ record: true # 如果需要录制到Dashboard parallel: true ci-build-id: ${{ github.run_id }} env: CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}配合cypress-split插件可以在运行时动态分配测试文件给每个容器。优化单个测试速度减少cy.visit()每个cy.visit()都会加载整个页面成本很高。对于测试同一页面的多个场景使用cy.session()Cypress 12来缓存和复用登录状态避免重复登录。使用cy.intercept()拦截静态资源拦截并Stub掉不必要的图片、字体、第三方脚本请求可以显著加快页面加载。beforeEach(() { // 拦截所有图片请求返回一个1x1的透明GIF cy.intercept(‘**/*.{png,jpg,jpeg,svg,gif}’, { fixture: ‘images/1x1.gif’ }); // 拦截Google Analytics等第三方脚本避免其加载和报错 cy.intercept(‘https://www.google-analytics.com/**’, { statusCode: 200 }); });避免不必要的等待用cy.intercept()和.should()代替cy.wait(毫秒数)。5.3 生成与解读测试报告在CI中你需要清晰的测试报告来快速定位失败原因。Cypress默认输出简单的spec格式报告到控制台但这不够直观。方案A使用mochawesome生成漂亮的HTML报告最流行安装依赖npm install --save-dev mocha mochawesome mochawesome-merge mochawesome-report-generator在cypress.config.js中配置reportermodule.exports defineConfig({ e2e: { reporter: ‘mochawesome’, reporterOptions: { reportDir: ‘cypress/reports’, // 报告生成目录 overwrite: false, // 避免覆盖方便合并 html: true, json: true } } });运行测试npx cypress run --reporter mochawesome如果并行运行每个容器会生成独立的JSON报告。使用mochawesome-merge合并它们再用mochawesome-report-generator生成最终HTML。// package.json scripts “scripts”: { “cy:run”: “cypress run --reporter mochawesome”, “cy:merge-reports”: “mochawesome-merge cypress/reports/*.json cypress/reports/combinedReport.json”, “cy:generate-report”: “marge cypress/reports/combinedReport.json -f report -o cypress/reports”, “test:e2e”: “npm run cy:run npm run cy:merge-reports npm run cy:generate-report” }生成的HTML报告包含通过率、耗时、错误堆栈、甚至测试步骤的截图非常利于排查。方案B集成到CI的测试结果面板如GitHub Actions的AnnotationsJenkins的JUnit插件让Cypress生成JUnit格式的XML报告// cypress.config.js module.exports defineConfig({ e2e: { reporter: ‘junit’, reporterOptions: { mochaFile: ‘cypress/reports/junit/results-[hash].xml’, toConsole: false } } });在CI配置中将生成的XML报告路径告知CI系统。GitHub Actions示例- name: Publish Test Results uses: actions/upload-artifactv3 if: always() # 即使测试失败也上传 with: name: cypress-junit-reports path: cypress/reports/junit/ - name: Publish to GitHub Checks uses: EnricoMi/publish-unit-test-result-actionv2 if: always() with: files: cypress/reports/junit/*.xml这样在GitHub的Pull Request中就能看到详细的测试结果摘要。CI/CD集成心得测试的稳定性比覆盖率更重要。一个经常“飘红”失败的测试套件很快就会被团队忽略。确保你的测试是独立的不依赖执行顺序、可重复的在任何环境结果一致、快速的反馈及时。在CI流水线中可以考虑将E2E测试放在部署到预发布环境之后进行这样测试的是最接近生产的环境。同时设置失败重试机制Cypress的--retries选项并配置通知如Slack、钉钉让团队能第一时间知道构建状态。
