接口测试的是在什么输入下、经过什么途径、返回了什么、系统状态是不是因此发生了正确的改变。入参、出参、状态码、超时和幂等。

入参：测的是包括了哪些拒绝途径。 必填参数至少设计缺失和为空的用例，确定接口返回确定的参数检查失败，而不是500或默认值兜底；选填参数包括完全不传、传空值、传合法值，确定默认值思路符合契约。类型和格式方面，包括类型错误、格式错误、枚举字段的全部有效值加一个无效值，有范围限制的字段用等价类划分出范围内、范围外、边界值，边界再细分为最小值、最小值减一、最大值、最大值加一。结构方面还要包括请求体不是合法JSON、字段名拼错、多传未定义字段、数组传成对象等情况。入参检查不完整本身就是缺陷：如果非法入参返回了错误提示但数据库已经被部分写入，入参测试就必须和出参、数据库检查联动，不能止步于接口报错。

出参加状态码：必须分层断言，只测HTTP 200等于没测。 HTTP状态码是传输层概念，只说明服务器收到了请求并给出了响应；业务是不是成功藏在响应体里。只断言200的测试，在后端吞掉异常、照样返回200但字段为null的场景下，会给出虚假的通过。完整测试至少分三层：第一层是 HTTP 状态码，成功场景返回 2xx，参数错误预期 400，未认证预期 401，无权限预期 403，资源不存在预期 404，服务端异常预期 5xx；第二层是业务码，成功时业务码为 0 或 SUCCESS，失败时业务码非 0 且和 HTTP 状态码语义不冲突；第三层是数据内容和结构，data 非空且类型正确，字段如登录返回的token不为 null，整体响应结构符合Schema，缺字段或类型漂移能被自动发现。要注意出错也返回 HTTP 200、业务码放在body里的设计，对这种接口，业务码断言和字段断言不可省略，否则只测试了网络通了，没有测试接口对了。

超时：测的是系统在慢和断面前的行为，而不只是有没有超时。 HTTP超时至少分三种。连接超时发生在TCP三次握手阶段，典型场景是目的服务未启动或宕机、防火墙拦截目的端口、DNS分析失败，测试时观察客户端是不是快速失败、重试是不是被合理触发、日志是不是有清晰的连接阶段错误。写超时发生在客户端向服务端发送请求数据的过程中，常见于请求体过大、网络拥塞导致数据包无法及时写入socket缓冲区，或服务端接收缓冲区已满，测试重点是客户端能否感知发送阶段失败，而不是误判为服务端没有响应。读超时是请求已发出但客户端在阈值内没有收到完整响应，根因可能是服务端处理缓慢、下游依赖超时导致上游等待、网络延迟过高，需要测试客户端是不是正确区分读超时和连接超时，以及超时后是不是留下足够定位问题的日志。故障模拟除了用客户端timeout参数，更系统的做法是用Toxiproxy、Chaos Mesh等工具在连接、写、读三个步骤分别注入延迟或中断，观察容错和恢复行为。

幂等：测试的是同一个思路请求到达N次，系统状态只改变一次。 幂等测试不是接口返回了一样的响应，而是后端副作用是不是被重复执行。重复创建订单、重复扣款、重复扣库存，都是幂等失效的典型表现。需要测试几个方面：顺序重试，即发送请求、记录响应和系统状态，再用相同的幂等键和相同请求体发一次，断言业务只执行一次，第二次返回结果和第一次一致或符合契约定义的重放语义；并发重复，即两个相同请求几乎同时到达，如果服务端是先查再写，并发窗口内两者都可能查到不存在然后都写入，因此并发测试是幂等验收的阻塞项，只能有一个真正执行写操作，另一个必须被幂等机制拦截或返回一致的重放结果；同键不同体，即同一个幂等键但请求体不同，契约必须定义确定行为，一般是拒绝并返回错误，而不是静默按新请求体再执行一次；幂等键的生命周期，测试去重窗口和保留期是不是和契约一致，窗口内重试返回首次结果，窗口过期后同样的键可能被当作新请求执行，服务端崩溃或处理中断后用同一键重试的行为也应有确定约定。底层实现上，不管上层用 Token、Redis 记录还是分布式锁，数据库层的唯一约束是最后防线，即使幂等思路被绕过，订单表上的幂等键唯一约束也能阻止重复记录落库。

把五个方面串起来看：入参测试保证接口能正确拒绝错误输入，状态码和出参测试保证正确输入下返回的结果是对的而不只是通了，超时测试保证系统在异常时序下不会产生不可控的副作用，幂等测试保证重复和并发不会放大这些副作用