前端测试

前端测试是一套覆盖从代码粒度到用户体验的完整质量保障体系，核心目标是验证前端应用 “是否符合预期”“是否稳定可靠”“是否满足用户需求”。它并非单一环节，而是按测试粒度、测试目标、测试场景划分的多层级体系，下面从「核心维度」「测试类型」「落地实践」「工具生态」「避坑指南」五个层面全方位拆解：

一、前端测试的核心维度（先明确 “测什么、为什么测”）

前端测试需围绕 4 个核心维度展开，覆盖 “代码→交互→体验→兼容性” 全链路：

维度	测试目标	核心关注点
功能正确性	代码 / 交互是否符合产品需求	函数返回值、组件渲染、用户操作后的状态变化
稳定性	异常场景下是否崩溃 / 报错	边界值、异步失败、网络异常、数据异常
体验一致性	交互 / 视觉是否符合预期	响应速度、动画流畅度、样式一致性
环境兼容性	不同设备 / 浏览器 / 网络下是否正常运行	浏览器兼容、移动端适配、低网络 / 断网场景

二、前端测试的核心类型（按 “粒度从细到粗” 划分）

前端测试按「测试粒度」可分为 5 类，从 “代码单元” 到 “端到端场景” 逐层覆盖，不同类型互补而非替代：

1. 单元测试（Unit Testing）：测 “最小可测试单元”

• 定义：针对前端中 “最小的、独立的代码单元”（函数、组件方法、工具类）的测试，隔离外部依赖（如 mock 接口、全局变量），验证其逻辑是否正确。

• 核心目标：确保单一功能点的逻辑无错，是 “代码级别的安全网”。

• 适用场景：

  • 工具函数（如日期格式化、数据校验、金额计算）；
  • 组件的核心方法（如表单校验逻辑、列表筛选逻辑）；
  • 状态管理逻辑（如 Vuex/Redux 的 reducer/action）。

• 测试原则：

  • 隔离性：每个测试用例独立，不依赖其他用例 / 外部环境；
  • 原子性：一个用例只测一个逻辑点（如 “输入负数返回错误”“输入空值返回默认值” 分开测）；
  • 无副作用：测试后不修改全局状态、不污染环境。

• 举例：测试formatPrice(1000)是否返回¥1,000.00，测试validatePhone('123456')是否返回false。

2. 组件测试（Component Testing）：测 “组件的完整性”

• 定义：针对 UI 组件的测试（比单元测试粒度大），验证组件在不同 props / 状态下的渲染、交互是否符合预期，模拟用户真实操作（点击、输入、选择）。

• 核心目标：确保组件 “看得见、能用、行为对”，而非仅测试内部实现。

• 适用场景：

  • 通用组件（按钮、输入框、弹窗、表格）；
  • 业务组件（购物车组件、支付表单、商品卡片）。

• 测试原则（核心：模拟用户视角）：

  • 不测试组件内部实现（如不关心 “用了 useState 还是 ref”，只关心 “输入内容后是否显示正确”）；
  • 覆盖组件的核心状态（如按钮的禁用 / 启用、弹窗的显示 / 隐藏、表单的校验提示）；
  • 模拟真实用户操作（如用 “点击按钮” 而非直接调用组件方法）。

• 举例：测试 “点击提交按钮后，校验失败的表单是否显示错误提示”，测试 “传入不同 props 的商品卡片是否渲染正确价格 / 图片”。

3. 集成测试（Integration Testing）：测 “模块间的协作”

• 定义：验证多个单元 / 组件 / 模块组合在一起的交互是否正常，重点测 “依赖关系” 和 “数据流转”。

• 核心目标：确保模块间协作无断层（比如 “组件 A 的输出是否能正确作为组件 B 的输入”）。

• 适用场景：

  • 组件嵌套（如 “搜索框 + 搜索结果列表” 的联动）；
  • 前端与接口的集成（如 “调用接口后，数据是否正确渲染到组件”）；
  • 状态管理与组件的集成（如 “Redux 状态更新后，组件是否重新渲染”）。

• 关键区别：单元测试隔离外部依赖，集成测试则 “部分放开依赖”（如用真实的接口 Mock 而非完全隔离）。

• 举例：测试 “用户在搜索框输入关键词→点击搜索→接口返回数据→列表渲染结果” 的完整链路（但仅测前端内部，不涉及后端真实服务）。

4. 端到端测试（E2E Testing）：测 “用户完整场景”

• 定义：模拟真实用户操作，从 “打开应用” 到 “完成某个业务流程” 的全链路测试，覆盖前端 + 后端 + 数据库的完整交互。

• 核心目标：验证 “用户视角的核心业务流程是否能跑通”，接近真实使用场景。

• 适用场景：

  • 核心业务流程（登录→加购→结算→支付、注册→验证→完善信息）；
  • 跨页面交互（如从商品详情页跳转到购物车，数据是否同步）。

• 测试原则：

  • 模拟真实用户行为（如点击、输入、等待加载）；
  • 聚焦核心流程（不覆盖所有细节，只测关键路径）；
  • 允许一定的执行时间（比单元测试慢，因为要模拟真实操作）。

• 举例：测试 “用户登录后，修改个人昵称，退出再登录，昵称是否更新”。

5. 专项测试：测 “特殊场景 / 非功能需求”

除了核心功能测试，前端还需覆盖 “非功能类” 专项测试，解决 “功能对了，但体验 / 兼容性不行” 的问题：

专项类型	测试目标	常用方法 / 工具
兼容性测试	不同浏览器 / 设备 / 系统下是否正常运行	浏览器：Chrome/Firefox/Safari/Edge/IE；设备：真机 / 模拟器（BrowserStack、Sauce Labs）；CSS：Autoprefixer 校验
性能测试	页面加载 / 交互 / 渲染是否流畅	Lighthouse（加载性能、FCP/LCP/CLS）、Web Vitals、Chrome DevTools Performance 面板
可访问性测试	满足无障碍标准（如 WCAG），适配残障用户	axe-core、Lighthouse（可访问性评分）、屏幕阅读器（NVDA、VoiceOver）
视觉回归测试	页面样式 / 布局是否意外变更	Percy、Loki、Chromatic（截图对比）
安全测试	防范 XSS、CSRF、敏感信息泄露等	CSP 校验、XSS 扫描工具（XSS Hunter）、手动检查 localStorage/sessionStorage 是否存敏感信息

三、前端测试的落地实践（从 0 到 1 搭建测试体系）

1. 测试策略：按项目阶段 / 规模适配

项目类型	测试重点	落地建议
小型 / 一次性项目	核心单元测试 + 手动 E2E 测试	只覆盖支付、登录等核心逻辑，不追求全覆盖
中大型 / 长期项目	单元 + 组件（80% 覆盖）+ E2E（核心流程）+ 专项测试	先搭测试框架，迭代时补测试，CI/CD 自动化
组件库 / 通用工具	单元 + 组件（100% 核心覆盖）+ 兼容性测试	TDD 模式（先写测试再写代码），覆盖所有边界值

2. 测试流程：闭环管理

1. 需求阶段：梳理测试点（产品需求→拆解为可测试的功能点 / 边界场景）；

2. 开发阶段：

   • 新功能：TDD（先写测试用例，再写业务代码）；
   • 改 bug：先写 “复现 bug 的测试用例”，再修复代码（避免回归）；

3. 提交阶段：Git Hooks（husky）触发单元 / 组件测试，不通过则禁止提交；

4. 合并阶段：CI/CD（GitHub Actions/GitLab CI）触发全量测试（单元 + 组件 + E2E），不通过则禁止合并；

5. 发布阶段：触发兼容性 / 性能测试，生成测试报告；

6. 发布后：监控线上报错（Sentry），发现问题后补测试用例。

3. 测试覆盖率：追求 “有效覆盖” 而非 “数字”

• 覆盖率指标：行覆盖率（line）、分支覆盖率（branch）、函数覆盖率（function）；

• 核心原则：

  • 单元测试：核心工具函数 / 逻辑分支覆盖率≥90%，展示组件≥50%；
  • 组件测试：覆盖所有 props / 状态 / 用户操作，不追求 100% 行覆盖；
  • 避免 “为了覆盖率写无用测试”（比如覆盖空行、注释行）。

四、前端测试的工具生态（按测试类型分类）

前端测试工具已形成成熟生态，核心是 “框架 + 辅助工具” 组合，按场景选择即可：

测试类型	核心框架 / 工具	补充工具
单元测试	Jest（通用、功能全）、Vitest（轻量、快）	ts-jest（TS 支持）、mockjs（数据 mock）
组件测试	Testing Library（React/Vue/Angular 通用）、Vue Test Utils、React Testing Library	MSW（接口 mock）、jsdom（模拟浏览器环境）
E2E 测试	Cypress（易用、可视化）、Playwright（多浏览器、跨平台）、Selenium（老牌、通用）	Allure（测试报告）、faker.js（生成测试数据）
性能测试	Lighthouse、Web Vitals、Chrome DevTools	Calibre（性能监控）、Bundle Analyzer（包体积）
兼容性测试	BrowserStack、Sauce Labs、CrossBrowserTesting	本地：Chrome/Firefox/Safari/Edge 开发者工具（设备模拟）
视觉回归测试	Percy、Loki、Chromatic	Resemble.js（自定义截图对比）
可访问性测试	axe-core、Lighthouse、WAVE	NVDA（屏幕阅读器）、VoiceOver（Mac/iOS）
自动化集成	husky（Git Hooks）、lint-staged（暂存区测试）、GitHub Actions/ GitLab CI（CI/CD）	-

五、前端测试的避坑指南（避免 “白忙活”）

1. 常见误区

• ❌ 追求 100% 覆盖率：覆盖边界值 / 核心逻辑比 “数字达标” 更重要；
• ❌ 测试实现细节：比如测试 “组件用了 useState” 而非 “组件点击后状态变化”，重构后测试全失效；
• ❌ E2E 测试写得太细：覆盖所有按钮 / 输入框，导致测试慢、易维护；
• ❌ 忽略异步场景：比如未等待接口返回就断言，导致测试偶发失败；
• ❌ 测试环境与生产不一致：比如本地用 mock 数据，CI 用真实数据，导致测试结果不准。

2. 优化技巧

• ✅ 单元测试：优先测 “纯函数”（无副作用），复杂逻辑拆分为小函数再测；
• ✅ 组件测试：用 Testing Library 的 “用户行为 API”（如 fireEvent.click），模拟真实操作；
• ✅ E2E 测试：只测核心流程（如登录、支付），每个用例控制在 10 步以内；
• ✅ 异步测试：用 async/await 等待异步操作完成，避免 “假通过”；
• ✅ 测试复用：抽离通用 mock 数据 / 测试方法（如登录逻辑、接口 mock）；
• ✅ 本地 + CI 结合：本地跑单元 / 组件测试（快），CI 跑 E2E / 兼容性测试（慢但全）。

六、总结：前端测试的核心逻辑

前端测试不是 “单一工具的使用”，而是以 “用户需求” 为核心，按 “粒度从细到粗” 搭建的质量保障体系：

• 单元测试：保障 “代码逻辑对”（基础）；
• 组件测试：保障 “组件交互对”（中层）；
• 集成 / E2E 测试：保障 “业务流程对”（上层）；
• 专项测试：保障 “体验 / 兼容 / 安全对”（补充）。

对于前端开发者而言，测试的核心价值不是 “写了多少用例”，而是 “用最低的成本，避免最大的风险”—— 短期看增加了代码量，但长期看：

• 减少线上 bug 的修复成本（线上 bug 的成本是测试成本的 10 倍以上）；
• 降低迭代时的回归成本（不用手动点几十次页面验证）；
• 让代码更健壮、团队协作更顺畅（测试用例是 “可执行的文档”）。

最终，前端测试的目标是：让应用 “在任何环境、任何操作下，都能符合用户预期”—— 这也是前端工程化的核心环节之一。

前端测试高频面试考点

前端测试是前端工程化面试的高频考点，面试官不仅关注「工具使用」，更侧重「测试思维、体系设计、问题解决」。以下梳理核心考点分类 + 高频问题 + 标准答案思路 + 避坑要点，覆盖基础到进阶全维度：

一、基础概念类（必问，考察对测试体系的认知）

1. 前端测试有哪些类型？区别和适用场景是什么？

• 标准答案思路：按「粒度从细到粗」拆解，突出「互补性」而非「替代性」：

  • 单元测试：测最小独立单元（函数 / 组件方法），隔离依赖，快、覆盖边界，适合工具函数 / 状态逻辑；
  • 组件测试：测 UI 组件的渲染 / 交互，模拟用户行为，适合通用组件 / 业务组件；
  • 集成测试：测模块间协作（组件嵌套 / 接口联调），验证数据流转，适合跨模块逻辑；
  • E2E 测试：测完整业务流程，模拟真实用户操作，覆盖前后端，适合登录 / 支付等核心流程；
  • 专项测试：兼容性 / 性能 / 可访问性，解决非功能需求问题。

• 避坑：不要只罗列名称，要说明「为什么不同场景用不同测试」（比如单元测试快但测不了跨模块，E2E 贴近用户但慢）。

2. 单元测试的核心原则是什么？

• 标准答案思路：核心是「隔离、原子、无副作用、可重复」：

  • 隔离性：每个用例独立，mock 外部依赖（接口 / 全局变量），不依赖其他用例结果；
  • 原子性：一个用例只测一个逻辑点（比如「输入负数报错」和「输入空值返回默认」分开测）；
  • 无副作用：测试后不污染全局状态、不修改本地存储；
  • 可重复：多次运行结果一致，不依赖随机数 / 时间等不稳定因素。

3. 测试覆盖率是什么？是不是越高越好？

• 标准答案思路：

  • 定义：衡量测试覆盖代码的比例（行 / 分支 / 函数覆盖率），是「参考指标」而非「目标」；
  • 不是越高越好：✅ 有效覆盖：核心逻辑（支付 / 校验）的分支覆盖率≥90%，比「100% 行覆盖」更重要；❌ 无效覆盖：为了数字覆盖空行 / 注释，或测试实现细节（重构后全失效）；
  • 合理目标：单元测试核心逻辑≥80%，组件测试覆盖核心交互，E2E 不追求覆盖率。

二、工具使用类（考察实操能力）

1. Jest/Vitest 的核心区别？怎么选？

• 标准答案思路：

  维度	Jest	Vitest
  底层	基于 Node.js	基于 Vite，支持浏览器 / Node.js
  速度	中等（缓存优化）	极快（ES 模块 + Vite 编译）
  生态	丰富（React/Vue/TS 适配成熟）	轻量（兼容 Jest API，生态快速补齐）
  适用场景	大型老项目、依赖 Jest 生态	Vue3/Vite 项目、中小型新项目

  • 选择逻辑：新项目优先 Vitest（快），老项目 / 复杂生态选 Jest（稳）。

2. Testing Library 的核心思想？为什么不推荐测试组件实现细节？

• 标准答案思路：

  • 核心思想：「以用户视角测试」（测组件「做什么」，而非「怎么做」）；
  • 关键原则：✅ 优先查询用户可见的元素（如 getByRole/getByText，而非 getByTestId）；✅ 模拟真实用户操作（fireEvent/await findBy）；
  • 不测试实现细节的原因：❌ 测试实现（如组件内部用了 useState/refs）→ 重构（比如改 useReducer）后测试全失效；✅ 测试行为（如点击按钮后弹窗显示）→ 无论内部怎么改，只要行为符合预期就通过。

3. Cypress/Playwright 的区别？E2E 测试怎么写才高效？

• 标准答案思路：

  维度	Cypress	Playwright
  浏览器支持	仅 Chromium（扩展支持 Firefox）	全浏览器（Chromium/Firefox/Safari）
  并行测试	支持但弱	原生支持，速度快
  移动端模拟	有限	原生支持手机 / 平板模拟
  易用性	高（可视化、API 简单）	中等（API 稍复杂，功能更全）

• E2E 测试高效写法：✅ 只测核心流程（登录 / 加购 / 支付），每个用例≤10 步；✅ 抽离通用逻辑（如登录方法），避免重复代码；✅ 用 fixture 管理测试数据，避免硬编码；❌ 不测试细节（如按钮颜色、文字排版），交给视觉回归测试。

4. 如何 Mock 异步请求 / 全局变量？（Jest/Vitest 示例）

• 标准答案思路：

  • Mock 接口（MSW/Jest.mock）：

    // MSW（推荐，贴近真实）
    import { rest } from 'msw';
    import { setupServer } from 'msw/node';
    const server = setupServer(rest.get('/api/user', (req, res, ctx) => res(ctx.json({ name: 'test' }))));
    beforeAll(() => server.listen());
    afterAll(() => server.close());
    

  • Mock 全局变量（如 window.localStorage）：

    beforeEach(() => {
      Storage.prototype.setItem = jest.fn();
      Storage.prototype.getItem = jest.fn().mockReturnValue('token');
    });
    afterEach(() => jest.clearAllMocks());
    

三、测试设计类（考察工程化思维）

1. 如何给一个组件库设计测试体系？

• 标准答案思路：按「粒度 + 场景」分层：

  1. 单元测试：覆盖工具函数 / 组件内部方法（100% 核心逻辑），用 Jest/Vitest；

  2. 组件测试：

     • 覆盖所有 props / 插槽 / 事件（如按钮的 size/type/onClick）；
     • 用 Testing Library 模拟用户操作（点击 / 输入）；

  3. 兼容性测试：用 BrowserStack 测试不同浏览器 / 设备的渲染；

  4. 视觉回归测试：用 Chromatic/Percy 做截图对比，避免样式变更；

  5. 自动化：CI/CD 触发全量测试，发布前必须通过；

  6. 策略：TDD 模式（先写测试再写组件），覆盖所有边界值（如空 props / 异常输入）。

2. 老项目如何补测试？（无测试的遗留项目）

• 标准答案思路：「先核心后边缘，先易后难」：

  1. 梳理核心链路：先覆盖登录 / 支付 / 结算等核心业务逻辑；
  2. 优先补单元测试：工具函数→状态管理→组件核心方法（易落地、见效快）；
  3. 迭代时补测试：每次改需求 / 修 bug，先补对应测试用例，再改代码；
  4. 逐步覆盖：不追求一次性全覆盖，每周补 1-2 个模块；
  5. 自动化兜底：先加 Git Hooks，提交前跑已有的测试，避免改坏核心逻辑。

3. TDD（测试驱动开发）的流程和优势？适合前端哪些场景？

• 标准答案思路：

  • 流程：需求→拆解测试点→写失败的测试用例→写业务代码直到测试通过→重构代码（测试不失效）；
  • 优势：✅ 逻辑更清晰：测试用例明确「代码要做什么」，避免过度开发；✅ 代码更健壮：天然覆盖边界值，重构无压力；✅ 可执行文档：测试用例就是文档，新人易理解；
  • 适用场景：工具函数 / 组件库 / 核心业务逻辑（如表单校验），不适合纯展示组件。

四、问题排查类（考察实战能力）

1. 测试用例 “偶发失败”（flaky test）怎么排查？

• 标准答案思路：按「优先级」排查：

  1. 异步问题：未等待异步操作完成（如接口返回、组件渲染）→ 用 await/findBy（而非 getBy）；
  2. 时序问题：测试用例依赖执行顺序→ 保证用例独立（beforeEach/afterEach 清理状态）；
  3. 环境问题：测试环境与生产不一致（如 mock 数据 / 全局变量）→ 统一测试环境；
  4. 资源竞争：E2E 测试并行操作同一元素→ 加等待 / 避免并行测试核心流程；
  5. 随机因素：依赖随机数 / 时间→ mock 随机数 / 时间。

2. 组件测试中，如何模拟用户的复杂交互？（如表单提交 + 弹窗确认）

• 标准答案思路：

  // Testing Library示例
  test('表单提交后弹窗确认', async () => {
    render(<LoginForm />);
    // 1. 模拟输入（用户行为）
    await userEvent.type(screen.getByLabelText('手机号'), '13800138000');
    await userEvent.type(screen.getByLabelText('密码'), '123456');
    // 2. 模拟点击提交
    await userEvent.click(screen.getByRole('button', { name: '登录' }));
    // 3. 等待弹窗出现并点击确认
    const confirmBtn = await screen.findByRole('button', { name: '确认' });
    await userEvent.click(confirmBtn);
    // 4. 断言结果
    expect(screen.getByText('登录成功')).toBeInTheDocument();
  });
  

• 核心：用userEvent（而非 fireEvent）模拟真实用户操作，用await等待异步渲染。

3. 如何平衡测试的 “全面性” 和 “开发效率”？

• 标准答案思路：

  1. 分层测试：核心逻辑（单元 + E2E）全覆盖，展示组件少测，纯样式不测；
  2. 工具提效：用 Vitest（快）、MSW（mock 接口）、抽离通用测试逻辑；
  3. 自动化兜底：本地跑单元 / 组件测试（快），CI 跑 E2E / 兼容性测试（慢）；
  4. 拒绝过度测试：E2E 不测细节，单元测试不测实现，组件测试不测样式；
  5. 补测策略：修 bug 时补测试，迭代时补测试，不追求一次性全覆盖。

五、进阶场景类（大厂高频）

1. 微前端项目如何做测试？

• 标准答案思路：

  1. 子应用测试：独立测试（单元 + 组件 + E2E），模拟主应用的环境（mock 全局变量 / 通信方法）；
  2. 主应用测试：测试子应用的加载 / 卸载 / 通信（如通过 mock 子应用的入口函数）；
  3. 集成测试：测试跨子应用的流程（如从 A 子应用跳转到 B 子应用，数据是否同步）；
  4. 注意：避免 E2E 测试全量微前端（慢），拆分核心流程单独测。

2. 前端性能测试怎么落地？（指标 + 工具 + 流程）

• 标准答案思路：

  1. 核心指标：Web Vitals（LCP/CLS/FID/INP）、首屏加载时间、包体积；

  2. 工具：Lighthouse（本地 / CI）、Web Vitals 库（线上监控）、Bundle Analyzer（包体积）；

  3. 落地流程：

     • 开发阶段：用 Bundle Analyzer 优化包体积，本地跑 Lighthouse；
     • CI 阶段：触发 Lighthouse CI，设置指标阈值（如 LCP<2.5s），不通过则禁止合并；
     • 线上阶段：接入 Sentry/Firebase，监控性能指标，异常告警。

3. 可访问性测试（A11y）的核心要点？

• 标准答案思路：

  1. 核心标准：WCAG 2.1（可感知 / 可操作 / 可理解 / 鲁棒性）；

  2. 测试方法：

     • 自动化：axe-core/Lighthouse（检测标签语义化 / 颜色对比度）；
     • 手动：屏幕阅读器（NVDA/VoiceOver）、键盘操作（Tab 遍历所有元素）；

  3. 核心检查点：✅ 语义化标签（不用 div 代替 button/ul）；✅ 颜色对比度≥4.5:1；✅ 表单有 label/aria-label；✅ 可键盘操作（无鼠标也能完成所有流程）。

总结：面试答题核心技巧

1. 先框架后细节：回答时先讲整体体系（如测试类型），再讲具体工具 / 场景；
2. 结合场景：不要只说 “会用 Jest”，要说明 “在 XX 场景下用 Jest 做了 XX 测试，解决了 XX 问题”；
3. 突出思维：面试官更关注 “为什么这么测”（测试策略），而非 “怎么写代码”；
4. 避坑关键词：不要说 “追求 100% 覆盖率”“测试组件内部的 useState”“E2E 测所有细节”。

以上考点覆盖初中高级前端面试，基础考点（类型 / 工具）是中小厂重点，进阶考点（微前端 / 性能 / 可访问性）是大厂高频，结合 “概念 + 实操 + 思维” 回答即可拿到高分。

请给我落地一套 Vue2项目 前端测试实战方案

Vue2 前端测试实战方案落地指南

一、方案整体架构

基于 Vue2 生态，搭建单元测试 + 组件测试 + E2E 测试 三层测试体系，技术栈选型如下：

测试类型	核心工具	辅助工具	适用场景
单元测试	Jest	babel-jest、vue-jest@3	工具函数、mixins、Vue 方法
组件测试	Vue Test Utils (v1)	Jest、jsdom	单文件组件（SFC）逻辑 / 渲染
E2E 测试	Cypress	cypress-vue-unit-test（可选）	页面流程、交互场景

二、环境搭建（从零开始）

1. 基础依赖安装

# 核心测试依赖
npm install jest vue-jest@3 @vue/test-utils@1 babel-jest @babel/core @babel/preset-env -D

# E2E 测试依赖
npm install cypress -D

# 辅助工具（根据项目情况可选）
npm install jsdom @types/jest jest-serializer-vue jest-transform-stub -D

2. 配置文件编写

（1）Jest 配置（jest.config.js）

module.exports = {
  // 测试文件匹配规则
  testMatch: ['**/tests/unit/**/*.spec.(js|jsx|ts|tsx)'],
  // 模块文件扩展名
  moduleFileExtensions: ['js', 'jsx', 'json', 'vue'],
  // 模块别名（和项目webpack alias保持一致）
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1',
    '\.(css|less|scss|sass)$': 'jest-transform-stub' // 忽略样式文件
  },
  // 转换器
  transform: {
    '^.+\.vue$': 'vue-jest', // 处理.vue文件
    '^.+\.js$': 'babel-jest' // 处理js文件
  },
  // 快照序列化器
  snapshotSerializers: ['jest-serializer-vue'],
  // 测试环境
  testEnvironment: 'jsdom',
  // 覆盖率配置
  collectCoverage: false, // 默认关闭，运行时可通过--coverage开启
  collectCoverageFrom: [
    'src/**/*.{js,vue}',
    '!src/main.js', // 排除入口文件
    '!src/router/index.js', // 排除路由配置（可单独测）
    '!**/node_modules/**'
  ],
  coverageDirectory: 'tests/unit/coverage',
  coverageReporters: ['html', 'text-summary']
}

（2）Babel 配置（babel.config.js）

适配 Jest 对 ES6+ 语法的兼容：

module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        targets: {
          node: 'current' // 适配当前Node版本
        }
      }
    ]
  ]
}

（3）Cypress 配置（cypress.config.js）

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:8080', // 项目本地运行地址
    specPattern: 'tests/e2e/specs/**/*.cy.js',
    supportFile: 'tests/e2e/support/index.js',
    fixturesFolder: 'tests/e2e/fixtures',
    screenshotsFolder: 'tests/e2e/screenshots',
    videosFolder: 'tests/e2e/videos'
  }
})

（4）package.json 脚本配置

{
  "scripts": {
    "test:unit": "jest --config=jest.config.js", // 运行单元/组件测试
    "test:unit:coverage": "jest --config=jest.config.js --coverage", // 带覆盖率
    "test:e2e": "cypress open", // 打开Cypress界面
    "test:e2e:run": "cypress run" // 无头运行E2E测试
  }
}

三、实战案例

1. 单元测试（工具函数）

测试目标

src/utils/format.js 中的日期格式化函数：

// src/utils/format.js
export function formatDate(date, format = 'YYYY-MM-DD') {
  const d = new Date(date)
  const year = d.getFullYear()
  const month = String(d.getMonth() + 1).padStart(2, '0')
  const day = String(d.getDate()).padStart(2, '0')
  return format.replace('YYYY', year).replace('MM', month).replace('DD', day)
}

测试用例（tests/unit/format.spec.js）

import { formatDate } from '@/utils/format'

describe('formatDate 函数测试', () => {
  it('格式化合法日期', () => {
    expect(formatDate('2025-01-01')).toBe('2025-01-01')
    expect(formatDate(new Date(2025, 0, 1), 'YYYY/MM/DD')).toBe('2025/01/01')
  })

  it('处理非法日期返回默认格式', () => {
    expect(formatDate('invalid-date')).toBe('NaN-NaN-NaN') // 边界情况
  })

  it('月份/日期补零', () => {
    expect(formatDate(new Date(2025, 1, 5))).toBe('2025-02-05')
  })
})

2. 组件测试（Vue 单文件组件）

测试目标

src/components/Button.vue 基础按钮组件：

<template>
  <button 
    class="custom-btn"
    :class="{ 'btn-disabled': disabled }"
    @click="handleClick"
  >
    {{ label }}
  </button>
</template>

<script>
export default {
  name: 'CustomButton',
  props: {
    label: {
      type: String,
      default: '按钮'
    },
    disabled: {
      type: Boolean,
      default: false
    }
  },
  methods: {
    handleClick() {
      if (!this.disabled) {
        this.$emit('click')
      }
    }
  }
}
</script>

测试用例（tests/unit/Button.spec.js）

import { mount } from '@vue/test-utils'
import CustomButton from '@/components/Button.vue'

describe('CustomButton 组件测试', () => {
  // 基础渲染测试
  it('默认渲染正确', () => {
    const wrapper = mount(CustomButton)
    expect(wrapper.text()).toBe('按钮')
    expect(wrapper.find('.custom-btn').exists()).toBe(true)
    expect(wrapper.classes('btn-disabled')).toBe(false)
  })

  // Props 测试
  it('接收 label 和 disabled props', () => {
    const wrapper = mount(CustomButton, {
      propsData: {
        label: '提交',
        disabled: true
      }
    })
    expect(wrapper.text()).toBe('提交')
    expect(wrapper.classes('btn-disabled')).toBe(true)
  })

  // 事件测试
  it('点击触发click事件（非禁用状态）', async () => {
    const wrapper = mount(CustomButton)
    await wrapper.trigger('click')
    expect(wrapper.emitted('click')).toBeTruthy()
    expect(wrapper.emitted('click').length).toBe(1)
  })

  it('禁用状态不触发click事件', async () => {
    const wrapper = mount(CustomButton, {
      propsData: { disabled: true }
    })
    await wrapper.trigger('click')
    expect(wrapper.emitted('click')).toBeFalsy()
  })
})

3. E2E 测试（页面流程）

测试目标

登录页面（src/views/Login.vue）的登录流程：

• 输入账号密码
• 点击登录按钮
• 验证跳转逻辑

测试用例（tests/e2e/specs/login.cy.js）

describe('登录页面 E2E 测试', () => {
  beforeEach(() => {
    // 每次测试前访问登录页
    cy.visit('/login')
  })

  it('输入合法账号密码登录成功', () => {
    // 输入账号
    cy.get('input[name="username"]').type('admin')
    // 输入密码
    cy.get('input[name="password"]').type('123456')
    // 点击登录按钮
    cy.get('button[type="submit"]').click()
    // 验证跳转到首页
    cy.url().should('include', '/home')
    // 验证首页显示欢迎信息
    cy.get('.welcome-text').should('contain', '欢迎 admin')
  })

  it('密码错误登录失败', () => {
    cy.get('input[name="username"]').type('admin')
    cy.get('input[name="password"]').type('wrong-password')
    cy.get('button[type="submit"]').click()
    // 验证提示错误信息
    cy.get('.error-message').should('be.visible').and('contain', '密码错误')
    // 验证停留在登录页
    cy.url().should('include', '/login')
  })
})

四、进阶优化

1. 测试覆盖率分析

运行 npm run test:unit:coverage 后，会在 tests/unit/coverage 生成 HTML 报告，重点关注：

• 行覆盖率（Line coverage）：代码行是否被执行
• 分支覆盖率（Branch coverage）：if/else 等分支是否都覆盖
• 目标：核心业务代码覆盖率 ≥ 80%

2. Mock 处理

（1）Mock Vuex

import { mount } from '@vue/test-utils'
import MyComponent from '@/components/MyComponent.vue'

const store = {
  state: { count: 0 },
  getters: { doubleCount: () => 0 },
  actions: { increment: jest.fn() }
}

const wrapper = mount(MyComponent, {
  mocks: {
    $store: store
  }
})

（2）Mock Axios

import axios from 'axios'
jest.mock('axios')

test('请求数据测试', async () => {
  axios.get.mockResolvedValue({ data: { list: [] } })
  // 执行请求逻辑
  // 验证axios.get被调用
  expect(axios.get).toHaveBeenCalledWith('/api/data')
})

3. 集成到 CI/CD

在 gitlab-ci.yml 或 GitHub Actions 中添加测试步骤：

# .github/workflows/test.yml
name: Test
on: [push, pull_request]

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '16' }
      - run: npm install
      - run: npm run test:unit:coverage

  e2e-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '16' }
      - run: npm install
      - run: npm run serve & # 启动项目
      - run: npm run test:e2e:run

4. 测试规范

• 测试文件命名：[文件名].spec.js（单元 / 组件）、[场景].cy.js（E2E）
• 测试结构：describe（测试套件）→ it（测试用例）→ expect（断言）
• 优先测试：核心业务逻辑、边界条件、异常场景
• 避免测试：第三方库、纯 UI 样式（可通过快照辅助）

五、常见问题解决

1. Vue2 与 vue-jest 版本兼容：必须使用 vue-jest@3 + @vue/test-utils@1，高版本不支持 Vue2
2. 样式文件解析报错：通过 jest-transform-stub 忽略样式文件
3. DOM 操作报错：确保 testEnvironment 为 jsdom
4. E2E 测试页面访问失败：检查 baseUrl 是否正确，确保本地服务已启动

六、落地步骤总结

1. 安装依赖并配置 jest/cypress 配置文件
2. 编写核心工具函数的单元测试（快速落地）
3. 覆盖核心业务组件的组件测试
4. 编写关键流程的 E2E 测试
5. 集成到 CI/CD，确保每次提交都运行测试
6. 逐步完善测试覆盖率，优化测试用例

通过这套方案，可实现 Vue2 项目的测试全覆盖，提升代码质量，减少线上 Bug。