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

---

一、性能测试环境准备

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/sec：3341.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，可以是10），1是最小的模拟单位</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