企业官网建设流程全解析

自动化测试这件事，很多团队不是没做过，而是做了一半就烂尾了。特别是像Userbase这类以用户数据为核心的系统，业务链路长、状态组合多、权限关系复杂，手工回归一次要一整天，自动化又经常挂在环境不稳定和数据干扰上。我最近把我们负责的用户管理系统（下面统一叫它Userbase）从纯手工测试切到了Cypress自动化方案，跑了两个迭代之后，回归时间从原来的大半天压缩到二十分钟左右，最关键的是稳定性能维持在九成以上。这篇就把我们整套测试策略、踩过的坑、以及最终落地的完整方案一次性说清楚，想直接抄作业的也可以照着做。

要做用户系统的自动化，先得想清楚一个问题：这类系统的测试难点到底在哪。Userbase表面看是注册、登录、资料维护、权限控制这几个模块，但真正把它拆开之后，你会发现它有个特别头疼的特点——每个用例几乎都依赖前置用户状态。你测注册，得准备一个不存在的手机号；测登录，得有一个已激活的用户；测资料修改，又要保证用户当前处于特定角色。这些状态叠加在一起，用例与用例之间天然就容易互相污染。所以整套策略的核心，不是把Cypress用得多花哨，而是怎么把测试数据、用户状态、接口依赖这三件事管好。

1. 测试策略：Userbase这类系统到底该怎么测

1.1 为什么自动化测试要优先打在用户链路上

我见过不少项目，自动化测试覆盖率很高，但每次发版心里还是没底。原因很简单，测的都是不痛不痒的页面展示、静态文案这类低风险点，真正的核心链路反而没人碰。Userbase这类系统，自动化资源应该优先砸在用户链路上，因为这里是业务风险最密集的区域。

用户链路指的是用户从注册、激活、登录、信息维护到权限触达这一整条线上所有关键路径。任何一个环节出错，影响的不是一个页面，而是整个产品的用户资产安全。比如注册后验证邮件没发出去、登录时验证码校验逻辑错位、改绑手机导致旧会话失效、高权限角色被降权后仍然能访问管理接口——这类问题手工测试偶尔能发现，但频率低、回归成本高，恰恰最适合自动化去覆盖。

我们当时的判断标准很简单：凡是用户能直接感知、且出问题后影响范围超过单个页面的功能，一律优先做成自动化用例。页面样式、文案拼写、布局错位这类视觉问题，反而放到了手动抽查里。这个取舍非常关键，它决定了你有限的自动化精力到底花在哪里。

1.2 Cypress在同类型框架里胜在哪里

选择Cypress之前，我们也对比过其他方案。有的框架上手成本低，但对时间戳、弹窗这类异步场景支持很弱；有的框架浏览器兼容性好，但写起来相当啰嗦；还有的基于Selenium体系，环境依赖重，跑一次要装一大堆驱动。Cypress在这几个维度的表现，正好卡在我们的需求点上。

首先，Cypress跑在浏览器内部，不用额外启动浏览器驱动，安装一个npm包就能跑。这个体验差异是决定性的——团队里任何一个前端开发都能立刻上手写用例，不需要搭一套复杂的Selenium Grid互相比对浏览器驱动版本。其次，Cypress自带自动等待机制，大部分按钮点击、页面跳转、请求返回它都会等稳定了再继续，省掉了写sleep或显式等待的大量工作。第三是它的调试体验，时间旅行和报错截图几乎是开箱即用，定位问题比对着黑盒日志猜快太多。

当然，Cypress也有自己的偏向性，比如多标签页支持弱、跨域访问限制多。但对于Userbase这种以用户态为核心的Web应用来说，它几乎没有短板。而且它内置的cy.session()、cy.intercept()对用户系统的会话保持和接口Mock场景有非常好的支持，这两个能力直接决定了我们的测试策略能落地到什么程度。

1.3 整体测试分层与用例规划

Userbase的测试用例，我们按三个层级来规划。底层是接口层测试，覆盖注册、登录、资料更新、权限校验等核心API的逻辑正确性。中间层是组件级测试，但说实话这部分我们投入不多，因为Cypress本就更擅长E2E场景，组件级测试我们更多依赖开发侧的单测。最上面一层是端到端测试，也就是Cypress重点承载的场景——真实浏览器环境里，用户走进度条、点按钮、填表单、看结果。

端到端测试用例，我们是按业务场景来组织的，而不是按页面来分。比如“手机号注册并自动登录”是一条场景，“老用户找回密码并重置”是一条场景，“管理员给用户分配角色”是一条场景。每个场景都尽量模拟真实用户的操作路径，而不是只在一个页面里打转。这样做的直接好处是，测试跑通一次，意味着这个业务闭环从入口到数据落库都没有大问题。

用例数量也要控制。我们目前在跑的端到端用例大概在90到110个之间，再多跑批时间就上来了，再少关键路径覆盖不住。数量控制的核心原则是：每条用例覆盖一个独立的业务闭环，尽量避免为了凑覆盖率把一步操作拆成三个用例。

2. 环境搭建与工程结构规划

2.1 安装Cypress与基础配置

环境搭建这块没什么玄学，但有几个配置项直接决定了后面测试能不能稳定跑。安装还是常规套路，项目根目录执行npm install cypress --save-dev，然后npx cypress open把初始目录结构生成出来。这里我要特别提醒一下，Cypress版本升级非常频繁，建议在package.json里锁定一个大版本，不要随手升级到最新版，我们遇到过升级后默认浏览器行为变化导致十几个用例集体挂掉的情况。

真正需要花心思的是cypress.config.js里的配置。以Userbase为例，我们做了这几个关键默认值：

const { defineConfig } = require('cypress'); module.exports = defineConfig({ e2e: { baseUrl: 'http://localhost:8080', viewportWidth: 1440, viewportHeight: 900, defaultCommandTimeout: 10000, requestTimeout: 10000, retries: { runMode: 2, openMode: 0 }, video: true, screenshotOnRunFailure: true, experimentalMemoryManagement: true } });

baseUrl的作用是让所有cy.visit()和cy.request()都基于这个地址写相对路径，避免在几十个用例里硬编码域名导致后期换环境全盘修改。viewport宽高设置成主流桌面分辨率，保证大多数页面元素在可视区域内，减少滚动带来的定位不稳定。retries在runMode下设为2，意味着正式跑批时候每条用例失败会自动重试两次——这个后面稳定性治理部分会细说。

还有一个容易被忽略的选项是experimentalMemoryManagement。Userbase前端页面比较重，单个用例跑久了内存占用会持续上涨，开这个选项可以让Cypress在用例间做内存清理，实测能减少不少偶发崩溃。

2.2 测试目录与自定义命令设计

工程结构这块，我们的目录组织是这样的：

cypress/ ├── e2e/ │ ├── auth/ │ │ ├── register.cy.js │ │ ├── login.cy.js │ │ └── forgot-password.cy.js │ ├── profile/ │ │ ├── edit-info.cy.js │ │ └── change-password.cy.js │ ├── admin/ │ │ ├── user-search.cy.js │ │ └── role-assign.cy.js │ └── api/ │ └── user-api.cy.js ├── fixtures/ │ ├── users.json │ └── roles.json └── support/ ├── commands.js └── e2e.js

e2e目录按业务模块分文件夹，每个文件对应一组场景。fixtures放静态测试数据，这些数据是接口层测试和后端造数时通用的。support/commands.js是全局自定义命令的聚合地，这里我强烈建议把Userbase测试中频繁重复的操作提取成命令，最典型的就是登录。

Userbase的登录包含手机号、密码、图形验证码三个要素，如果每条用例都手动走一遍登录流程，代码会极其冗余，而且验证码环节很容易成为不稳定因素。所以我们做了两类登录命令：

// 通过UI完成登录，用于测试登录流程本身的用例 Cypress.Commands.add('loginViaUI', (phone, password) => { cy.visit('/login'); cy.get('[data-testid="phone-input"]').type(phone); cy.get('[data-testid="password-input"]').type(password); cy.get('[data-testid="login-submit"]').click(); cy.get('[data-testid="user-menu"]').should('be.visible'); }); // 通过接口直接完成登录，用于其他业务场景的前置准备 Cypress.Commands.add('loginViaAPI', (phone, password) => { cy.request({ method: 'POST', url: '/api/auth/login', body: { phone, password } }).then((resp) => { window.localStorage.setItem('token', resp.body.data.token); }); });

loginViaAPI是绕开UI直接拿登录态的关键。登录页本身由专门的登录用例去覆盖，其他业务场景没必要每次把登录流程重新走一遍——既慢又不稳定。这个思路贯穿了我们整个测试策略：登录流程本身只测一次，其他用例用接口造登录态。

自定义命令里还做了一个很实用的小工具，叫clearAllUserData，用来在执行用例前清理脏数据。Userbase的测试环境里有大量历史测试用户，不清场的话，造数时容易撞上已存在的手机号。这个命令本质上是一个批量调用后端清理接口的封装，虽然不值得单独开一节讲，但建议每个Userbase测试工程里都备一个类似的命令。

2.3 测试数据的组织与动态生成

数据这块是用户系统自动化最容易翻车的地方。Userbase要求手机号、邮箱、身份证号这类字段全局唯一，如果测试数据是写死的静态值，两个用例同时用同一个手机号注册，必有一个会失败。

我们的做法是动态生成，而且遵循一个原则：**所有用户数据不允许在用例里直接写死，统一从fixtures或API造数接口取。**手机号用时间戳生成假装符合规范的号码，邮箱用UUID拼接一个不会真的发信的域名。这样能保证每次跑批用户都是全新的，不存在旧数据残留问题。

function generatePhone() { const prefix = '138'; const suffix = String(Date.now()).slice(-8); return prefix + suffix; } function generateEmail() { const salt = CryptoJS.MD5(Date.now().toString()).toString().slice(0, 8); return `user_${salt}@test.local`; }

邮箱后缀用test.local是经过考虑的，因为这个域名不会真实发信，也就不会造成测试环境的邮件垃圾。正式环境的验证邮件发送依赖真实SMTP，而在测试环境里我们通常会拦截或直接走模拟发送通道。这里涉及一个关键决策：像Userbase这类依赖邮件验证的系统，自动化测试到底要不要真的走邮件链路。我们的答案是不要，至少不要走真实的第三方邮件服务。邮件发送延迟不可控，会拖慢用例、增加不确定性，所以测试环境里邮件验证接口是打桩的，用例直接通过接口拿到验证码。

3. 核心测试场景的完整实操

3.1 注册到登录的“黄金路径”测试

我把Userbase最高频的一条业务链路叫做“黄金路径”，就是新用户进来，注册账号，然后登录使用产品。这条路径上每一步都有可能出错，也是每次发布前必须回归的用例。我们把它写成一条完整的E2E用例，而不是拆成注册、登录两条各自的用例。

describe('黄金路径：注册到登录', () => { it('新用户可通过手机号注册并直接登录', () => { const phone = generatePhone(); const password = 'Test@123456'; cy.visit('/register'); cy.get('[data-testid="phone-input"]').type(phone); cy.get('[data-testid="sms-code-input"]').type('123456'); cy.get('[data-testid="password-input"]').type(password); cy.get('[data-testid="agree-terms"]').click(); cy.get('[data-testid="register-submit"]').click(); cy.intercept('/api/user/profile').as('profileRequest'); cy.wait('@profileRequest').its('response.statusCode').should('eq', 200); cy.get('[data-testid="welcome-tip"]').should('contain.text', '您已注册成功'); cy.url().should('include', '/dashboard'); cy.get('[data-testid="user-menu"]').click(); cy.get('[data-testid="logout"]').click(); cy.url().should('include', '/login'); cy.loginViaUI(phone, password); cy.get('[data-testid="user-menu"]').should('be.visible'); cy.contains('[data-testid="dashboard-title"]', '工作台').should('be.visible'); }); });

这条用例里有个容易被忽略但很重要的设计——登录之后我们做了退出登录，然后用同一个账号再走一次UI登录。原因是注册后直接处于登录态是前端行为，但不代表下次登录一定能成功，只有真正走一遍登录接口才能确认账号数据完整落库了。这个“一进一出再进”的设计，测试的就是用户数据从注册到登录的完整闭环。

短信验证码这里我们直接填了固定值123456，这是一个约定——测试环境的验证码服务被Mock掉了，任何请求都返回成功且验证码固定为这个值。实际项目里如果无法Mock验证码服务，就需要走数据库查询或调内部接口动态取码，都会增加复杂度。Mock短信服务这件事建议在测试环境搭建时就把接口约定好，能省掉后续大量麻烦。

3.2 用户资料变更与数据一致性校验

用户资料变更这块，很多人只测“页面显示成功”，这是远远不够的。Userbase的资料变更涉及前端展示、接口写入、数据库持久化三层，页面显示成功只能说明前端收到了200响应，但数据是否真的更新、刷新后是否还能看到，必须进一步校验。

所以我们的资料变更用例，核心是一句话：刷新之后重新声明断言。

it('修改昵称后刷新页面仍然保持新值', () => { cy.loginViaAPI('13800001234', 'Test@123456'); const newNickname = `nickname_${Date.now()}`; cy.visit('/profile/basic'); cy.get('[data-testid="nickname-input"]').clear(); cy.get('[data-testid="nickname-input"]').type(newNickname); cy.get('[data-testid="save-profile"]').click(); cy.get('[data-testid="save-success-tip"]').should('be.visible'); cy.reload(); cy.get('[data-testid="nickname-input"]').should('have.value', newNickname); });

这个用例里我做了cy.reload()之后再次断言输入框值，就是为了验证数据真的写到库里了，而不是前端内存里的假象。如果你希望更严谨，还可以加一层接口断言，直接调用查询接口验证数据库返回值。但注意不要在页面里直接用cy.request查数据库接口——那是白盒测试行为，塞进E2E用例里容易把用例复杂度拉高。我们是另外在接口层测试里去验证的。

资料变更用例还有一个关键点——测试数据要动态创建。Userbase的用户昵称是可以重复的，但有些字段如手机号、身份证号是强校验的。所以修改资料时，凡是涉及唯一性校验的字段，必须用动态生成的值，否则第二次跑同一套用例必挂。

3.3 权限矩阵与越权访问测试

Userbase有三种核心角色：普通用户、管理员、超级管理员。权限相关的测试，是所有用例里最有价值也最容易遗漏的。很多人只测“管理员能访问管理后台”，却忽略了“普通用户访问管理后台必须被拒绝”这个反向场景。实际上，反向用例比正向用例更能发现安全问题。

我们专门建了一个权限矩阵用例文件，用表格驱动的方式来组织场景：

const permissionMatrix = [ { role: 'user', url: '/admin/users', expect: 403 }, { role: 'user', url: '/admin/settings', expect: 403 }, { role: 'admin', url: '/admin/users', expect: 200 }, { role: 'admin', url: '/admin/settings', expect: 403 }, { role: 'superAdmin', url: '/admin/settings', expect: 200 } ]; permissionMatrix.forEach(({ role, url, expect }) => { it(`角色${role}访问${url}，期望状态码${expect}`, () => { const account = roleAccounts[role]; cy.loginViaAPI(account.phone, account.password); cy.request({ url, failOnStatusCode: false }).then((resp) => { expect(resp.status).to.eq(expect); }); }); });

这种表格驱动的方式有几个好处。第一，新增一个角色或者新增一个受保护页面时，只需要在数组里加一行；第二，每个用例的名字是自动生成的，跑挂了之后一眼就能看出是哪个角色、哪个页面出问题；第三，采用cy.request而不是UI页面访问，是因为后端接口的鉴权判断是权限控制的根本，页面只是末端表现，接口层面验证才是最可靠的方式。

当然，UI层面的路由守卫也值得测，方法是直接访问页面，断言会跳转到登录页或显示无权限提示。但这类用例成本高、收益相对低，不需要每个权限组合都过一遍UI，挑几条有代表性的覆盖一下即可。

对称地，正向权限用例也要覆盖。比如管理员在用户管理页面能看到“分配角色”按钮，而普通用户即使通过某种方式进入了管理后台页面，这个按钮也不应该渲染出来。这类“按钮级鉴权”的UI验证，跑通一遍能有效防止前端把全部权限数据一股脑下发到页面，然后靠CSS隐藏的粗糙做法混过发布。

4. 接口Mock与测试隔离策略

4.1 为什么Userbase系统的测试必须Mock接口

很多人做E2E测试，喜欢让测试跑最真实的环境，连真实后端、连真实数据库、连真实短信服务，听起来很美好，实际非常脆弱。Userbase系统依赖大量外部服务和异步任务，比如短信网关可能超时、邮件服务可能排队、队列消费可能延迟，任何一个环节抖动，都会让测试挂掉。而测试挂了之后，你得花很长时间判断是业务代码问题还是环境问题，信心消耗极其严重。

我们在做测试隔离时，核心原则是：**自动化用例所在的环境，必须是一个完全可控的封闭环境。**什么意思？后端服务和数据库可以连真实的测试环境，但所有外部依赖（短信、邮件、第三方登录）必须Mock，所有非核心的下游接口必须打桩。

4.2 用cy.intercept拦截写入与读取

Cypress的cy.intercept()是我认为整个框架里最核心的能力，它对测试隔离的作用主要体现在两个场景：一个是拦截不必要的请求直接返回假数据，另一个是监听请求断言请求参数。

第一个场景，用户读取消息列表时，如果这个消息列表依赖一个队列消费服务，消费延迟会导致页面数据时有时无。我们直接在用例前置里拦截它：

cy.intercept('GET', '/api/user/messages*', (req) => { req.reply({ statusCode: 200, body: { code: 0, data: { messages: [], total: 0 } } }); });

第二个场景，在注册用例里监听注册接口的请求体，确保前端提交的参数符合预期：

cy.intercept('POST', '/api/auth/register', (req) => { req.body.phone.should('match', /^1\d{10}$/); }).as('registerRequest'); cy.get('[data-testid="register-submit"]').click(); cy.wait('@registerRequest');

Mock接口的取舍标准，要反复强调的是：**Mock的目的是消除不确定性，而不是掩盖业务问题。**核心业务链路（注册、登录、资安全验证）永远不要Mock，要让代码逻辑真实跑一遍；只有外围链路的依赖（短信、搜索、推荐）才适合Mock。如果无脑把所有接口全部打桩，E2E测试就退化成前端组件测试，价值直接减半。

4.3 前置数据准备：从UI造数到数据库直连

测试用例执行时，经常需要预先存在某个用户。比如测试忘记密码功能，你得先有一个已注册用户；测试管理员分配角色，你得先有一个普通用户。这些前置数据怎么来？三种思路，从慢到快排开。

第一种是走UI造数，就是动态注册一个用户，然后用这个用户执行后续步骤。这种方式最真实，但最慢，一个注册流程至少三五秒，如果一条用例要造三个不同类型用户，光造数就占了十秒，跑批速度完全没法接受。

第二种是走接口造数，直接调用后端提供的用户创建接口。这比UI快很多，但需要有内部接口可用，而且仍然受后端逻辑约束，比如创建后要等同步任务刷新才能用。

第三种是走数据库直连，在测试的before里执行SQL语句直接插一条用户记录。这最快，也最灵活，可以插入任意状态的数据。但风险也最大——绕过业务代码直接写库，可能造出业务逻辑上不合理的数据，导致用例后面步骤反而执行不下去。

我们最终采用的是组合方案：常规场景用接口造数，特殊场景用数据库直连。比如需要构造一个“已冻结用户”，接口可能不允许创建冻结状态的用户，那就走SQL更新。这种做法不需要每个测试工程师都会写SQL，但至少团队里要有一个人能完成任务分工。

数据库直连的代码用一个示例来说明，比如要造一个已验证手机号的用户：

const mysql = require('mysql2/promise'); async function createVerifiedUser(phone) { const conn = await mysql.createConnection({ host: '10.x.x.x', user: 'test_user', password: 'test_pass', database: 'userbase_test' }); await conn.execute( 'INSERT INTO users (phone, password_hash, status, is_verified) VALUES (?, ?, ?, ?)', [phone, bcrypt.hashSync('Test@123456', 10), 'active', 1] ); await conn.end(); }

在Cypress的before钩子里调用这个异步函数，就能在用例执行前把数据准备好。这种方法最大的优势是造数的速度——一条SQL插入几乎无感知，测试的启动时间大幅缩短。

5. 接入CI与稳定性治理

5.1 跑批与并行的规模选择

Cypress自动化测试做出来了，如果不能顺畅地接入持续集成（CI）流水线，用例写得再精细也只能当摆设。我们最开始是把测试挂在发布的前一天晚上手动执行，但效果很差——过了个夜回来一看几十个用例挂着，根本不知道前一天改代码时问题出在哪，定位成本极高。

后来把测试直接插入CI流水线，每次代码合并到主干后自动触发跑批。这里先要确定跑批规模。90到110个E2E用例，Cypress跑完整套的话，在普通环境下大概要15到20分钟。如果超过20分钟，就该考虑并行策略了。

Cypress并行执行有两种方式：一是用官方DashBoard的并行能力，但这个要从平台登录，增加外部依赖；二是在同一台机器上多实例并行，比如用npm-run-all或直接开多个终端跑。

我们用的是Cypress官方推荐的并行策略，在CI里配置好多个容器同时跑：

# 在CI配置文件中定义4个并行容器，每个容器执行一部分用例 cypress run --group e2e --parallel --record --key $CYPRESS_RECORD_KEY --ci-build-id $CI_BUILD_ID

并行跑起来之后，最直接的感受是时间从17分钟压缩到6分钟，开发者在CI里看到结果的速度快了很多，反馈周期短了，修复问题的效率也提高了。不过并行牵扯到一个特点：每个用例必须能独立运行、不依赖其他用例的执行顺序，否则并行后随机执行的顺序会把用例顺序依赖全部暴露出来，这也是为什么前面测试隔离策略这么重要的原因。

5.2 失败重试与用例去抖动

E2E测试读空白，必然会有偶发失败。有些失败是业务Bug，有些是测试自身不稳定，比如某个按钮动画挡住了点击、页面加载慢了一点点、某个接口响应超时。我们要做的是区分这两类失败，并尽可能让“假失败”不影响CI的信心。

Cypress提供了两个层面的重试机制。第一层是全局配置retries，这个我在配置部分提过，设置runMode: 2，意味着正式跑批时失败用例自动重试两次。第二层是单个用例或者单个断言的重试设置，有些用例稳定性稍微差一点，可以在用例级别单独加：

it('用户搜索功能支持模糊匹配', { retries: { runMode: 3 } }, () => { // ... });

我们在实践中的经验是：全局重试两到三次可以明显减少肉眼可见的偶发失败，但不能把重试次数调得过高。如果一个用例本身就有问题，重试三次大概率还是失败，只会白白拖慢CI。真正要做的是把问题分类——某个用例连续失败三次以上，就说明它不是因为偶发因素，而是存在真实的稳定性隐患。

去抖动方面，最重要的做法是去掉一切固定等待，改用Cypress的自动等待和显式断言。很多不稳定的用例都是因为测试里写了一长串cy.wait(3000)这种硬等待，数据早回来了在等，数据还没回来也等，碰到慢的环境照样挂。要改成对目标元素做should('be.visible')断言，让Cypress自己等它出现。这个是基本功，但真的能清理掉不少偶发失败。

5.3 测试报告的可观测性建设

自动化测试最怕的不是失败，而是失败后找不到原因。Cypress自带的screenshot和video能力帮了大忙，但还不够。我们需要一套清晰的可观测体系，让任何人看一眼报告就知道该往哪儿查。

Cypress默认会在失败时截取屏幕截图，也在跑批时录制全程视频。我们在CI里配置了失败截图和视频的上传，并接入IM通知。每次CI跑批结束后，通过脚本解析Cypress生成的JSON测试结果汇总，把失败用例名、失败原因、截图链接、视频链接推送给团队群。这个汇总脚本不复杂，大概几十行代码：

const fs = require('fs'); const results = JSON.parse(fs.readFileSync('results.json', 'utf8')); const failed = results.runs[0].tests.filter(t => t.state === 'failed'); failed.forEach(t => { const msg = `用例失败: ${t.title.join(' > ')}\n` + `原因: ${t.error || 'timeout'}\n` + `报告地址: ${buildUrl(t)}`; postToIM(msg); });

这步做完之后，团队里没人再抱怨“测试挂了不知道怎么回事”，看消息就能直接跳转到失败用例和相关截图，排查效率提升非常明显。可观测性的价值，很多时候比多用例数量更重要——你宁可只有80条稳定、可排查的用例，也不要150条一到晚上就集体报红的用例。

6. 实战中躲不开的坑与排查经验

6.1 动态用户状态引起的用例互相干扰

用例之间的互相干扰，是Userbase自动化里最凶的坑，比环境问题还难查。我们遇到过这种情况：单条跑没有问题，打包跑偶尔出现几条零星失败，重试又能过。排查了很久，最后发现是公共测试账号被并发用例改了密码或改了昵称，导致依赖这个账号的其他用例在登录或断言时挂掉。

怎么解决？核心就是把“共享数据”降为零。每条用例需要用户，就动态创建独立用户，用完不管，下次重新创建。公共账号只保留一个用于只读场景，比如查看公开列表页面，如果每条用例都去改这个账号的状态，那迟早要出问题。

另外要小心同一个用例文件内部的状态串联。Userbase的用例文件里，如果你用了before而不是beforeEach去登录，那么第一个用例退出登录之后，第二个用例的登录态可能已经没了。这种情况极其隐蔽，因为你看到的报错经常是“找不到用户菜单”而不是“未登录”。我们后面定了规矩：**每个用例必须自己准备自己的登录态，不依赖before里的公共状态。**这样虽然多写几行代码，但稳定性是实打实的。

6.2 弹窗、iframe与异步加载的定位难点

Cypress对页面里的普通元素定位非常顺手，但Userbase里有两个场景经常让人抓狂：一个是第三方登录的iframe弹窗，另一个是二次确认的对话框。

iframe问题，Cypress官方是支持获取的，但写起来比常规选择器复杂，而且iframe加载完成的时间很难精准等待。我们的处理是能不让用例碰iframe就不碰，第三方登录场景单独在集成了第三方登录的环境里维护一套手工冒烟用例，不纳入Cypress跑批。如果你实在需要测iframe，常规的做法是：

cy.get('iframe[title="第三方登录"]') .its('0.contentDocument.body') .should('not.be.empty') .then(cy.wrap) .find('[data-testid="confirm-button"]') .click();

异步对话框这里是另一个高频坑。Userbase的很多操作都需要弹窗二次确认，比如删除用户、解绑手机号。弹窗可能出现延迟，或者弹窗里的按钮要等接口返回才变成可用状态。我们在实践中的经验是，不要对弹窗机制做太多花样处理，直接用cy.within来限定作用域，然后对目标按钮做显式等待：

cy.get('[data-testid="delete-user-modal"]').should('be.visible'); cy.get('[data-testid="delete-user-modal"]') .within(() => { cy.get('[data-testid="confirm-delete"]').should('be.enabled').click(); });

这里确定弹窗真正出现，再做点击，配合Cypress本身的自动重试机制，绝大多数情况能稳定通过。如果还有偶发卡顿，就要往弹窗组件渲染逻辑层面排查，很少是Cypress的问题。

6.3 Cypress在Userbase项目中值得注意的局限

说了这么多优点，Cypress也有一些在Userbase这类系统上绕不过去或者成本很高的局限。先说跨域问题。Cypress默认关闭跨域访问，集成第三方登录时如果第三方认证页面被iframe包裹在系统内，Cypress拿不到页面细节，很难做完整的跨系统流程测试。我们的妥协方案就是前面说的，第三方登录走单独的手工冒烟通道。

第二个局限是多标签页测试。Userbase有“在另一窗口打开用户详情”的交互，Cypress不支持直接操作多标签页，它设计的理念是单页操作。如果需要验证新标签页里的内容，得通过获取新页面的URL后，用cy.visit在新标签页的位置去访问。这样能做，但不是原生支持，写起来不自然，可维护性也差。

第三个局限是iframe场景支持较弱，前面已经提到过了。第四个局限是Cypress跑批时会有一个很重的容器进程，在并行跑多个容器时对CI机器的要求比较高，内存小的机器跑十几个并发容器可能会被拖垮。这个可以从控制并行容器数量上来规避，不用追求无限并行。

这些局限不是说不能用Cypress，而是说任何工具都有自己的边界，你在设计测试策略时就要把这些边界考虑进去。Userbase的核心链路Cypress能覆盖得非常好，但边缘的跨域场景和第三方集成场景，该用其他手段补的就要用其他手段补。

6.4 常见问题速查表

把日常跑批中碰到最频繁的几个问题整理成一张表，方便直接对照排查。

这个表是跑了两三个迭代之后慢慢沉淀出来的，每次碰到一个“看起来很奇怪”的问题，解决了就记进去。后面团队里有新人接手测试脚本，遇到问题时先翻这个表，大部分情况都能快速定位。

最后说点实际操作中的体会

整套Cypress方案在Userbase项目上跑起来之后，我最深的感受是：自动化测试的难点从来不是怎么写用例，而是怎么设计一套能稳定、快速、可维护的运行体系。工具本身只是载体，真正决定测试体系成败的，是数据隔离、接口Mock、用例独立性这些架构层面的决策。如果一个用例三天两头因为环境原因挂掉，团队很快就会对自动化失去信心，再好用的框架都没有意义。

在Userbase之后的迭代里，我给自己的规矩是：每条新用例必须在打包跑批里连续通过至少五次才允许合入主干。这个过程很笨，但它能筛掉大量“看起来能跑”的脆弱用例。另外就是时刻提醒自己，不要让测试用例数量无限膨胀——每加一个页面都写一堆用例，早晚会被维护成本压垮。用例数量要服务于业务风险覆盖，而不是数量本身。

如果你正准备给用户系统上Cypress自动化，我建议你从一套最小的黄金路径用例如手，先跑通一条“注册到登录”的完整闭环，再逐步往外扩展。不要一上来就追求几十条用例，更不要把Cypress当成万能的。跑通了核心闭环，你对测试体系整体架构的理解就会清晰很多，后面加用例只是一个熟练活而已。