项目实操三-性能测试用例执行

一、性能测试环境准备

1、性能测试环境服务器配置

1、硬件型号尽量一致
2、服务器数量
在生产环境可能有20多台机器大公司甚至有上千台机器是不是在性能测试环境下把整个服务器数量全部罗列到性能测试环境不需要

基准测试
同理可得以此类推
例如1台机器能够承载1000/s的并发理论上说1000台机器能够承载100000/s的并发
并没有严格要求性能测试环境服务器数量。

2、数据准备

a、纯数据库SQL
b、用代码去生成数据导入的SQL语句比较常用
技巧

衍生已有的数据
随机生成

c、用代码/工具去调用接口/UI自动化生成

注意事项
a、注意数据的状态分布
b、比如造订单数据- 多种状态尽量贴合生产环境分布情况
数据分布决定了数据库层面的性能情况
c、极端数据情况
做性能测试是基于正常的场景大批量用户用户是分散的性能场景如果脱离了业务场景这种性能测试是没有必要的。

二、性能测试执行工具Jmeter

版本5.4.1
依赖java环境JDK1.8
第三方插件

放到下面的目录下
apache-jmeter-5.4.1\lib\ext

线程模型多线程并行执行
线程数同时多少个虚拟用户在干活干活的内容就是线程组里面的内容
多个线程会同时开干
同一个线程去执行线程组内的任务是有序的

1、用户定义的变量

2、事务控制器

使用场景当我们测试的场景中包含了多个接口的时候需要做整体的数据统计
多个操作当作一个事务去统计合算

事务中任一操作失败则整个事务状态执行异常虽然整个事务中大多数的接口没有问题只有某个接口错误事务执行失败。

3、测试结果查看

a、汇总报告

缺点只能查看最终的结果无法看到过程无法分析出哪一个阶段系统达到了性能拐点

Label

接口名称

样本

接口请求次数

平均值ms

以第一个接口为例总共发起1000次请求每次请求相加除以1000得到平均响应时间

最小值ms

第一个接口最短为10ms第二个接口最短为1ms以此类推

最大值ms

第一个接口最长为115ms第二个接口最长为15ms以此类推

标准偏差

表示浮动大不大也就是说第一次请求、第二次请求等等响应时间的差距

异常%

接口请求出错的个数/总的请求数

吞吐量

每秒完成的请求数从jmeter发出请求到服务端处理完请求返回到jmeter整个过程为1——》业务吞吐量

首页-点击热榜单个接口系统最高能处理每秒28.6个请求
整个事务系统最高能处理每秒19.2个请求

吞吐量不分tps和qps
tps数据变更的场景
qps数据查询的场景

接收KB/sec

网络接收速度——》网络吞吐量

发送KB/sec

网络发送速度——》网络吞吐量

平均字节数

网络吞吐量

b、梯度线程组

c、图形插件

三、用例执行过程

1、基准测试

场景1线上服务器资源规划
性能基准极少的并发去测试每一次用户操作需要占用的资源以及性能指标
基准测试结果分析

1024KB——》1MB
1024MB——> 1GB
接收KB/sec3341.10KB/sec意味着网络带宽有3M那并发量能达到每秒40个请求
1、根据网络吞吐量接收- 如果服务器带宽不能支持每秒传输3M左右的数据则服务器无法实现40/s吞吐量
2、一个线程模拟40个并发想要模拟4000/s并发理论需要100个线程模拟虚拟用户

2、负载测试

不断增加系统并发压力直到系统达不到我们的性能要求

响应时间
吞吐量
资源占用

场景1线上预计达到4000/s的并发系统能不能抗住
4000/s性能需求分析时得到的。
梯度压测——》手法

注意事项当负载测试的结果与预估的结果有出入调整线程数
比如吞吐量理论来说系统的吞吐量曲线

a、吞吐量模型

回顾银行小例子把银行比作系统项目

银行有10个柜员窗口窗口不会增加原因是系统资源是有限的每次处理一笔业务需要1秒
第一秒来了1个人吞吐量为1
第二秒来了5个人吞吐量为5
第三秒来了8个人吞吐量为8
第四秒来了12个人吞吐量为10
第五秒来了20个人吞吐量为10剩下的人在大厅等待排队

第五秒来了20个人第1s很快处理完毕后面10个人需要等待1s才能处理完毕——》响应时间增加吞吐量持平了。这并不说明系统出现问题了。
银行承诺3s内完成所有的请求如果超过3s银行系统需要升级了。

综合上述吞吐量持平响应时间一定会增加

第一种可能

后续的人越多导致银行没有地方站了——人挤满了没有空气呼吸了
最终导致银行柜员没有空气呼吸了晕倒1个晕倒2个…10个系统垮掉了。——》此处的空气、大厅都是系统资源。

第二种可能

人达到一定的数量银行保安直接关门不允许继续进入

预期现象
第一个阶段并发量增加——》吞吐量也会增加
第二个阶段并发量增加——》吞吐量持平不会增加响应时间会变长

吞吐量不变认为系统处理不过来了新的请求会等待/积压积压会占用资源资源是有限的不会无限的积压最终会崩溃

第三个阶段——崩溃并发量增加——》
1、吞吐量下降

系统不断积压请求资源不够用

2、请求错误率提高

无法请求请求超时
系统拒绝新请求

基准测试汇总报告
1个线程——》吞吐量为40/sec

想法根据基准测试结果负载测试时响应时间应该和基准测试时一致吞吐量翻倍。
负载测试汇总报告
60个线程——》吞吐量为134/sec理论上40/sec*60没有达到理想的点

结论
接口变慢了

四、性能测试领域-细分概念

基准测试收集系统在极低并发场景中的性能基线
基准测试线程数为什么是1

对线程数要求系统100%能够承载的情况下可以是2可以是101是最小的模拟单位</font>

负载测试目的是为了发现程序系统的实际处理能力
负载测试线程数量

根据基准测试里面每个线程能够在每秒模拟多少次并发例如基准测试中1个线程能够模拟40/s并发
目标测试系统是否能够承载4000/s
初步线程数量=目标并发/单线程模拟并发数量

五、jmeter相关

表示1s启动100个线程去干活运行1次

具体干活的内容为

3个人干活3次一共干了9次
这3个人是同时去干活的
循环次数表示每个线程数要干活的次数

jmeter的执行顺序
1、对于同一个线程而言http请求是有先后顺序的先执行1任务再执行2任务

2、如果有3个线程同时干这2件任务是没有顺序的。
可能线程1执行到任务2了线程2才开始执行任务1