取样器（Sampler）： 模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。

监听器： 负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。

断言： 用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

逻辑控制器： 允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。

定时器： 负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。

配置元件： 维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。

前置处理器和后置处理器： 负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。

测试计划 Test Plan

用来描述一个性能/接口测试脚本和场景设计，包含与本次测试所有相关的功能。也就是说，使用jmeter进行测试的所有内容都是于基于一个测试计划的。

线程组 Thread Group

一个性能测试请求是基于一个线程组完成的，一个测试计划必须至少有一个线程组。

• 工具->函数助手对话框->函数助手，选择CSVRead函数
• 填入文件名和文件列号
• 复制函数字符串
• 添加 CSV data set config：右键单击线程组->添加->配置元件->CSV Data Set Config
• 填入文件名（filename）、编码方式（file encoding）、变量名（以逗号分隔）

是否允许带引号（Allow quoted data）：默认不考虑（false），如果数据中有”123,456”，不考虑引号的话，则会按照逗号分隔。如果考虑引号，逗号不会被分隔，即123,456为一个整体。

格式${变量名}

Cookie管理器

场景：只有登录之后才能查看个人动态，所以此时需要使用到cookie

• 不添加cookie

  不添加cookie时，即使是同一个用户在请求不同接口，服务器并不能知道当前发起请求的人是谁。所以，虽然同一个人登录了，再次请求查看个人动态时，服务器会提示用户未登录。

• 添加HTTP cookie管理器（在线程组里面添加，添加位置任意，不需要做任何配置）

  作用：会获取发起登录请求时的cookie信息，当同一个人再次发起请求（比如查看个人动态）时，cookie信息就会被传入。关联纽带是同一个用户。

  登录与其他请求需要在同一个线程组内

  逻辑控制器

  循环控制器

• 循环控制器可以设置请求的循环次数或永久循环
• 作用：该控制器下的取样器请求可以循环运行

事务控制器

• 作用： 事务控制器会生产一个额外的采样器，用来统计该控制器子结点的所有时间。
  在线程组下创建事务控制器

• Generate parent sample：(选中这个参数结果展示如下图红框，否则显示为下图蓝框)
• Include duration of timer and pre-post processors in generated sample：选中这一项会统计定时器(timer)的时间，否则只统计采样器(sample)的时间

• 事务控制器可以将对各请求放在同一个事务中。如果选中Generate parent sample，则聚合报告中只显示事务控制器的数据，而不会显示其中的各个请求的数据，反之则全部显示。

  断言

  断言(Assertions)可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
  两个重要断言：响应断言和JSONAssertion

  前置/后置处理器

  前置处理器(Pre Processors)和后置处理器(Post Processors)负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。我们主要在动态关联中用到后置处理器的正则表达式提取器。
  https://www.cnblogs.com/fengpingfan/p/4755411.html

• 样本：并发量

• 平均值：平均响应时间

• 中位数：响应时间的中位数

• 90%百分位：90％的样品不超过此时间。 剩余的样本至少要花这么长的时间。

• 95%百分位：95％的样品不超过此时间。 剩余的样本至少要花这么长的时间。

• 99%百分位：99％的样品不超过此时间。 剩余的样本至少要花这么长的时间。

• 最小值：最小响应时间

• 最大值：最大相应时间

• 异常：本次测试中出现异常的请求的数量/请求的总数量

• 吞吐量：默认情况下表示每秒完成的请求数

  吞吐量 = 请求总数 / 总花费时间

• 接收KB/sec：每秒从服务器端接收到的数据量，以kb为计算的单位

• 发送KB/sec：每秒发送到服务器的数据量，以kb为计算的单位

  95%响应时间 2、5、8原则，2秒性能很好，5秒可以接受，8秒快不能接受

  定时器

  定时器(Timer)负责定义请求之间的延迟间隔

  同步定时器（Synchronizing Timer）： 相当于一个储蓄池，累积一定的请求，当在规定的时间内达到一定的线程数量，这些线程会在同一个时间点一起并发，可以用来做大数据量的并发请求。

  值得注意的是模拟用户数量和线程数有关。模拟用户数量为3,代表着3个线程一次发送请求。

  如果用户数不足，将会一直等待（因为设置超时时间为0，0为一直等待时间。单位为ms）

  并发开始时间基本相同

  图形结果

  作用： 通过图形展示出本次性能测试数据的分布。 图形结果一般作为聚合报告的分析辅佐

• 样本数目：总共发送到服务器的请求数。
• 最新样本：代表时间的数字，是服务器响应最后一个请求的时间。
• 吞吐量：服务器每分钟处理的请求数。
• 平均值：总运行时间除以发送到服务器的请求数。
• 中间值：有一半的服务器响应时间低于该值而另一半高于该值。
• 偏离：表示服务器响应时间变化、离散程度测量值的大小。

正则表达式提取

运用Jmeter正则提取器，可以从请求的响应结果中取到需要的内容，从而实现关联。关联是请求与请求之间存在数据依赖关系，需要从上一个请求获取下一个请求需要回传回去的数据
**正则表达式(regular expression)**描述了一种字符串匹配的模式（pattern），可以用来检查一个串是否含有某种子串、将匹配的子串替换或者从某个串中取出符合某个条件的子串等。

匹配前面的子表达式零次或多次。例如，zo* 能匹配 “z” 以及 “zoo”。* 等价于{0,}。 匹配前面的子表达式一次或多次。例如，’zo+’ 能匹配 “zo” 以及 “zoo”，但不能匹配 “z”。+ 等价于 {1,}。 匹配前面的子表达式零次或一次。例如，”do(es)?” 可以匹配 “do” 、 “does” 中的 “does” 、 “doxy” 中的 “do” 。? 等价于 {0,1}。 标记一个子表达式的开始和结束位置。子表达式可以获取供以后使用。 匹配除换行符 \n 之外的任何单字符。要匹配 . ，请使用 . 。

构造正则表达式的方法和创建数学表达式的方法一样。也就是用多种元字符与运算符可以将小的表达式结合在一起来创建更大的表达式。正则表达式的组件可以是单个的字符、字符集合、字符范围、字符间的选择或者所有这些组件的任意组合。

服务器性能监控

安装JMeter插件管理器 JMeter Plugins Manager

下载地址： https://jmeter-plugins.org/wiki/PluginsManager/

将其放在 lib/ext 目录下

重启jmeter生效，在选项中，就可以找到plugins manager（插件管理器）

常用的插件

3 Basic Graphs 三个基本图表，可以监控：
Average Response Time–平均响应时间
Active Threads–活动的用户数）
Successful/Failed Transactions–成功/失败的事务数

5 Additional Graphs 五个附加图表，可监控：
Response Codes–响应码
Bytes Throughput–吞吐量
Connect Times–连接时间
Latency–latencies over time:主要展示的是负载测试期间的响应延迟时间，延迟时间指的是请求结束到服务器开始响应的这段时间
Hits/s–每秒点击数/连接数

Custom Thread Groups 自定义线程组，jmeter中，一个线程代表一个用户，用于设置用户加载的方式，怎么去增加用户。
Adds new Thread Groups–增加新的线程组
Stepping Thread Group–步进线程组
Ultimate Thread Group–终极线程组
Concurrency Thread Group–并发线程组，可以设置梯形的加压方式
Arrivals Thread Group–抵达线程组
Free-Form Arrivals Thread Group–自由抵达线程组

PerfMon (Servers Performance Monitoring) 服务器性能监控，允许收集目标服务器资源指标，如cpu，内存，网络，磁盘等。

需要在目标计算机上启动ServerAgent服务。下载地址： https://github.com/undera/perfmon-agent/blob/master/README.md把这几个插件都勾上，然后安装，安装后重启即可使用这些插件

启动服务方法：
运行 CMDRunner.jar 包，启动 jar 包时指定端口为 8085

命令：java -jar CMDRunner.jar –tool PerfMonAgent –udp-port 7777 –tcp-port 8085

如何判断是运维问题还是开发问题

添加物理资源监控插件，在运行请求时，会动态监测CPU、内存、网络IO等资源。刚开始性能比较低时，CPU压力比较小，当增加压力时，CPU会升高，如果性能不达标，CPU飙升至85%以上就是运维的问题，需要抬升资源。

压力测试需要和产品经理进行沟通，询问产品经理到底测试什么场景

第一种： 先进行测试，出结果后再定测试方向和目标。

• 需要去询问运维，服务器现有配置（硬件信息，如CPU、内存、硬盘、带宽等），再梳理测试场景
  • 比如我测试的机器 CPU是4核3.8GHz，10TB 7200转 西部数据机械黑盘，8GB双通道内存 3200GHz
  • 测试的场景是批量登录接口
  • 我的性能目标是基于这样的配置，能支撑学校的学生在200人左右登录。或者在不改代码的情况下，该配置最大能支持多少人的并发量或吞吐。
  • 如果把物理配置再加大一倍，能测试出什么水平（代码没问题，物理资源不够）
    • 需要核算成本，使用人数（规模）
    • 如果2核4G内存可以支持学校200人同时登录，那么400人时需要资源翻倍
    • 测试需要测不同场景，分别能达到什么样的水平

    第二种： 老前辈已经测试过了，直接告诉你，这次是否能达到目标

    非并发场景看吞吐量，并发场景看响应时间

    JMeter5.2基本使用

    JMeter 各种逻辑控制器(Logic Controller)

    JMeter组件介绍

    1. 1. JMeter 工具使用
       1. 1.1. 主要组件介绍
       2. 1.2. 测试计划 Test Plan
       3. 1.3. 线程组 Thread Group
       4. 1.4. HTTP请求
       5. 1.5. 监听器
       6. 1.6. 参数化方法
       7. 1.7. Cookie管理器
       8. 1.8. 逻辑控制器
       9. 1.9. 断言
       10. 1.10. 前置/后置处理器
       11. 1.11. 聚合报告
       12. 1.12. 定时器
       13. 1.13. 图形结果
       14. 1.14. 正则表达式提取
       15. 1.15. 服务器性能监控
           1. 1.15.1. 安装JMeter插件管理器 JMeter Plugins Manager
           2. 1.15.2. 常用的插件
           3. 1.15.3. 如何判断是运维问题还是开发问题
           4. 1.15.4. 压力测试需要和产品经理进行沟通，询问产品经理到底测试什么场景