学习软件测试的第十二天(接口测试)
一.如果一个接口请求不通,那么你会考虑那些方面的问题?
如果一个接口请求不通,我会像“排查水管漏水”一样一步步定位问题发生在哪一段,主要从这几个方向去思考:
当一个接口请求不通时,我会从以下几个方面进行排查:
接口地址与请求方式是否正确:确认 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 | 中 |
✅ 通俗解释:
当你访问一个接口(比如打开一个网页、请求一个后端服务),服务端都会返回一个“状态码”告诉你处理得怎么样。
返回 200,就像对方说:“✅ 请求我收到了,也处理成功了。”
如果是 404,意思是“❌ 你找的接口地址我没有”;
如果是 500,是“❌ 我服务端出错了”;
如果是 401,是“❌ 你没有权限(可能没登录)”。
🎯 专业术语表达:
HTTP 状态码是服务器对客户端请求的响应结果的标准表示,其中
200 OK
表示接口请求成功且服务器已正确处理了该请求。
在接口测试中,检查是否返回 200 是最基础的断言,用于判断接口是否通、是否处理成功。
🧠 注意:
虽然 返回 200 表示接口成功响应,但:
不代表业务一定正确!例如:登录接口返回 200,但登录失败;
所以还要结合业务字段断言(如 code、msg、data)判断接口是否真的“业务成功”。
总结:在接口测试过程中,我不仅关注接口是否返回 200,还会从参数合法性、权限控制、业务逻辑完整性、数据一致性等多个维度设计用例,实际也发现了不少隐藏较深的 Bug,比如重复下单、越权访问、幂等缺失、接口结构不规范等,这些问题在早期发现能极大提升系统的稳定性与安全性。