06 接口测试与接口自动化

接口自动化是测开最应该优先拿下的一块：接口比 UI 更稳定、执行更快、更容易接入 CI。

为什么重要

很多团队的自动化测试主力都是接口回归。学会这一章，你就有了第一个能写进简历、能在面试里展开讲的完整项目（参见第 12 章项目一）。

原因很简单：接口比 UI 更稳定，执行速度更快，也更容易接入 CI。UI 页面每周都在改，而接口契约的变化相对可控。

知识清单

接口基础【必须掌握】

• 会读接口文档：OpenAPI / Swagger 规范，路径、方法、参数（query / path / body / header）、响应结构。
• 抓包分析：Charles / Reqable / Fiddler / mitmproxy 至少会一个，能抓 App 和 Web 的请求。
• 加密与签名接口的处理思路：签名怎么生成、时间戳防重放、Token 怎么获取和传递。

接口调试工具【必须掌握一个】

Postman、Apifox、Reqable、Insomnia。会：接口调试、环境变量、前置 / 后置脚本、断言、测试集合（Collection）执行。

工具	特点	适合
Postman	事实标准，生态最全	团队协作、CI 里跑 Collection
Apifox	API 设计 + 调试 + Mock + 自动化一体，中文友好	国内团队协作
Reqable	抓包 + 调试一体	移动端测试多的人
Insomnia	轻量	个人轻量使用

接口测试设计【必须掌握】

• 单接口测试：参数校验（必填、类型、长度、边界）、业务码分支、鉴权失效。
• 场景（链路）测试：把多个接口串成业务流，如注册 → 登录 → 下单 → 支付 → 查询 → 取消。
• 异常与容错：超时、重试、幂等（重复提交同一笔订单）、并发修改。
• 数据驱动：同一场景跑多组数据（正例 / 反例 / 边界）。

自动化框架设计【必须掌握】

一个像样的接口自动化框架，至少包含六大件：

1. 环境配置：测试环境、预发环境的接口域名、账号和 Token 分层管理（config 文件 + 环境变量，不硬编码）。
2. 请求封装：统一处理 Header、Cookie、鉴权、超时、重试、日志（一处修改全局生效）。
3. 数据管理：测试数据准备（API 造数 / SQL 造数 / 工厂函数）、清理（前置清理 + 后置清理）、参数化。
4. 断言体系：状态码、响应字段、业务码、数据库状态、消息队列副作用（下文展开）。
5. 报告输出：Allure 或 HTML 报告，失败时能看到请求、响应和日志详情。
6. CI 集成：每次提交或每天定时执行，失败通知到人（衔接第 09 章）。

断言设计【必须掌握——本章灵魂】

不要只断言 status_code == 200。接口测试真正有价值的断言，应该能证明业务状态正确：

• HTTP 200 只说明「服务活着」，业务码才说明「业务成功」。
• 创建订单接口执行后，要验证订单表状态、库存变化、支付单状态、消息事件或审计日志。
• 删除接口执行后，要验证数据是真删了还是软删，关联数据怎么处理。
• 断言分层：字段级（类型、格式、必填）、业务级（状态机正确）、副作用级（数据库 / 缓存 / 消息队列）。

Mock 与依赖隔离【必须掌握（概念 + 动手一次）】

不是所有依赖都值得真实调用。三类场景要上 Mock：

• 外部依赖不稳定或没有测试环境：支付回调、短信、风控、第三方登录——真调贵、慢、结果不可控。
• 异常注入：正常环境里你造不出「第三方超时」「返回 500」，Mock 才能按需注入故障。
• 契约先行：接口还没开发完，按文档先 Mock 出来把用例写好，联调时再切真实接口。

动手层次选一个深入：

层次	工具	适合
工具层	Apifox / Postman 内置 Mock 服务	给前端联调、手工测试供数
服务层	WireMock / moco 本地起服务	自动化框架、CI 里隔离第三方
代码层	pytest-mock / Mockito（见第 03 章）	单测里 mock 函数、SDK、未就绪模块

两条纪律：

• Mock 了什么必须可见：用例名或报告里标注，否则没人知道这条用例没走真实链路。
• Mock 要跟契约同步：接口文档改了 Mock 没改，全绿的报告是假的。保留少量真调关键链路的用例兜底。

安全测试入门【必须掌握（基础项）】

测开不需要做专业渗透测试，但接口层的安全用例要会设计（对应 OWASP Top 10 的常见项）：

• 越权：水平越权（改 ID 访问别人订单）、垂直越权（普通用户调管理员接口）。
• 注入：SQL 注入的探测用例（' OR '1'='1）、命令注入。
• 敏感信息：响应里是否泄露密码哈希、手机号明文、内部错误堆栈。
• 重放与频率：无时间戳的裸重放、短信 / 验证码接口的频率限制。
• 传输：敏感接口是否强制 HTTPS。

AI 在接口测试中的用法【必须掌握】

• 根据 OpenAPI / Swagger 文档生成初版测试用例。
• 根据接口返回生成数据模型（Pydantic / DTO）和断言模板。
• 帮你审查用例是否只测了成功路径。

但测试数据、业务断言和环境清理要自己把关。AI 不知道你们系统里哪些字段会影响后续流程。具体提示词模板见第 10 章。

学习建议与常见误区

• 学习路径：工具（Postman 单接口调试）→ 工具集合（Collection + 环境变量 + 断言）→ 代码（requests + pytest 写前 10 条）→ 框架化（分目录、封装、报告）→ CI（GitHub Actions 定时跑）。每一步都有明确产出再进下一步。
• 先测透一个系统再谈框架。推荐用自己写的 FastAPI / Spring Boot 小服务（第 03 章练过的）或公开练习 API（如 httpbin、JSONPlaceholder、Swagger Petstore）起步，然后过渡到真实业务系统。
• 误区一：把接口自动化写成「接口遍历器」。 每个接口调一遍、断言 200 就叫接口测试了——这叫冒烟，不叫回归保障。面试官最爱问「你的断言验证了什么业务」。
• 误区二：用例之间强依赖。 用例 B 必须等用例 A 创建的数据，A 挂了 B 全挂，排查半天是链式失败。学会每个用例自造数、自清理。
• 误区三：忽略脏数据。 本地跑通了，CI 上失败，因为 CI 数据库里有上次跑剩下的数据。前置清理和唯一性约束（时间戳后缀）要从第一天设计进去。
• 误区四：Token 写死在代码里。 密码进 git 仓库是安全事故级错误。用环境变量 + 密钥管理。

自查清单

1. 你的框架六个组成部分分别是什么？各自的目录放什么？
2. 「创建订单」接口，列出你至少 5 层断言（HTTP 状态、业务码、响应字段、数据库、消息队列）。
3. 支付回调这类外部依赖，什么时候 Mock、什么时候必须真调？Mock 响应怎么和接口文档保持同步？
4. 用例幂等怎么做？连续跑两遍结果一致吗？
5. 接口需要签名（参数排序 + MD5），你的封装怎么设计？
6. 水平越权的测试用例怎么写？自动化里怎么覆盖？
7. Allure 报告里，一个失败的用例能看到哪些信息才算合格？
8. CI 上接口测试失败的三大类原因（环境、数据、代码）你怎么快速区分？
9. 让 AI 根据 Swagger 生成用例初稿，你审查的清单有哪些？

推荐资源

• httpbin.org：各种 HTTP 特性的练习靶场。
• Swagger Petstore：标准 OpenAPI 文档 + 可测的示例接口。
• Rest Assured 官方文档：Java 系接口自动化主力库。
• Allure 报告文档：测试报告事实标准。
• OWASP Top 10：安全测试用例设计的对照清单。
• Apifox 帮助文档：国内团队协作的主流选择。
• AI 测试开发导航 · 精选课程：接口自动化实战教程，与本章框架六大件配套。
• AI 测试开发导航 · Skill 技能商店：接口测试提效技能（用例生成、执行调度、失败诊断、报告生成）。