接口测试基础
接口
接口(Interface)是一个在计算机科学、软件工程中广泛使用的概念,核心是定义 “交互规则”,用于规范不同实体(如模块、系统、组件、对象等)之间的通信方式,而不关注具体实现细节。
简单来说,接口就像 “协议” 或 “说明书”:它规定了 “能做什么”“需要什么输入”“会返回什么结果”,但不规定 “具体怎么做”。
接口一般有两种,一种是程序内部接口,一种是系统对外接口
程序内部接口
方法之间/模块之间的交互,有程序内部抛出的接口,比如在进行下单操作之前需要先登录账号,那么在下单和登录这两个模块之间就会抛出接口,用来内部调用,一般的逻辑为:
-
下单方法在执行到核心逻辑之前,会先调用 “检查登录状态” 的方法(这可以理解为内部接口)
-
若检查到未登录,会触发跳转登录页的逻辑(这是交互的结果)
这里的 “接口” 更像是模块间约定好的调用方式(比如方法名、参数、返回值),而非主动 “抛出” 接口,而是通过定义清晰的方法或函数来实现交互。这种设计的核心是解耦:下单模块不需要知道登录模块的具体实现,只需调用其提供的 “检查登录” 方法即可,符合 “高内聚、低耦合” 的原则。
系统对外接口
当我们需要从其他的网站或者服务器上获取到想要的数据或者资源信息时,别人往往不会直接将数据库进行共享,而是提供一个他们写好的方法来获取数据,而我们去引用他提供的接口就能直接使用他写好的方法,来达成数据获取的操作,比如:
-
常用的app、网站在进行数据处理的时候都是通过接口来进行调用的
外部系统只需按照接口约定(如请求地址、参数格式、协议类型等)发起调用,就能获取所需数据或触发特定操作,无需关心接口背后的具体实现
核心特点
-
抽象性:只定义 “规则”,不包含具体实现。
-
规范性:明确输入、输出、格式、错误处理等,让交互双方有章可循。
-
解耦性:使用方无需依赖实现细节,只需依赖接口,便于替换实现或扩展功能
接口测试
概念
接口测试是针对软件系统中不同模块、组件或系统之间的 “接口” 进行的测试,核心是验证接口的功能、性能、安全性、兼容性等是否符合设计要求,确保接口在交互过程中能正确、稳定地传递数据和执行操作。
简单来说,接口测试不关注软件的界面(如按钮、页面展示),而是直接对 “接口本身” 发起请求,检查其返回结果是否符合预期,以此验证接口的逻辑正确性和可靠性。
接口组成
接口的组成可以从 “交互规则” 的核心出发,拆解为多个关键要素,这些要素共同定义了接口的调用方式、输入输出及约束条件。
接口表示(唯一标识符)
用于唯一确定一个接口的 “地址” 或 “名称”,是调用方找到接口的依据。
-
对于代码内接口(如函数 / 方法):通常是函数名、方法名(如
checkLogin()
)。 -
对于 HTTP API:通常是请求 URL(如
https://api.example.com/user/login
)。 -
对于 RPC 接口:可能是服务名 + 方法名(如
com.user.service.UserService.login
)。
请求参数(输入)
调用接口时需要传递的信息,用于告知接口 “做什么” 或 “用什么数据做”。
-
参数类型:如字符串、数字、布尔值、数组、对象等(需符合接口约定的数据格式,如 JSON、XML、表单等)。
-
参数约束:
-
必选 / 可选:哪些参数必须传,哪些可省略(如登录接口中 “用户名” 是必选,“验证码” 可能可选)。
-
格式限制:如手机号必须是 11 位数字,日期必须是
yyyy-MM-dd
格式。 -
取值范围:如年龄需在 0-150 之间,状态只能是 “启用” 或 “禁用”。
-
响应结果(输出)
接口执行完成后返回给调用方的信息,用于告知 “操作是否成功”“结果是什么”。
-
状态标识:通常是状态码(如 HTTP 的 200 表示成功,400 表示参数错误;自定义业务码如
0
表示成功,1001
表示用户名不存在)。 -
数据内容:成功时返回的业务数据(如登录成功返回
token
和用户信息),失败时返回错误描述(如 “密码错误”)。 -
数据格式:与请求参数对应,如 JSON 格式的响应:
{"code": 0,"message": "success","data": { "token": "xxx", "username": "test" }
}
通信协议(交互方式)
定义接口调用的底层通信规则,确保调用方和提供方 “能听懂对方的语言”。
-
常见协议:HTTP/HTTPS(Web API 主流)、TCP/UDP(底层网络接口)、RPC(如 gRPC、Dubbo)、WebSocket(实时通信)等。
-
协议细节:如 HTTP 接口的请求方法(GET/POST/PUT/DELETE)、请求头(Headers,如
Content-Type
、Authorization
)、超时时间等。
权限与安全约束
限制接口的访问范围,防止未授权调用或恶意攻击。部分接口有请求头 header
header: 是服务器以HTTP协议传HTML资料到浏览器前所送出的字符串,在标头与 HTML 文件之间尚需空一行分隔,一般存放 cookie
、 token
等信息
-
认证方式:如 Token、Cookie、API 密钥(AppKey)、OAuth2.0 等(如登录接口需要先获取 Token,后续接口需携带 Token 才能调用)。
-
权限控制:不同角色能调用的接口不同(如普通用户不能调用 “删除所有用户” 接口)。
-
安全策略:如接口加密(HTTPS)、防重放(时间戳 + 签名)、限流(防止高频调用)等。
异常处理规则
定义接口在出错时的行为,确保调用方能明确问题原因。
-
错误类型:如参数错误、权限不足、服务器内部错误、网络超时等。
-
错误反馈:明确的错误码、错误信息(如 “错误码 1002:手机号格式不正确”),而非模糊的 “系统错误”。
接口测试的重要性
接口就是前端页面或者APP调用与后端做交互用的,如果我们只是在前端进行了校验,不对后端进行校验,在用户通过抓包绕过前端校验直接发送到后端时,可能就会出现问题.所以接口测试的作用就是:
-
可以发现很多在页面上操作发现不了的bug
-
检查系统的异常处理能力
-
检查系统的安全性、稳定性
-
前端随便变,接口测好了,后端不用变
用一个例子就很好看出来:
当前我们所处的页面是百度一下的起始页面,找到一个url
这个是他原本的返回
我也可以通过直接输入url的方式进行访问
那如果我在输入的url中对参数进行了修改呢?如果使用SQL注入呢?如果我们不进行测试,就可能会有一定的风险
如何进行接口测试
在进行接口测试之前,我们还需要了解一些东西:
GET和POST请求
GET和POST是常见的请求方法。如果是GET请求的话,直接在浏览器里输入就行了,只要在浏览器里面直接能请求到的,都是GET请求,如果是POST的请求的话,就不行了,就得借助工具来发送。
如果我们直接在浏览器里输入POST请求,会直接被默认转换为GET类型
这就是相同的url,但是直接通过浏览器进行访问就转换为了GET请求
http状态码
每发出一个http请求之后,都会有一个响应,http本身会有一个状态码,来标示这个请求是否成功,常见的状态码有以下几种:
-
200
2开头的都表示这个请求发送成功,最常见的就是200,就代表这个请求是ok的,服务器也返回了。 -
300
3开头的代表重定向,最常见的是302,把这个请求重定向到别的地方了。 -
400
400代表客戶端发送的请求有语法错误,401代表访问的页面没有授权,403表示没有权限访问这个页面,404代表没有这个页面 -
500
5开头的代表服务器有异常,500代表服务器内部异常,504代表服务器端超时,没返回结果
设计测试用例
接口测试在设计测试用例的时候一般分为两步: 通过接口设计用例+结合业务逻辑来设计用例
接口用例编写
通过性验证
首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。
用例编号 | 用例标题 | 前置操作 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
01 | 接口正常调用测试 | 接口服务正常运行 | 1.按照接口文档要求,传入所有必填参数 2.调用接口 3.检查返回结果 | 状态码返回200,返回结果符合预期 |
参数组合
假设现在有一个操作用户信息的接口,有一个字段type,为1的时候代表修改用户,用户id、用户名字、用户联系方式有一个是必传的;type为2的时候是删除用户,用户id为必传;type为3的时候是创建用户,用户id、用户名字、用户联系方式三个都是必传的,这里就需要设计参数的组合了
用例编号 | 用例标题 | 前置操作 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
02 | 修改用户只传用户名称测试 | 接口服务正常运行,用户存在 | 1.设置 type=1 2.只传用户名称 3.调用接口 | 返回状态码200,用户名称修改成功,其他信息不变 | ||
03 | 修改用户传id、名字、联系方式测试 | 接口服务正常运行,用户存在 | 1.设置 type=1 2.传用户id、名称、联系方式 3.调用接口 | 返回状态码200,用户信息修改成功 | ||
04 | 删除用户测试 | 接口服务正常运行,用户存在 | 1.设置 type=2 2.传用户id 3.调用接口 | 返回状态码200,用户删除成功 | ||
05 | 创建用户测试 | 接口服务正常运行,用户不存在 | 1.设置 type=3 2.传用户id、名称、联系方式 3.调用接口 | 返回状态码200,用户创建成功 |
接口安全
-
绕过验证,比如说用户的联系方式应该是有没有12开头的,但是在进行修改的时候,将这个联系方式改为了12开头的一串数字,后端是否会进行验证,如果改为负数呢?
-
绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用戶,能不能修改成功,我传一个其他的卖家能不能修改成功
-
参数是否加密,比如说我登陆的接口,用戶名和密码是不是加密,如果不加密的话,别人拦截到你的请求,就能获取到你的信息了,加密规则是否容易破解。
-
密码安全规则,密码的复杂程度校验
用例编号 | 用例标题 | 前置操作 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
06 | 绕过联系方式验证测试 | 接口服务正常运行 | 1.修改用户联系方式 2.提交时,将联系方式改为12开头的长度为11位的一串数字 3.调用接口 | 返回状态码400或403,提示联系方式验证失败 | ||
07 | 绕过身份授权测试 | 接口服务正常运行 | 1.使用普通用戶调用修改商品信息接口 2. 调用接口 | 返回状态码403,提示无权限操作 | ||
08 | 参数加密测试 | 接口服务正常运行 | 1.检查登录接口的用戶名和密码是否加密 2. 拦截请求查看数据 | 用戶名和密码已加密,且加密规则难以破解 | ||
09 | 密码复杂度校验测试 | 接口服务正常运行 | 1.注册或修改密码时,输入不符合复杂度要求的密码 2. 调用接口 | 返回状态码400,提示密码不符合安全规则 |
-
异常验证
所谓异常验证,也就是我不按照你接口文档上的要求输入参数,来验证接口对异常情况的校验。比如说必填的参数不填,输入整数类型的,传入字符串类型,长度是10的,传11,总之就是你说怎么来,我就不怎么来,其实也就这三种,必传非必传、参数类型、入参长度。
用例编号 | 用例标题 | 前置操作 | 测试步骤 | 预期结果 | 实际结果 | 测试结果 |
10 | 必填参数缺失测试 | 接口服务正常运行 | 1.不传必填参数(如商品id) 2. 调用接口 | 返回状态码400,提示必填参数缺失 | ||
11 | 参数类型错误测试 | 接口服务正常运行 | 1.传入错误类型的参数(如将整数类型传为字符串) 2. 调用接口 | 返回状态码400,提示参数类型错误 | ||
12 | 参数长度超限测试 | 接口服务正常运行 | 1.传入长度超限的参数(如长度限制为10,传入11) 2. 调用接口 | 返回状态码400,提示参数长度超限 |
结合业务逻辑
结合业务逻辑设计接口测试用例的核心是从业务场景出发,覆盖接口在实际使用中的各种交互场景,确保接口不仅功能正确,更能适配业务流程的合理性。以下是结合业务逻辑设计测试用例的思路和步骤:
-
明确接口在业务中的定位:接口服务于哪个业务场景?是核心流程(如下单、支付)还是辅助流程(如地址校验、库存查询)?
-
梳理接口关联的业务规则:接口调用前后依赖哪些业务状态(如登录状态、库存数量、用户权限)?输出结果会影响哪些后续流程(如扣减库存、生成订单)?
-
覆盖 “正常业务流” 和 “异常业务流”:既要验证接口在合规场景下的正确性,也要模拟实际业务中可能出现的异常(如库存不足、权限不够)。