接口测试面试题¶

接口测试面试重点通常包括 HTTP 基础、接口用例设计、鉴权、断言、数据校验和异常场景。

GET 和 POST 有什么区别？¶

推荐回答：

GET：通常用于查询，参数放在 URL Query 中
POST：通常用于创建或提交数据，参数放在请求体中

从测试角度看：
- 不能只按方法判断业务含义，还要看接口设计文档
- GET 请求也要验证参数校验、权限和分页
- POST 请求要重点验证必填字段、重复提交和数据落库

不要绝对化地说"GET 一定没有请求体""POST 一定安全"。实际项目里要看实现和规范。

接口测试怎么设计用例？¶

可以从这些角度回答：

正常参数
必填参数为空
参数类型错误
参数长度边界
枚举值非法
未登录、登录过期、权限不足
重复提交和幂等
数据库落库校验
错误信息是否合理

示例回答：

比如创建订单接口，我会测：
- 正常下单
- 商品不存在、库存不足
- 地址为空、优惠券不可用
- 重复提交
- 未登录访问
- 支付金额计算
- 数据库订单状态

HTTP 状态码 200 是否代表接口成功？¶

推荐回答：

不一定。HTTP 200 只能说明 HTTP 请求正常返回。

业务是否成功还要看：
- 业务码（code 字段）
- 响应字段
- 数据变化

有些系统业务失败也返回 200，比如 code 为 1001 表示参数错误。

接口断言建议：

HTTP 状态码
业务码
响应字段
数据库或缓存变化
响应时间

token 过期怎么测试？¶

可以这样回答：

准备 4 种 token 分别请求需要登录的接口：
1. 有效 token → 预期可以访问
2. 过期 token → 预期返回 401 或业务未登录错误
3. 伪造 token → 预期拒绝访问
4. 空 token → 预期拒绝访问

重点：任何情况都不能返回敏感数据。

接口自动化断言怎么写？¶

示例：

assert response.status_code == 200
body = response.json()
assert body["code"] == 0
assert body["data"]["orderStatus"] == "PAID"

更完整的回答：

我不会只断言状态码，还会断言：
- 业务码
- 关键字段
- 数据库状态
- 必要时校验响应时间和日志

接口测试发现前后端问题怎么定位？¶

回答思路：

排查步骤：
1. 看请求是否正确（URL、方法、Header、参数、token）
   → 请求不正确 → 前端传参问题
2. 请求正确但响应错误 → 看后端日志、数据库数据
3. 接口数据正确但页面展示错误 → 前端渲染或字段映射问题

面试自查¶

是否能说清楚 HTTP 状态码和业务码区别
是否能设计异常参数
是否知道鉴权和越权测试
是否能结合数据库校验说明接口正确性

RESTful API 的设计规范了解吗？¶

RESTful 是一种接口设计风格，核心原则：

1. 资源用名词表示
   /users、/orders ✅
   /getUsers ❌

2. 用 HTTP 方法表示操作
   GET 查询、POST 创建、PUT 全量更新、PATCH 部分更新、DELETE 删除

3. 状态码语义化
   201 创建成功、204 删除成功、404 资源不存在

4. 版本号放在 URL 或 Header 中
   /api/v1/users

测试关注：接口是否遵循规范、URL 是否语义化、状态码是否正确。

接口依赖怎么处理？¶

比如下单接口依赖登录接口返回的 token，支付接口依赖下单接口返回的订单号。

处理方式：
1. 用例之间共享数据：登录后保存 token，后续用例自动携带
2. 前置请求：在用例执行前先调用依赖接口获取数据
3. 数据库直取：直接从数据库查需要的数据（适合稳定的测试数据）
4. Mock：用 Mock 服务模拟依赖接口的返回

怎么测试接口的幂等性？¶

幂等性 = 同一个请求调用多次，结果和调用一次一样

测试方法：用同一个请求参数连续调用 2-3 次，检查：
- 数据是否只创建一条（不是重复创建）
- 状态是否保持一致
- 是否返回合理的提示（如"订单已存在"）

重点测：支付回调、订单创建、退款接口

接口超时怎么测试？¶

1. 正常超时：设置合理的超时时间（如 5 秒），模拟接口响应超过 5 秒，检查客户端是否正确处理
2. 边界：刚好在超时时间返回，检查是否正常处理
3. 重试机制：超时后是否有重试，重试次数是否合理
4. 幂等：超时后重试是否会导致重复操作

Mock 和挡板有什么区别？¶

Mock：在测试侧模拟接口返回
  - 场景：被测系统依赖的第三方服务不可用时
  - 工具：Postman Mock Server、WireMock、responses 库

挡板：在服务侧模拟下游服务
  - 场景：压测时隔离外部依赖

测试中常用 Mock：比如支付接口用 Mock 返回成功/失败，不需要真实调用支付平台。

接口测试和 UI 测试怎么分配？¶

遵循测试金字塔：

接口层：覆盖大部分业务逻辑验证（70-80%）
  → 成本低、速度快、稳定性高

UI 层：只覆盖核心用户路径（10-20%）
  → 成本高、速度慢、容易因页面变化失败

单元测试：由开发负责（覆盖底层逻辑）

所以：复杂数据校验、边界值、异常场景放接口层，只在 UI 层验证用户可见的交互流程。

接口测试中如何处理加密参数？¶

常见加密方式：MD5、AES、RSA、Base64、Token 签名

处理步骤：
1. 先看接口文档，确认加密规则
2. 签名类参数：按规则排序、拼接、加密生成签名
3. Token/登录态：先调登录接口获取 Token，放到 Header 或参数中
4. 在 Postman 或 Python 脚本中写好加密函数，自动生成

举例（MD5 签名）：
  参数按字母排序 → 拼接成字符串 → 加密 → 和签名参数对比
  sign = MD5("app_id=xxx&timestamp=xxx&key=secret")

面试评分参考¶

维度	初级（1-2年）	中级（3-5年）
HTTP 基础	知道方法、状态码、Header	能解释鉴权、跨域、缓存
用例设计	能设计正常+异常用例	能考虑幂等、并发、数据一致性
工具使用	会用 Postman 发请求	能搭自动化框架、CI 集成
问题定位	能用抓包看请求响应	能从前端→接口→后端→数据库逐层定位