性能测试基础

一、性能测试的目的

性能测试就是通过性能压测工具，通过特定方式，对系统施加一定的压力：正常、异常负载以及峰值来对系统实施压力，得到各项性能指标。保证系统的性能需求。

1.基本目的：验证是否达到用户的性能指标；发现软件中存在的性能瓶颈和优化
2.评估系统的能力：帮助做出决策，为后续性能优化提供数据
3.识别体系中的弱点，修复体系的瓶颈或薄弱的地方
4.系统调优：重复运行测试，验证调整系统的活动是否得到了预期的结果；改进性能。如：长时间的测试执行可导致内存泄漏。
5.验证稳定性：在一定的生产负荷下执行测试一定的时间评估系统稳定性和可靠性是否满足要求。

总括：
1，评估当前系统的性能情况
2，找出系统存在的性能瓶颈，并调优
3，预估未来的业务，看系统性能是否能满足需求

作用：多快好省

• 多：高并发
• 快：延时、响应时间
• 好：稳定性（长时间运行）
• 省：资源的使用率

性能测试主要针对哪些方面测试：
1）后端代码的性能
2）应用服务器，数据库服务器，系统架构是否存在瓶颈
3）服务器资源的消耗

为什么要进行接口压测？
现在互联网项目标准结构是前后端分离的；重后端，轻前端，后端的压力相对较大，比较影响系统性能。所以压测一般是做后端接口压测。

注意：
没有经过初始化的性能环境=没有作用的环境。

二、五大性能指标

1.静态：网络带宽瓶颈、缓存多
2.动态：进程多、消耗内存多、磁盘IO频繁
3.动静结合：DB压力大、存储压力大、内存压力大、CPU压力大

性能测试关键指标:
1.资源指标：CPU（上限不超过85%）、内存、IO、网络带宽
2.系统指标：TPS、并发用户数、响应时间、事务成功率、超时错误率

1.响应时间

用户操作一个请求得到响应的时间。
包含：
1、用户客户端呈现时间
2、请求/响应数据网络传输时间
3、应用服务器处理时间
4、数据库系统处理时间

一个系统普遍能接受的标准时间2/5/8s

2.并发用户数

含义：大量用户在同一个时间访问同一个业务

广义并发------不一定是同一个请求；例如双十一抢购。
严格并发----同一个请求

c:平均并发用户数
并发用户数=c+3*根号c

在线用户数，对系统的内存影响最大。（用户登录产生session）

3.吞吐率（TPS）

单位时间内系统处理用户的请求数。吞吐量可以反映服务器承受的压力。
计算公式：F=VU*R/T
F：吞吐量，VU虚拟用户个数，R每个虚拟用户发出的请求数，T性能测试所用的时间

TPS：每秒事务数，即吞吐率.单位时间内处理的用户请求数
QPS：每秒查询数，服务器每秒处理指定请求数

TPS的计算： 
2022年最高的一天又10w笔交易，预测2023年TPS需要多少合格？    
按照二八定律（80%的事务在20%的时间完成）计算： 

没有更精确的数据那么TPS=10w*80%/(24*60*60*20%)=4.6     

如果有更详细的数据，5w交易在完善8-9点完成。： TPS=5w/(24*60*60)=13.9

4.思考时间

操作之间的时间间隔，主要为了更真实的模拟用户的操作。

5.资源指标

CPU,内存，磁盘使用情况 ：
一般cpu使用率不超过80%；
内存不高于80%；
磁盘不高于90%；
网络带宽不超过80%

三、测试方法

负载测试----找到最优负载量

负载测试：着重于用户规则和需求。

单接口负载测试场景：
通过逐渐对一个接口进行施压知道出现性能拐点，获得被测接口的最大指标。

混合负载压测场景：
为了验证整个业务的最大最优性能体现，重点在于模型的设计，模型是来自于生产环境的日志，或产品经理给的。

压力测试-----找到极限负载量

关注软件系统极限负载的性能
着重于软件本身。识别系统的弱点和在极限负载下程序结果如何运行。规划能力，预估系统的使用情况。 期望： 面临压力时能够保证稳定，速度可以变慢，但是系统不能奔溃。

稳定性测试------关注长时间运行稳定性

1.测试系统在一定的负载下长时间运行后是否会发生问题。
2.系统需要时间积累到一定量的程度。
3.一般是程序占资源却不能及时释放而引起的。比如内存泄漏。
4.客户端和服务器连接通路，不能有效的及时释放。

并发测试------大量用户同一时间访问某个业务的运行情况

验证系统的并发处理能力

验收测试

验收性能测试：模拟用户环境，测试系统是否满足要求。
特点：确定用户的环境；用户要求的性能指标；执行，分析结果；验收性质；一定要有客观性的结果。

分析如何开展验收测试：
1.性能测试需求分析：向客户了解用户数；高频/ 常用的功能，场景；运行情况时间（考虑并发时间段30分钟，2h，7*24小时；防火墙，负载均衡器都要长时间测试）。
2.了解软硬件情况。

基准测试

相当于迭代版本对之前版本的功能测试。新增一个模块，判断模块对系统性能的影响。

一般性能测试测试中是单接口基准测试，也就是一个用户测试接口5min。
目的：为了在没有任何压力的情况下，查看各项性能指标。

配置测试

对被测系统的软硬件环境测试进行调整，了解对系统性能影响程度，找到系统各项资源最优分配原则。

恢复测试

系统局部发生问题，是否能继续使用系统；该问题对用户影响的严重程度；能否快速地从错误状态恢复到正常状态。

测试环境插件辅助说明

如果需要监控服务器的性能：CPU \ 内存
可以用grafana，如果小项目可以直接在jmeter中插件监控也可以。

PerfMon Metrics Collerctor使用与那样：

• 1.需要在服务器上安装一个ServerAgent.zip，由于手机服务器的性能参数，然后通过4444端口输出。
• 2.在PerfMon Metrics Collerctor组件中通过444端口去捕获服务器性能参数。

四、性能测试流程

• 1.性能需求分析：
  做性能测试条件；项目的熟悉；明确性能测试范围；性能测试指标；初步性能测试策略。1年或3年之后需要达到什么样的性能。
• 2.测试计划：
  怎么安排：时间（测试项目的开始结束；各环节的时间安排）；人员；使用的工具（并发工具，监控工具，分析工具，辅助工具）；场景模型（软硬件环境，网络环境）；方法。
• 3.性能测试设计：
  测试环境；场景设计；测试用例；脚本开发（录制，自己编写）；测试数据。
• 4.测试执行（执行脚本，记录数据，通过工具执行场景）。
• 5.测试分析与报告：
  性能分析（系统框架分析，指标分析，性能问题分析）；性能总结报告（测试环境，性能策略人员分配，场景描述，指标对比，问题描述，结果与原因，优化方案等）。

环境：http://47.96.181.17:9090/

性能需求分析

1.熟悉被测系统

• 熟悉被测系统的业务功能
• 熟悉被测系统的技术架构

2.明确性能测试内容

• 从业务角度明确测试内容--------确定关键业务
• 从技术角度明确测试内容
  1）逻辑复杂度高，cpu密集运算大的地方，考量服务器CPU在预定性能指标下是否达标
  2）数据量大的业务很占用系统内存。考量服务器内存预定性能指标是否达标

3.明确性能测试策略----负载？压力？稳定性？并发
4.明确性能测试的指标
1）需求无明确指标-------通过查找相关资料，和类似的系统对比（竞品分析），跟客户沟通，以及对未来流量的预估
2）有明确需求指标----------下订单并发用户2个；平均响应时间小于3s;cpu使用率小于85%
有明确的指标根据分析结果和预期指标做对比即可。

性能测试计划，方案

1.项目背景
2.测试目标
3.人员安排
4.时间进度安排
5.性能测试环境（系统架构，软硬件配置，测试数据）
6.性能测试工具，监控工具
7.测试策略

• 确定性能测试类型（负载？压力？并发等？）
• 确定性能测试场景（单一业务场景，混合场景）

8.风险控制

性能测试用例设计

测试环境搭建与脚本编写、录制、执行

环境搭建：
根据测试用例的场景展现出来
提示：
1）虚拟用户数量及启动虚拟用户方式；
2）场景相关设置，如集合点；
3）脚本是否存在依赖关系（登录和注册）

运行脚本：
注意：
1）负载的测试机不能运行设定的虚拟用户数
2）没有“预热”过程 （本地多次测试可能会有缓存，需要注意）
3）没有模拟用户的真实环境
4）性能用例运行次数过少

系统性能调优

性能测试分析人员经过对结果的分析对比，提出系统存在性能瓶颈

提示：
1）调优人员对系统进行调整
2）验证性能测试人员继续第二轮，第三轮…的测试。 到最终系统的性能是否有达标为止。

注意：
系统调优由易到难的顺序：
1）硬件问题
2）网络问题
3）应用服务器，数据库等配置问题
4）源代码，数据库脚本问题
5）系统架构问题

性能测试总结报告：

1）对整体性能测试阶段的回顾（覆盖需求，测试不同阶段的进度和产物、性能测试结果的分析，问题的解决）--------技术角度
2）对整体性能测试阶段风险的管理------管理角度
3）对项目性能测试结果的总结—通过与否，经验教训

五、性能测试

性能测试工具简单介绍

Loadrunner特点：
1）工业化性能测试根据，能支持大量用户，提供详细的报表来提供测试分析的数据
2）支持协议多
3）使用c语言写的
优点：支持用户量大；提供精确报表；支持IP欺骗
缺点：收费高，体积大，不支持定制功能

jmeter 特点：
1、多线程框架-支持多并发操作
2、同于对服务器模拟负载
3、支持web、数据库、ftp服务器系统的性能测试
4、开源、纯java,可二次定制开发

jmeter是用java开发的，优点：免费开源，可以二次开发；体积小；
缺点：不支持ip欺骗；分析和报表能力相对LR欠缺。

jmeter的基本使用

见：jmeter基本使用

分布式测试—多机协作

应用场景：
当测试机无法模拟用户需要的业务负载量时，需要更多测试机配合测试

原理：

• 分布式测试是分为一台控制机和多台代理机
• 控制机负责发布测试任务给代理机
• 代理机接受任务并向服务器发送请求，并接受服务器返回的响应，然后将测试结果返回给控制机
• 由控制机对测试结果数据进行汇总统计

分布式相关注意事项：

• 所有测试机防火墙都要关闭
• 所有的测试机及服务器在同一个网络
• 所有测试机的jdk和jmeter的版本要一致
• 关闭jmeter的RMI_SSL开关

分布式配置：

• 代理机：
  1，server port：不重复。若使用多台机器做代理机，可不用配置
  2，关闭RMI_SSL
• 控制机：
  1，remote_server：所有代理机的IP+port,有多台代理机时用逗号分开。注意是在控制机的jmeter的bin目录下，找到jmeter.properties文件，编辑该文件：

查找：
remote_hosts=127.0.0.1
修改为：
remote_hosts=192.168.9.99:1099,192.168.9.130:1099
特别注意端口号

2，关闭RMI_SSL

运行：

• 代理机：jmeter-server.bat运行
• 控制机：jmeter-bat运行；
  控制代理机执行脚本：菜单->运行->远程启动所有

更多多机协作问题，参见：http://t.zoukankan.com/AmilyWilly-p-6794998.html

插件技术（监听）

将插件管理器放在：安装目录/lib/ext/
插件安装方式：
1、通过Plugins Manager安装插件
2、直接将需要的插件放在/lib/ext/下
注意：jmeter一定要重启！！！

插件管理器jar包下载路径：https://jmeter-plugins.org/wiki/PluginsManager/

1、安装插件：
PerfMon只是安装显示在Jmeter的，实际使用需要客户端安装JMeterPlugin-Standard和JMeterPlugin-Extras（需要搭配ServerAgent使用，serverAgent需要安装在服务器上）
2、配置
将 JMeterPlugins-Standard-1.3.1.zip 中 lib\ext 目录下的 JmeterPlugins-Standard.jar 文件都放到apache-jmeter-2.13\lib\ext目录中。

将 JMeterPlugins-Extras-1.3.1.zip 中 lib\ext 目录下的 JMeterPlugins-Extras.jar 文件放到apache-jmeter-2.13\lib\ext目录中。
下载地址：https://jmeter-plugins.org/downloads/old/

将 ServerAgent-2.2.1 放到要监控的服务器中，window中执行startAgent.bat，linux中执行startAgent.sh（须要有执行权限，chmod 775 startAgent.sh 然后再执行 ./startAgent.sh）.

3、执行脚本，监控数据。
先在线程组中添加监听器jp@gc-PerfMon Metrics Collector，在AddRow中添加要查看的资源。默认主机为localhost，端口为4444（Server-Agent的默认启动端口），监控项目选择。也可以修改主机为对应服务器ip便可（端口不占用状况下使用默认便可）


grafana跟serverAgent原理差不多，都是监听数据运行的情况。优点：比较详细，并且能实时监控查看数据。

服务器资源监控分析

CPU使用率：用户进程与系统进程消耗的CPU时间百分比长时间情况下，服务器的使用率不能超过85%

通过putty工具连接linux系统，远程操作。
47.96.181.17

问题分析：
响应时间>10s
排查：
1、查看原因，使用jmeter监控系统指标，cpu、内存、磁盘等
2、若cpu使用率达到90%，cpu就一定有问题嘛？
分析：看具体哪一个进程使用率高-----top指令
若不是测试软件系统占有率高----先kill掉；若是本身测试系统的问题—很可能是cpu瓶颈
4、验证，确定是否是cpu的瓶颈
a)部署感觉的 ，cpu配置高的系统环境
b)降低并发数，看看情况。

答：否，可能一开始就有开启其他的应用，导致cpu已经达到了80%导致。

无界面压测

补充知识：

http协议简介

http请求包括四个部分：请求行，请求头，空行，请求体（请求参数）
响应也包含四部分：状态行，响应头，空行，响应正文

http工作原理见：https://blog.csdn.net/weixin_43973848/article/details/119084365?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22119084365%22%2C%22source%22%3A%22weixin_43973848%22%7D&ctrtid=dN2J4

请求方式差异

get 方法：向服务器i请求静态资源
特点：
1.所有的请求内容在url中
2.明文传输，安全性差
3.访问速度快
4.浏览器历史纪录中有记录

post方法：向指定的资源提交数据进行处理
特点：
1.所有的参数封装在body中提交，安全性高
2.没有数据参数类型要求
3.速度较慢
4.浏览器中没有详细记录

正则表达式

正则表达式快速格式转换见：https://www.json.cn/

正在表达式：元字符+限定符

最常用的几个字符：

元字符	定义
.	任意单个字符
\d	任意单个数字
[0-9]	等价于0-9的数字
[a-zA-Z]	等价所有的大小写字母

限定符	定义
+	匹配至少大于1次
？	匹配0次或1次
*	匹配0次或多次 贪婪匹配
{n,}	匹配限定次数

可以通过“在线正则表达式”来测试表达式获取的值是否正确。

其他补充：

请求中cookies的处理

1、线程中添加http cookie管理器即可。
2、利用正则表达式+http 信息头处理：
a)先发一个登录请求，查看response heads的数据，会发现有cookie内容
b)在登录接口下添加正则表达式，提取cookies.。注意：该正则表达式需要在信息头中获取数据！
c)将提取到的数据通过http request 默认值设置在下一个请求中
d)添加一个Debug Sampler查看请求是否成功

请求中token的处理方式

1.一个测试计划中多个线程组会同时运行，可以通过测试计划中的独立运行线程组解决。也可以通过setup线程操作，例如：创建一个setup线程组，将登录请求放在里面，那么每次执行整个测试计划的时候，就会先执行该线程，后面如果有接口关联可以通过json提取获取。

简单的接口关联操作：
1.在需求提取数据的请求下-----增加提取器（正则 or json）
2.增加一个后置处理器------beanShell PostProcessor
将提取器的数据获取并设置为全局变量：${__setProperty(newtoken,${token},)} newtoken代表设置的新的全局变量名称，token表示提取器中设置的名称(最好通过函数助手设置，容易出错！！！)
3.在后面的线程组请求中添加一个header manager，获取全局变量---------newtoken
${__P(变量名)} 基本等同于 ${__property(变量名 )}

注意事项：
1、当添加了http请求默认值，单个请求也设置了值，会以单个请求设置的值为准。
2、已添加了全局变量，需要先调用一下，后面的请求取值才能成功
3、不同的参数传递格式会导致报错，详细解析见：遇到的疑难问题