接口测试看似简单发个请求看返回码，实则新手极易踩坑，导致漏测或线上事故。

误区一：只看HTTP 200，不看业务错误码

错误：只要接口返回 HTTP Status 200 OK 就标记 Pass，完全忽略响应体里 {"code":500, "msg":"库存扣减失败"} 的业务报错。

后果：流量高峰时，虽然服务没挂，但用户看到的是操作失败的白屏。

正确做法：双重断言。必须检查 HTTP Code == 200 且 响应体 code / success 字段符合预期。JMeter 里要加JSON断言或响应断言，Postman里写在Tests脚本里。

误区二：测试数据硬编码，未做参数化

错误：登录脚本里用户名密码写死，注册脚本手机号写死。压测时全用同一个Token跑。

后果：

缓存透过假象：同一个ID反复查，Redis命中率 100%，数据库没压力，得出性能很好的错误结果。

唯一键冲突：注册/下单接口跑第二遍直接报错Duplicate entry，测试中断。

正确做法：数据工厂 + 参数化。使用CSV文件导入千万级测试账号，或用 __RandomString函数动态生成手机号/订单号前缀。

误区三：只测正向流程，不测异常和幂等性

错误：传参规范就过，不传必填参数没试过，重复提交同一个订单号也没试过。

后果：上线后，用户网络卡顿连点两次支付，直接扣了两笔钱（接口未做幂等）。

正确做法：

必测异常场景：参数类型错误（传字母到 Int 字段）、空值、超长字符、SQL注入特殊符号（' OR '1'='1）。

必测幂等性：同一个业务流水号连续调两次接口，第二次应返回请勿重复提交而不是系统异常。

误区四：环境混乱误连生产库

错误：测试环境配置文件没改，接口调通了，但其实连接的是生产环境数据库的只读备库，甚至通过测试脚本往生产 Redis 里写了一条脏数据。

后果：测试数据污染生产报表，严重时造成生产事故。

正确做法：

染色隔离：测试配置 URL 必须以 test- 或特定域名结尾。

Host 强制绑定：在本地 /etc/hosts 写死测试环境 IP，物理隔绝误操作。

断言检查：脚本里检查返回的环境标识（如 Header 里的 env: test）。

误区五：忽略上下游依赖和超时设置

错误：接口调通了，一看响应时间21秒（超时重试导致的累积耗时），前端用户早就关页面了。

后果：测试报告显示 TPS 很高，实际生产调用链超时雪崩。

正确做法：

设置合理超时：HTTP客户端连接超时ConnectTimeout=3s，读取超时ReadTimeout=5s。超过此时间应判为失败。

Mock不可控下游：对于短信、支付、人脸识别等外调接口，测试环境一律挡板Mock，返回固定成功，保证测试稳定性。

误区六：缺乏脏数据清理意识

错误：跑完注册接口，测试库攒了几百万条无用垃圾数据，导致后续查询接口越来越慢。

后果：接口性能测试曲线随时间单调递减，误判为有内存泄漏，实际是数据库表太大索引失效。

正确做法：前置准备，后置清理。测试脚本 setUp 造数据，tearDown 通过唯一标识（如 test_ 前缀）把刚产生的数据物理删除，保持环境干净。

接口测试的本质是测试数据在系统间的正确流动，而不是测试网络是不是通。养成看Server Log和Response Body的习惯。