接口自动化测试的局限性有哪些？
 
1. 不能替代界面（UI）测试
接口只测数据逻辑，不测页面展示、交互、样式、渲染。
按钮点不动、前端报错、布局错乱、权限按钮不隐藏等，接口自动化测不出来。
 
2. 对接口文档依赖极强
接口文档不全、字段经常变、参数不规范，自动化脚本极易失效。
接口一改动，脚本就要跟着改，维护成本高。
 
3. 难以覆盖复杂前端交互场景
前端校验、倒计时、验证码、滑块、富文本、上传文件等复杂逻辑，接口很难完整模拟。
前端异步、并发、缓存导致的问题，接口层不易发现。
 
4. 无法测性能、压力、并发问题
接口自动化 = 功能自动化，不等于性能测试。
并发冲突、超卖、接口耗时、数据库死锁、限流熔断，普通接口自动化测不出来。
 
5. 不能测安全性深层问题
能测简单权限、越权，但：
SQL 注入
XSS
越权批量篡改
加密破解、中间人攻击
这些需要专业安全测试，接口自动化覆盖很浅。
 
6. 环境、数据依赖性高
环境不稳定、数据被污染、依赖第三方接口（支付、短信、物流），脚本容易随机失败。
用例之间容易相互影响，导致误报率高。
 
7. 维护成本高，收益边际递减
项目迭代快 → 接口字段、参数、路径频繁变
脚本要不断修、不断跑，写得快，坏得更快。
简单接口收益高，复杂业务接口维护成本爆炸。
 
8. 无法测试硬件、设备、蓝牙等底层能力
像你之前问的蓝牙、WiFi、传感器、硬件通信，接口自动化完全覆盖不到。
必须做：真机适配 + 硬件专项测试。
 
9. 对人员能力有要求
纯手工测试人员不能直接维护。
需要：代码、协议、数据库、抓包、环境排错能力。
 
10. 不适合一次性、临时需求
短期项目、小需求、一次性接口，写自动化反而比手工慢。
只适合：长期迭代、核心链路、回归频繁的项目。