一、接口测试

1.1接口的概念

接口分 2 类：

1. 程序内部接口：是代码 / 模块之间的 “沟通桥梁”。比如贴吧的 “登录模块” 和 “发帖模块”，发帖前必须先登录，这俩模块就得通过接口交互（登录模块抛个接口给发帖模块调用）。

2. 系统对外接口：是不同系统之间的 “数据共享通道”。比如你用的 APP 要拿其他平台的数据，对方不会直接给数据库，而是给个 “接口”（写好的方法），你调用这个接口就能拿到数据。像 APP、网站的数据交互，都是靠对外接口实现的。

常见接口类型：HTTP API、RPC 等（重点讲 HTTP API）。

1.2接口测试

1. 核心概念

接口测试是测试系统组件间接口的测试，重点检查：

• 数据的交换、传递、控制逻辑
• 系统 / 子系统之间的依赖关系

简单说：通过 “传不同入参→看返回的出参”，判断接口是否满足功能、安全要求。

它比功能测试简单？功能测试要测页面、UI、前端交互；接口测试没有页面，只需要拼请求（按接口文档填地址、参数）、发请求、看结果 —— 所以确实更聚焦 “入参 & 出参”。

2. 接口的组成（看接口文档就懂）

接口文档必须包含这些信息（比如微信小游戏的接口文档）：

接口文档示例：https://developers.weixin.qq.com/minigame/dev/api-backend/open-api/access-token/auth.getAccessToken.html

• 接口说明：这个接口是干啥的（比如 “获取 accessToken”）
• 调用 URL：接口的地址（比如https://xxx/auth.getAccessToken.html）
• 请求方法：是 GET 还是 POST
• 请求参数：要传啥数据（参数名、类型、说明）
• 返回参数：接口会返回啥数据（字段、含义）
• （部分接口有）请求头（header）：存校验信息（比如 cookie、token）

3. 请求头（header）和入参的区别？

虽然都是发给服务器的参数，但分工不同：

• header：存 “权限 / 校验信息”（比如 cookie 是用来证明 “你有权请求服务器”）。服务器会先看 header，确认你有权限了，才会处理你的请求地址和入参。
• 入参：是接口的 “业务数据”（比如发帖时传的 “帖子内容”）。

1.3接口测试的重要性

功能测试测了页面，为啥还要测接口？举个例子：用户注册要求 “用户名 6~18 字符”，功能测试时前端会拦截 “20 字符”“特殊符号”—— 但如果后端没做校验，有人绕开前端（比如抓包改数据）直接发请求到后端，就能注册违规用户名，甚至用 SQL 注入盗号！

所以接口测试的价值是：

1. 发现页面操作测不出来的 Bug（比如后端校验缺失）
2. 检查系统异常处理能力（比如传错参数时，接口会不会崩溃）
3. 提升安全性 / 稳定性（防注入、防越权）
4. 解耦前后端：前端页面随便改，只要接口逻辑不变，后端不用动

1.4如何执行接口测试

1. GET 和 POST 请求

都是 HTTP 请求方法，核心区别：

• GET：请求参数直接拼在 URL 里（比如https://xxx/user/detail?uid=36482），可以直接在浏览器输入访问。
• POST：请求参数藏在请求体里，浏览器没法直接发，得用工具（比如 Postman）。

2. HTTP 状态码（接口返回的 “状态信号”）

接口请求后，服务器会返回一个数字编码，代表请求结果：

• 2xx（成功）：比如 200 → 请求成功，服务器返回数据。
• 3xx（重定向）：比如 302 → 请求被转到其他地址了。
• 4xx（客户端错）：
  • 400：请求语法错（比如参数格式不对）
  • 401：没授权（比如没带 token）
  • 403：没权限（比如普通用户想访问管理员接口）
  • 404：接口地址不存在
• 5xx（服务器错）：
  • 500：服务器内部崩溃了
  • 504：服务器超时，没返回结果

二、如何执⾏接⼝测试

接⼝测试分两步⾛：通过接⼝设计⽤例+结合业务逻辑来设计⽤例

2.1接⼝⽤例的编写

1. 通过性验证：⾸先肯定要保证这个接⼝功能是好使的，也就是正常的通过性测试，按照接⼝⽂档上 的参数，正常传⼊，是否可以返回正确的结果。

2. 参数组合：

针对商品操作接口的type字段（控制 “修改 / 删除” 功能），需覆盖以下参数组合场景：

• 当type=1（修改商品）：
  1. 仅传 “商品名称”，验证是否能成功修改名称（其他信息保持不变）；
  2. 同时传 “商品 id + 名称 + 价格”，验证是否能成功修改所有信息；
• 当type=2（删除商品）：
  1. 仅传 “商品 id”，验证是否能成功删除商品。

3. 接⼝安全： 

接口安全需覆盖以下场景：

1. 绕过数据验证：例如商品原价 300 元，提交订单时将价格篡改为 3 元（甚至 - 3 元），验证后端是否校验价格合理性（避免支付金额异常或余额反向增加）；
2. 绕过身份授权：例如修改商品信息接口仅卖家可用，验证普通用户、其他卖家调用该接口时，是否会被拦截（无权限操作）；
3. 参数加密校验：例如登录接口的用户名、密码，需验证是否加密传输（防止请求被拦截后信息泄露），同时检查加密规则的安全性（是否易破解）；
4. 密码安全规则：验证密码的复杂度校验逻辑（如长度、字符类型等是否符合安全要求）。

4. 异常验证：

核心目标：验证接口对不符合文档要求的参数的校验能力，需覆盖 3 类场景：

1. 必传参数缺失：故意不传入接口文档要求的必填参数（如商品接口不传 “商品 id”）；
2. 参数类型错误：故意传入与文档要求不符的类型（如要求传整数，实际传字符串）；
3. 入参长度超限：故意传入长度超出文档限制的参数（如要求长度≤10，实际传 11 位内容）。

预期结果：接口返回 400 类错误码，并给出明确的参数错误提示（如 “必填参数缺失”“参数类型错误”）。

2.2 结合业务逻辑来设计⽤例

核心思路：结合系统自身的业务规则设计用例，本质和功能测试的用例设计逻辑一致 —— 需先梳理业务规则，再针对规则设计测试场景。

举个例子：贴吧业务的接口测试用例设计

先明确贴吧的业务规则，再对应设计接口测试场景：

1. 登录限制规则：登录失败 5 次后，需等待 15 分钟才能再次登录→ 测试接口场景：故意连续调用登录接口失败 5 次，第 6 次调用时，验证接口是否返回 “需等待 15 分钟” 的提示。

2. 发帖权限规则：新注册用户需过实习期才能发帖→ 测试接口场景：用 “未过实习期的新用户” 调用发帖接口，验证接口是否返回 “无发帖权限” 的提示。

3. 积分规则：删除帖子会扣除用户积分→ 测试接口场景：调用删除帖子接口后，查询用户积分接口，验证积分是否按规则扣除。

操作步骤：先梳理业务规则→提炼测试点→构造对应数据（如 “未过实习期的新用户”“登录失败 5 次的账号”）→调用接口验证结果。

详解解释：接口自动化测试的完整流程（按顺序）

1. 第一步：通性验证（接口 “能不能用”）

• 测试目标：验证接口的基础功能是否正常可用（相当于 “冒烟测试”）。
• 测试逻辑：严格按照接口文档传 “所有必填 + 正确格式的参数”，看是否返回预期结果。
• 谁会操作？→ 这是用户的实际操作：用户正常用接口时，就是按文档传正确参数的。

2. 第二步：参数组合测试（接口 “常用场景对不对”）

• 测试目标：覆盖接口的主流业务场景（用户实际会用到的参数组合）。
• 测试逻辑：针对接口的 “功能分支”（比如商品接口的type=1修改、type=2删除），传用户常用的参数组合（比如修改商品时 “只改名称”“改 id + 名称 + 价格”）。
• 谁会操作？→ 这是用户的实际操作：用户用接口时，会自然触发不同的参数组合（比如改商品信息时，可能只改名称，也可能全改）。

3. 第三步：安全测试（接口 “有没有漏洞”）

• 测试目标：验证接口的安全性（防止恶意攻击、越权、数据泄露）。
• 测试逻辑：模拟 “恶意用户的攻击行为”，比如：
  • 绕过价格验证（把 300 元改成 3 元）；
  • 越权操作（普通用户调用卖家接口）；
  • 窃取未加密的账号密码。
• 谁会操作？→ 这是测试人员额外做的：普通用户不会故意 “攻击接口”，但恶意攻击者会 —— 所以测试人员要站在 “黑客视角” 挖漏洞。
• 为啥考验经验？安全场景是 “非直观” 的，比如 “参数加密是否易破解”“越权的边界在哪里”，需要测试人员见过类似漏洞、懂攻击思路，才能想到更多场景。

4. 第四步：异常验证（接口 “错了会不会崩”）

• 测试目标：验证接口的容错能力（传错参数时，接口不会崩溃、能给出明确提示）。
• 测试逻辑：故意传 “不符合文档要求的参数”，比如：
  • 不传必填参数；
  • 传错参数类型（整数传字符串）；
  • 传超长参数。
• 谁会操作？→ 大部分是测试人员额外做的：用户可能会 “误操作”（比如手滑输错参数），但不会故意传极端错误的参数 —— 测试人员要覆盖 “用户误操作 + 极端异常” 的场景。
• 为啥考验经验？异常场景的边界很广（比如参数长度超限到多少会崩？类型错到什么程度会出问题？），需要测试人员积累 “接口常见崩溃点” 的经验，才能想到更多极端情况。

总结：用户操作 vs 测试额外操作

测试步骤	属于 “用户实际操作” 吗？	核心特点
通性验证	✅ 是	基础、必过的 “正常流程”
参数组合测试	✅ 是	用户常用的 “主流业务场景”
安全测试	❌ 测试额外做	模拟恶意攻击，挖潜在漏洞
异常验证	❌ 大部分是测试额外做	覆盖用户误操作 + 极端异常场景

接口测试的 “进阶补充”

前面的 “通性、参数、安全、异常” 是从 “接口本身” 出发设计测试，而这一步是从 “系统的业务规则” 出发，覆盖接口在实际业务流程中的场景。

它的核心作用：

确保接口不仅 “本身能用”，还要 “符合业务规则”（毕竟接口是为业务服务的，只测接口本身，可能漏了业务逻辑的问题）。

举个例子（贴吧业务）：

前面的测试可能已经验证了 “登录接口能正常返回 token”“发帖接口能接收参数并返回成功”，但业务规则要求 “新用户过了实习期才能发帖”—— 如果只测接口本身，就会漏掉 “未过实习期的新用户调用发帖接口” 的场景，而这一步就是补全这类业务关联的测试。

它和前面四类测试的关系：

前面四类是 “基础保障”（接口功能、参数、安全、异常没问题），这一步是 “业务适配”（接口行为符合实际业务要求）。

简单说：前面是 “接口行不行”，这一步是 “接口在业务里用得对不对”。

参数组合的业务场景” 和 “业务规则的业务场景”—— 两者不是一回事

1. “参数组合测试”覆盖的是：接口 “功能分支” 的业务场景

比如商品接口的type=1（修改）、type=2（删除），参数组合测的是 “接口不同功能分支下，传不同参数是否能完成对应的操作”（比如修改商品时 “只传名称”“传全参数” 的效果）。它聚焦的是 “接口自身功能的业务场景”，是接口 “能做什么” 的验证。

2. “结合业务逻辑设计用例”覆盖的是：系统 “全局业务规则” 的场景

比如贴吧的 “登录失败 5 次需等 15 分钟”“新用户实习期不能发帖”，这些是系统层面的业务规则（不是接口自身的功能，而是多个接口 / 模块配合的业务约束）。它聚焦的是 “接口在整个业务流程中，是否符合全局规则”，是接口 “该做什么、不该做什么” 的验证。

参数组合测试：只针对单个接口

是对 “同一个接口的不同功能分支” 做测试 —— 比如商品接口的type=1（修改）、type=2（删除），都是单个接口内部的参数组合，不需要其他接口配合。

业务逻辑测试：通常涉及多个接口 / 模块的联动

是对 “系统级的业务规则” 做测试 —— 这些规则需要多个接口配合才能验证。比如贴吧的 “新用户实习期不能发帖”：

• 要先调用「注册接口」生成新用户；
• 再调用「发帖接口」用这个新用户发帖；
• 还要结合 “用户状态模块” 的实习期判断逻辑。这是多个接口 + 业务模块联动的场景，不是单个接口能覆盖的。

再举个例子：

• 参数组合测试：测「支付接口」传 “金额 100 + 订单 id” 能不能成功支付（单个接口）；
• 业务逻辑测试：测 “用户余额不足时调用支付接口”，是否会触发 “余额不足提示”（需要「支付接口」+「用户余额查询接口」联动）。

总结：

• 参数组合测试 → 单个接口的功能分支；
• 业务逻辑测试 → 多个接口 / 模块联动的业务规则。

两者是互补的：参数组合保证接口 “功能分支能跑通”，业务逻辑保证接口 “符合全局规则”

三、接口自动化测试

3.1概念

接口自动化是用代码 / 工具自动执行接口测试，代替人工反复调接口、看结果。它的优势：

• 效率高：一次写脚本，重复执行（比如回归测试）；
• 准度高：避免人工操作的疏忽；
• 易定位：直接测系统内部逻辑，问题定位更快。

3.2接⼝⾃动化流程

1. 需求分析：先把接口 “摸清楚”

核心是明确接口的 “请求” 和 “响应”：

• 分析请求：接口的 URL、请求方法（GET/POST 等）、请求头（header）、请求参数 / 请求体；
• 分析响应：接口返回的数据格式（JSON/XML）、状态码（200/400 等）、错误提示（比如 “参数缺失”）。→ 相当于 “先拿到接口的使用说明书”。

2. 挑选自动化接口：不是所有接口都要自动化

得结合项目资源 + 接口特性选：

优先选这 3 类接口：

• ① 核心业务接口（比如教育平台的 “课程购买接口”）；
• ② 频繁使用的接口（比如 “登录接口”“查询课程接口”）；
• ③ 容易出错的接口（比如逻辑复杂的 “新增课程接口”）。

怎么判断？看 3 个维度：

• 功能复杂度：逻辑分支多、参数多的接口（比如 “新增课程” 要传名称 / 价格 / 分类，还得联动其他模块）；
• 高风险功能：影响业务核心的接口（比如 “登录” 崩了，用户用不了系统）；
• 重复性高：需要反复测的接口（比如用户每次用都要登录，回归测试要测 N 次）。

3. 设计自动化测试用例：复用 + 补充

• 可以直接用功能测试阶段的用例（省事儿）；
• 要覆盖正向场景（正常传参）和反向场景（异常 / 边界值 / 参数组合）—— 和之前讲的 “通性、参数、安全、异常” 对应。

4. 搭建自动化测试环境：选工具 + 装依赖

• 选技术栈：比如用 Python（简单易上手），配 PyCharm 开发环境；
• 装依赖库：
  • requests：用来发 HTTP 请求（调接口）；
  • pytest/unittest：测试框架（管理用例、执行测试）。

5. 设计自动化执行框架：让脚本更规范

框架要包含 3 个核心能力：

• 参数化处理：把接口的 URL、参数等写成配置（比如放 yaml 文件里），改配置不用改代码；
• 用例执行逻辑：比如 “先登录→再调用其他接口” 的流程；
• 报告生成：执行完自动出报告（方便看结果）。  

6. 编写代码：把用例写成脚本

比如用 Python+requests 写一个登录接口的测试脚本：

7. 执行用例：跑脚本

用测试框架执行，比如在命令行敲：

pytest test_login.py -v

8. 生成测试报告：可视化结果

用工具生成易读的报告，比如：

• HtmlTestRunner：生成 HTML 格式报告；
• Allure：生成更美观的交互式报告（能看用例通过率、失败原因）。