性能测试场景设计
简介
性能测试过程中,目标不同,需要选择的性能测试场景也有很大的差异,今天以 JMeter 为例,简单说说性能测试、负载测试、压力测试三大场景到底都是什么怎么个含义
介绍
市面上有很多的性能测试工具 各有千秋，后面我们将采用 JMeter 进行
| 工具名称 | 特点 |
|---|---|
| jmeter | 基于 ==java== 开发的开源,多线程工具，学习成本低,能做接口测试、接口自动化、性能测试、需要做jmeter第三方依赖扩展 |
| loadrunner | 商业 ==loadrunner== 要付费购买并发用户数,费用高，脚本是c语言,性能比较好,性能指标值比较准确,性能测试的标杆 |
| wrk | 快速响应性能测试工具,但是,不能做很复杂事情 安装服务后用过命令行执行 |
| ab | 快速响应性能测试工具,但是,不能做很复杂事情 安装服务后用过命令行执行 |
| ngrinder | 做性能侧开平台、性能工程的平台groovy（java衍生）、 jython（java+python衍生）运行时依赖jre jdk1.8+ 环境 ngrinder 版本选3.x以上 |
| python+locust | python语言进行性能测试，基于协程运行 |
环境准备
- cpu主频3Ghz 大概能启动3000个并发用户数 在实际运行中 http协议协议簇 大概一台电脑在1500-2000并发用户数 过多会报错
环境准备
插件管理器安装
将下载的 ==jmeter-plugins-manager-1.6.jar== 文件复制jmeter安装目录下的 ==/lib/ext== 文件夹下 重启一下jmeter（如果移动前已启动）
jpjc插件安装
下载jdbc插件 安装可能会失败再次点击 ==apply changes and restat jmeter== 因为插件托管到国外导致的网络原因 安装成功后会自动重启jmeter 如果一直失败 尝试手动导入
验证插件是否安装成功
正常情况下只要上面步骤安装没有报错 自动重启了那么就表示已经安装成功了，接下来也可以进行一些查看来验证
验证的方式 可以去==lib\lib目录下查看== 是否有下载出来文件 或者在对应的 ==菜单中是否有对应选项==
三大场景设计
前提提示
每次执行执行性能测试前确保 CPU 1分钟内的负载值尽量为不高于1的小数，越小越好
性能测试遵循准则 ==缓起步 慢结束== 拿生活中举例 在汽车驾驶中要缓慢的起步不要太猛，刹车的时候可以踩快一点刹车
负载测试
概念
逐步增加并发用户数，探测服务器最大的拐点区间，再次对区间进行性能测试找出相对准确的最大并发用户数 阶梯式场景
基础配置说明
Tish group will start【 100 】 threads：这个线程组最终要启动100个线程
First，wait for 【 0 】 seconds：启动第一个线程需要等待0秒
Then start 【 0 】threads：从第0个线程开始
Next，add 【 10 】 threads every 【30】seconds using ramp-up【5】seconds：在5秒内，增加10个线程，然后持续运行30秒
Then hold load for【60】seconds：线程都启动完后持续运行60秒
Finally，stop【5】 threads every【1】seconds：当持续60秒运行完毕后每一秒停止5个线程
脚本转换
将普通的功能测试脚本转换为负载的脚本，转换前先确保脚本能执行成功
jp@gc - Transactions per Second：==tps响应时间==
jp@gc - Response Times Over Time：==随着时间变化的响应时间==
jp@gc - Active Threads Over Time：==随着时间变化的并发用户数==
确认最大并发区间
点击执行等待结果，当满足条件时停止线程（如：响应时间≤1.5S，或给出具体的TPS值当出现大于该指标值时停止线程）进行分析
如果此次执行结果表现性能良好，那么把Tish group will start【 100 】 threads：这个线程组最终要启动100个线程个线程改为200 Then start 【 0 】threads：从第0个线程开始，改为100（上面的最后的并发数），再次进行测试分析
通过下图结果结合企业标准（tps下降 响应时间≥1.5S 请求报错），我们确定了性能拐点区间为20-40个并发用户数
确认最大并发数
Then start 【 0 】threads：从第0个线程开始，这里改为区间最小值20
Tish group will start【 100 】 threads：这个线程组最终要启动100个线程，这里改为40
Next，add 【 10 】 threads every 【30】seconds using ramp-up【5】seconds：在5秒内，增加10个线程，然后持续运行30秒 改为【1】【60】【1】在1秒内，增加1个线程，然后持续运行60秒
通过下图结果结合企业标准（tps 响应时间≤1.5S），我们确定了最大并发用户数为23-25（相对保守）23-28（相对激进）
压力测试
概念
在一定的压力下，持续较长的时间，测试服务的稳定性，可靠性，一般是以小时为单位或者1-2天（因为现在互联网环境，速度很快）,在服务器出现不稳定的情况下再去做压力测试
一定的压力：最大并发用户数*20%+相对较长时间，最大并发用户数X80%+相对短时间 波浪场景
性能测试
可靠性测试
在给定一定的业务压力下，持续一段时间看系统是否稳定 最大并发x20%
容量测试
不同数据量级,数万条,百万条数据的操作读写不一样,因为测试环境数据一般不会很多,除非自己创造,所以在测试环境的速度和正式环境会有差异
在性能测试时,如果数据库的数据量级是不一致的,性能指标值,也可能存在差异
生成的数据库数据量级百万级,测试环境几千几百条读写速度肯定会有差异，因此在做性能测试的时候数据库的量级要保持一致（可通过主从数据进行同步，或者批量造数据）
