4.4 API 测试：契约的验收环节
4.4 API 测试：契约的验收环节
本节摘要：测试是契约交付前的验收：单元测逻辑、集成测咬合、端到端测全链路、性能测扛压、安全测防攻。本节讲清这五层的分工与先后，用一次"高并发回归把集成测试顶挂"的演练展示如何用契约测试与负载测试守住边界，最后落到测试金字塔与回归纪律。
一笔"假成功"订单敲响的验收警钟
先看一次常见的事故：用户在前台提交订单，页面弹出"支付成功"，后台却查不到这笔单。追到接口层才发现，支付的 POST 返回了 201，可它内部的订单落库环节压根没跑——因为只有"返回成功"这单一断言，序列化、落库、状态流转这些关键路径从不在发布前被真正验证。像这种"看着成功、实则失败"的接口，只有把过硬的验收节奏立起来才能在出厂前拦住。本节讲的五层测试，就是给这类漏风上保险。
学习目标
阅读完本节，你应当能够：
- 区分单元、集成、端到端、性能、安全五种测试的职责。
- 说清测试金字塔的层数与比例原则。
- 设计一套契约测试，防止客户端与服务端的假设错位。
- 安排自动化回归与性能看门狗，守住交付边界。
测试不是"最后补一枪"
测试常被当作上线的最后一道手续，其实它是交付质量的验收环节——和做工一样，验收不合格就不能出厂。把测试分五层想清楚，比"多写几个用例"更能管住质量。本节的钥匙，是理解每一层在堵哪一类漏。
二、五层测试的分工与先后
| 层 | 测什么 | 快慢 | 放哪层防 |
|---|---|---|---|
| 单元 | 单个函数/模块逻辑 | 最快 | 字段校验、业务分支 |
| 集成 | 组件（API 层与业务层）的咬合 | 较快 | 序列化、数据库交互 |
| 端到端 | 从入口到后端的全链路 | 慢 | 路由、依赖编排 |
| 性能 | 高并发下的响应与吞吐 | 慢 | 慢查询、瓶颈 |
| 安全 | 认证绕过、注入、越权 | 依场景 | 漏洞面 |
单元测试验证单个函数在给定输入下的正确输出，是质量底盘；集成测试确认组件之间能对上话；端到端模拟真实请求走完整条链路，眼见为实；性能测试用并发压出吞吐与延迟，看它扛不扛得住峰值；安全测试专门打认证绕过、注入、越权这类漏洞面。
把五层各自的日常形态也说破，层与层之间就不容易混。单元常见于给校验函数"输入坏邮箱、坏密码"这类分支喂用例；集成常见于"调用一次序列化、落一次库、捞回再对比"的接口与存储协作；端到端最典型是一条"注册→登录→下单→查订单"的真链路；性能常写一个"200 并发持续 5 分钟，看 p99 延迟和错误率"的脚本；安全则是有针对性地打"越权访问别人的订单、注掉登录参数、拖出整张用户表"。每一层盯的变量不同，混在一起只会让用例又慢又脆。
把五层测试的放量与先后画成一张金字塔透视图，一图看懂投入比例：
图：五层测试金字塔
三、测试金字塔与比例
一张被验证过无数次的铁律：越多、越快、越便宜的要测在底层。金字塔从下到上是"单元 → 集成 → 端到端"，数量与成本自上而下递增、自下而上递减。
意思是：底层的单元测试最多最便宜，端到端最少最贵。正确的自动化投入，应该把大头压在金字塔底，而不是全都堆在又贵又慢的端到端上。
比例上的一个常用参考是"单元 : 集成 : 端到端 ≈ 7 : 2 : 1"，但别把它当教条死背——真正要紧的是方向：凡是能用再便宜一层的测试覆盖的，就不该往上堆。一个关注点一旦能在单元层断言，就别让它在端到端里兜底；端到端的价值在于验证"组装起来对不对"，而不是替你重跑一遍单元该做的校验。把这个方向钉住，金字塔的比例自然收敛，而不必靠清单硬凑。
四、一次"高并发回归把集成测试顶挂"的演练
背景：一次例会前，团队要发布一个订单接口的小改动，回归跑了一遍慢吞吞的端到端套件，性能测试也偶发超时。
操作与结果：把测试重新分层——逻辑校验下放到单元（秒级跑完），序列化与数据库交互归集成，端到端只留最关键的主干链路，另给高并发接口挂一个性能看门狗：每次合入自动跑最小并发的压测，超阈值即失败。
解读：分层后，一次微调在分钟级能跑完大部分自动化，性能回归也不再"偶发超时却无人问"。问题是"每一层各扫一摊，靠最便宜的兜最大面积"，而不是把重活全堆在一个又贵又慢的套件上。
变式：若接口改动特别大（动了路由表、改了认证流程），才值得端到端全量跑一遍，平时的日常改动用金字塔底层足矣。
五、契约测试与回归纪律
测试要守的，不只是"代码跑对"，更是"把契约钉住"：
-
契约测试：客户端存一份对服务端响应的断言（schema、字段、状态码），服务端测试本质也在校验同一份 spec。两方对着同一个 OpenAPI 的"成文版本"各测各的，能早期抓住"前端以为有、后端没给"的错位。
举个落到实处的样子：客户端测试断言"订单详情必须有
status字段且取值为枚举内"，服务端测试断言"status的值域和它在枚举里一致"。一旦某天后端把status改名成state，服务端测试先红；前端契约测试随后也红——两边各红一次，谁都不用靠"上线后用户报错"才发现。 -
回归纪律：改一处契约，触发契约测试与相关自动化，防"改了 A，B 监听 A 跳闸"，没人事先知道。让机器当你我记忆的延伸。
⚠️ 常见坑：只在"发版前手动点两下"当测试，功能一改就回归破防。测试是周期性投入，端的不是"答题"，是"契约验收"，必须自动、常态、分层。
💡 关键直觉：测试金字塔的实质是把最贵的验收尽量下放到最便宜的层。能用单元测逻辑，别让端到端跑全局；能自动化常态跑，别等发版前手动补枪。
本节要点回顾
- 要点一：五层测试单元、集成、端到端、性能、安全各堵一类漏。
- 要点二：测试金字塔底层多而便宜，顶层少而贵，成本反之。
- 要点三：分层后日常改动用底层兜底，大改动才全量端到端。
- 要点四：契约测试让客户端与服务端对着同一份 OpenAPI 各守一端。
- 要点五：回归纪律让机器兜住"改 A 坏 B"，做记忆的延伸。
- 要点六：测试是常态自动的验收，不是发版前的补枪。
验收通过，服务要出门见客了——先送给网关调度台接好线，再给跨域签发一张 CORS 通行证。