想转软件测试的人，十有八九是从接口测试开始的。我面试过不少候选测试工程师，发现一个普遍现象：很多人做过接口测试，但问到底层逻辑、用例设计、依赖处理、Mock场景，能讲清楚的反而不多。软件测试岗位里，服务端接口测试恰恰是投入产出比最高的一环，它不像UI自动化那样脆弱，也不像性能测试那样需要一整套压测环境，却能最快时间暴露出后端逻辑、数据权限、异常处理这些真正影响线上质量的问题。这篇文章适合正在看软件测试面试题的朋友，也适合刚接触软件测试基础培训的新人，同样适合想把手头项目接口测试流程系统化的团队老人。我会从概念、流程、用例设计、工具实操、Mock方案、自动化落地、问题排查一路讲下来，尽量说人话，把我自己踩过的坑和复盘结果一起放出来。
1. 接口测试到底是测什么：概念、分层与核心价值
1.1 接口测试的定义与测试范围
接口（API）可以理解为系统之间通信的“契约”。前后端之间、后端与第三方服务之间、平台与平台之间，数据都是通过接口传递的。所谓接口测试，就是绕过界面展示，直接向服务端发起请求，然后根据返回结果验证业务逻辑是否正确。用一个生活化的类比：你点一份外卖，前端页面是菜单照片，服务端接口是后厨，外卖骑手是网络传输，而收到的菜品就是你看到的响应结果。如果只看照片（UI测试）确实能发现问题，但想确认菜品分量足不足、口味对不对，最直接的方法还是打开餐盒看实物，这就是接口测试的价值。
接口测试不只是看返回值和状态码，它的范围其实很宽，至少包括这么几块：
- 功能正确性：正常请求是否返回预期数据和业务状态码；异常请求是否返回合理的错误信息。
- 数据格式与结构：字段是否完整、类型是否正确、嵌套结构是否符合约定，比如该返回Integer的不能返回String。
- 异常场景：参数缺失、参数类型错误、超长字段、非法字符、必填项为空等情况下，后端能否“优雅地失败”。
- 权限与安全：未登录、越权访问、鉴权过期、敏感数据脱敏等场景是否被正确拦截。
- 幂等性与一致性：重复提交、并发请求、重试机制下，数据是否会出现覆盖或重复扣除的问题。
- 性能基线：响应时间、吞吐量、接口在持续压力下是否出现超时、内存溢出等隐患。
1.2 接口测试在软件测试分层中的地位
在经典测试金字塔模型里，测试层级自下而上通常是单元测试、接口测试、UI测试。我之前在团队里做了一套自动化回归体系，最大的感受是接口测试是整个自动化体系里的“承重墙”。UI测试的优点是从用户视角出发，但同时也很脆弱：一个按钮位置移动、一个CSS样式调整、一次截图比对失败，都可能让整个用例崩掉。接口测试则不同，只要后端契约不变，前端页面怎么改都影响不到测试结果，执行稳定性非常高。
从发现问题的效率看，接口测试也比UI测试更早、更直接。举个真实场景：一个下单接口在“库存不足时返回错误码失败”，但UI层已经提前拦截了大部分非法操作，界面测试往往测不到极端情况。而接口测试可以越过后端所有前置校验之外的限制，直接模拟库存为0时的用户请求，这时候后端是否按预期做库存判断、是否回滚订单、是否返回给前端可读的错误信息，都会暴露出来。另外一个容易忽略的点是，接口测试可以在前端未开发完成时提前介入，不需要等UI，这在大团队并行开发时能抢出不少时间。哪怕你所在项目涉及物联网设备，比如智能硬件上报数据，也可以用接口测试直接模拟设备上报报文，不需要真实硬件就能验证服务端接收逻辑，这就是接口测试的延展性。
2. 接口测试的完整流程与用例设计要点
2.1 从接口文档评审开始
很多人拿到接口文档就开始对着Postman输入URL、点Send，这么做容易漏掉很多隐形问题。我习惯的第一步是文档评审，流程上先确认这几点：请求方法是不是符合业务语义、请求参数是否和字段文档一致、响应结构是否完整、错误码是否穷举清楚。为了让你快速上手，我一般会整理一个接口文档信息速查表，里面至少包含这些字段：
| 关注项 | 说明 | 容易踩的坑 |
|---|---|---|
| URL | 接口路径，分为测试和正式环境 | 环境地址切换时容易配错 |
| Method | GET、POST、PUT、DELETE等 | 语义不符，比如修改数据用了GET |
| Headers | Content-Type、Authorization等 | 漏传认证信息导致401 |
| Query参数 | URL问号后的参数 | 拼接错误或编码问题 |
| Body参数 | JSON、表单等请求体 | 字段名大小写不一致 |
| Response | 响应体结构和业务码语义 | 只看HTTP 200，忽略业务code |
| 错误码 | 成功、失败、参数错误、服务异常枚举 | 错误码含义不清，测试拿不到统一标准 |
文档评审阶段，我还会重点关注两个约定：第一，接口是否具备幂等性。尤其对于支付、订单创建这类重要业务，重复点击或网络重试时必须保证第二次请求不会重复扣款或重复下单。第二，业务状态码和HTTP状态码的语义区分。很多项目习惯无论业务失败还是成功都返回HTTP 200，然后把具体结果放在响应体的code里，如果不提前看明白，后面的断言就很容易写错方向。
如果项目里没有接口文档，也不要硬等开发补。我常用的做法是抓包准备：浏览器F12开发者工具的Network面板，或者用Charles和Fiddler这类抓包工具，把真实请求和响应结构抓下来，再通过Jmeter或Apifox保存为测试用例。这时候要注意，抓包抓到的请求里可能带着敏感信息，比如Cookie或Token，一定不要直接提交到公开的文档平台，避免泄露。
2.2 接口测试用例设计：从正常到异常全覆盖
接口测试用例设计的核心思维是“把参数当作变量，业务规则当作约束，穷举每个约束的边界”。我举个例子，登录接口通常有用户名、密码两个参数，很多人只测“正确账号密码登录成功”和“错误密码登录失败”就结束了。这远远不够。下面是一张我常用模板的简化版本，直接照着这个思路扩展就行：
| 用例编号 | 场景 | 请求参数 | 预期结果 |
|---|---|---|---|
| API_LOGIN_001 | 正常登录 | 正确用户名+正确密码 | HTTP 200，响应码0000，返回token |
| API_LOGIN_002 | 缺少密码 | 只有用户名 | HTTP 400或业务码40001，提示密码不能为空 |
| API_LOGIN_003 | 密码错误 | 正确用户名+错误密码 | HTTP 200，业务码10002，提示用户名或密码错误 |
| API_LOGIN_004 | 用户不存在 | 随机未注册账号 | HTTP 200，业务码10003，提示用户不存在 |
| API_LOGIN_005 | 用户名超长 | 用户名超过数据库长度上限 | HTTP 400，提示参数长度校验失败 |
| API_LOGIN_006 | 特殊字符 | 用户名带单引号或脚本标签 | HTTP 400，特殊字符被拒绝，验证是否存在注入风险 |
| API_LOGIN_007 | 重复请求 | 同参数连续两次请求 | 验证是否幂等，第二次是否被拒绝或不影响状态 |
这张表背后有四个设计原则，你在面试时也完全可以照着讲：第一是等价类划分，把有效等价类和无效等价类分别覆盖；第二是边界值分析，重点测最大长度、最小长度、0、负数、空字符串、超过长度等边界；第三是场景串联，登录之后紧接着调查询、下单、支付等依赖接口，确认token在整个会话链路里有效；第四是异常注入，网络超时、响应超时、返回非JSON格式、响应体为空等情况，也要想办法覆盖，很多线上事故其实是后端在异常情况下没有处理好。
设计用例时还有一点容易被忽略，就是断言不能只看状态码。我在实际工作中发现很多测试人员的接口用例断言仅仅是“response.status_code == 200”，这等于把接口测试做成“通没通”检查，而业务逻辑是否正确根本没验证。一个合格的接口断言必须包含：HTTP状态码、业务响应码、关键字段值、响应时间和返回的数据结构。比如订单创建后返回了orderId，你不仅要断言orderId非空，还要断言数据库里对应的订单状态是待支付。
2.3 测试数据准备与依赖管理
接口测试最让人头疼的不是写用例，而是造数据。尤其是支付、订单、优惠券这类强依赖前置状态的业务，没有数据根本跑不动。我在实际项目中用过三种方式来准备测试数据：
第一种是数据库直接准备，适合少量可控数据。直接连测试库，向用户表、订单表插入固定数据，前提是有数据库权限，同时要注意不要污染别人在用的公共环境。第二种是调用前置接口，这也是最符合真实链路的做法，比如测查询订单接口前，先通过创建订单接口生成一笔订单，再从响应里拿到订单号，作为后续接口的入参。第三种是依赖外部系统时，用Mock服务来代替，比如支付回调、短信下发这类第三方能力，详细方案我会在后面单独讲。
依赖管理上，最容易翻车的是登录态传递。很多系统采用Cookie或Token鉴权，你必须在测试前置步骤里先调登录接口，从响应中提取出认证信息，再传递到后续请求的Header中。这不是一个“死数据”问题，因为Token一般都有有效期，如果写死一个Postman变量，过几个小时用例就会间接失败。我建议把登录动作做成全局前置脚本，每次测试套件执行前自动刷新Token，并在断言里增加Token有效期检查，维护起来会轻松很多。
3. 核心工具实战：Postman、Apifox、JMeter怎么选、怎么用
3.1 工具选型思路：场景决定选择
工具本身没有高下之分，关键是匹配你的场景。我自己的习惯是分三层来看：
| 工具 | 擅长场景 | 核心优势 | 主要限制 |
|---|---|---|---|
| Postman | 接口调试、单接口快速验证、小型回归 | 上手快、集合管理方便、支持脚本断言 | 团队协作和接口文档管理偏弱 |
| Apifox | 接口文档、调试、用例管理一体化 | 文档和测试联动，调试结果可直接转用例，适合团队协作 | 相对较重，纯压测能力不如JMeter |
| JMeter | 接口回归、批量数据驱动、性能测试 | 线程组并发能力强、断言和提取器丰富、可做压测 | 调试体验不如Postman，脚本维护成本高 |
一句话结论：一个人快速验证用Postman；团队里想让接口文档和测试用例一起维护，直接上Apifox；需要定时批量执行、并发压测或者做自动化回归的，JMeter会更稳。实际项目里，我的用法往往是“多工具混搭”：前期用Postman调试逻辑，最后把脚本转成JMeter或者Python自动化用例，作为持续回归的一部分。
3.2 Postman核心操作要点
Postman我最常用的三个功能是环境变量、集合和断言脚本。先说环境变量，在管理环境里配置好base_url，请求地址写{{base_url}}/api/login，切换测试环境和生产环境时只需切换环境，不用改每个请求的URL，这一步能避免大量低级错误。
然后是脚本断言。Postman的Tests区域用JavaScript编写，最常用的写法是这样的：
pm.test("状态码是200", function () { pm.response.to.have.status(200); }); pm.test("业务码是0000", function () { const jsonData = pm.response.json(); pm.expect(jsonData.code).to.eql("0000"); }); pm.test("返回token不为空", function () { const jsonData = pm.response.json(); pm.expect(jsonData.data.token).to.not.be.empty; });更实用的一个场景是保存登录Token供后续接口使用。在登录接口的Tests里写：
const jsonData = pm.response.json(); if (jsonData.code === "0000") { pm.environment.set("token", jsonData.data.token); }然后其他请求的Headers里用{{token}}引用即可。我建议每次写完断言后，手动改一下参数多跑几轮，确认断言本身是可靠的，而不是只为了“变绿”而写。
3.3 Apifox：从调试到用例管理一体化
Apifox这几年在团队里越来越常用，原因是它把接口文档、调试、数据模型、测试用例放在一个平台里，减少了接口信息不同步的问题。我在一个电商项目中就用它管理了40多个接口，开发在Apifox里更新接口字段，测试那边直接重新调试，文档和用例不会像传统模式那样“各改各的”，一致性好了不少。
使用Apifox有一个比较顺的工作流：拿到接口文档后，在项目里导入或手动创建接口定义，填好请求参数和响应模型；然后直接点击“调试”，发起真实的接口请求，检查响应是否符合定义；确认无误后，把调试内容“另存为用例”。这里有个实操小技巧：Apifox的测试用例支持配置“前后置操作”，你可以在前置操作里先调用登录接口并设置环境变量，后续用例统一使用返回的Token，这样比每个请求单独登录要高效得多。
3.4 JMeter：当接口测试需要并发和回归
JMeter是压测和批量接口回归的利器。用JMeter做接口测试的基本配置流程是：在测试计划下添加线程组，配置线程数和循环次数；在线程组下添加HTTP请求，填写协议、域名、方法、路径、参数；再添加响应断言，判断响应正文或状态码是否符合预期；加上“查看结果树”，用来观察每个请求的详细返回。
JMeter处理接口依赖时，重点靠JSON提取器。它的用法是：在登录请求下添加JSON提取器，Variable名称填token，JSONPath表达式填$.data.token，随后在后续HTTP请求的Headers中直接写${token}，即可完成参数传递。这个写法看起来不起眼，但在实际项目中能解决大量请求串联问题。如果你想用JMeter做并发验证，比如同时有10个用户、每个用户循环5次，只需要在线程组里设置线程数为10、循环次数为5，就可以模拟一个轻量级的并发场景，验证接口是否存在并发下单、重复扣款等问题。
4. Mock模拟接口测试：从原理到落地
4.1 什么时候需要Mock
Mock原理不复杂：用一个可控的替身接口，替代真实依赖系统，并按你的预期返回特定结果。它就像排练节目时的“替身演员”——正式演员没到场，替身先把位置、走位和台词都走一遍，能让整个团队的工作不被阻塞。
需要Mock的典型场景主要有四类。第一类是第三方接口未就绪，比如接入支付、短信、地图、物流等外部服务，对方还在开发或需要商务开通，测试等不起，就先Mock一个响应。第二类是异常场景难构造，比如“支付回调返回签名失败”“第三方接口断连”“返回超长报文”，这些场景很难让真实第三方配合你触发，Mock可以随时造出来。第三类是前后端并行开发，后端可能还没完成，前端或测试可以先按契约Mock住，提前验证。第四类是测试环境不稳定，比如依赖的另一个业务系统频繁重启，接口测试因此频繁中断，这时把不该依赖的环境Mock掉，能提高自动化稳定性。
4.2 常见Mock方案与选型
我分别用过几类Mock方案，各有适用场景：
| 方案 | 实现方式 | 适用场景 | 注意事项 |
|---|---|---|---|
| 本地Mock工具 | WireMock、JSON Server等 | 开发/测试本地快速造数 | 需要维护独立的模拟规则 |
| 网关Mock | 在API网关或代理层拦截请求 | 团队共享Mock服务 | 需要网关支持路由匹配 |
| 代码层Mock | Python Mock库、Java Mockito等 | 单元测试、集成测试内嵌 | 只在测试进程内生效 |
| 在线Mock平台 | Apifox内置Mock、Mockoon等 | 临时接口联调 | 数据在第三方网络，注意保密 |
如果只是测试端需要快速返回不同响应，我推荐用Apifox内置Mock功能，它能根据字段类型自动生成模拟数据，也可以自定义响应模板，管理起来非常轻。如果对Mock的灵活性和可控性要求高，WireMock是更专业的选择，可以通过一组JSON规则文件定义不同路径的响应。
4.3 实战：模拟支付回调异常并验证业务处理
拿最常见的“模拟支付回调异常”举例。第一步是先确定模拟对象：接口测试中对订单支付成功流程有依赖，但真实支付回调需要真实支付平台，测试环境拿不到，所以用Mock创建一个本地回调接口。第二步是定义Mock规则，在Mock服务里配置一个路由，比如POST /api/pay/callback，当请求中携带amount=100且sign=fakeSign时，返回支付成功的响应体；同时再配置一个路径，当sign错误时返回签名失败的错误码。第三步是在测试脚本里把支付回调地址指向Mock服务，发起一个订单支付请求，再触发回调，最后断言订单状态是否从“待支付”变为“已支付”，同时验证签名失败时订单状态是否保持不变。
这里有个关键经验：Mock出来的数据和逻辑必须尽量贴近真实环境，尤其是签名校验逻辑，如果Mock里面没有签名校验，只能验证“正常路径”，验证不了异常路径，这样的Mock结果在回归时是不可信的。我见过一个项目把支付回调Mock成“永远返回成功”，结果上线后才发现，真实支付平台偶尔返回“签名错误”时，业务系统不会做重试和告警，差点造成用户已付款但订单未更新的重大事故。
5. 接口自动化测试落地：从脚本到持续集成
5.1 自动化框架选型：Python+Requests+Pytest
进入自动化阶段后，我比较推荐Python+Requests+Pytest这个组合。因为Python语法简单，Requests库处理接口请求非常直观，Pytest又是目前最主流的Python测试框架，断言和参数化都做得很成熟。而且这套技术栈在软件测试面试题里也是高频考点，在简历上写“能独立搭建接口自动化框架”时，这条路是可以直接拿来复盘的。
一个基础的自动化项目结构大致是这样的：
api_test/ ├── config/ # 环境配置，比如base_url、账号信息 ├── common/ # 公共方法，如请求封装、日志、断言 ├── testcases/ # 测试用例目录 │ └── test_login.py ├── test_data/ # 测试数据，JSON或Excel驱动 ├── report/ # 测试报告输出 └── conftest.py # Pytest全局钩子，比如fixture5.2 核心代码：请求封装与断言
先写一个最简单的登录接口用例，你看一下整体脉络：
import requests BASE_URL = "http://192.168.1.100:8080" def test_login_success(): url = f"{BASE_URL}/api/login" payload = { "username": "admin", "password": "123456" } resp = requests.post(url, json=payload) # 断言HTTP状态码 assert resp.status_code == 200 # 断言业务码 assert resp.json()["code"] == "0000" # 断言关键数据存在 assert "token" in resp.json()["data"]如果用例量增大，把所有逻辑塞在单个脚本里会非常难维护。我的做法是分两层：第一层是common/request_util.py，封装统一的post、get方法，统一加日志和超时；第二层是conftest.py里定义一个login_token的fixture，在需要的用例前自动执行一次登录，并把token传给用例。这样测试函数本身就只关注业务断言。
5.3 数据驱动与用例组织
接口测试的场景很多，如果变化只体现在参数上，一定要用数据驱动。Pytest的parametrize可以很好满足这个需求：
import pytest import requests BASE_URL = "http://192.168.1.100:8080" @pytest.mark.parametrize("username,password,expected_code", [ ("admin", "123456", "0000"), ("admin", "wrong_password", "10002"), ("", "123456", "40001"), ("admin", "", "40001"), ]) def test_login_with_params(username, password, expected_code): resp = requests.post(f"{BASE_URL}/api/login", json={"username": username, "password": password}) assert resp.status_code == 200 assert resp.json()["code"] == expected_code数据驱动的收益很直接，新增用例只需要在这一组参数里加一行，代码不用动，回归成本低，也更容易让新人接手维护。我通常会配合pytest-html或Allure生成测试报告，报告里把步骤截图、请求体、响应体、断言结果和失败信息都输出出来，这样领导看报告、开发定位问题都省事。
5.4 测试报告与CI集成
接口自动化测试脚本写好后，最重要的是让它自动跑起来。我常配的方案是Jenkins：新建一个任务，配置好托管代码的仓库地址，构建步骤里执行pytest命令并生成报告，然后设置每天凌晨跑一次，或者提交代码时触发。GitLab CI也是类似逻辑，在一个.gitlab-ci.yml里定义测试任务的镜像、执行命令和产物报告。
第一次接入CI时，有两件事容易翻车：执行环境里没有安装项目依赖，或者测试数据库的初始化脚本没有执行。我的建议是先保证本地全量跑通一次，再在CI环境里从零拉取项目、安装依赖、执行测试，确认流程完整后再加入定时任务。同时要关注接口的稳定性问题，如果被测环境经常不稳定，自动化报告里的失败项多到没人看，这个自动化项目就会从“资产”变成“负担”。
6. 高频问题排查与面试实战分享
6.1 接口测试中最容易踩的坑
做了这么多年接口测试，我把自己和团队成员翻车最多的场景汇总成了一张速查表。
| 问题现象 | 常见原因 | 排查思路 |
|---|---|---|
| 同样一段脚本，本地成功、CI失败 | 环境变量或数据库数据不一致 | 核对CI执行环境的配置文件和初始化脚本 |
| 登录成功，后续接口却报401 | Token未更新或已过期 | 检查是否每次执行前都重新调用登录接口刷新Token |
| 接口返回中文乱码 | 请求或响应编码不一致 | 确认请求Header里的Content-Type包含charset=utf-8 |
| 响应断言总是失败的“玄学” | 接口存在动态字段，比如时间戳、随机数 | 对动态字段用正则或忽略策略处理，不要强匹配 |
| 重复执行用例出现数据冲突 | 用例间共享了公共数据 | 每条用例尽量自行造数据，结束时清理现场 |
6.2 常见HTTP状态码与排查方向
接口测试里，HTTP状态码是我们最先接触的排查入口，我整理了一份我会要求团队成员必须先记住的对照表：
| 状态码 | 含义 | 排查方向 |
|---|---|---|
| 200 | 请求成功 | 继续校验业务码和响应体 |
| 400 | 请求参数错误 | 检查请求方式、参数名、参数类型 |
| 401 | 未认证 | 确认Token、Cookie是否有效 |
| 403 | 无权限 | 检查用户权限、令牌作用域 |
| 404 | 路径不存在 | 核对URL是否正确、服务是否部署 |
| 405 | 方法不允许 | 确认GET/POST是否用反 |
| 500 | 服务端内部错误 | 去服务端日志里查异常堆栈 |
| 502/503/504 | 网关或超时问题 | 检查网关配置、服务负载、上游响应时间 |
6.3 面试常问的接口测试题与回答思路
无论是招人还是被面，我经常遇到下面这些问题，回答思路也是可以讲的：
第一，“你做过哪些接口测试？”回答时不要只报工具名，要说清系统是什么、哪些模块、多少个接口、怎么设计用例、发现过什么问题。第二，“接口测试用例怎么设计？”按正常、异常、权限、安全、幂等五个维度回答，顺便举登录或下单的具体例子。第三，“Cookie和Token有什么区别？”Cookie偏服务端对客户端的本地状态保存，Token偏身份令牌，常用于无状态接口鉴权。第四，“接口重试时怎么保证幂等？”需要回答幂等键、唯一事务号、状态机防重复更新、数据库唯一索引等手段。第五，“Mock是什么？你在项目中怎么用？”这是高频题，回答时突出“可控地模拟异常和依赖，让测试不被外部系统阻塞”。第六，“接口自动化框架怎么搭？”讲清分层结构、请求封装、数据驱动、断言、报告、CI这六个环节就够了。
请注意，回答面试题时最忌背概念。面试官更想听到的是你遇到过的真实问题和解决过程，哪怕是一个很小的编码问题，讲清楚“发生了什么—排查思路—怎么解决—沉淀了什么”就很有说服力。
6.4 简历里的接口测试项目经验怎么写
我筛简历时，最怕看到“负责接口测试”这种空话。一份好的接口测试项目经验至少要包含项目背景、你的角色、采取的动作、量化结果四部分。我给你一个可以参考的写法：
负责XX电商系统登录、订单、支付模块的接口测试，参与接口文档评审和用例设计，累计完成120个接口测试用例，覆盖正常、异常、权限、幂等、并发场景；使用Postman完成接口调试与联调，利用JMeter对下单接口进行并发压测，发现重复扣款问题1个、越权访问问题2个；独立搭建Python+Pytest+Requests接口自动化框架，集成Jenkins每日执行，回归时间从2小时缩短到15分钟。
这份简历的特点是每个动作都有颗粒度，有数字，能看出来你会设计用例、会选工具、会处理数据依赖、还能推动自动化落地，这是面试官最想看到的接口测试能力。
最后聊一点我个人的经验。接口测试这个东西，谁都能很快上手点几下鼠标，但想真正做好，必须把精力花在“可控性”上：依赖可控、数据可控、异常可控、环境可控。我带的测试新人里，做得最快的那批人有个共同特点，就是遇到问题不会忙着换工具，而是先梳理清楚请求、响应、数据、依赖这条链路，再决定用什么方法解决。如果你也准备在这个方向上深入，我建议你从自己手头最熟悉的系统入手，挑一个核心业务接口，把文档评审、用例设计、工具调试、Mock异常、自动化脚本、CI接入整个链路完整走一遍。走完这一遍，你对接口测试的理解会比只看教程几个月都要深。
另外再分享一个小习惯：我写接口测试用例的时候，会专门留一个“观察断言”字段，用来记录那些不影响功能但会影响稳定性的信号，比如响应时间有没有突然飙升、错误码含义是否前后不一致。别小看这个细节，很多线上事故都是先从接口响应异常开始的，接口测试如果能提前捕捉到这些“小异常”，价值会比你想象的更大。
