JMeter接口性能测试从入门到精通

前言：

本文主要介绍了如何利用jmter进行接口的性能测试

1.在测试计划中添加线程组

1.1.线程组界面中元素含义

如果点击循环次数为永远：

2.添加HTTP取样器

2.1.填写登录接口的各个参数

2.2.在线程组下面增加查看结果树

请求成功的情况：

请求失败的情况：

我们注意到在同一个系统中，协议+IP+端口号是不会发生改变的，所以我们需要添加HTTP请求默认值

3.添加HTTP请求默认值

当取样器中存在未配置的选项，会直接去HTTP请求默认值配置中去取；取样器中配置了的选线不会去http请求默认值配置中取

当我们在测试列表页接口的时候，发生了错误，因为我们没有能获取到用户的登录信息，直接跳过登录进入列表页，这肯定是不行的，因此我们还需要给HTTP请求添加请求头数据

4.给HTTP请求添加请求头数据

注意左侧目录跟二叉树结构类似：

5.Json提取器

接口响应成功，通过提取返回值对应字段，可用于其他接口的参数配置

5.1.添加Json提取器

Json操作符参考：

5.2.添加Json配置

5.3.配置Json提取的参数

注意变量名要用 ${变量名} 的格式！

当然我们也可以输入表达式，点击右侧的test按钮检查json提取表达式写的是否正确 

注意要先调整成JSON Path Tester格式 

如何提取登录接口返回值里的data数据，作为列表页接口的请求信息呢？

如果多个接口中都有符合条件的json提取字段，则会发生覆盖，那我们如何只提取登录界面的token呢？根据目录的主从关系！

想象场景:有两百个详情页接口，每个接口都要用到写死的id值，而这个id值后续可能需要修改---最好的方式用批量修改的方式

6.用户定义变量

一次修改，终身受益！

解决bug

 当出现问题时，先放在postman上面进行运行看看正确情况，在jemter上不好发现错误

添加博客时，出现了内部的错误

将请求的content-type类型的数据修改之后，成功了！

7.JSON断言

接口发送请求成功，响应码为200并不能完全代表接口请求成功，我们更多需要关注接口响应数据是否符合预期。

7.1.添加断言

7.2.添加JSON配置

注意:

1. 若不选Additionally assert value，表示添加断言值，则可用来判断字段是否存在
2. 选择Additionallyassert value，则必须添加Expected Value期望的断言值
3. 若不选Match as regular expression正则匹配，则Expected Value必须填写完整，少一个字符都会导致断言失败
4. 若选择Match as regular expression正则匹配，则Expected Value可以仅写上部分关键词即可断言成功

正则表达式的使用方法：

8.同步定时器（集合点）

我们如果不手动添加同步定时器，那么多线程是达不到同步的效果的，那么我们创建多线程就失去了意义。

如下图：配置了五个线程，这五个线程是陆陆续续的完成了测试计划，谁先准备好谁先执行

所以我们要添加同步计时器：

这下我们测试多线程就完美实现了同步的效果！

TIP：

模拟用户组的数量不能超过线程组里配置的线程数 当准备好的线程数>=配置数量，就直接发送请求当配置的数量小干线程数时，最好把循环打开，避免最后一次为准备好的线程数量达不到并发数

8.CSV数据文件设置

以登陆接口为例，当我们执行登陆接口的性能测试时，手动配置了用户名和密码为固定的username和password，然而实际使用中不可能只有一个用户登陆，为了模拟更真实的登录环境，我们需要提供更多的用户username和password来实现登录操作、

添加方式:线程组--配置元件--CSV数据文件设置

操作步骤：

8.1.CSV数据文件设置

• 文件名:填写csv文件的路径。建议使用绝对路径。
• 文件编码:UTF-8
• 变量名称:从csv数据文件中读起的数据需要保存到的变量名。有多个变量时用逗号分隔
• 是否忽略首行:是否从csv数据文件第一行开始读取。
• 分隔符:要求与csv数据文件中多列的分隔符一致
• 遇到文件结束符再次循环:若选择为True当数据不够的时候会从头取。若选择False，则需要勾选下面的配置，遇到文件结束符停止线程，这里如果不勾选，请求将会报错。

此时就需要根据我们自己写的变量名称进行赋值，如下图：

测试效果：

两者登录的账号密码各不相同

8.2.编写test.csv文件

注意一定要这样转为csv文件，不能直接改后缀，不然会出现未定义的错误！

8.3.修改登陆接口及其他涉及到username和password获取的参数

8.4.修改线程组中线程数，使得每次取到的username和password都不⼀样

9.HTTP Cookie管理器

添加了HTTP Cookie管理器后，会自动存储并发送Cookie

10.添加梯度压测线程组

10.1.解析梯度压测线程组

注意要先将项目里面的内容拷贝一份！

• This group will start:启动多少个线程，同线程组中的线程数
• First,wait for:等待多少秒才开始压测，一般默认为0
• Then start:一开始有多少个线程数，一般默认为0
• Next,add:下一次增加多少个线程数
• threads every:当前运行多长时间后再次启动线程,即每一次线程启动完成之后的的持续时间:
• using ramp-up:启动线程的时间;若设置为5秒,表示每次启动线程都持续5秒、
• thenhold loadfor:线程全部启动完之后持续运行多长时间
• finally,stop/threadsevery:多长时间释放多少个线程;若设置为5个和1秒，表示持续负载结束之后每1秒钟释放5个线程

进一步解读：

解读:每隔3秒启动5个线程，这5个线程必须在1秒之内完成准备

结束方式：

还需要吞吐量和响应时间 都需要添加进来

还有活跃线程的状态

11.常见监听器

11.1.聚合报告

从聚合报告可以看到性能测试过程中整体的数据变化，

11.2. Response Times Over Time

Response Times Over Time主要用于监听整个事务运行期间的响应时间。在测试过程中，它可以帮助测试人员观察并分析响应时间的实时平均值以及整体响应时间的走向。通过这一监听器，测试人员能够更直观地了解系统在不同时间点的响应性能，从而发现可能存在的性能问题或瓶颈。

Response Times Over Time的图形展示中，横坐标通常代表运行时间，而纵坐标则代表响应时间(单位是毫秒)。测试人员可以根据图形中的趋势线来判断响应时间的稳定性以及是否存在大的波动。例如，如果响应时间在某个时间点突然增加，这可能意味着系统在该时间点遇到了性能问题。

11.3.Transactions per Second(TPS)

JMeter中的Transactions per Second(TPS)监听器是一个用于分析系统吞吐量的重要工具。TPS即每秒事务数，表示一个客户机向服务器发送请求后服务器做出反应的过程。这个指标反映了系统在同一时间内处理业务的最大能力。TPS值越高，说明系统的处理能力越强。

在使用TPS监听器时，横坐标通常代表运行时间，而纵坐标则代表TPS值。通过监听器展示的图表，可以清晰地看到TPS值随时间的变化情况。在图表中，红色通常表示通过的TPS，而绿色可能表示失败的TPS。这有助于我们快速识别系统性能的变化和瓶颈。

12.测试报告

JMeter测试报告是一个全面而详细的文档，它提供了关于测试执行结果的详细信息，帮助用户全面评估系统的性能并进行性能优化。 生成性能测试报告的命令:

jmeter -n -t 脚本文件 -l ⽇志文件 -e -o 目录 -n ： 无图形化运行 -t ： 被运行的脚本 -l ： 将运行信息写入日志文件，后缀为jtl的日志文件6-e ： 生成测试报告 -o ： 指定报告输出目录

 最后生成测试报告的时候，先要进入到测试报告的那个目录

打开报告 发现全部通过！

双击index.html文件，界面展示如下：

13.性能分析

通过三大指标来分析性能问题

13.1 响应时间

如果响应时间超过了要求，代表系统到了瓶颈注意事项:分析在多少线程的情况下发生了超标 响应时间变化的原因: 系统不稳定，有时快有时慢 随着并发压力变大而慢慢变慢，响应时间变高

13.2 错误率(可靠性)

高并发场景下，系统是否能够正常处理业务要求:99.99%可靠，99.9999% 错误率高的原因， 接口请求错误 服务器无法继续处理，达到了瓶颈(代码写的不好，内存泄漏、硬件资源等)后端系统限流(系统里配置了不能超过多少并发)、熔断、降级什么是熔断、降级?

熔断:防止系统因某个服务的故障而整体崩溃。当电商平台上用户支付时，收银台发现某个支付渠道，如微信支付失败率突增，超时严重，那么就可以临时把这个支付方式熔断掉降级:主动关闭一些非核心功能，以确保核心功能的正常运行。某次腾讯视频挂了的时候，用户名称默认显示腾讯用户，这也是一种降级方式，用兜底名称做展示

13.3 吞吐量

吞吐量越大，性能越好，吞吐量相对稳定或者变低，可能系统达到了性能瓶颈吞吐量变化规律: 波动很大:代表系统性能不稳定 慢慢变高，再趋于稳定:和并发量强相关。如果并发量小于吞吐量，慢慢增大并发量，吞吐量也会随之增加 慢慢变低，并发量也减少了:要么说明性能测试要结束了，并发减少;也可能是系统变的卡顿，从而导致响应时间变慢，导致单个线程发起的并发量变少

TIP：解决jmeter乱码问题：

通过后置处理器BeanShell PostProcessor

        1）在线程组中添加后置处理器：BeanShell PostProcessor

        2）输入prev.setDataEncoding("utf-8")，目的是修改响应数据编码格式为utf-8

        3）保存脚本再次执行jmeter即可。

用后置处理器修改响应编码的方式更方便一些，不用改文件，也不用重启jmeter。

所以性能测试的拐点如何测试？

14.HTTP请求中post和get有什么区别？

1. 语义和使用场景

• GET:
  • 语义: 用于请求从指定的资源获取数据。
  • 用途: 常用于请求服务器发送某个资源，例如请求一个网页、图片或其他文件。
  • 幂等性: GET请求被认为是幂等的，即多次执行同一请求对资源状态没有副作用。
  • 缓存: GET请求的结果可以被缓存。
  • 参数传递: 请求参数附加在URL之后，以查询字符串的形式传递，例如 http://example.com/resource?param1=value1&param2=value2。
• POST:
  • 语义: 用于向指定的资源提交数据，请求服务器进行处理（例如创建/更新资源）。
  • 用途: 常用于提交表单数据、上传文件等操作。
  • 幂等性: POST请求通常不是幂等的，即多次执行同一请求可能会对资源状态产生副作用。
  • 缓存: POST请求的结果一般不被缓存。
  • 参数传递: 请求参数包含在请求体中，而不是URL中。

2. 数据传输

• GET:
  • 数据传输量有限制（由于URL长度限制，不同浏览器和服务器有不同限制）。
  • 数据暴露在URL中，不适合传输敏感信息。
• POST:
  • 没有数据大小的严格限制（虽然服务器可能设置了自己的限制）。
  • 数据在请求体中传输，相对更安全，适合传输敏感信息（但仍需注意使用HTTPS来保证安全性）。

3. 浏览器行为

• GET:
  • 浏览器会将GET请求的结果缓存起来，并在用户尝试重新加载页面时可能直接从缓存中读取数据。
  • 用户可以将GET请求的URL收藏为书签。
• POST:
  • 浏览器通常不会缓存POST请求的结果。
  • 用户无法直接将POST请求的URL收藏为书签。

4. IDEMPOTENCY（幂等性）

• GET 是幂等的，即多次执行同一GET请求对服务器状态没有副作用。
• POST 通常不是幂等的，多次执行同一POST请求可能会改变服务器状态。