接口测试学习

陈小吨

已于 2024-09-18 16:04:17 修改

阅读量929

点赞数 18

分类专栏：测试工程师文章标签：学习

于 2024-09-13 11:37:20 首次发布

本文链接：https://blog.csdn.net/m0_46391590/article/details/142200928

版权

测试工程师专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、接口测试基础

1.相关概念

1.1 接口介绍

软件接口的由来

软件系统中，前端和后端是两大重要组成部分
前端主要由于与用户交互，用户通过前端页面，操作–>查看结果显示
后端主要用于处理数据，用户提交了数据–>处理好逻辑–>与数据库交互

接口大体分类

硬件接口（USB口/网口/VGA视频接口/HDMI接口）
软件接口（软件测试只关注软件接口）

概念
有规范，且用于通信的管道

作用

数据交互

软件接口的分类

按照客户端划分
- web接口
- APP接口
- 小程序接口
按照协议划分
- HTTP接口
- TCP接口
- socket接口
- WebService接口
按开发人员归属划分
- 自研接口
- 第三方接口

面试题

什么是接口[1]

具备一定规则通信通道
本质上就是能够被前端所访问的后端的函数

1.2接口测试介绍

为什么要学习接口测试
场景
某软件可以提供注册功能，并且已经通过了功能测试，但是项目上线一段时间后，却发现注册了大量垃圾用户，比如:有的账号或密码超长/为空/格式错误，请问为什么？

要解决上述问题，必须得学习接口测试

概念
绕过前端，直接测试后端接口实现是否符合规则
作用

发现程序的安全隐患
提高效率
定位bug

面试题

接口测试怎么定位bug的？[2]

确认bug后，对后端做接口测试，如果没问题，那么该bug是前端问题
如果后端有问题，不能判断前端是否也存在问题，可以在后端修复后，再从界面上进行验证
- 验证后如果bug消失了，那么确认原来的问题就是后端引起的
- 验证后，如果bug还存在，那么前端也有问题，需要修复

接口测试三要素

定位接口资源（通过路径找到接口）
提交测试数据
判断响应结果

接口测试分类

按测试目的进行划分
- 接口的功能测试
- 接口的回归测试
- 也可以有接口冒烟测试
按照是否自动化进行划分
- 接口（手工）测试
- 接口自动化测试

2.restful风格

2.1概述

定义
restful是一种接口设计风格，约束了接口实现的规范

如果使用restful风格来约束，该如何定义用户的增删改查的接口路径

路径统一使用/user
用户请求方式区分操作get查询，post新增，put修改，delete删除
除此之外，restful 风格还约束了响应状态码和响应数据

作用
提高了API文档的易读性

2.2 三要素

既然接口测试关注三要素，那么API文档中对接口的描述必须交代清楚三要素

描述:实现用户登录功能
三要素：

接口资源
测试数据
响应结果

2.2.1 要素一：接口资源

组成

URL（统一资源定位符）
- 协议：常见的有http/https等
- IP地址：服务器的IP地址
- 端口：http默认80 https默认443
- 路径：通过路径，可以找到对应的接口
请求方式（数据的提交方式）
- 常见的实现有：get，post，put，delete，分别对应查，增，改，删四种操作

描述:实现用户登录功能
三要素：

URL：http:www.xxx.com/login
请求数据：post
测试数据
响应结果

面试题

get和post比较有什么区别?[3]

提交方式不同，get提交的数据显示在地址栏，post是隐式的提交数据，post更安全
可提交的数据量不同，get提交的数据量有限制，而post没有
执行效率不同，get的执行效率比post稍高

2.2.2 要素二：测试数据

两种常见的提交格式

键值对
JSON格式（类似于Python的字典）

举例

键值对

格式： username=hhh&password=123&aihao=chuiniu&aihao=xuexi

JSON

格式：
{
“username”:“hhh”,
“password”:“123”,
“aihao”:[“chuiniu”,“xuexi”]
}

2.2.3 要素三：响应结果

两大关注点

状态码
- 1xx：请求正常，但是没有响应，只有在试验状态下
- 2xx：请求正常，响应正常，比如：200查询成功；201新增或者修改的操作是成功的；204删除成功
- 3xx：以其他的方式获取相应，比如：302重定向；304取本地的缓存
- 4xx：浏览器端异常，比如401未授权；403拒绝访问；404资源路径有误
- 5xx：服务器端异常，比如：500服务器运行异常；502网关异常；504网关超时
响应体
- 最常见的响应体是JSON格式的数据，如{ "code":0,"data":[]"msg":"登录成功"}

面试题

常用的状态码有哪些？[3]

200 一般是代表查询成功；201代表新增或修改成功；204代表删除成功
302代表重定向；304代表拒绝访问；404代表路径错误
500代表服务器异常，504网关超时

2.2.4小结

接口虽多，但是不外乎增删改查四种类型并且每种类型的实现也是由三要素组成

请求类型	要素一	要素二	要素三
查	URL+get	键值对	状态码：200；响应体：单条或多条数据
增	URL+post	键值对/JSON	状态码：201；响应体：新增后的数据
改	URL+put	键值对/JSON	状态码：201；响应体：修改后的数据
删	URL+delete	键值对	状态码：204；响应体：删除后的数据

请求行	URL，请求方式	相应行	http协议版本号，状态码
请求头	接收文件类型，支持语言，浏览器信息	响应头	web服务器信息；相应内容的类型；响应内容的长度
请求体	请求的参数（测试数据）	响应体	http响应的具体数据

面试题

http接口有哪些类型？[1]

操作的类型主要是增删改查四种
查询类型的接口一般对应get这种请求方式
新增post；修改用put；删除用delete

请求头中和响应头中有哪些常用的字段，以及分别是什么作用？[2]

请求头
- accept 表示浏览器可以接受的响应类型的数据
  - accept-encoding 用于指定压缩方法，
  - accept-language 申明接收的语言
- content-type 客户端告诉服务器，我们发送的数据类型，方便服务器去解析数据
- user-agent 告诉服务器，客户端的操作系统和浏览器名称及版本
- cookie 用来存储一写用户信息，以便于服务器辨别用户身份
响应头
- content-length 响应消息的长度
- server服务器信息（如Apache/1.327 /Linux）
- set-cookie 告诉客户端，把什么信息设置进cookie

http和https的区别[3]
- 默认端口不同，前者是80，后者是443
- 安全性不同，前者是明文传输，后者是ssl加密的，后者更安全
- http不需要证书，https协议需要到CA机构申请证书需要一定的费用

3.接口测试环境

3.1环境分析

项目（后端），按理由Java编写，需要编译之后才能运行，依赖的内容有：

JDK
ide 开发软件
Tomcat
MySQL

测试工具

浏览器
postman
jmeter

3.2项目部署和运行

后端
- 在jar文件所在目录，运行java -jar xxx.jar
数据库
- 创建一个数据库

3.3测试工具

浏览器，本身只能帮助测试get方式的请求（不算插件）
postman：主流工具之一功能强大
jmeter:开源，支持多种协议，免安装，可做性能测试

4.jmeter基础

4.1 基本使用流程

需求：使用jmeter访问项目的查询全部区域信息

组件与原件

组件：是jmeter中的一些功能点实现
元件：对组件按照性质归类分组，作用：方便管理组件

4.2 组件-线程组

概念

进程：正在运行的程序
程序启动，进程创建，程序关闭，进程释放，反之进程释放，程序关闭
线程：程序中的执行线索（路径）
游戏中的每个角色
线程组：对线程分类归组

层级关系：
进程>线程组>线程 ==一个进程可以包含多个线程组，一个线程组可以包含多个线程

并发执行：多个线程同时执行 == 多部电影同时下载 == 线程的启动顺序和结束顺序不一定一致
顺序执行：多个线程按照顺序依次执行 ===电影下载后播放 ==线程的启动顺序和结束顺序一定一致

4.2.5特殊线程组

setUp线程组：最先执行的线程组，一般用于初始化操作
tearDown线程组：最后执行的线程组，一般用于资源销毁

5.测试流程扩展

二、单接口测试

接口功能测试

1.概念

含义
模拟用户的多样性操作，查看实际结果是否符合预期
原则【背下来】
- 设计各种正向+逆向的测试用例
- 接口覆盖率达到100%

2.测试流程

根据API文档，编写测试计划
根据API文档设计接口功能测试用例，并发起评审
使用工具，编写测试脚本，进行测试用例
输出测试报告

2.1 编写测试计划

编写测试计划的核心目的是分配资源
在这里插入图片描述

2.2 设计测试用例

分析测试点

面试题

测试用例
如何写测试接口测试用例？[3] 一般写多少条测试用例[1]

单个参数类型，长度
- 各种类型（字符串，数字，特殊字符等）
- 各种长度，注意长度边界和超长问题
必填项
- 必填参数全传，看是否返回正确结果
- 单个必填项不传，看是否请求失败
参数组合
- 正向：一条测试用例尽量覆盖多个测试点
- 逆向：逆向的测试点，每个测试点都是一条测试用例
接口安全
- 加密问题，敏感数据是否有加密，加密规则是否复杂
- 权限问题，绕过身份认证，是否能访问接口，没有授权的情况，能不能访问接口

一个接口对应多少条测试用例？
一般一个参数对应的逆向的测试点大概有3,4个，多个参数*n
实际工作中，如果非要写测试用例的话，一般一个有4,5个参数的接口，测试用例大概15-20条
（实际工作中，时间比较紧张，接口的功能测试一般是不需要写测试用例的）

2.3 编写测试脚本

面试题

jmeter 中如何使用csv,有什么实际的应用场景[1]

jmeter中使用csv数据文件比较简单，有个组件叫csv数据文件设置，可以引入csv并使用csv内的数据
一般使用csv数据文件是在需要做接口功能测试时，因为测试用例比较多，我们把测试数据提前放到csv文件中

2.4 输出测试报告

可以视为接口功能验证表

参数化小结

1.概述

目前
已经用到的参数化方式

用户定义的变量
- 提前定义变量，需要时引用，修改方便，常用于换将参数配置
csv数据文件设置
- 接口功能测试，多条测试用例，动态读取数据

参数化概念
将静态的数据转换为动态数据的过程，用于动态的生成，设置或导入数据

作用

高效
提高脚本的编写质量，可维护性更好

2.实现方式介绍

用户定义的变量
csv数据文件设置
函数

三者互补，重点是csv数据文件设置

3.函数

需求
访问查询area接口20次，在结果树为请求添加标号

常用函数介绍

counter()–>计数器，参数1：TURE | FASLE
- TURE，一个线程对应一个单独的计数器
- FALSE，所有线程共用一个计数器
random()–>随机数，参数1：最小值，参数2：最大值
time()–>时间参数，参数1：格式化时间yyyy/MM/dd HH:mm:ss

断言

概念
程序代替人工，判断响应结果是否符合预期
作用

高效
安全

常用断言方式
响应断言，判断相应数据中包含预期结果

如果包含，断言成功（说明本条测试用例执行是通过的）
如果不包含，断言失败（说明本条测试用例是不通过的）

扩展

JSON表达式中，$是根节点 .是子节点
如果是数组类型数据，用[下标]来进行选择，下标是从0开始的

连接数据库

1.原理

jmeter连接数据库：jmeter --> 驱动 --> 数据库

应用场景

比如测试新增一个area信心的接口，可以去数据库查看数据是否新增成功，用于断言
比如执行测试用例后，需要清除垃圾数据，就需要连接数据库，并执行删除表数据的操作，用于销毁测试数据

注意
JDBC请求中，返回的数据是一个列表，如果你定义的变量名是name，那么引用的结果的方式为${name_N}

例，引用方式为${name_1}

三、多接口测试

1.依赖登录的接口测试

常见的接口回归测试的策略

基于模块，回归每个模块的核心接口
- 接口覆盖率高
- 工作量较大，项目迭代更安全
基于业务流，回归核心业务流程
- 接口覆盖率低
- 工作量较少，项目迭代更高效
  多接口测试的原则
接口覆盖率没必要100%，只需要测试重要的接口
只需要设计正向的测试用例
脚本需要重复执行

1.1项目和技术介绍

关联得概念：提取上游接口的响应部分，在请求下游接口时提交
关联的实现思路：提取上游的部分响应，在请求下游接口时引用
作用：在不同接口间传递数据

1.2 关联

1.3跨线程组关联

需求
在之前案例的基础上，把强求A和请求B设置到不同的线程组，在实行一次

结果：请求B接口失败，无法引用token
原因：变量作用域不对
解决：将局部变量转换成全局变量

步骤

通过setproperty函数建立局部变量和全部变量的对应关系
通过BeanShell取样器，执行setProperty函数，生成全局变量（属性）
下游线程通过property函数引用全局变量即可

如何查看jmeter中的全局变量？
可以通过一个辅助组件属性显示：测试计划–>添加–>非测试元件–>属性显示

2.基于模块的多接口测试

业务概述
业务指的是谁需要处理什么事情

软件中华的业务指的是谁可以使用软件的什么功能，处理什么实际工作内容
业务流额度含义
指的是业务实现所经历整个流程，也就是要实现某个业务，需要操作的步骤
业务流分析思路

对软件价值有整体认知
找出所有角色，以及每个角色能使用到的哪些功能

3.基于业务流的多接口测试

业务概述
业务指的是谁需要处理什么事情

软件中的业务指的是谁可以使用软件的什么功能，处理什么实际内容
业务流的含义
指的是业务实现所需要经历整个流程，也就是要实现某个业务，需要操作的步骤
业务流分析思路

对软件价值有整体认知
找出所有角色，以及每个角色能使用到哪些功能

jmeter小结

文件上传问题

面试题

接口测试过程中，遇到文件上传的操作，怎么处理？[2]

文件上传接口和其他接口一样，无非是在传参时需要注意一下类型问题
jmeter中有一个单独的窗口叫文件上传，填写对应的参数名和文件路径后只需要修改一下MIME类型即可
如传的图片，填写image类型即可，如传的是视频，填写video类型即可

需要加密的接口测试

此处说的不是接口具备加密功能，而是为了安全考虑。请求的某些参数需要加密

如，最常见的，登录密码需要加密
如，支付信息需要加密

常见加密方式了解

MD5：一种简单的哈希算法，将任意长度数据通过算法生成一个固定长度的值，速度快，但安全性较差
SHA-256：比MD5更安全但也有安全隐患，比之前安全的是SHA-256加盐
此外还有AES，RSA等加密算法

面试题

遇到需要加密的接口该如何测试？[2]

接口是否加密不影响我们的测试方法和流程
如果遇到传参需要加密的接口，我会首先确认加密方式
- 如果是简单的MD5加密，那么jmeter内置函数就可以是实现
- 如果是256加盐的这种复杂的加密方式，则会让开发提供加密函数，我直接在Bean Shell中调用即可

jmeter中的Bean Shell组件有没有用过，什么时候用的[1]

当然
最常见的使用场景是用来执行jmeter的内置函数，如在跨线程组关联中需要把局部变量设置为全局属性
另外在测试需要加密的接口中也会用到，Bean Shell来执行数据的加解密操作

第三方接口

应用场景
本公司产品中，某些功能需要依赖第三方提供的服务，如支付，地图，快递/物流查询等服务

面试题

依赖第三方接口的接口测试怎么做

接口中含有对第三方接口的请求，种种情况很普通
从黑盒角度对接口进行测试和其他自研接口一样，只需要做好字段验证，业务逻辑和异常的验证即可
只不过在定位bug时，需要定位清楚属于调用错误还是第三方接口的bug
- 如果是自研代码错误，则提交给本公司开发进行修复
- 如果是第三方接口本身的问题，则考虑反馈（对方更新后，再重新测试）或更换第三方服务

作用域

概念
作用范围，在jmeter 中专指当前组件对哪些范围的取样器生效

分类

取样器自身：无所谓作用域，在作用域概念中作为参考物存在
大多数组件：如查看结果数，http信息头管理器，csv数据文件设置，JSON提取器
- 测试计划下：对所有线程组中的所有取样器生效
- 线程组下：对当前线程组中的所有取样器生效
- 取样器下：对当前取样器生效

执行顺序

在这里插入图片描述

图形化测试报告

jmeter支持以图形化的方式显示脚本的运行结果

应用场景

对测试报告有更高的要求时
执行性能测试时，命令执行的方式比图形化界面占用更少的资源

在这里插入图片描述

面试题

接口测试报告包含哪些重点内容[1]

测试结果
缺陷汇总和分析
风险评估
工作总结和改进

接口测试是怎么做的？（接口测试流程）[3]

首先确认需求和分工
拿API文档，了解具体接口的业务，URL，请求方式，入参的各个字段，以及响应数据
设计接口测试用例，并组织用例评审
- 如果是功能测试：要求100%覆盖新接口，每个接口设计正向+逆向的测试用例
- 如果是回归测试：不要100%覆盖全接口，只要求覆盖重要的和使用频率高的接口，每个接口只需要1条正向用例，最后还要求脚本能重复执行
用jmeter编写测试脚本，执行，并查看结果
产出测试报告