目录
1.接口介绍
接口一般来说有两种，一种是程序内部的接口，一种是系统对外的接口。
程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口。比如贴吧系统，有登录模块、发帖模块等等，要发帖就必须先登录，这两个模块就得有交互，它就会抛出一个接口，供内部系统进行调用。
系统对外的接口：比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的。比如说咱们用的 APP、网址这些，在进行数据处理的时候都是通过接口来进行调用的。
接口类型有很多，如 HTTP API 接口、RPC 等等，这里基于 HTTP API 接口进行理解。
2.接口概念
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
简而言之，所谓接口测试就是通过测试不同情况下的入参与之相应的出参信息，来判断接口是否符合或满足相应的功能性、安全性要求。
3.接口测试与功能测试的区别
功能测试是从页面输入值，然后通过点击按钮或链接等传值给后端，功能测试还要测 UI、前端交互等功能；但接口测试没有页面，它是通过接口规范文档上的调用地址、请求参数，拼接报文，然后发送请求，检查返回结果。
| 维度 | 功能测试 | 接口测试 |
|---|---|---|
| 核心目标 | 验证用户操作后的功能是否正常 | 验证接口的入参、出参及逻辑是否合规 |
| 测试范围 | 涵盖 UI 交互、前端逻辑、后端逻辑 | 仅关注后端接口的逻辑和数据处理 |
| 参数校验 | 间接验证（通过界面输入） | 直接验证（强制校验参数格式、必填项等） |
| 错误场景覆盖 | 侧重用户可见的错误提示（如页面弹窗） | 侧重接口返回的错误码、异常信息（如 “参数格式错误”） |
| 性能与安全性 | 较少涉及（主要依赖功能表现） | 重点关注（如接口响应时间、防注入攻击） |
4.接口的组成
接口文档应该包含以下内容：
- 接口说明
- 调用 url
- 请求方法（get\post）
- 请求参数、参数类型、请求参数说明
- 返回参数说明
由接口文档可知，接口至少应有请求地址、请求方法、请求参数（入参和出参）组成，部分接口有请求头 header 。
标头 (header)：是服务器以 HTTP 协议传 HTML 资料到浏览器前所送出的字符串，在标头与 HTML 文件之间尚需空一行分隔，一般存放 cookie 、 token 等信息。
header 和入参有什么关系？它们不都是发送到服务器的参数吗？
它们确实都是发送到服务器里的参数，但它们是有区别的。header 里存放的参数一般是一些校验信息，比如 cookie，其作用是校验该请求是否有权限请求服务器。若有权限，才能请求服务器，随后将请求地址连同入参一起发送到服务器，服务器再根据地址和入参返回出参。也就是说，服务器会先接收 header 信息，判断该请求是否有权限，确认有权限后，才会接收请求地址和入参。
| 维度 | Header（请求头） | 入参（请求参数） |
|---|---|---|
| 传递位置 | 位于 HTTP 请求的 “头部”（与请求体分离，无格式时以空行分隔） | 通常位于 URL 的查询字符串（GET）或请求体（POST 等）中 |
| 作用 | 主要用于控制请求的元信息（如权限、格式、缓存等） | 主要用于传递业务数据（如用户 ID、操作内容等） |
| 典型内容 | - 权限校验：Token、Cookie、Authorization- 数据格式： Content-Type（如application/json）- 客户端信息： User-Agent（浏览器 / 设备类型）- 缓存控制： Cache-Control |
- GET 请求：URL 中?后的参数（如id=1&name=test）- POST 请求：请求体中的 JSON / 表单数据（如 {"username":"admin"}）- 路径参数：URL 路径中的变量（如 /users/{userId}中的userId） |
| 服务器处理顺序 | 服务器通常先解析 Header（如校验权限），若不通过直接拒绝请求 | 仅在 Header 校验通过后，服务器才会解析入参并处理业务逻辑 |
| 与业务的关联 | 多数与具体业务无关，是通用的 HTTP 协议规范或框架约定 | 直接与业务逻辑相关，是业务接口的核心输入 |
微信接口文档的示例：
5.接口的重要性
接口其实就是前端页面或 APP 等调用并与后端做交互用的。有人会问，功能测试都测好了，为什么还要测接口呢？
先举个例子：
比如测试用户注册功能，规定用户名为 6~18 个字符，包含字母（区分大小写）、数字、下划线。
首先功能测试时肯定会对用户名规则进行测试，比如输入 20 个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验。如果有人通过抓包绕过前端校验直接发送到后端怎么办？试想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录，可能会通过 SQL 注入等手段随意登录，甚至可以获取管理员权限，那这样不是很恐怖？
所以，接口测试的必要性就体现出来了：
- 可以发现很多在页面上操作发现不了的 bug
- 检查系统的异常处理能力
- 检查系统的安全性、稳定性
- 前端随便变，接口测好了，后端不用变
6.接口测试
get 和 post 请求
get 请求示例：https://gateway.acgo.cn/acgoAccount/openapi/user/detail?uid=36482
get 和 post 是常见的请求方法。如果是 get 请求，直接在浏览器里输入 URL 就能发起请求（凡是能在浏览器中直接请求到结果的，都是 get 请求）；而 post 请求则无法通过浏览器直接发起，必须借助测试工具（如 Postman）来发送。http 状态码
每发出一个 http 请求后，都会收到响应，http 会通过状态码标识请求的处理结果。常见的状态码如下：- 2xx（成功）：表示请求发送成功，最常见的是 200，代表请求正常，服务器已返回数据。
- 3xx（重定向）：代表请求需要重定向，最常见的是 302，表示请求被重定向到其他地址。
- 4xx（客户端错误）：400 代表客户端请求有语法错误；401 代表访问未授权；403 代表没有权限访问该资源；404 代表请求的资源不存在。
- 5xx（服务器错误）：500 代表服务器内部发生异常；504 代表服务器响应超时，未返回结果。
接口测试分两步走：
通过接口设计用例 + 结合业务逻辑来设计用例
7.接口用例的编写
1. 通过性验证
首先要保证接口功能可用，即进行正常的通过性测试，按照接口文档的参数要求正常传入，验证是否返回正确结果。
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
|---|---|---|---|---|---|---|
| 01 | 接口正常调用测试 | 接口服务正常运行 | 1. 按照接口文档要求，传入所有必填参数 2. 调用接口 3. 检查返回结果 |
返回状态码 200，返回结果符合预期（如操作成功、返回数据完整） |
2. 参数组合
针对接口中存在的多参数依赖场景，需测试不同参数组合的有效性。例如：有一个操作商品的接口，字段type传 1 时代表修改商品（商品 id、商品名称、价格至少传一个）；type传 2 时代表删除商品（商品 id 为必填项）。
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
|---|---|---|---|---|---|---|
| 02 | 修改商品只传商品名称测试 | 接口服务正常运行，商品存在 | 1. 设置type=12. 只传商品名称 3. 调用接口 |
返回状态码 200，商品名称修改成功，其他信息不变 | ||
| 03 | 修改商品传 id、名称、价格测试 | 接口服务正常运行，商品存在 | 1. 设置type=12. 传入商品 id、名称、价格 3. 调用接口 |
返回状态码 200，商品信息修改成功 | ||
| 04 | 删除商品测试 | 接口服务正常运行，商品存在 | 1. 设置type=22. 传入商品 id 3. 调用接口 |
返回状态码 200，商品删除成功 |
3. 接口安全
主要验证接口的防绕过、权限控制、参数加密等安全性：
- 绕过验证：如修改商品价格、金额等关键数据，验证后端是否校验；
- 绕过身份授权：如非权限用户调用需特定权限的接口；
- 参数加密：如登录接口的用户名、密码是否加密，加密规则是否安全；
- 密码安全规则：验证密码复杂度校验是否有效。
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
|---|---|---|---|---|---|---|
| 05 | 绕过价格验证测试 | 接口服务正常运行 | 1. 购买商品 2. 提交订单时，将商品价格改为 3 元 3. 调用接口 |
返回状态码 400 或 403，提示价格验证失败 | ||
| 06 | 绕过身份授权测试 | 接口服务正常运行 | 1. 使用普通用户调用修改商品信息接口 2. 调用接口 |
返回状态码 403，提示无权限操作 | ||
| 07 | 参数加密测试 | 接口服务正常运行 | 1. 检查登录接口的用户名和密码是否加密 2. 拦截请求查看数据 |
用户名和密码已加密，且加密规则难以破解 | ||
| 08 | 密码复杂度校验测试 | 接口服务正常运行 | 1. 注册或修改密码时，输入不符合复杂度要求的密码 2. 调用接口 |
返回状态码 400，提示密码不符合安全规则 |
4. 异常验证
不按接口文档要求传入参数，验证接口对异常情况的处理能力，主要包括：必填参数缺失、参数类型错误、参数长度超限等。
| 用例编号 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
|---|---|---|---|---|---|---|
| 09 | 必填参数缺失测试 | 接口服务正常运行 | 1. 不传必填参数（如商品 id） 2. 调用接口 |
返回状态码 400，提示必填参数缺失 | ||
| 10 | 参数类型错误测试 | 接口服务正常运行 | 1. 传入错误类型的参数（如将整数类型传为字符串） 2. 调用接口 |
返回状态码 400，提示参数类型错误 | ||
| 11 | 参数长度超限测试 | 接口服务正常运行 | 1. 传入长度超限的参数（如长度限制为 10，传入 11） 2. 调用接口 |
返回状态码 400，提示参数长度超限 |
8. 结合业务逻辑设计用例
根据系统具体业务逻辑设计用例，不同公司的业务场景不同，需针对性测试（类似功能测试的用例设计思路）。
举例：以贴吧系统为例，需结合以下业务规则设计用例：
- 登录失败 5 次，需等待 15 分钟后才能再次登录；
- 新注册用户需过实习期才能发帖；
- 删除帖子会扣除用户积分；
- ......
需将这些业务测试点列出，通过构造对应数据验证接口是否符合业务逻辑。