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

学习软件测试的第十二天(接口测试)

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

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

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

  1. 接口地址与请求方式是否正确:确认 URL 是否拼写正确,是否使用了正确的 HTTP 方法(GET、POST 等)。

  2. 网络连通性检查:使用 ping、curl 或 Postman 检查接口是否能访问,是否存在 DNS 或代理等网络层问题。

  3. 请求参数合法性:检查必传参数是否缺失,格式是否符合接口规范。

  4. 服务端状态排查:查看服务是否部署正常,接口是否已上线或存在异常(如500错误)。

  5. 权限与鉴权问题:确认是否传递了正确的 token 或 API key,是否有权限访问该接口。

  6. 跨域限制(前端场景):检查是否存在 CORS 跨域问题导致请求被浏览器拦截。

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

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

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

1.通俗易懂解释

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

  1. 确认输入是否正确处理(比如投币+按键,能买到饮料);

  2. 测试异常输入会不会报错(比如投假币);

  3. 看看它稳定性如何(快速多次操作会不会崩);

  4. 验证权限(是不是管理员才能开机);

  5. 验证边界情况(最多能买多少瓶);

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

2.面试术语

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

1. 明确接口需求和文档

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

2. 划分测试维度

主要包括:

  • 功能测试:验证接口是否按预期返回正确结果(如正常输入返回 200 和期望数据);

  • 🚫 异常/负面测试:如缺失参数、参数类型错误、非法输入等,检查返回是否符合预期错误(如400/401等);

  • 🔐 权限测试:是否需要鉴权?Token 缺失/无效是否能拦截?

  • 🔁 边界测试:如字符串最大长度、数组最大值、分页边界等;

  • 📶 兼容性和稳定性测试:高并发、大数据量、重复请求、请求顺序等;

  • 🕒 超时与性能测试:模拟慢响应或超大请求,看系统是否稳定处理;

3. 设计具体测试用例

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

  • 用例编号

  • 测试目标

  • 请求方法/URL

  • 输入参数

  • 预期返回结果(状态码+响应内容)

4. 构造测试数据

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

5. 使用工具执行测试

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

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

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

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

  • 偷看(信息泄露)

  • 偷用(越权访问)

  • 捣乱(注入攻击、篡改数据)

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

2.面试术语

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

  1. 身份认证与权限控制

    • 确认接口是否正确校验用户身份(如 token、API key),并防止未授权或越权访问。

    • 重点测试未登录、低权限用户访问敏感接口的行为。

  2. 参数校验与防注入

    • 验证接口是否对输入参数做了格式校验,能否抵御 SQL 注入、XSS、命令注入等攻击。

    • 会构造恶意 payload,如 ' OR 1=1 --、HTML 标签等,进行黑盒验证。

  3. 敏感数据保护

    • 检查接口是否启用了 HTTPS,传输过程是否加密;

    • 响应中是否有明文密码、身份证号、token 等敏感信息泄露。

  4. 防刷与限流机制

    • 测试接口是否具有限速、IP 限制、验证码等防刷设计,防止接口被恶意调用或攻击。

    • 通常使用并发脚本测试限流阈值和响应策略。

  5. 防重放与签名机制

    • 检查是否使用时间戳、nonce、签名等方式防止请求被截获重放;

    • 对关键接口进行重复请求验证。

  6. 接口暴露与错误信息控制

    • 验证是否存在未授权的调试接口、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 是“数字签名的通行证”,你带着它,别人不能伪造,常用于移动端、分布式登录。

对比项CookieSessionToken(如 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

✅ 通俗解释:

当你访问一个接口(比如打开一个网页、请求一个后端服务),服务端都会返回一个“状态码”告诉你处理得怎么样。

  • 返回 200,就像对方说:“✅ 请求我收到了,也处理成功了。”

  • 如果是 404,意思是“❌ 你找的接口地址我没有”;

  • 如果是 500,是“❌ 我服务端出错了”;

  • 如果是 401,是“❌ 你没有权限(可能没登录)”。

🎯 专业术语表达:

HTTP 状态码是服务器对客户端请求的响应结果的标准表示,其中 200 OK 表示接口请求成功且服务器已正确处理了该请求。

在接口测试中,检查是否返回 200 是最基础的断言,用于判断接口是否通、是否处理成功。


🧠 注意:

虽然 返回 200 表示接口成功响应,但:

  • 不代表业务一定正确!例如:登录接口返回 200,但登录失败;

  • 所以还要结合业务字段断言(如 code、msg、data)判断接口是否真的“业务成功”。

总结:在接口测试过程中,我不仅关注接口是否返回 200,还会从参数合法性、权限控制、业务逻辑完整性、数据一致性等多个维度设计用例,实际也发现了不少隐藏较深的 Bug,比如重复下单、越权访问、幂等缺失、接口结构不规范等,这些问题在早期发现能极大提升系统的稳定性与安全性。 

http://www.dtcms.com/a/269859.html

相关文章:

  • Spring Security架构与实战全解析
  • 人工智能-基础篇-24-RAG和LLM到底怎么理解和区分?(LLM是深度训练的大语言生成模型,RAG是LLM更智能的补充技术)
  • 日语学习-日语知识点小记-构建基础-JLPT-N3阶段(1):新的开始-尊他开始
  • 【无标题】导出pdf
  • 数据库版本自动管理
  • MVP架构接口开发套路
  • TCP/IP协议基础
  • mybatis/mybatis-plus添加数据,自增id的值为负数
  • 第十四天,7月8日,八股
  • 《UE5_C++多人TPS完整教程》学习笔记42 ——《P43 瞄准(Aiming)》
  • 【音视频】HLS-m3u8协议介绍
  • Redis基础学习(五大值数据类型的常用操作命令)
  • 超低功耗CC2340R SimpleLink™ 系列 2.4GHz 无线 MCU支持BLE5.3/Zigbee/Thread/专有协议
  • 微软上线 Deep Research 预览版:o3+必应赋能研究自动化
  • css 面试题
  • 从零构建MCP服务器:FastMCP实战指南
  • 跨平台软件构建方法及工具介绍
  • 深度学习-多分类
  • Java 实现 Excel 文件对比与数据填充
  • 多线程(1)
  • Minmax 算法与 Alpha-Beta 剪枝小教学
  • (普及−)B3629 吃冰棍——二分/模拟
  • 【Spring WebSocket详解】Spring WebSocket从入门到实战
  • Spring Boot 事务失效问题:同一个 Service 类中方法调用导致事务失效的原因及解决方案
  • MATLAB/Simulink电机控制仿真代做 同步异步永磁直驱磁阻双馈无刷
  • CD46.【C++ Dev】list的模拟实现(1)
  • 一天一道Sql题(day02)
  • SSH密钥 与 Ed25519密钥 是什么关系
  • 服务器的RAID存储方案如何选择最合适?
  • 20250708-2-Kubernetes 集群部署、配置和验证-使用kubeadm快速部署一个K8s集群_笔记