接口自动化的价值不在脚本数量，而在反馈速度

接口自动化应该承担快速反馈，而不是替代所有人工判断。

接口自动化很容易变成数量游戏。脚本越写越多，报告越来越长，但失败没人看、环境经常坏、数据互相污染，最后团队对自动化结果失去信任。真正有价值的接口自动化，应该让研发和测试更快知道“这次改动有没有破坏关键行为”。

先选关键链路

不要一开始就追求覆盖全部接口。先挑稳定、高频、业务价值高的链路，例如登录、下单、支付回调、权限校验、核心查询。每条链路都要有清晰断言，不只是检查 HTTP 200。

type ApiCheck = {
  name: string;
  endpoint: string;
  assertion: 'schema' | 'business-rule' | 'database-state';
  owner: string;
};

const smokeChecks: ApiCheck[] = [
  {
    name: 'create order with valid coupon',
    endpoint: '/api/orders',
    assertion: 'business-rule',
    owner: 'qa-platform',
  },
];

自动化失败要能诊断

一个自动化用例失败后，报告至少要告诉团队三件事：

• 请求参数是什么。
• 实际响应和预期响应差在哪里。
• 失败更像产品问题、环境问题还是脚本问题。

如果每次失败都要测试同学手动翻日志、查数据库、问研发，那自动化就没有真正节省时间。

数据要可控

接口自动化最大的隐形成本是测试数据。共享测试账号、固定订单号、写死库存、依赖昨天的数据，都会让用例变脆。更稳的方式是让用例自己准备数据，执行后能清理，或者使用独立测试环境和可重复的种子数据。

写在最后

接口自动化不是把人工测试搬到脚本里。它应该成为团队的反馈系统：改动提交后尽快跑，失败后尽快定位，关键链路长期可见。脚本数量可以慢慢涨，信任感一旦丢了就很难补回来。