在上一讲中简单的介绍了Jmeter的安装与Http Requet请求，在实际工作，咱们对工具的使用还需咱们进一步学习与操作才能掌握；
话说【间单的事情重复做，就会成为行家；简单的事情用心做，就会成为赢家。简单的法坚持修，就会成为大法，每天持之以恒做简单的事情，这个人就会不简单】
一、Thread Group
线程组也叫用户组，是性能测试时的虚拟用户资源池，该组件可以用来设置运行时间和虚拟并发数。具体组件结构如下：
参数说明：
Name：线程组的名称，可以随意修改
Comments：备注信息，记录一些参数设置的原因和策略可填可不填
Action to be taken after a Sampler error:线程内的采样器失败后，接下来采取的动作：
Continue：继续执行接下来的操作
Start Next Thread Loop：执行下一个线程循环
Stop Thread：退出该线程，不在执行该线程的任何操作
Stop Test：等待该线程的采样结束后，结束整个测试，不会立即停止
Stop Test Now：立即停止整个测试
Thread Properites：线程属性
Number of Threads(users)：线程数，也就是一共要启动多少线程用来并发执行
Ramp-uo Period(in seconds)：多长时间将上一步设置的线程数启动完毕。设置不同的值可以验证在不同并发的情况下验证系统的性能
Loop Count：设置sampler循环的次数，勾上Lnfinte后就会死循环一直执行
Specify Thread lifeTime：调度器，日程表。选上之后才能设置执行时间
操作说明：
Loop Count: 如果勾选就不断重复
如：不会停止，除非自己停止服务；
按次数执行
View Results Tree 结果：
按时间执行
View Results Tree：
二、断言
在做性能测试中判断是不可缺少的组件，jmeter叫断言（Assertion），它的作用和loadrunner中的检查点类似；用于检查测试中得到的响应数据等是否符合预期，用以保证性能测试过程中的数据交互与预期一致。
jmeter中断言的方式也有很多，我们只介绍以下最常用的几种。
以下是Jmeter中断言截图，其实在工作中只有掌握常见的几种满足工作，如果把断言全部学习，也可以参考官方文档或者自己把每个断言尝试下。
1. Response Assertion：响应断言
操作步骤
添加断言内容
作用：用来做检查点，对sampler做额外的检查，比如判断响应数据中是否存在指定的内容，也可以对请求数据做断言。
参数说明：
Apply to：指定断言的作用范围
- Main sample and sub-sample：作用于主main sample和子sub-sample
- Main sample only：只作用于main sample
- Sub-samples only：只作用于sub-sample
- JMeter Variable name to use：作用于JMeter变量
注意：
1、大多数情况下，可只勾选“main sample only”，因为一般情况下，发起一个请求，实际就只有一个请求。但是在某些情况下，发起一个请求时，会触发多个服务器请求，这时候就有main sample和sub-sample之分，类似ajax请求，另外，如果发起重定向请求，并且勾选“跟随重定向”，
2、如果sub-sample断言失败，但main sample断言成功，那么main sample也被设置为失败状态。如果作用域JMeter变量，且该变量关联main sample，那么如果断言失败，则main sample也被设置为失败(If the JMeter variable option is used, it is assumed to relate to the main sample, and any failure will be applied to the main sample only)。
3.如果执行完每个sampler的所有断言，变量JMeterThread.last_sample_ok会被设置为true或false
Field to test：
- Text Response：断言服务器返回的响应文本，比如body，不包含HTTP headers
- Response Code ：断言响应码，
- Response Message：断言响应码的具体信息，比如
- Response Headers：断言响应头，包括Set-Cookie 头，如果有的话
- Resquest Headers：断言请求头
- URL Sampled：
- Document(text) -通过Apache Tika追踪的各种各种类型文档的文本
- Ignore Status：指示JMeter设置sampler status的初始状态为success。sample status是否成功，由已Response status和断言结果决定，当选中Ignore Status时，Response status被强制设置为success，不执行进一步的断言判断。仅第一次断言时使用。
- Resquest Data：断言请求数据
Pattern Matching Rules：模式匹配规则
- Contains：如果文本中包含指定的正则表达式则为true
- Matches：如果整个文本匹配指定的正则表达式则为true
- Equals：如果整个文本等于给定的字符串（大小写敏感），则为true
- Substring：如果整个文本包含给定的字符串（大小写敏感），则为true
- Not：表示非，不匹配给定的模式，可以和前4个配合使用
- Or：表示或，和前4个配合使用，有一个为true则为true
注意：
Contains,Matches：将字符串当做正则表达式处理
Equals,Substring：纯字符串，不会解析成正则表达式，大小写敏感
示例：用Substring模式和contains模式分别匹配：.*
Substring模式，将.*当做文本来匹配，所以会匹配失败
结果：
Contains模式：
结果：
l Patterns to Test:
填写需要测试的模式列表，(通过重复点击面板的添加按钮来添加多个测试模式)，和多个断言，每个断言一个模式是一样的。
如：
演示：
提示成功：
断言失败
结果：
2. Response Assertion and 正则提取器
添加正在【Regular Expression Extractor】
打开结果查看树【View Results Tree】
打开后置处理器组件中的【Regular Expression Extractor】：
输入内容：
说明：
（1）引用名称：下一个请求要引用的参数名称，如填写title，则可用${title}引用它。
（2）正则表达式：
()：括起来的部分就是要提取的。
.：匹配任何字符串。
+：一次或多次。
?：抑制贪婪，在找到第一个匹配项后停止。
（1）模板：用$$引用起来，如果在正则表达式中有多个正则表达式，则可以是$2$$3$等等，表示解析到的第几个值给title。如：$1$表示解析到的第1个值
（2）匹配数字：有多个匹配值时，0代表随机取值；正数n代表取第n个匹配的值；负数代表将变量名和数字拼接，比如如果写-1的话，那么拼接后的变量就是title_1。通常情况下填0
（5）缺省值：如果参数没有取得到值，那默认给一个值让它取。
添加调试
结果查看树验证
3. Duration Assertion：响应时间断言
设置服务器响应的最大时间，如果超过设定的值则认为执行失败，组件如下：
结果显示：
参数说明：
Apply to：适用范围，也就是断言范围
- Main sample only：只作用在主sample中
- Sub-sample only：只作用在子sample中
- Main sample and Sub-sample only：主sample和子sample中都起作用
Duration in milliseconds：响应允许的最大时间，单位为毫秒，超过此值即测试失败。
演示：
设置10ms
运行结果：
设置1000ms
结果显示：
4. JSON Assertion：json断言
具体显示：
说明：
作用：对响应的json数据断言，查找指定的内容
参数说明：
l Assert JSON Path exists：符合json path规则的断言表达式
json断言的规则就是json path，和xpath类似也是有类似根和子节点的概念，对比如下：
xpath | json path | 描述 |
/ | $ | 根节点 |
. | @ | 根据判断条件取得的当前节点 |
* | * | 匹配所有元素节点 |
// | .. | 查找任意位置的元素 |
/ | .或者[] | 基于当前元素查找子元素 |
[] | [] | 下标运算符 |
N/A | [start:end] | 类似于切片的运算符 |
() | N/A | xpath中的分组 |
json断言的表达式可以使用点运算符也可以使用括号；
- Additionally assert value：勾选了此项之和才能在Excepted value中填写断言值
- Match as regular expression：以正则的方式匹配，默认勾选
- Excepted value：断言值
- Excepted null：断言空值，断言的数据为null的话可以勾选此项，或者在Excepted value中直接写null
- Invert assertion (will fail if above condition met)：取反，也就是不包含断言表达式中的内容才成功
待演示数据
增加json断言【正确】
结果：
断言失败：
验证结果：
三、jmeter常用组件介绍
启动Jmeter添加线程组
解释：
- test plan：测试计划，是其它组件的容器
- thread：线程组，用来设置多少线程，怎么运行这些线程
- config element：配置信息
- listener：监听，查看执行的结果、统计、发出的请求
- timer：等待时间，集合点、按照请求流量加压
- pre processor：前置处理器，在发出正式请求前做好准备工作
- post processor：请求之后需要做的事情，提取各种响应内容
- assertion：各种断言，和post processor部分相似，提取出指定的内容后作为断言内容。
- test fregment：测试片段，用于其他的控制器使用
- Non-test element：非测试相关的元件，比如（HTTP Mirror Server，HTTP(S) Test Script Recorder（脚本录制）等等
1. Sampler：取样器
简单的说取样器可以理解为性能测试中的协议，每次请求需要选择相应的协议才能用于向服务器发起请求，里面最常用的就是HTTP Request，Debug Sampler、TCP Sampler、jdbc Request等。每种不同类型的sampler可以根据服务端所需要的参数进行构建请求类型，进而达到测试的效果。
2. Controller:控制器（逻辑控制器）
JMeter中的Logic Controller分为两类：
a) 控制测试计划执行过程中节点的逻辑执行顺序，如：Loop Controller、If Controller等；
b) 对测试计划中的脚本进行分组、方便JMeter统计执行结果以及进行脚本的运行时控制等，如：Throughput Controller、Transaction Controller。
3. Pre Processor:预处理
前置处理器会在采样器发出请求之前做一些特殊操作。如果前置处理器附着在某个采样器之下，那么它只会在该采样器运行之前执行。前置处理器通常用于在采样器发出请求前修改采样器的某些设置，或者更新某些变量的值（这些变量不在服务器响应中获取值）。
4. Post Processor:请求之后的处理
后置处理器会在采样器发出请求之后做一些特殊操作。如果后置处理器附着在某个采样器之下，那么它只会在该采样器运行之后执行。后置处理器通常被用来处理服务器的响应数据，特别是服务器响应中提取数据。
5. Assertions:断言
用户可以使用断言来检查从服务器获得的响应内容。通过断言可以测试服务器返回的响应与测试人员的期望是否相符
6. Timer:定时器
定时器会让作用域内的每一个采样器都在执行前等待一个固定时长，如果不设定这种延迟，JMeter可能会在短时间内产生大量访问请求，导致服务器被大量请求所淹没。如果为线程组添加了多个定时器，那么JMeter会将这些定时器的时长叠加起来，共同影响作用域范围内的采样器。定时器可以作为采样器或者逻辑控制器的子项，目的是只影响作用域内的采样器。在Java中常见的就是sleep.
7. Test Fragment：片段
是控制器上一个种特殊的线程组，它在测试树上与线程组处于一个层级。但使用时需要和include Controller或者Module Controller配合。它的主要作用是模块化测试过程，类似于编程语言中的函数。即，将测试过程封装成测试片段，就可以在其他地方直接引用了；
8. Config Element:配置元件
用于提供对静态数据配置的支持。CSV date set config将本地数据文件形成数据池（date pool），而http request sampler和TCP request sampler等类型的配置元件则可以修改sampler的默认数据。
9. Listener：监听器
它是用来对测试结果数据进行处理和可视化展示的一系列元件。图形结果、查看结果树、聚合报告等都是我们经常用到的元件。
10. Non-test element：非测试相关的一些组件
一般代理录制就使用该组件
