5.5 测试策略：单元、集成与端到端的分工

5.5 测试策略：单元、集成与端到端的分工

本节摘要：测试不是"写得越多越好"，而是"在正确的位置写正确的测试"。本节以测试金字塔为主线，讲清单元测试、集成测试、端到端测试三层各自的职责、工具与代价，介绍各框架的测试工具链（Jest/Vitest、Testing Library、Cypress/Playwright），并给出覆盖率指标、质量门禁与 CI 集成的落地方法。核心结论：金字塔是原则，不是教条——按"风险"而不是"数量"分配测试投入。

上手前先明确

阅读完本节，你应当能够：

1. 画出测试金字塔并解释三层的职责分工。
2. 为 React/Vue/Angular 选择合适的测试工具组合。
3. 用 Testing Library 写"以用户视角"的组件测试。
4. 制定合理的测试覆盖率目标与质量门禁。
5. 把测试接入 CI 实现自动回归。

一、问题与直觉：为什么测试多得像山，Bug 还是漏到生产

有的团队测试文件堆成山，上线照样出事；有的团队测试不多，质量却稳。差别不在"写得多不多"，而在"测试守不守得住关键风险"。一个 100% 覆盖率的"假测试"（只断言"组件能渲染"的套话用例），和一个 30% 覆盖率的"真测试"（覆盖登录、权限、支付等核心流程），后者对业务的价值远大于前者。

理解测试，要先放下"覆盖率数字崇拜"，回到测试的本质：测试是"风险保险"——为"改了代码会不会把已有功能改坏"上保险。不同位置的代码，改坏的代价不同：核心业务逻辑改坏了最痛，纯展示组件改坏了影响小。测试投入应该跟着"风险"走，而不是跟着"代码行数"走。这就是测试金字塔存在的原因——它把"风险"和"成本"配对，告诉你每个位置该投入多少。

💡 关键直觉：测试金字塔的本质是"成本与收益的平衡表"。底部便宜但覆盖宽，顶部昂贵但覆盖关键——按风险配比投入，而不是均匀撒钱。

二、核心原理：三层测试的分工

2.1 单元测试（Unit Testing）：测最小的逻辑单元

针对函数、组件、纯逻辑做隔离测试，隔离外部依赖（mock 掉请求、定时器）。目标：快速、稳定、定位精准。成本：低，跑得快。适合：工具函数、状态管理逻辑（reducer、store）、组件渲染与交互的局部行为。

工具：Jest / Vitest（测试框架）、@testing-library/react、@testing-library/svelte、Vue Test Utils。

2.2 集成测试（Integration Testing）：测模块间的协作

把多个单元组装起来测"它们能不能配合"：组件 + 状态管理 + 路由的组合，或一个完整的业务流程（登录 → 进列表 → 操作）。目标：发现"单元各自正常但合起来出错"的问题（接口不匹配、状态不同步）。成本：中等。

2.3 端到端测试（E2E Testing）：模拟真实用户走完整流程

用真实浏览器跑完整用户旅程（注册、下单、支付），验证"从输入到最终结果"全链路正确。目标：验证系统级行为与关键业务流程。成本：高（要浏览器、要环境、跑得慢），所以数量要精。

工具：Cypress、Playwright。注意 Angular 的 Protractor 已弃用，官方转向 Cypress/Playwright。

2.4 测试金字塔

金字塔的教训：底层单元测试要多（便宜、兜底广），顶层 E2E 要少（贵、只守关键）。很多人把金字塔画反了——大量昂贵脆弱的 E2E，配少量单元测试，结果跑得又慢又常挂。

2.5 框架测试工具链速览

三、工程实践要点：把测试做成质量防线

3.1 覆盖率目标：合理的数字比 100% 更健康

• 核心业务逻辑：覆盖率目标高（80% 以上）——这是最容易出事故的部分。
• 组件渲染层：中等（50%-70%）——重点测"关键交互与数据流"，别为纯展示追求全覆盖。
• 集成/E2E：不追求覆盖率数字，追求"关键用户旅程全覆盖"。

覆盖率是"体检报告"不是"KPI"。把覆盖率当 KPI 的团队，会写出大量"为了覆盖而覆盖"的空测试。正确用法：覆盖率下降要警觉（是不是没测新代码），覆盖率数字本身不设硬性门槛。

⚠️ 常见坑：用"测试数量"或"覆盖率"做绩效考核。两者都能被刷：写 50 个只断言"能渲染"的测试，覆盖率一样高，价值却接近零。考核应该看"Bug 漏出率"与"回归事故数"——那才是测试真正防住的东西。

3.2 测试金字塔的实际配比参考

一个健康的项目大约：单元测试占 70%、集成测试占 20%、E2E 占 10%（按用例数量）。E2E 只覆盖最高风险的旅程：登录注册、下单支付、核心业务流程。其余细节交给便宜的下层。

3.3 质量门禁与 CI 集成

把测试接进 CI：每次提交/合并前自动跑单元与集成测试（快、频繁跑），E2E 在合并前或夜间跑（慢、低频）。测试失败 → 阻断合并。门禁的关键是"跑得够快 + 结果可靠"——测试又慢又 flaky（偶发失败）的团队，会忍不住跳过测试，门禁形同虚设。宁可少而稳，不可多而崩。

3.4 "以用户视角"写测试

Testing Library 的核心哲学：像用户一样测，而不是像实现者一样测。不查组件内部 state，而是查"用户能看到的"——点击按钮后页面上出现了什么、没出现什么。这样做的好处：测试不绑定实现细节，组件重构后测试依然有效。这比"查 className 是否存在"的测试健壮得多。

3.5 一个测试策略建议

从"最重要的三条业务旅程"开始写 E2E，从"最容易出错的核心逻辑"开始写单元测试，别追求一步到位。测试体系像免疫系统，是"长期养成"而非"一次建成"的。每修一个 Bug，补一个对应的测试（防回归），测试的价值会随时间复利增长——这是最省力也最有效的测试建设方式。

3.6 快照测试：看似省事实则脆弱的"双刃剑"

前端测试里有一个名声很两极的招式：快照测试（Snapshot Testing）——把组件渲染结果存成快照，之后每次渲染与快照比对，不同就报错。它的优点是写起来极快；缺点也同样明显：任何微小的、无关紧要的改动（加了行内样式、改了文案）都会让快照失败，团队为了"让测试通过"会随手 --update 更新快照——更新得多了，快照测试就退化成"测了等于没测"的摆设。所以对快照测试的建议是：要么不用，要么限定用途（只对"结构稳定、改动低频"的关键组件用），并且严格禁止"无脑更新快照"。真正守护行为的，还是"以用户视角断言行为"的 Testing Library 式测试——快照守的是"它长什么样"，行为测试守的是"它能不能用"，后者对用户才有意义。

3.7 测试的投入产出：什么时候"别写测试"

最后说一个很多人不敢说的话：不是所有代码都值得写测试。判断标准有三个"不值得"：一是一次性代码——活动页、演示 demo、临时脚本，跑完就扔，写测试是纯浪费；二是纯展示且无逻辑的组件——渲染一个静态卡片，写"能渲染"的测试等于没写；三是高频改动的早期原型——需求还在快速变化，测试会变成"反复重写"的负担，等需求稳定再补更划算。反过来，核心业务逻辑、状态管理、数据请求、支付权限这类"改坏了代价高"的代码，必须写测试。把"该不该写测试"的判断交给"风险与稳定性"，而不是"行数或覆盖率"，你才不会陷入"为了测试而测试"的泥潭——测试是投资，该投的投，不该投的别硬投。

3.8 测试替身的选择：mock 到什么程度才够

写单元与集成测试时，必然要处理"外部依赖"——接口请求、定时器、浏览器 API。这里有个常见的两难：mock 得太少，测试又慢又不稳定（依赖真实网络）；mock 得太多，测试变成"自己验证自己"（测的都是假数据）。给一个分层原则：按测试层级决定 mock 深度。单元测试：mock 掉所有外部依赖，只测本逻辑单元——此时"全 mock"是合理的。集成测试：mock 掉"跨系统边界"（真实后端接口），但保留"应用内部协作"（组件间通信、状态流转）——这样能验证模块配合。E2E 测试：完全不 mock 接口（用测试环境真后端），验证全链路。这条"层级决定 mock 深度"的约定，能避免两种极端：底层测试被网络拖垮，顶层测试被假数据蒙骗。mock 不是"尽量少"也不是"尽量多"，而是"在该层合适的边界上断"。

3.9 测试文化的落地：从"写测试"到"测试是交付的一部分"

测试最后能不能真正帮到团队，拼的不是工具，是文化。落地测试文化有三个务实的动作。动作一：把测试写进"完成的定义"——一个需求"做完"的验收清单里包含"测试通过"，而不是"功能能点了"。动作二：让测试在提交前就跑——提交前本地跑一遍单元与集成测试（快的那部分），测试红不许提交。动作三：善待失败的测试——测试挂了不是"麻烦"，而是"系统在报警"，第一反应是查为什么，而不是顺手把测试删了或改了。这三个动作不花一分钱预算，却能决定测试是"团队的护城河"还是"仓库里的摆设"。见过太多团队买了最好的测试工具，却因为没有文化而让测试名存实亡——工具是必要不充分条件，文化才是让测试真正运转的发动机。

3.10 一个测试实战：给"登录流程"设计一套分层测试

用"登录流程"演示三层测试怎么分工，最能说明测试金字塔的实操价值。单元层：测"登录表单的校验逻辑"（邮箱格式、必填项、密码强度）、测"认证状态管理模块"（登录成功/失败/过期分别怎么改状态）——这两个都是纯逻辑，跑得快、定位准。集成层：测"表单组件 + 认证 store + 路由跳转"的协作——用户填完表单、提交、store 状态更新、跳转到首页，验证这几步能否衔接。E2E 层：用真实浏览器走完整旅程——输入真实测试账号、点登录、进系统、登出——只测这一条最关键的用户旅程。三层的分工一目了然：单元层兜住"逻辑对不对"，集成层验证"模块配不配"，E2E 层确认"用户顺不顺"。如果这条流程出 Bug，从 E2E 能最快发现，从集成层能定位到协作环节，从单元层能锁定具体逻辑——三层互为支撑，而不是三套重复。这就是测试金字塔在真实项目里"各司其职"的样子。

本章回顾

• 要点一：测试的本质是"为改坏代码的风险上保险"，投入跟着风险走。
• 要点二：金字塔三层——单元多而便宜、集成居中、E2E 少而贵守关键。
• 要点三：覆盖率是体检不是 KPI，合理的数字比 100% 更健康。
• 要点四：E2E 只守最高风险旅程，别把金字塔画反。
• 要点五：测试接入 CI 做成门禁，关键在"快 + 稳"。
• 要点六：以用户视角写测试，每修一个 Bug 补一个回归用例。

质量有测试兜底，接下来是"体验怎么更好"——性能优化四件套。