JMeter - 核心组件以及自定义参数

1.JMeter核心组件

1.1 Thread Group线程组和Sample采样器

 这两个组件我们在上一篇博客【JMeter - 揭开分布式压测的神秘面纱】中做过一个简单的介绍，这里我们再稍微过一遍。
 这里我们先通过测试计划去添加一个setUp Thread Group

 这里我们修改几个主要参数，

1. Name：线程组名称
2. Number of Threads：线程数，即虚拟用户数。一个虚拟用户占用一个进程或线程。
3. Ramp-up period：准备时长，即多少秒内到达指定线程数。例如20个线程10秒启动完成，则表示10秒内20个线程都需要启动完成，每秒启动2个。
4. Loop Count：循环次数，即每个线程发送次数，可勾选无限循环。
   
    这里我们再来新增一个HTTP请求。
   
    这里我们也修改一些参数，大家应该一目了然就知道什么意思，英文不好的同学可以中英文切换使用慢慢熟悉。
   
    有了上一篇文章的基础，我们这里直接添加组件结果树。如下图操作即可添加结果树。
   
    启动之后可以看到结果树中将我们每次请求的结果以及一些数据都展现了出来。这里是我们GET接口的一个操作，这里我们还准备了一个POST接口，我们来看下如何操作。
    这里我们按照之前的步骤新建一个用于POST接口的采样器和结果树。这里有几个区别需要注意，Method需要修改为POST，另POST请求需要勾选Use multipart/from-data。
   
    运行之后，成功调用。
   

1.2 Assertion断言

 在我们实际开发中，当我们请求API成功响应正确Code码，也不一定意味着结果符合我们的要求，我们可能还需要对其进行一系列的判断验证才可以确定其最终正确性。在``JMeter`中就提供了断言这一个功能，我们可以通过在请求时返回层面增加一层验证机制以便提高接口测试的正确性。这里我们主要介绍下我们平时使用最多的响应断言。

1.2.1 Response Assertion(响应断言)

 这种断言主要是在我们请求的响应中增加一系列验证。这里我们在之前GET请求上添加几个断言做示例。
 首先在我们所需添加断言的采样器上选择添加Assertions -> Response Assertion。

 下面这个界面就是响应断言的主要界面，这里我们这个断言的意义就是会检测响应文本中是否包含james这个字符串，若包含则通过检验。这里我们稍微介绍一下每个选项的含义。

 上面我们添加了一个响应文本断言，这里我们再添加一个响应码断言。

 这里我们知道，当前接口我们响应内容为{"kobe":99,"tracy":95,"nash":94}，运行看一下结果。这里可以看到我们所发送的请求被标红了，并且可以查看到具体未通过的断言。

 这里我们将球星名称的断言勾选NOT反转一下再运行验证，请求通过断言正确记录结果树。

 另外这里顺带再介绍一个，我们还可以添加一个断言结果***。这个***可以将断言产生的结果记录下来并可以选择是否需要持久化到某个文件上。

1.3 Summary Report(聚合报告分析)

 之前我们所了解和操作的都没有涉及到和性能相关的概念，这里要介绍的聚合报告则是我们对压测对象的数据统计分析，是一个指标性的报告。这里我们同样在之前采样器上添加Aggregate Resport。

 这里我们不需要其他配置和操作，直接运行测试计划。

 这里就可以看到一系列的数据报告，这里我们做一个简单的介绍。

1. Label：Sample采样器名称
2. Samples：总共发送请求数
3. Average：平均响应时间
4. Median：中位数，50%用户响应不超过该时间
5. 90%Line：90%线，90%用户响应不超过该时间
6. 95%Line：95%线，95%用户响应不超过该时间
7. 99%Line：99%线，99%用户响应不超过该时间
8. Min：最小响应时间
9. Max：最大响应时间
10. Error：错误请求率
11. Throughput：吞吐量，一般情况下可看做每秒完成请求数(和QPS类似)
12. Received KB/Sec：每秒从服务器端接收到的数据量
13. Sent KB/sec：每秒从客户端发送的请求的数量

 
 这里还可以通过配置将聚合报告的结果保存到指定文件。聚合报告主要就是上面这些数据指标，通过这些数据我们可以对测试对象性能以及抗压程度有一个清晰的了解啦。

1.4 JMX压测脚本

 这里我们对jmx压测脚本做一个简单的介绍，为什么要了解这个呢？因为我们之后在Linux服务器上进行压测的时候是没有现在我们使用的可视化界面的，所以我们需要通过修改jmx脚本文件去修改对应的配置。
 我们之前已经进行了一系列的操作，现在去退出或者保存大家会发现在指定目录下生成了一个jmx的脚本文件。这个文件里面就是我们整个测试计划中所添加的组件和配置的参数了。

 SetupThreadGroup：这个是我们配置的线程组，这里面主要是配置线程数、准备时长以及循环次数等配置。

 HTTPSamplerProxy：Http采样器，就是我们开始添加具体API接口相关信息的配置，包括接口url、端口、请求方式等。

 ResultCollector ViewResultsFullVisualizer：这个就是结果树了，这里可以配置我们获取哪些请求和响应的属性。

 ResponseAssertion：断言，这里就是我们开始配置的两个响应断言。这里主要是修改断言的类型以及各种自定义参数。

 ResultCollector StatVisualizer：聚合报告，这个就是我们所需要的一系列测试结果数据，平时除了修改保存文件路径之外其他的一般不会经常改动。

2.自定义变量以及CSV可变参数

2.1 User Defined Variables(用户自定义变量)

 无论是在编程还是在其他软件的使用过程中，我们都会有一个场景，那就是有很多配置都是同一个值。当我们需要修改则需要全部修改一遍，增加了极大的工作量。这里我们就介绍下JMeter的用户自定义变量，做到一处配置处处使用。
 我们在之前球星列表采样器上添加Config Element -> User Defined Variables。

 这里我们添加了两个变量ip和port。

 接下来使用就非常简单了，我们可以通过${}方式在配置中引用我们自定义的变量。再去启动，请求一切正常，大家可以查看请求数据包，都已经转换成我们引用的变量值。

2.2 CSV Data Set Config(CSV可变参数)

 在我们平时压测过程中，我们大部分情况是需要根据不同参数去发送请求，这里我们我们就可以利用CSV数据文件设置去达到这个目的。这里我们在采样器上添加Config Element -> CSV Data Set Config。

 我们首先对之前POST请求接口做一个小调整。使其支持两个参数的传入。

 @PostMapping("/getScore")
 public Object getScore(String name,String msg){
     HashMap<String, Integer> stars = getStars();
     System.out.println("getScore...");
     return stars.get(name) + msg;
 }

 这里我们准备了一份CSV文件，内容如下。这里我们保存的格式是默认的逗号分隔。

 这里我们首先需要选择我们读取的Filename文件路径、Variable Names分隔后的变量名称以及Delimiter分隔符。这里我们CSV默认的逗号这里配置为逗号即可。

 配置好CSV数据设置之后，我们需要修改之前采样器里面的配置。这里我们将CSV可变参数名配置到指定参数内容上即可。

 运行之后，可以发现他会根据我们CSV文件中的切割变量去循环请求接口，这就达到了我们利用CSV文件去发送可变参数请求的目的。



 另外这里也支持txt文件参数设置，这里我们也准备了一份txt格式的文件。

 内容和之前csv文件是一致，唯一的区别就是分隔符不同，这里我们只需要修改文件路径以及分隔符即可。CSV可变参数的设置大概就是这些需要注意的，十分简单。