性能测试及jmeter的使用

1. 性能测试相关概念

术语	含义	解释
并发数VU（virtual user）	系统同时处理的操作业务的用户	通俗来讲就是同时有多少人在使用这个系统
响应时间RT (response time)	服务端对请求的响应时间	通常取平均响应时间，平均响应时间——接口响应时间总和/接口请求总数
QPS(queries per seconds)/RPS(requests per second)	每秒请求数	服务每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。计算公式： 并发数/平均响应时间
TPS (transaction per seconds)	每秒事务数	它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数. 计算公式为 并发数/平均响应时间，与QPS一般认为是相同的。
吞吐量	吞吐量通常QPS（TPS）、并发数两个因素决定

2. 使用jmeter测试系统性能

2.1 jmeter的安装及环境变量配置

前置条件，下载jdk8和jmeter。下载后是一个zip包，解压后即可使用。

以GUI模式打开jmeter，为了方便起见，我们可以将jmeter所在的目录配置的环境变量中，方便我们以命令行的方式打开GUI界面：

1. 配置JMETER_HOME
2. 将%JMETER_HOME%\bin加入Path最后，现在windows10不像以windows7还需要在前面加个;.
   
   这样就可以在命令行输入jmeter再回车就可以打开jmeter的GUI了，也可以在任意目录通过命令命令行的方式运行压力测试。

2.2 jmeter使用教程

jmeter上比较重要的几个按钮：

其中，1为保存按钮，2为运行按钮，3为清除按钮，4为启动的线程数图标。其中2右边的两个按钮是·STOP按钮，右边扫把是清除result report按钮。

2.2.1 测试计划

一个jmeter测试脚本就是一个测试计划，jmeter只能打开一个测试计划。
可以给测试计划取个名字，其中，可以在测试计划中添加一些公有的变量，比如服务器地址，或者测试过程中需要用到和token等。

2.2.2 添加并发线程组

性能测试一般使用并发线程组。

并发线程组的配置：
并发线程组的配置如下图如示，用到的值我都一一解释标记在图中了。

术语	含义	特殊说明
Target Concurrency	目标并发数	这个值通常由客户给出，目标并发数是多少，一般来说会取同时在线人数的10%这样。
Ramp Up Time	机翻为耐压上升时间，去他的吧，我就叫线程完全启动时间。	这里有一个梯式增压的概念，意思就是在多少时间内目标并发数的线程启动完毕，避免在一瞬间启动过多的线程，造成服务器瞬时压力太大。
Ramp Up Steps Count	这里有一个梯式增压的概念，就是分几步启动所有并发	见含义，这里配置为2步，即，前30秒先启动10个线程对服务器请求，后30秒再启动10个线程对服务器请求，这里是为了避免一开始就同时启动过多的线程，服务器还没有准备好足够的资源。
Hold Target Rate Time	保持目标速率的时间	看图是不是白图的总时间多了两秒，意思就是线程完全启动完成后保持以这个稳定的速率请求服务多少时间。

在上图配置中，开始的1分零2秒内的请求数据不会计入jmeter测试报告中，那个两秒就是Hold Target Rate Time.

2.2.3 使用逻辑控制器包装取样器

为了将不同的模块接口分开，可以使用Logic Controller将被测接口包装起来，当然，Logic Controller的功能不止于此。

2.2.3.1 取样器（也叫采样器）

取样器这个翻译我也不懂为什么叫取样器，还是直接叫英文好，Sampler，即显得专业，又能避免尴尬，哪怕你自己不理解什么意思，你一说，别人不理解什么意思，也不好意思问你，还会在心里夸你一句：

大概意思呢就是通过取样器，添加我们需要测试的接口，这里使用的是HTTP Request取样器。

HTTP Request取样器的配置如下：

由于刚才我们在测试计划中添加了一些公有的共同的变量，这样，我们测试时就可以将服务地址用变量代替（使用方法为${variable_name}）：

配置比较简单

1. 取样器的名称，描述
2. 协议，服务地址（或IP），端口号，接口请求方式，接口路径，字符编码
3. url参数等（body参数在Parameters旁边，当然，get方法不能设置Body Data, 见上图数字2框下三个tab页）
   4

2.2.3.2 Asserting

对一个采样器增加断言：

一般会使用到的断言有那么几个，对断言来说response assertion能够满足大部分内容。

也就是如何去判断一个请求是否是成功的，在上面的采样器中，断言为响应断言，匹配为text响应，可以选择响应code, 响应message 等，匹配模式为“”，含义为响应中应该包含这个字符串。因为我测的是百度的搜索接口：

通过View results可以看到请求是否成功，绿色为断言成功，红色为断言失败。

2.2.3.3 逻辑控制器

Jmeter对逻辑控制器的描述为：Logic Controllers determine the order in which Samplers are processed.，即逻辑控制器可以控制采样器的执行顺序。

JMeter中的Logic Controller分为两类：

1. 控制测试计划执行过程中节点的逻辑执行顺序，如：Loop Controller、If Controller， ForEach Controller blabla；
2. 对测试计划中的脚本进行分组、方便JMeter统计执行结果以及进行脚本的运行时控制等，如：Throughput Controller、Transaction Controller。

2.2.3.4 常用控制器

逻辑控制器分很多种，比较常会用到的有Simple Controller， Transaction Controller, Throughput Controller.

Simple Controller

简单控制器呢，没有任何控制功能，不会影响采样器的执行顺序，这是Jmeter里最简单的一个控制器，它可以让我们组织我们的采样器和其它的逻辑控制器（分组功能），提供一个块的结构和控制，并不具有任何的逻辑控制或运行时的功能。

Transaction Controller:

事务控制器呢，顾名思义，他将在这个控制器下建立的采样器，当做一个事务，当所有的采样器都正常返回，才算是一个事务完成，否则就当这次事务失败。在聚合报告（聚合报告见下文）中，除了会对每个采样器生成测试结果以后，会额外生成一行这个事务的总体数据（这个数据中的Throughput就是这个事务控制器中事务的TPS,上面讲到TPS计算公式时，说并发数除以平均响应时间，在事务控制器中，这条额外的数据的平均响应时间即——这个事务控制器下所有采样器平均响应时间之和；如果用到事务控制器，应该明白，由于不同的事务包含的接口不一样，每个事务中每个接口的响应时间不一样，所以不同的事务应该以不同的标准去衡量）。

以下是一个错误示范：

admin_首页是定义的一个事务控制器，它包含了6个采样器（即HTTP Request），在这个控制器中设置的并发是3，应用场景是在某系统中，客户对系统TPS的要求是15（接口平均响应时间是200ms——这个值呢是经过接口单压得出来的一个值，整个系统的并发呢是10，但是呢这10个并发中，30%的用户是在使用admin_首页，根据这三个值就能得到目标tps: (10 * 30%) / 0.2 = 15。这也是为什么这个事务控制器中设置的并发是3），结果也看到了，throughput值远远达不到目标TPS，大家想想，按照这个逻辑，接口响应时间要达到多少才能满足TPS, admin_首页这个事务要小于 3 / 10 即300ms才能达到目标，也就是平均每个接口必须在50ms内完成，嗯。。。fxck.

Jmeter中Throughput的确代表的含义就是Transactions per second，但是在不同的聚合报告中这个Transaction代表了不同的含义，尤其在使用事务控制器时需要注意。

性能测试有一个指标是TPS（Transactions per second），这个事务可不是这里的事务的意思。千万不要见到以TPS作为衡量标准去测试就想当然：我明白了，用Transaction Controller!

这两个事务完全是不同的意思，切记，否则，你的开发会打死你的。

Throughput Controller

这个控制器就有点意思了，字面翻译，吞吐量控制器，但他压根不能控制吞吐量，惊不惊喜。
先看个图吧：
下面是一个Throughput Controller的配置了，同样的，也是名称，含义，然后是两种执行方式，我使用的是Percent Executions.

回到刚才那个例子，正确的使用方式就是建立一个并发线程组，并建立一个Thoughput Controller命名admin_首页，然后设置30的百分比，这样得出来的throughput才是指标TPS.
当然，有些测试人员使用的是按照并发数*业务百分比得到当前业务的并发，然后对每个业务新建一个线程组的方式，也是可行的。

2.3 监听器

2.3.1 聚合报告

聚合报告监听器会在压力测试执行完成后生成一个报表。
添加一个监听器，画红圏的几个监听器是比较常用的几个监听器：

View Result Tree一般是用来在GUI上测试，观察我们的sampler是否配置正确。
Summary Report一般是用来侦听总的报表的成功失败百分比的
大概是这么个东西：

Aggregate Report这个侦听器就是我们所说的聚合报告侦听器，对一个控制器添加这个侦听器后，生成的聚合报告内容就是这个样子：

jmeter聚合报告内容的表头含义：

Label	#Samples	KO	Error%	Average	min	max	90-99th pct	throughput	received	sent
标签，采样器的名称，事务控制器会多一个控制器的名称	请求数	@todo KO是个什么东西，查不到。。。	错误率	平均响应时间	最小响应时间	最大响应时间	百分之多少的用户访问这个请求时，响应时间没有超过这个时间	tps，但要注意在事务控制器中的特殊含义。	每秒接收字节数	每秒发送字节数

2.4 使用命令行方式运行压力测试

在jmeter的最佳实践中，为了减小压力机的资源消耗，推荐使用命令行方式运行压力测试。
https://jmeter.apache.org/usermanual/best-practices.html

命令行方式时需要将jmeter加入环境变量。
命令行如下：
jmeter -n -t test.jmx -l result.jtl
压力测试完成后，会在当前运行命令的目录生成result.jtl文件, 然后可以通过以下命令生成图形化的聚合报告：
jmeter -g result.jtl -o outputDirecotry, outputDirectory必须是一个空目录，打开这个目录会看到一个index.html，打开这个页面就能看到图形化的聚合报告。

溜了溜了。