7.2 测试金字塔与契约测试：复查三道关

7.2 测试金字塔与契约测试：复查三道关

摘要：微服务太快、太分布，靠"手工点点 + 端到端反复跑"根本扛不住发布频率。解题是分层：底层多而便宜的单元测试，中间集成与契约测试，顶层少而贵的端到端。本文重点讲契约测试怎么单挑"两个服务私下改接口互相打崩"，并把它和依赖扫描一起装进上线门禁。

微服务的测试有个拧巴：既要跟上频繁发布，又要覆盖跨服务依赖，还不能跑到地老天荒。所以不能靠"多打几个全链路用例"，要靠分层的测试金字塔——用性价比最高的那批自动化做高频守门，把最贵的端到端留给最关键的场景。

黄金三维：单元、集成/契约、端到端

金字塔的关键是分配数量比：底层最多、最便宜，越往上越少、越贵。

原则一句话："多而便宜的"做高频门禁，"少而贵的"做最后关键验证。别把端到端当日常护身符——它又慢又脆，跑一次能睡一觉，还总被环境问题干扰。

微服务特有的第二关：契约测试

单体和集成测试在微服务里有个致命短板：它们测的都是"一个服务内部"，测不出"我对另一个服务的约定是不是被对方悄悄改了"。A 依赖 B 的接口，B 上线前把返回值字段改了，A 没跑全链路根本没发现——等上线就崩。契约测试专门解决这个跨服务信任问题。

契约测试（如 Pact 那套"消费者先声明期望，提供者回放校验"）的核心价值就是把这个"跨服务约定"做成自动化门禁：B 想改接口，构建时用 A 留下的契约校验，一旦不兼容直接在 CI 就红，而不是上线才炸。它还有副作用——倒逼服务把接口文档化到能机读，这是前面"API 优先"的自然延续。

顺带补一关：依赖与漏洞的"体检"

除了功能测试，微服务还有一根容易漏的弦：依赖安全。一个服务用到的第三方包是否有已知漏洞，要不要提示进 CI 拦。开关这一类叫 SCA（软件供应链安全）扫描，它的价值是"别等被打了才知道"。把"依赖清单 + 漏洞库"比对做成门禁，成本极低、收益极稳。做灰度发布时它也能和"版本对比"接上（我们第 8 章讲依赖管理会再展开）。

# 示意：把依赖漏洞扫描并进 CI 门禁（表达想法，不是某个工具的命令行）
scan-dependencies --project order-service --fail-on high
# 输出：订单服务 依赖树，发现 2 个高危 → CI 直接红，拦截合并
​

一道常见的取舍：契约测试要不要每个接口都上

契约测试有建设成本，别一上来给每个偶发接口都追着建。正确取舍：只对"高频、横跨两个团队、改动频繁"的接口建契约；低频、稳定、好靠端到端兜底的少量接口，可以跳过。契约的价值来自"它被频繁触碰"，一年才动一次的接口没必要为契约付认知成本。

陷阱：把契约测试做成"又一份文档"

契约测试最大的坑是只建不验、建筑时的环境里没人真用，最后沦为"贴在 wiki 上的第二份文档"。判断标准是"它到底有没有在 CI 里拦住过一次真正的违约"——如果半年没拦到任何东西，要么你们接口太稳（好事），要么契约已经从真实行为上脱节了（坏事，该补对账）。

端到端测试的"少"和"贵"是特点，不是缺点

讲金字塔最容易误读的是端到端那几行——以为顶层"贵"就该被砍掉。恰恰相反，端到端在金字塔里的意义是不可替代的最终扇门：只有它真的把"前端→网关→服务→数据库"整条链串起来跑一遍，才能回答单元/契约都答不了的问题——"它们拼在一起到底通不通、配置对不对、网络通不通、权限拦没拦错"。所以端到端该被精简的不是"删除"，而是"挑最关键的几条"：每一条覆盖一条用户主线（登录下单、库存出库、支付回调），数量控制在能短时间跑完、稳定不脆。

判断取舍时就问一句："这条链路一旦出问题，造成的线上损失值不值得每次发布前多花它这一分钟去验？" 值就留，纯粹重复、慢、容易抖的就删。减负不是砍掉安全，是把贵的验证花在刀口上。这跟你做降级、做加班预算是一样的取舍逻辑：资源永远是有限的心力，要用在最会出大事的地方。

把"自动化门禁"真正接进 CI，而不止于"会写测试"

写了测试、且测试在 CI 里跑，和"测试真的在守门"是两件事。很多团队的测试栈非常齐全，但 CI 里"挂着绿但没人看"——门禁形同虚设。要让测试真的成为"复查三道关"，至少得做到三点：

1. 失败即中断：任何一层测试失败都让流水线红，直接拦下合并/发布，别允许"我先合，回头补"的路径。
2. 有门禁的分层节奏：单元/契约这类低价位测试在每一次提交就跑，贵的端到端在上线前那道关才跑，让成本和风险恰好匹配。
3. 有人对"变红负责"：门禁暴露的问题要有明确的 owner 和快速修的正常流程，而不是"反正会滚回来的先发了"。

一句话：测试的价值取决于它守不守得住门，不取决于它写得多漂亮。把这三点落到实处，金字塔才从"一张设计图"变成"一道每次发布都真的拦住问题的闸"。

一个纠偏：别把"覆盖率数字"当成质量目标

讲到测试，团队很容易掉进"覆盖率要上 90%"的 KPI 执念。这个数字若作为绿灯标准，往往催生两种病：一是为了补覆盖率，给毫无逻辑的 getter 也写测试；二是把"达成了 90%"当终点，却不管那些最贵的路径（跨服务、异常、并发）根本没有测。覆盖率的真正价值不是"数字越高越好"，而是提醒你"哪些关键代码还没有被任何一行测试碰到"——它是一个"启发线索"，而不是一个"唯一真值"。

更值得盯的是"测试有没有覆盖那些改坏了会炸死用户的地方"：核心的下单链路、跨服务契约、幂等与重试的边界、权限校验这些高危点，宁可用几条高质量用例去锁住，也好过在无关紧要的角落堆到覆盖率高。把"该测的都测了"当作质量目标，而不是把"覆盖率达到 90%"当作数字目标——这两者差一个维度，也是最容易被 KPI 带偏的地方。

本节要点

• 测试金字塔：底层多而便宜作高频门禁，顶层少而贵作关键验证
• 集成测内部、契约测跨服务约定、端到端测整体，职责各不同
• 契约测试=消费者先声明期望、提供者回放校验，把接口改动压进 CI 门禁
• 依赖漏洞扫描（SCA）别漏，把"被打"变成"拦在构建前"
• 契约只对高频跨团队接口建，别沦为无人真用的第二份文档