性能测试（一）—— 性能测试理论+jmeter的使用

1.性能测试介绍

定义：软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。

由定义可知性能关注的是软件的非功能特性，所以一般来说性能测试介入的时机是在功能测试完成之后。另外，由定义中的及时性可知性能也是一种指标，可以用时间或其它指标来衡量，通常我们会使用某些工具或手段来检测软件的某些指标是否达到了要求，这就是性能测试。

性能测试定义：指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

2.性能测试目的

(1)评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策；
(2)寻找系统瓶颈，进行系统调优；
(4)检测软件中的问题；
(5)验证稳定性、可靠性；

3.性能测试分类

1.负载测试

通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的前提下，系统所能承受的最大负载量的测试。如cpu使用率≤80%。

2.压力测试

通过逐步压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效。什么条件能把系统压崩溃。

3.异常测试

失败测试，是指系统架构方面的测试。如在负载均衡架构中，要测试宕机、节点挂掉等情况系统的反映。

4.并发测试

测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，所以几乎所有的性能测试都会涉及一些并发测试。因为并发测试对时间的要求比较苛刻，通常并发用户的模拟都是借助工具，采用多线程或多进程方式来模拟多个虚拟用户的并发操作。通常测试方法设置集合点。

5.容量测试

在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景，在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力、最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。预估未来。

6.可靠性测试

通过给系统加载一定的业务压力的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，所以通常可以测试出系统是否有内存泄漏的问题。如cpu使用率在80%以上7*24小时运行，系统是否稳定。

7.递增测试

指每隔一定时间段加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。如果所有的虚拟用户同时加载，有可能造成AUT的资源突然增大，进而影响后续测试中关心的测试点的数据，所以前面可以稍稍放缓，递增加载虚拟用户。

4.性能测试工作流程

需求分析
性能指标指定
脚本开发
场景设置
监控部署
测试执行
性能分析
性能调优
测试报告

5.系统应用分层架构

显示层 view
- web
- android
- ios
- H5
逻辑控制层 controller
- api
数据存储层 model
- mysql
- mongodb
- redis
- ....

6.性能测试指标定义（掌握）

事务

事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。
TPS （TransactionPerSecond）

每秒钟系统能够处理的事务
请求响应时间

从客户端发起的一个请求开始，到客户端接收到从服务器返回的响应。整个过程所耗费的时间。
事务响应时间

事务可能由一个或多个请求组成的，事务响应时间主要是针对于用户的角度而言，如转账。
并发定义

没有严格意义上的并发。并发总有先后，无论差距是1毫秒或者是1微秒，总有一个时间差。所以并发将的是一个时间范围内，比如1秒内。

比如：

（一）多用户在系统上进行同一操作，比如双十一，大家都针对同一种商品进行秒杀

（二）多用户在系统上进行不同操作，比如双十一时，大家针对不同商品进行秒杀，或者是大家有其他不同的操作，比如商品浏览。
并发用户数

同一单位时间内对系统发起请求的用户数量
吞吐量

一次性能测试过程中网络上传输的数据量的总和
吞吐率

单位时间内网络上传输的数据量

吞吐率=吞吐量/传输时间
点击率

每秒钟用户向服务器提交的请求数。这个指标是Web应用程序特有的一个指标，可以想象为每秒钟用户总共在页面上进行多少次点击动作，但是需要注意的是一次鼠标单击的操作后，客户端有可能向服务器发送了多次请求。
资源使用率

对不同系统资源的使用情况，如CPU、内存、io

7.性能测试需求分析

分析目的

1.明确测试指标

2.明确测试场景
新系统（新业务）

1.同行业比较

2.业务预期（日活、用户增长...）
老系统

1.对比以往的用户使用行为以及用户数

8.性能测试工具

常用工具

LoadRunner

JMeter
对比

对比纬度	LoadRunner	JMeter
量级	重	轻
易用性	易	易
是否开源	否	是
语言支持	C/java1.5	java
是否收费	是	否

jmeter的组成

测试计划

线程组
断言
定时器
监听器
配置元件
后置处理器
前置处理器
逻辑控制器
Sanmpler 取样器/采样器

小朋友看到这里你是否有很多问号？不着急采臣君，就针对每一个在以下的每一篇都做了更详细的介绍，通过小例子就能够清晰明了，开始吧~！

jmeter实现多并发

启动工具：

找到Jmeter的bin目录，运行jmeter.bat，双击启动即可(前提条件:需要配置jdk环境变量)

备注： windows 使用 j meter.bat，Mac或者Liunx系统运行 j meter.sh启动

新建线程组（开启测试的前提）：

用于模拟大量用户负载，此元件中可以设置运行的线程数（就是模拟多用户并发等，一线程就是一个用户）
访问路径：【测试计划】——【线程组】

界面说明：

1、取样器错误后要执行的动作：

继续：忽略错误，继续执行（常用）

Start Next Thread Loop：忽略错误，线程当前循环终止，执行下一个循环。

停止线程：当前线程停止执行，不影响其他线程正常执行。

停止测试：整个测试会在所有当前正在执行的线程执行完毕后停止

Stop test now：整个测试会立即停止执行，当前正在执行的取样器可能会被中断。

这几个配置项控制了“当遇到错误的时候测试的执行策略”是否会继续执行。

2、设置线程数：

线程数也就是并发数，每个线程将会完全独立的运行测试计划，互不干扰。多个线程用于模仿对服务器的并发访问。

3、设置ramp-up period控制线程执行时间：

ramp-up period用于设置启动所有线程所需要的时间。如果选择了10个线程，并且ramp-up period是100秒，那么JMeter将使用100秒使10个线程启动并运行。每个线程将在前一个线程启动后10（100/10）秒后启动。

当这个值设置的很小、线程数又设置的很大时，在刚开始执行时会对服务器产生很大的负荷。

下图的线程配置中，在6秒时间内启动6个线程，每个线程执行2次循环。那么每个线程之间启动延迟为 1 秒。如果点击永远那就不停止，跟输入2次是互斥关系。

4、设置循环次数：

该项设置线程组在结束前每个线程循环的次数，如果次数设置为1，那么JMeter在停止前只执行测试计划一次。

5、Delay Thread creation until needed：

默认情况下，测试开始的时候，所有线程就被创建完了。如果勾选了此选项，那么线程只会在合适的需要用到的时候创建。

6、线程组调度器设置

什么时间执行脚本，时间的控制

调度器配置可以更灵活的控制线程组执行的时间

①持续时间（秒）：

控制测试执行的持续时间，以秒为单位。

②启动延迟（秒）：

控制测试在多久后启动执行，以秒为单位。

③启动时间：

控制测试在某个时间点启动。但这个配置会被“启动延迟”配置覆盖。

④结束时间：

控制测试执行的结束时间。但这个配置会被“持续时间”配置覆盖。

如果不想立即执行执行，可以通过调度器控制测试执行的开始时间和结束时间。

当测试开始时，如果设置了调度器，JMeter将等待直到到了开始时间。在每个周期结束，JMeter将会检查是否到达结束时间，如果达到，停止运行；否则测试继续运行直到达到了重复限制。

jmeter实现逻辑分支控制

逻辑控制器可以控制采样器(samplers)的执行顺序。由此可知，控制器需要和采样器一起使用，否则控制器就没有什么意义了。放在控制器下面的所有的采样器都会当做一个整体，执行时也会一起被执行。
比如在收邮件时，只需要登录一次邮箱就可以查看多封邮件，这个场景在JMeter中只需要使用控制器中的“一次控制器”就可以控制登录的次数。
控制器的访问路径：【测试计划】——【线程组】—— 【逻辑控制器】

一般情况下我们通常会使用if控制器比较多

场景：访问百度，变量为1就可以访问

新建线程组
新建用户自定义变量

3.新建if控制器

4.新建Http请求

5.添加结果树并运行

变量为1时：

变量为2时：

请求失败，不满足逻辑判断条件

jmeter实现配置管理

配置元件为取样器提供预备数据、然后由取样器发出请求；还可以用来记录服务器的返回数据，比如： Http Cache Manager，自动记录服务器返回的Cache信息。
性能测试中为了模拟大量用户操作往往需要参数化，JMeter中的参数化可以通过配置元件来完成，比如： CSV Data Set Config，可以帮助我们从文件中读取数据。另外JMeter也提供了从多函数来帮助我们生成动态数据。
配置元件的访问路径：【测试计划】—— 【配置元件】，详情如下图：

CSV Data Set Config：保存数据，参数化

DNS Cache Manager：前端保存图片

FTP：请求缺省值

HTTP：协议相关

JDBC Connection Configuration：连接数据库

案例： Jmeter连接数据库

添加线程组
添加 J DBC Conne ction Config uration

1)Varible Name: 这个是变量的名字，具有唯一性，不能重复

2)Database URL: jdbc:mysql://数据库地址:数据库端口号/数据库名

3)JDBC_Driver_Class:org.gjt.mm.mysql.Driver

或者 com.mysql.jdbc.Driver 这是固定值

4) Username：这个数据库的登录名

5) Password：这个是数据库的登录密码

jmeter实现请求预处理

前置处理器在取样器发送请求之前做一些环境或参数的准备工作
例如：在对数据进行操作前需要建立一个数据库连接，那么前置处理器可以完成这个工作
前置处理器的访问路径：【测试计划】—— 【前置处理器】

案例：请求前先先获取参数

创建线程组
添加用户参数
添加BeanShell Sampler

Beanshell 是一种轻量级的 Java 脚本，纯 Java 编写的，能够动态的执行标准 java 语法及一些扩展脚本语法，类似于 javaScript 和 perl。

4.查看结果树查看结果

jmeter集合点、定时并发

定时器用于在模拟大量用户在同一时间处理系统业务，起到集合的功能（常用于并发测试），往往实际测试中用的不同，主要是发现性能瓶颈
访问路径：【测试计划】—— 【线程组】—— 【定时器】

案例：

访问百度，我期望在我开始执行的时候，停顿2秒

添加线程组
添加HTTP请求
添加定时器

这里我设置了3秒
查看结果树

点击启动

中间会有3秒的等待时间

3秒后展示结果

jmeter实现各种请求的发送

Sampler【取样器/采样器】用来模拟用户操作，向服务器（被测试系统）发出Http请求、WebService(SOAP/XML-RPC Requests)请求或者Java请求等。
取样器的访问路径：【测试计划】—— 【线程组】—— 【Sampler】, 常见的取样器如下图：
常用的取样器为 HTTP请求，我们可以把HTTP请求元件看成是一个没有界面的浏览器，它可以发送Http请求，接收服务器的响应数据。

看到这么多是不是很慌，其实工作中只是用到了几项

BeanShell Sampler 可以理解为写java代码，引用包（包目录： lib目录下）

Jmeter导入包：

导入完毕BeanShell Sampler 中就可以使用jar包了
Debug Sampler 协助调试工作
java请求，如果在Sampler中请求都未满足你特定的需求，使用此请求，自定义编写代码发起请求

jmeter实现关联

- 后置处理器一般放在取样器之后，用来处理服务器的返回结果。（专门用来对响应数据做处理的元件，JMeter中的关联也是通过后置处理器来完成）
- 比如一个Web程序在登录后返回一个SessionID，这个SessionID在登录之后的业务过程中会做为验证条件，验证用户是否合法登录了。我们利用取样器模拟这个请求时就需要带上这个属性，那么如何获取呢？首先我们要知道这个SessionID从哪里来？ ——它是由服务器返回的。我们需要用什么工具获取它？ JMeter提供了元件，比如正则表达式提取器，它支持正则表达式的方式来提取数据。
- 访问路径：【测试计划】——【后置处理器】，详情如下图：

案例：

访问百度，通过正则截“取百度一下，你就知道 ”字符，并通过BeanShell Sampler打印出来

1.新建线程组

2.添加HTTP请求

3.添加正则表达式提取器（具备正则表达式知识基础）

模板： $1$截取的第一个内容

4.添加 BeanShell Sampler

5.添加察看结果树

后置处理器很多，有兴趣的可以自行百度查看学习一下。

jmeter实现数据预判试看

- 【断言】用来验证结果是否正确，类似于LoadRunner中的检查点。可以帮助我们来判断请求是否成功返回且是否符合要求。就是用一个预设的结果（值、表达式、时间长短等条件）与实际结果匹配，匹配到则成功，反之失败。
- 常用的是响应断言，对于复杂的断言可以通过BeanShell脚本来完成
- 断言的访问路径：【测试计划】—— 【断言】

案例：通过发起http请求百度网址，响应回来内容进行断言

1.添加线程组

2.添加HTTP请求，在这个请求中添加响应断言

3.查看结果树

备注：断言的话只有在错误的时候会显示断言，如果请求正确，断言的内容一致，不会展示断言结果

jmeter监控数据可视化

- 监听器收集JMeter的测试结果，JMeter结果收集程序的设计模式就是监听器模式。 JMeter的监听器有两个任务：
- 1.添加结果监听，并且可以保存测试结果到文件，这些结果数据可以供再次分析使用。
- 2.展示结果，JMeter可以以表格及图形的形式展示结果，方便测试人员分析测试结果。在开发测试脚本时，不可避免需要调试，监听器也提供了辅助（比如查看结果树，我们可以在其中看到请求与响应的数据）
- 监听器的访问路径：【测试计划】—— 【监听器】，详情如下图：
- 【取样器】、【断言】、【监听器】组合在一起就可以帮助我们完成发送请求、验证结果及记录结果三项工作。

主要常用为：

察看结果树：

聚合报告：

图形结果：

其他的可自行查看，本次讲解较为工作常用的。

jmeter小助手

函数助手

常用的函数助手

◆ 随机数（__Random）

复制代码

1. 一个范围内的最小值:随机数生成时开始数，也是最小数 2. 一个范围内允许的最大值:随机生成结束数，也是最大数

◆ 参数化助手（__CSVRead）

新建csv格式文件

假设内容如下：

name,sex

zhangsan,nan

lisi,nv

0代表的第一列

改为2显示第二列

◆ 计数器（__counter）

案例：通过计数器，算打印FLASE和True的累计

◆ 唯一数（__UUID）

jmeter实现分布式并发

在性能测试过程中，一旦进行高并发操作时就会出现以下尴尬场景，JMeter客户端卡死、请求错误或是超时等，为了解决这一问题，我们需要将一次大的操作分布在多个服务器上，由多个服务器来承担负载压力。

master（主压力机）在jmeter.properties中添加remote_hosts

配置路径： ...\apache-jmeter-5.0\bin\jmeter.properties；

2. 打开文件编辑： remote_hosts=127.0.0.1 后面增加远程负载机的ip和端口号，如果需要添加多个“, ”用英文逗号分隔

添加一个从机的IP和端口号

remote_hosts=127.0.0.1:1099,127.0.0.1:1100,192.168.0.1:1099

Slave（远程负载机）在jmeter.properties中添加server_port

1. 进入负载机的usr/local/apache-jmeter-5.1.1/bin目录，编辑jmeter.properties文件

# 每个人安装Jmeter路径可能不同，注意修改路径

vim  usr/local/apache-jmeter-5.1.1/bin

2. 修改端口号

找到#server_port=1099，去掉#号，wq保存退出

备注：这里的端口号可以自定义，只要与主压力机里面配置的一致即可

3. Slave（远程负载机）启动Jmeter-server

# 输入命令：


./jmeter-server -Djava.rmi.server.hostname=192.168.3.130

如果直接输入./jmeter-server会报如下错误：

防火墙未关可能引起错误

远程启动时一直连接不上负载机

解决办法：
遇到这种情况时，可能存在多种因素，可以参考以下步骤逐一排查
（1）远程负载机的Jmeter-server是否启动成功；

（2）远程负载机是否处于联网状态；

（3）防火墙是否处于关闭状态：


centos5/6开启和关闭防火墙命令：


开启：
service iptables start


关闭：
service iptables stop


centos7开启和关闭防火墙命令：

开启：
systectl start firewalld.service

关闭：
systectl stop firewalld.service

此方法为临时关闭，即时生效，重启后失效

（4）主压力机和远程负载机的Jmeter版本是否一致；