基于Jmeter的性能测试脚本开发、执行和实时监控
一、前言
1、Jmeter是一款轻量级的性能测试工具。 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。
可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。 可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
2、Jmeter是只是性能测试执行的一个工具。完整的性能过程还包括前期准备、制定方案、准备环境数据、开发脚本、执行、分析/调优、编写报告等内容。
本文重点介绍【场景建模 -> 脚本开发 -> 脚本执行 -> 实时监控】来介绍每个过程可以做的事情。
建议有条件的同学上机操作一把，理论结合实际，上机操作一把能更深入地理解。
二、场景建模
场景建模一般思路如下：
2.1、业务场景建模
业务场景建模的目的是尽可能将不同的业务做拆分解耦，这样能方便压测的实施以及性能瓶颈的分析监控。可以从以下几个角度入手：
- 【业务优先级】 从业务出发，梳理出核心业务场景和场景涉及的接口
- 【调用频率】 从日志出发，统计接口调用频率Top10/Top50的接口
- 【特殊业务场景】 秒杀、订单积分同步接口
统计出一批业务场景或接口后，可以将其按
- 【读】和【写】分类： 【读】为查询数据的操作（如查询商品、查询优惠券、查询积分），接口之间是并发的。
- 【写】为更新数据的操作（如查询商品->下单->支付），接口之间有上下文依赖，串行的。
PS：对用例/接口编号，有助于后续的统计、出报告梳理出的【压测场景列表】内容包括场景分组、接口名称、url地址、请求参数等信息，如：
2.2、压测场景建模
针对不同的业务场景，经过分析和建模后，会选择不同的测试策略。
常用的策略有：
- 负载测试：不断增加负载等来发现系统中所存在的性能问题。
- 压力测试：饱和状态下持续一段时间，来发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患。
- 并发测试：多个用户并发对一个模块或操作加压
- 配置测试：对软硬件调整，找出最佳状态
- 可靠性测试：中强度压力，持续运行一段时间，来发现系统稳定性的隐患
如抽奖抢券秒杀场景，就采用并发测试以及超卖验证等测试策略。 考虑到业务配比的情况，我们还需要进行单接口的基准测试以及单机混合场景容量测试。
核心业务流程，其特性要求系统具备高可用和稳定性，那么测试策略就需要采用高可用测试和稳定性测试。
产品中心压测环境执行标准：
2.3、数据场景建模
数据场景建模，很多时候往往被忽视，但实际上数据场景建模更加重要。如果测试过程中所采用的数据不完整不准确，那么测试结果往往出现较大的偏差。关于测试所需数据，可参考如下几点：
| 数据信息 | 说明 |
| 限制条件 | 用户操作权限、数据引用次数、数据过期设定（次数、绝对时间） |
| 数据量 | 实际生产环境的数据量为多少，在性能测试环境如何等量代换 |
| 数据类型 | 基础数据、热点数据、缓存数据、特殊数据 |
| 数据特点 | 是否可以复用、是否具有唯一性、自增、加密、拼接、转义等 |
| 准备方式 | copy真实环境数据、预埋铺底数据、脱敏生成数据 |
| 隔离方案 | 如何避免测试数据的污染？影子库？环境隔离？标记区分？ |
基础数据：也可以称之为铺底数据，铺底数据目的是让性能测试环境与线上保持一致（至少数量级一致），再结合线上数据增长率（半年&一年的数据量级），确认预埋数据量级及预埋方式；
涉及到压测时需要校验的数据，需要在铺底的时候就要精细化的设计，包括数据大小，数量，分布等。
热点数据：需要了解被测接口的实现逻辑，确认以下信息：
是否有热点数据相关的操作：比如说所有用户秒杀同一件商品；
不同类型数据处理逻辑有差异时，需通过测试数据多样化提高性能测试代码覆盖率；
缓存数据：要确认是否有缓存，缓存大小为多少（排除大key，一般来说142W的key占Redis一个G的内存）；
秒杀抢购相关数据，一般来说都是进行队列处理，将该类型数据放入缓存中进行处理来应对高并发。
三、脚本开发
Jmeter有提供UI界面进行脚本开发和调试，这里主要是介绍配置过程中可以用到的几个插件：
- 用【用户自定义变量】配置不同环境的网关、端口、token参数，以便压测时可以切换
- 用【同步定时器】模拟秒杀场景
- 用【固定定时器】或者【高斯随机定时器】模拟用户思考时间
- 用【步进线程组】模拟逐步施压的场景
- 用【3 Basic Graphs】生成并发线程图、RT图、TPS图
- 用【后端监听器】发送实时结果去监控平台（后面会说明）
- 用【内置函数】参数化入参（如${__time(,)}，${__UUID} )
3.1、利用查看结果树，保存失败的响应到XML文件
配置好后可以记录每个断言失败的请求的传参和响应，极大地方便问题的定位，且生成的xml文件按时间命名：
3.2、用【同步定时器】模拟秒杀场景
3.3、用【步进线程组】模拟逐步施压的场景
3.4、用【步进线程组】模拟逐步施压的场景
3.5、Jmeter脚本执行策略
可以遵循以下原则：
- 调试脚本用界面模式
- 执行脚本用命令行模式（单机）或远程启动模式（集群）
界面模式：
执行模式：
# 单机：
jmeter -n -t script.jmx -l script.jtl # 执行script.jmx文件，生成script.jtl日志文件
jmeter -g script.jtl -o script # 将script.jtl日志文件转换为html报告
# 集群：
jmeter -n -t script.jmx -l script.jtl -R 192.168.31.10:1099,192.168.31.11:1099,192.168.31.12:1099
jmeter -g script.jtl -o script # 将script.jtl日志文件转换为html报告
但为了执行和管理方便，我们建立一个工程，让其自动生成执行命令，工程架构为：
script
├─run.sh # 生成命令的脚本
├─MPC # Jmeter脚本目录，可以自定义名字，可以多个
│ └─config.txt # 配置文件
│ └─scriptA.jmx # 脚本
├─BOC #
│ └─config.txt #
│ └─scriptB.jmx #
├─iService #
│ └─config.txt #
│ └─scriptC.jmx #
└─result #
├─MPC # 存放结果的目录，对应脚本目录名
├─BOC #
└─iService #
将jmx脚本放到script/MPC下，同时新增一个config.txt，内容为脚本的名字【scriptA.jmx】：
$ cat MPC/config.txt
scriptA.jmx
在script目录下执行【run.sh MPC】即可生成执行命令：
$ ./run.sh MPC
-----------------------------------------------------
- Script need to run:
running [MPC/scriptA.jmx]
-----------------------------------------------------
-----------------------------------------------------
in [MPC/script.jmx]
-----------------------------------------------------
jmeter -n -t MPC/scriptA.jmx -l ./script/result/MPC/scriptA.jtl -e -o ./script/result/MPC/scriptA
-----------------------------------------------------
将命令复制到终端上运行：
$ jmeter -n -t MPC/scriptA.jmx -l ./result/MPC/scriptA.jtl -e -o ./result/MPC/scriptA
Creating summariser <summary>
Created the tree successfully using MPC/scriptA.jmx
Starting the test @ Thu Aug 29 15:26:32 CST 2019 (1567063592980)
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445
... ...
等其执行完就可以直接拿结果到本地。
四、实时监控
性能测试过程中要监控的指标很多，大体可以分为：
如果采用的云服务器（比如阿里云），云厂商都提供了监控大盘以及各种监控服务（比如阿里云的APM、ARMS、AHAS）。
如果是自建服务机房，可以借助运维搭建的监控体系，比如全链路追踪（pinpoint、cat、zipkin、skywalking），专业的监控工具比如nmon、zabbix等。
测试指标的监控，可以搭建基于开源组件的Grafana+InfluxDB+Jmeter，nmon2influxdb，或者ELK等监控体系。
参考资料：https://www.cnblogs.com/imyalost/p/11044709.html
且JMeter做性能测试，很难及时察看压测过程中应用的性能状况，总是需要等到测试完成后去看报告。
如果是长时间压测，比如压测1~2天，那就更烦人了。
这里可以借助Grafana+InfluxDB+Jmeter的组合套件，实现压测过程的实时监控：
同时，我们借助Prometheus+Grafana工具实现系统资源监控：
Redis监控：
数据库监控：
正文到此结束
- 本文标签： jmeter prometheus 性能测试
- 版权声明： 本站原创文章，于2021年09月14日由小蜜蜂社区发布，转载请注明出处
热门推荐
相关文章
近期评论
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 移动APP安全测试用例指南
-
来自： Android多设备自动化测试实践
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
