先说个让很多人沉默的场景
我待过一个团队，CI 里挂着 1247 个接口用例，每次跑 38 到 45 分钟，失败率常年 12%—18%。大家已经形成条件反射：红灯先点重跑，跑第二次还红再去看日志。有一天我抽了 20 个"重跑就绿"的用例逐个查，发现 13 个的断言只有一行 assert response.status_code == 200，另外 7 个多一行 assert json['code'] == 0。就这。
后来出了个事：订单接口返回的 total_amount 因为浮点运算精度丢失，137.25 变成 137.24999999，下游取整成 137.24。用户少付一分钱，单笔看不出来，三周后财务对账差了四千多块才发现。这个接口我们跑了三年测试，每次都绿，因为从来没人断言过这个字段的值。
这件事之后我彻底不信"接口测试覆盖率"这个指标了。用例数、接口覆盖数、行覆盖率，这些数字涨得再好看，只要断言是浅的，你测的就是"服务活着"，不是"服务对的"。
断言密度：一个接口写 5 条浅断言，不如写 1 组深断言
我现在评估一个团队接口测试做得好不好，不看用例总数，看一个东西——平均每接口的断言条数，我管它叫断言密度。低于 2 的，基本等于没测。
拿一个普通的下单接口举例，我会分三层断言：
结构层：用 JSON Schema 校验整个响应体的字段集合、类型、必填项、枚举范围。工具里 Postman 可以用 pm.response.to.have.jsonSchema()，pytest 配 jsonschema 库三行搞定。结构层最大的价值是拦截上游删字段、改类型这种静默破坏，比手写十行 assert 'xx' in json 靠谱得多。
业务值层：这才是有含金量的部分。下单接口至少断言：total_amount == 单价 * 数量 - 优惠金额（用 Decimal 比对，别用 float）、status 落在合法状态机里、order_no 符合正则 ^\d{17}$、库存扣减数等于订单数。这些断言需要你把业务规则翻译成可计算的表达式，写起来慢，但每一条都能真的抓到 bug。
异常分支层：同一个接口用不同入参再打一遍。库存不足返回 40015、金额为负返回 40002、重复下单返回 409。很多团队的接口用例只测 happy path，异常分支覆盖率不到 20%。
一个接口分三层写下来，断言大概 15 到 30 条，用例数可能只有 4 个。这套下来，我把那个 1247 个用例的套件砍到了 380 个，跑完时间从 42 分钟降到 16 分钟，但真出问题的时候抓到的比原来多。
工具选型：别按"谁功能多"选，按"谁来维护"选
网上那种六七个工具横向对比的文章太多了，我只说实测下来会踩的坑和取舍：
Postman + Newman：集合适合作接口契约的沉淀和手工联调，pm.test 写断言门槛低，导出 collection 直接进 CI。但 Newman 有几个坑要注意：--timeout-request 默认不限制，上游卡死会挂住整个 job，我在 CI 里显式设成 8000；--reporters cli,json 生成的 JSON 报告在 1000 用例量级能到 30MB 以上，塞进制品库很痛苦，改用 htmlextra 加 --reporter-htmlextra-export 更实在；还有 cookie 和全局变量在多环境切换时容易串。
RestAssured：Java 技术栈首选，JSONPath 和 Hamcrest 匹配器组合起来写业务断言很顺。但有个坑我见过三次——有人在 CI 里开了 log().all()，每个请求响应全打日志，一个 500 用例的套件日志量 200MB+，磁盘写满导致构建失败。生产 CI 里应该是 log().ifValidationFails()，只在失败时打日志。
Karate：BDD 风格，内置 mock server、并行执行、断言 DSL，开箱即用程度最高。它的 configure parallel 线程数我建议设成 CPU 核数 * 2，设太高会因为 HTTP 连接池争抢反而变慢，我们实测 8 核机器 16 线程是拐点，32 线程时 P95 反而涨了 40%。缺点是 DSL 出错了堆栈不友好，复杂逻辑调试起来像个黑盒。
pytest + requests：最灵活，没有之一。断言、fixture、参数化、插件生态全是现成的。代价是所有轮子自己造——环境管理、数据清理、报告生成、失败重试、并发，都得自己写。适合团队里有 2 个以上能写框架的人，否则半年后会变成一堆没人敢动的脚本。
关于响应时间的性能断言，顺便提一嘴：别写死 assert elapsed < 0.5。单次请求在网络抖动下毫无意义。用 P95 和 P99 做统计断言，阈值上普通查询接口 P95 设 500ms、P99 设 1s 是比较合理的，写接口可以放宽到 800ms / 1.5s。这个数字因业务而异，但关键是你要测的是分布，不是单点。
测试数据生命周期：这才是接口测试真正的成本黑洞
工具换来换去，大部分团队的问题其实不在工具。我自己复盘过，接口用例维护成本的 60% 到 70% 花在数据上，而不是断言或框架。
典型的翻车方式：所有用例共用同一个测试账号。跑一百次下单，库存字段被扣成负数，user_point 变成 -8400，然后某天一个新用例断言"积分大于等于 0"，红了，查两天。
我后来固定用这套做法：
用例级别的数据用工厂模式动态造，测试手机号用 139 + 时间戳后 8 位，永远不冲突。不依赖任何预置数据，每次跑前现造。
写操作的清理放在 fixture 的 teardown 里，且必须用 try/finally 包住，否则用例一失败数据就留在库里。我们在 pre-commit 钩子里加了条检查，禁止 setup 里出现硬编码 ID。
涉及金额、库存、状态机的接口，用独立库或独立 schema，跟其他用例物理隔离。这招有点土，但它一次性解决了 80% 的数据污染问题。
幂等键统一用 UUID 生成，不要用测试账号 + 商品 ID 拼，否则第二次跑就撞重复下单错误。
契约层和行为层，我强烈建议拆开
这是我这些年最想推的一个观点：接口测试不应该是一个东西，它是两个。
契约层测的是"我们和上下游对字段、类型、错误码的约定有没有变"。这一层用 Pact、Spring Cloud Contract 这类工具做，consumer 端生成契约文件，provider 端在 CI 里回放验证。字段删了、类型改了、必填变可选了，立刻红。这层用例轻，几乎不依赖数据，跑得快。
行为层测的是"业务逻辑对不对"。优惠券叠加顺序、状态流转、并发扣库存，这些是业务规则，跟契约没关系，用 RestAssured 或 pytest 写深度断言。
为什么必须拆？因为它们的生命周期完全不同。契约变更频率低、断言稳定、适合放在 provider 的提交前钩子。业务规则变更频繁、断言要跟着改、适合放在每日构建。混在一个套件里，结果是改业务规则时一堆契约用例跟着红，改字段时业务用例也红，谁都分不清到底哪儿坏了。
我见过太多团队把这两层搅在一起，最后套件变成了"谁都不敢删、谁都不敢改"的沼泽地。拆开之后维护成本至少降一半。
最后
接口测试这件事，工具是好选的，难的是你怎么定义"测到了"。我的标准很朴素：把上线后第一周线上发现的接口类 bug 拉出来，看看这些 bug 里有几个本来能被你的断言抓住。如果一个都抓不住，你的套件就是装饰品。