当前位置：首页 > news >正文

学习软件测试的第十二天（接口测试）

news 2025/7/9 10:26:01

一.如果一个接口请求不通，那么你会考虑那些方面的问题？

如果一个接口请求不通，我会像“排查水管漏水”一样一步步定位问题发生在哪一段，主要从这几个方向去思考：

当一个接口请求不通时，我会从以下几个方面进行排查：

接口地址与请求方式是否正确：确认 URL 是否拼写正确，是否使用了正确的 HTTP 方法（GET、POST 等）。
网络连通性检查：使用 ping、curl 或 Postman 检查接口是否能访问，是否存在 DNS 或代理等网络层问题。
请求参数合法性：检查必传参数是否缺失，格式是否符合接口规范。
服务端状态排查：查看服务是否部署正常，接口是否已上线或存在异常（如500错误）。
权限与鉴权问题：确认是否传递了正确的 token 或 API key，是否有权限访问该接口。
跨域限制（前端场景）：检查是否存在 CORS 跨域问题导致请求被浏览器拦截。

通过从客户端、网络、服务端三个层级依次排查，可以快速定位接口请求失败的根本原因。

在实际项目中，我遇到过因为 token 过期导致接口返回 401 的问题，通过日志定位并添加自动刷新机制解决了问题。

二.如何设计接口测试用例，请列举关键步骤

1.通俗易懂解释

设计接口测试用例，就像你要验证一个自动贩卖机是否工作正常。你需要：

确认输入是否正确处理（比如投币+按键，能买到饮料）；
测试异常输入会不会报错（比如投假币）；
看看它稳定性如何（快速多次操作会不会崩）；
验证权限（是不是管理员才能开机）；
验证边界情况（最多能买多少瓶）；

这些就是接口测试要覆盖的逻辑。

2.面试术语

设计接口测试用例通常包括以下关键步骤：

1. 明确接口需求和文档

理解接口的功能、输入参数、请求方式（GET/POST等）、返回格式、状态码等。

2. 划分测试维度

主要包括：

✅ 功能测试：验证接口是否按预期返回正确结果（如正常输入返回 200 和期望数据）；
🚫 异常/负面测试：如缺失参数、参数类型错误、非法输入等，检查返回是否符合预期错误（如400/401等）；
🔐 权限测试：是否需要鉴权？Token 缺失/无效是否能拦截？
🔁 边界测试：如字符串最大长度、数组最大值、分页边界等；
📶 兼容性和稳定性测试：高并发、大数据量、重复请求、请求顺序等；
🕒 超时与性能测试：模拟慢响应或超大请求，看系统是否稳定处理；

3. 设计具体测试用例

每个维度下撰写用例，通常包括以下字段：

用例编号
测试目标
请求方法/URL
输入参数
预期返回结果（状态码+响应内容）

4. 构造测试数据

区分正常值、边界值、非法值、空值等组合情况，覆盖不同场景。

5. 使用工具执行测试

如 Postman、JMeter、Python 脚本或自动化框架（如 pytest + requests）来执行与验证。

三.如何验证接口的安全性

1.通俗易懂解释：怎么理解接口安全性验证

可以把接口安全性理解成给“出入口加防盗门+监控”，防止别人：

偷看（信息泄露）
偷用（越权访问）
捣乱（注入攻击、篡改数据）

所以你要做的，就是模拟“坏人”常用的几种攻击手段，验证系统有没有防住。

2.面试术语

当验证接口的安全性时，我主要从以下六个维度进行系统性测试：

身份认证与权限控制
- 确认接口是否正确校验用户身份（如 token、API key），并防止未授权或越权访问。
- 重点测试未登录、低权限用户访问敏感接口的行为。
参数校验与防注入
- 验证接口是否对输入参数做了格式校验，能否抵御 SQL 注入、XSS、命令注入等攻击。
- 会构造恶意 payload，如 ' OR 1=1 --、HTML 标签等，进行黑盒验证。
敏感数据保护
- 检查接口是否启用了 HTTPS，传输过程是否加密；
- 响应中是否有明文密码、身份证号、token 等敏感信息泄露。
防刷与限流机制
- 测试接口是否具有限速、IP 限制、验证码等防刷设计，防止接口被恶意调用或攻击。
- 通常使用并发脚本测试限流阈值和响应策略。
防重放与签名机制
- 检查是否使用时间戳、nonce、签名等方式防止请求被截获重放；
- 对关键接口进行重复请求验证。
接口暴露与错误信息控制
- 验证是否存在未授权的调试接口、Swagger 文档泄露；
- 检查异常返回是否暴露堆栈信息或系统路径。

四.什么是接口断言，如何设计接口断言

1.通俗解释

可以把断言理解成验收标准：
我们不是只发出请求，而是要检查接口返回的结果是不是“对的”。

比如你点外卖后，收到的不是奶茶而是汉堡，你当然要投诉 —— 接口断言就是“检查你点的是不是你要的”。

2.面试术语

接口断言是指在接口测试中，对接口返回的状态码、响应体、字段内容、结构等进行自动化校验，以判断接口是否返回了预期结果。

例如，购物系统的订单状态查询接口测试中，设计断言，状态码是200，表示响应体中的订单状态字段值与数据库一致。

确定断言维度（设计断言类型）

✅ 1. 状态码断言

确保接口响应状态正确
例：assert response.status_code == 200

✅ 2. 字段值断言

验证返回中关键字段值是否为预期
例：assert response.json()["code"] == 0

✅ 3. 字段类型与格式断言

确保字段类型正确，或符合正则、格式标准
例：assert isinstance(response.json()["data"]["id"], int)

✅ 4. 字段存在性断言

验证返回体中是否包含预期字段
例：assert "userId" in response.json()["data"]

✅ 5. 列表/分页数据断言

校验数组长度、分页边界、顺序
例：assert len(response.json()["data"]["items"]) <= page_size

✅ 6. 业务逻辑断言（核心加分项）

如余额变更是否正确、订单状态是否符合流程等
例：assert response.json()["data"]["orderStatus"] == "PAID"

五.如何处理接口依赖

1.通俗解释

接口依赖就像做饭时要先洗菜、切菜，才能炒菜。

比如你要测试“下单接口”，但它依赖“登录接口”和“添加购物车接口”先执行，才能成功下单。

所以你要想办法：

把前置接口先跑一遍；
把里面的关键数据（比如 token、order_id）提取出来；
用在后面的接口请求中。

2.面试术语

在接口测试中，若某个接口依赖前置接口提供的数据（如 token、user_id、订单号等），可以通过以下方式进行处理：

1. 通过接口调用获取依赖数据

先执行前置接口（如登录），提取响应中的关键字段（如 token、id）；
使用该数据动态传入后续接口的请求参数中，实现数据链路闭环。

🧩 示例：从登录接口响应中提取 token，添加到下单接口的 header。

2. 利用测试框架的数据传递机制

使用全局变量、fixture（pytest）、环境变量或数据上下文对象，在多个接口间传递数据；
自动化框架如 Postman、pytest、HttpRunner 支持变量引用与参数提取机制。

3. 设计前置步骤或数据准备函数

将依赖数据的创建逻辑封装成 setup 方法或前置脚本，在测试执行前自动调用；
确保测试环境干净、数据可控、可复现。

4. 使用 Mock 或数据库初始化（降低强依赖）

若接口过于复杂或依赖不稳定，也可使用 Mock 接口模拟返回数据；
或通过 SQL 语句直接初始化测试数据，提高执行效率与稳定性。

总结：我处理接口依赖时，通常会通过执行前置接口并提取关键字段（如 token、id），结合自动化测试框架的变量机制传递到后续接口中。如果依赖关系复杂，也会将前置数据准备逻辑封装成 setup 方法，或者通过数据库初始化和 Mock 减少对上游接口的依赖，保证测试流程的稳定性和可复现性。

六.在多接口业务流程测试中，如何确保接口之间的调用顺序正确

1.通俗解释

可以把多接口测试流程想象成“网购流程”：

先登录 → 再加购物车 → 再下单 → 再支付 → 再查订单

如果顺序错了，比如还没登录就去下单，就会失败。

所以你要做的就是：

每个接口按业务顺序执行
上一个接口的返回值要正确传给下一个接口
并且中间出错时，整个流程要能及时终止或报警

2.思考流程

✅ 1. 明确业务流程与依赖关系

先分析接口间的上下游依赖，比如必须先登录再下单、必须先创建资源再更新等。

🧩 建议绘制接口流程图或写成步骤列表，帮助理清顺序。

✅ 2. 按顺序设计测试步骤

测试用例中接口调用应严格按照业务流程顺序执行，每一步成功后才执行下一步。

例如：Step 1：调用登录接口 → 获取 token Step 2：使用 token 调用创建订单接口 → 获取 order_id Step 3：使用 order_id 调用支付接口

✅ 3. 数据动态提取与传递

利用自动化测试框架（如 Postman、pytest、HttpRunner）提取前置接口的返回值，通过变量机制传入后续请求中。

🧩 示例：

提取 token：{{login_response.token}}
提取 order_id：extract_var("order_id") → inject_to("next_api_body")

✅ 4. 前置依赖封装（setup/fixture）

将前置步骤封装为 setup 方法或 fixture，让测试框架自动先执行前置接口，保障数据准备完整。

✅ 5. 流程中加入断言与失败中断机制

每个接口执行后加入断言，若任一步失败，及时中断后续接口调用，避免无效操作或误判结果。

✅ 6. 使用测试集或场景管理工具（高级做法）

在大型项目中，使用如 Postman Collection Runner、pytest 测试集、Jenkins 流程任务等，管理完整业务流程测试。

3.面试术语

在多接口流程测试中，我会先梳理接口依赖关系，明确业务顺序，然后按逻辑设计测试用例链条，并在每一步提取关键数据传给下一个接口。通过断言与前置方法机制，确保每一步成功执行，整体流程稳定可控。在自动化测试中，我也会使用 fixtures 或流程控制机制保障顺序性。

七.接口测试是什么，为什么要做接口测试

接口测试就像是“检查系统内部各个模块之间的沟通是否顺畅”，防止“你说的我听不懂”这种情况。

接口测试是指针对系统中模块或服务之间的数据交换接口（如 HTTP API、RPC 接口等）进行的测试，主要验证接口的功能正确性、稳定性、安全性、兼容性和性能，确保系统各个部分之间数据传输准确、调用逻辑合理。

通常包括：

请求是否能正确处理参数；
返回的数据是否符合预期；
接口是否具备容错机制、安全控制等。

接口测试是保障系统模块间通信正确性与稳定性的关键手段。相比 UI 测试，它更早介入、更高效稳定，能快速定位服务端问题，是构建高质量系统不可或缺的环节，尤其在微服务和前后端分离架构中更为重要。

八.Cookie、session、token的区别

Cookie 就像“你随身带的身份证”——浏览器存的，每次访问都会自动发给服务器。
Session 是“服务器开的档案柜”，你来一次，它给你一个编号（session id），存在服务端。
Token 是“数字签名的通行证”，你带着它，别人不能伪造，常用于移动端、分布式登录。

对比项	Cookie	Session	Token（如 JWT）
存储位置	浏览器端（客户端）	服务端	客户端（一般存 localStorage 或 Cookie）
数据存储	小量键值对（如 session ID）	用户信息保存在服务器内存或数据库中	用户信息编码后存储在 token 中
生命周期	可设置过期时间	一般随服务器关闭或用户退出而失效	可设置过期时间
安全性	容易被盗用，需配合 HTTPOnly + HTTPS	安全性较好，但服务端要保存大量会话信息	签名机制防伪造，不易被篡改
跨域支持	默认不支持跨域	不支持	支持跨域，适合前后端分离系统
是否依赖服务端	否（只是存数据）	是（需服务器维护 session 状态）	不依赖服务端存状态（无状态）
常见应用场景	网站登录记住我、简单信息记录等	PC端登录、传统网站	移动端、前后端分离、单点登录（SSO）

Cookie、Session 和 Token 都用于管理用户身份和状态：

Cookie 存在客户端，用于在每次请求时携带信息；
Session 存在服务端，基于 Session ID 实现身份管理；
Token（如 JWT）是一种无状态的身份验证机制，适合前后端分离和分布式系统。

实际中，我通常在传统网站使用 Cookie + Session，在前后端分离或移动端场景采用 Token 认证机制。

九.接口测试中如何处理第三方依赖

接口测试中，第三方依赖就像“外包服务商” —— 比如发短信、支付接口、地图服务等：

你要测试自己的系统，但这些外部接口你控制不了；
如果对方挂了、慢了、数据变了，你的测试就会出问题。

所以你要做的，就是：不完全依赖它，甚至“假装它在”，也能测自己。

✅ 1. 使用 Mock 技术模拟第三方接口返回

用 Mock Server 或工具（如 WireMock、Mock Service Worker、Postman Mock）模拟第三方接口的响应数据，避免测试依赖真实外部服务。

🧩 示例：

模拟支付接口返回 {"code": 0, "msg": "success"}；
模拟地图接口返回定位坐标。

✅ 2. 配置测试环境使用“沙箱环境”

如果第三方提供测试/沙箱环境，应切换接口配置，避免真实扣费、发短信等操作。

🧩 示例：

支付宝、微信支付、短信服务等都有沙箱环境。

✅ 3. 前置准备依赖数据 / 响应缓存

对于无法 Mock 的接口，可提前调用一次并缓存响应结果，用于后续测试中“模拟使用”。

✅ 4. 接口调用进行降级处理 / 添加重试机制

在自动化测试脚本中，若第三方接口不稳定，可设定超时重试或失败兜底逻辑，避免影响整条测试链路。

✅ 5. 仅测试集成逻辑，不重复验证第三方服务功能

第三方接口自身已被测试过，我们关注的仅是与我方系统的集成是否正确，如参数是否正确传入、回调是否处理成功。

总结：在接口测试中遇到第三方依赖时，我通常通过使用 Mock 服务模拟响应、切换至沙箱环境，或配置响应缓存，避免对外部接口的强依赖。同时，我会聚焦验证系统自身的集成逻辑，确保参数传递、响应处理、容错机制等正确，从而提高测试的稳定性和可控性。

十.你做接口测试的过程中发现了那些bug?

1.接口测试 Bug 汇总表

序号	Bug 类型	接口名称	问题描述	预期行为	实际返回示例 / 状态码	优先级
1	参数校验缺失	`/api/user/login`	密码字段为空仍返回 200 且提示登录成功	应返回 400 并提示“密码不能为空”	`{ "code": 0, "msg": "登录成功" }`	高
2	业务逻辑错误	`/api/order/create`	多次点击“提交订单”生成多笔相同订单，缺少幂等性	应限制重复提交或返回相同订单号	创建多个订单编号	高
3	越权访问	`/api/admin/user`	普通用户身份调用管理员接口可成功拉取所有用户数据	应返回 403 无权限	状态码：200，返回全量用户信息	高
4	数据未更新	`/api/pay/notify`	支付完成后，订单状态未更新，但接口提示支付成功	应将订单状态更新为“已支付”	返回成功但查订单仍为“待支付”	高
5	字段缺失	`/api/user/info`	接口文档中说明返回 `nickname` 字段，但实际返回中缺失	应返回完整字段	`{ "code": 0, "data": { "id": 1 }}`	中
6	错误码混乱	`/api/common/get`	所有错误均返回 `200` 状态码，错误信息写在 body 中	应使用语义正确的 HTTP 状态码（如 400、401、500 等）	状态码：200，body: `"msg": "参数错误"`	中
7	接口响应不一致	`/api/product/list`	部分情况下 `data` 字段返回数组，部分情况下返回 `null`	接口返回结构应一致，空列表也应返回空数组	`{ "data": null }` 或 `{ "data": [] }`	中
8	性能异常/超时	`/api/report/export`	数据量大时接口超时，无分页导出或异步处理机制	应使用异步任务或导出状态轮询机制	请求卡住30秒后失败	中
9	安全漏洞	`/api/reset-pwd`	无需登录即可传手机号与验证码重置任意账户密码	应限制登录态或增加权限校验	正常返回 `密码修改成功`	高
10	跨域限制缺失	`/api/open/query`	跨域请求时未配置 CORS 头，浏览器拦截请求	应返回带有 Access-Control-Allow-Origin 等 CORS 头部	浏览器控制台报错 `CORS policy blocked`	中