接口测试和前后端联调怎么做

接口在本机跑得通，一到联调就各种超时、字段对不上、谁的锅说不清——这种时候光看报错信息没用，得先把环境、契约、超时口径对齐。这篇给前后端和测试同学一套可执行的流程：联调前准备什么、按什么顺序测、超时和并发怎么定、出问题先查哪一步。

接口在本机跑得通，一到联调就各种超时、字段对不上、谁的锅说不清，这种时候光看报错信息没用，得先把环境、契约、超时口径对齐。联调不是「谁先跑谁点按钮」，而是一套有准备、有顺序、有复盘办法的流程，前后端和测试三方各管一段，出问题才知道先查哪一步。

下面按准备、执行、边界、复盘四个环节拆开讲。每节都给判断标准和可执行动作，你可以对着自己项目的情况增减，不必全盘照搬。判断类的内容会写清什么情况下不适用，别把它当成硬规定。

联调前的准备：把变量先固定住

联调最容易崩的地方不是业务逻辑，而是变量太多：地址一会儿是测试环境一会儿是本机，鉴权方式前后端理解不一致，字段命名两套写法。开始联调之前，先把这些东西写成一份能共享的说明，谁有疑问看它，而不是去群里问。

接口契约

路径、方法、必填字段、返回结构，任何一项没定就别开始联调

环境地址

每个环境单独一份配置说明，别靠记忆切换

鉴权方式

Token 放哪里、怎么刷新、过期返回什么状态码，先写清楚

实操上有一条低成本的习惯：Base URL 和 Key 从环境变量或配置文件读，不要写死在代码里。写死之后常见的后果是本地改一处、线上漏一处，或者前端连的是自己本机、后端以为连的是测试环境，两边都在「跑」，但根本没连上。先把一条最小请求跑通，确认能拿到 2xx 和预期字段，再往外扩业务字段。

连通性和响应时间的基线，可以对照站内 /tools/verify 和 /tools/speed-test 量出来的结果，先知道当前网络到目标服务大概是什么水平，后面出现异常时才分得清是接口问题还是链路问题。契约改动尽量走版本或者新增字段，别直接改同名字段的含义，否则前端和测试手里的旧用例会静默失效——它们还在跑，但已经验的不是同一件事了。

• 对齐三样东西：接口契约、环境地址、鉴权方式，缺一项就别开联调
• 给每个环境一份配置说明，Key 和 Base URL 从变量读，不写死在代码里
• 先用一条最小请求跑通鉴权，拿到 2xx 和预期字段再扩业务
• 契约改动走版本或加字段，不改同名字段的含义
• 把当前网络基线记下来，后面判断异常时有参照

接口测试的执行顺序：从单接口到串联

执行顺序不对，联调会变成互相甩锅。建议从单接口往外推，一层站住了再进下一层，否则一个串联用例失败，你根本不知道是哪个接口的锅。

第一层单接口，先把正例、必填缺失、类型不符、越权四类用例过一遍，保证每个接口自己站得住。第二层串联，按真实业务顺序把接口串起来，重点看上一下游之间传的字段能不能直接接上，特别是 id、状态、分页游标这类容易在类型或命名上出岔子的字段。第三层异常，专测超时、重复提交、中途失败后重试，看会不会产生重复数据，这类问题基本只在联调期暴露，上线后才发现代价很大。

测试同学尽量先写用例再点页面。用例里把预期状态码和关键字段写清楚，比一句「看着不对」有用得多；前后端拿到这条用例，也能立刻判断是自己的问题还是对面返回的问题。用例本身可以很朴素，一张表就够，关键是把预期写死。

超时、重试与降级：边界的定法

超时参数是最容易被忽略又最容易引发联调争议的地方。链路一长，每一跳都要有超时值，而且下游要短于上游，否则上游先断，日志里只剩一句超时，根本看不出是哪一层卡住。

1. 拆超时把连接超时、读取超时、整体超时分开设，逐个给值，不要只设一个笼统的超时时间
2. 排顺序确认链路里下游超时短于上游，逐跳核对，避免上游先断开
3. 定重试只对幂等操作开重试，设次数上限和退避间隔；非幂等的写接口重试前先确认有没有唯一键兜底
4. 定容量超时和并发上限一起定，并发一高、排队一长，读取超时就会被触发，看起来像接口坏了，其实是容量问题
5. 备降级准备一条可用备用路径（换源、返回缓存、走异步），并写明降级触发条件在哪一层生效

重试这块有个常见坑：写接口重试一次，数据库里多一条记录。判断标准很简单——这个操作是不是幂等，有没有唯一键或者去重逻辑兜底。没有的话就不要自动重试，宁可把失败抛出来让人工判断。降级同理，备用路径要提前准备、提前验，别等线上出问题再临时决定走哪条路，那时候往往已经来不及改代码了。

日志与复盘：让一次请求能查回来

联调出问题时，最怕的是「查不回来」：知道出错了，但不知道是哪次请求、哪个入参、走没走重试。这就得靠日志字段设计，而不是靠回忆和聊天记录。

• 每次请求至少记：时间、调用方、接口路径、状态码、耗时、重试次数、关键业务标识
• 请求和响应摘要按同一个 trace 串起来，前后端对不上时先比对同一 trace 下两边看到的入参出参
• 失败要能重放：保存能复现的最小请求，比截图和聊天记录可靠
• 按业务单号能反查全链路，缺了业务标识就做不到这一点

其中「关键业务标识」最容易被省掉，但正是它让排查从翻日志变成按单号查。前后端约定一个共同认的标识——订单号、任务号之类——写进日志，出问题时两边都能拿它去搜，比来回贴日志快得多。

这套流程也不是所有场景都值得上。一次性脚本、纯本地不联网的模块，可以只保留单接口正例，不必上完整链路和降级方案；团队只有一两个人的小项目，也可以先跳过正式的用例文档，只留最小请求记录。判断标准是：这条链路会不会长期维护、出问题会不会影响真实用户，会，就按上面的来；不会，别为了流程而流程。

联调阶段做完了想做长期一点的接口巡检和响应基线追踪，可以顺手把常用请求整理成可重复执行的用例集，后面接口改动时跑一遍，比每次人工点页面省事。