【背景】
做了 8 年测试开发，最近被 PM 问了一句特别扎心的话：「你们接口自动化跑了 2000 条用例，CI 要 40 分钟，但上个月 3 次线上事故，没有一次是被接口自动化拦住的——那这 2000 条到底在保护谁？」
我复盘了一下那 3 次事故：
- 第 1 次：订单取消接口参数校验没拦住负数金额，走了下游结算才炸——这是「逻辑错」，接口返回 200 但语义是错的；
- 第 2 次：库存扣减的并发窗口，两个请求同时通过校验、其中一个超卖——这是「竞态」，单接口测不出来；
- 第 3 次：上游把 price 字段从 int 改成了 string，下游没适配，JSON 反序列化静默吞了——这是「契约漂移」，但恰好那条链路没有自动化覆盖。
2000 条用例，拦住了 0.5 次（第 3 次被人工发现后补了用例）。这个 ROI 让我开始重新想：接口自动化测试的核心价值到底是什么？
【常见的几种做法，各有阵营】
-
全量回归派：每次发布前 2000 条全跑，CI 40 分钟到 2 小时。优势是覆盖面广、心理安慰强；劣势是慢、CI 资源贵、大量用例只是"把 200 再 assert 一遍"，真正的边界和异常路径反而写得最敷衍。就像体检只量体温，但量了 2000 次。
-
核心链路派：只覆盖 P0/P1 业务路径（下单、支付、退款、发货），大约 200~400 条，CI 5~10 分钟。优势是反馈快、维护成本可控；劣势是覆盖面窄，非核心接口改坏了没人知道。像消防演习只练主楼逃生，地下车库和天台没人管。
-
契约测试派（Pact / Spring Cloud Contract）：不验业务逻辑，只验"我给你的字段你认不认、你给我的字段我能不能读"。跑得快（1~3 分钟），能拦住"上游改字段下游炸"这类事故；但拦不住"字段对了但语义错了"。像验快递包装：箱子没破、面单没贴错，但里面装的是砖头你验不出来。
-
流量录制回放派（GoReplay / 线上镜像）：拿线上真实流量回放，覆盖率天然高；但环境一致性是硬伤（时间戳、第三方依赖、数据状态），而且敏感数据脱敏成本不低。像拿昨天的录像回放今天的球场——场地没变，但球员换了。
-
AI 生成用例派：用 LLM 根据 OpenAPI 文档自动生成用例，省事；但质量参差不齐，"AI 觉得 99.9% 的边界"和"真正会炸的边界"经常不是一回事。像让实习生批量写用例——数量上去了，但每条都值得怀疑。
【我的倾向与理由】
我倾向于核心链路 + 契约测试的组合，理由有三：
-
接口自动化的核心价值是"快速反馈"和"防契约漂移"，不是"全面覆盖"。 把 2000 条用例当"质量门禁"用，就像把体温计当 CT 用——工具用错了场景。业务逻辑 bug（比如负数金额、并发超卖）应该靠单元测试 + 集成测试（带 mock）在更上游拦住，而不是指望接口层兜底。
-
契约测试是接口自动化"最该干的活"。 它解决的是"服务间协作"问题：你改字段、改类型、改必填，我能不能第一时间知道？这个问题只有契约测试能高效回答。全量回归也能发现，但要等 40 分钟，而且得有人恰好写了那条用例。
-
CI 时间是真实成本。 40 分钟的 CI 意味着开发同学 40 分钟看不到结果，反馈环路越长，"顺手改一下"的概率越高，最终变成"先合了再说"。5 分钟的核心链路 + 2 分钟的契约测试，反馈环路短到"改完代码 7 分钟就知道有没有炸"，这才是自动化测试该有的节奏。
但我也承认这个方案有盲区：非核心接口（比如后台管理、运营工具）改坏了确实没人管。我的做法是给这些接口加"冒烟用例"（每个接口 1~2 条），不求覆盖全，只求"别整个 500"。
【想听大家在什么场景下怎么选】
- 你们的接口自动化用例规模是多少？CI 跑一轮多久？团队多少人维护？
- 线上事故复盘时，接口自动化实际拦住的占比大概多少？（别客气，说真实数字）
- 你们在什么场景下选全量回归、什么场景下选核心链路？判断标准是什么？
- 契约测试（Pact / Spring Cloud Contract / 自研）你们落地过吗？遇到的最大坑是什么？
- AI 生成用例你们试过吗？采纳率多少？是当"初稿"用还是直接跑？
- 如果只能保留 100 条用例，你们会留哪 100 条？选择标准是什么？
欢迎拍砖，也欢迎分享你们团队的"反例"——用全量回归拦住了大事故的、用契约测试救过命的、或者用 2000 条用例把 CI 拖垮最后全删了的。