【每日一题】接口契约测试，哪些说法站得住（附参考答案）

兴趣爱好交流
1

题目：微服务团队想做接口自动化，提出引入契约测试（Consumer-Driven Contract，如 Pact）。关于契约测试，下列说法正确的是：

A. 契约测试校验的是双方约定的字段、类型和交互方式，不要求消费者和提供者同时在线，联调环境拉不起来时也能挡住不兼容变更
B. 契约测试全部通过后可以下掉集成测试和端到端测试，接口约定一致就说明业务链路正确
C. 提供方在合并代码前执行「消费者契约验证」，能提前发现「上游改了字段，下游还不知道」的问题
D. 契约文件由消费者侧生成、纳入版本库并在 CI 里双向校验，变更才可追溯
E. 契约测试要求消费者与提供者使用同一份测试数据，否则用例无法执行

难度：中级
题型：笔试（多选题）

2

:point_right:参考答案：ACD

解析：

  • B 错：契约只保证「形状」兼容（字段、类型、状态码），不保证「语义」正确。字段还在但含义变了、金额单位从元变分、状态码 200 但业务码是失败，契约全都看不见。集成/E2E 依然要保留，只是可以按影响面缩量。
  • E 错：契约里消费者写的是匹配规则（正则、类型 matcher、eachLike 之类），不是双方共用一份数据；提供方拿自己的数据生成响应，只要满足 matcher 就算通过。

其余采分要点（高频追问）：

  1. 最常见的翻车是「匹配规则写太松」：消费者用 .* 或不管类型，提供方怎么改都绿，等于没测。规则要收到「恰好描述依赖」这一层。
  2. 提供方验证只校验消费者「已经用到的字段」，提供方新增字段不会报错——这正确，但也意味着契约挡不住新增字段的语义风险。
  3. 发布顺序要配套：提供方先上向后兼容版本 → 消费者再上新依赖，两边不能同时改；契约中心（broker）负责「哪个版本依赖哪个契约」的矩阵。
  4. 与 Mock 的分工：契约测试管「约定不破坏」，Mock 管「消费者侧单测能跑起来」，两者不是替代关系；Pact 的 stub 可以直接喂给消费者本地跑。
  5. 落地收益怎么证明：统计契约验证拦截下来的不兼容变更数量、与线上接口类故障数做趋势对比；只报「用例通过率」是无效指标。
  6. 别忘了非功能的约定：超时、重试、幂等键、限流错误码这些也得进契约或接口规范评审，光有 JSON Schema 不够。