jmeter（3）-入门到精通-测试计划元件
1、测试计划要素如下：
（1）要素一：脚本中测试计划只能有一个
1、Jmeter 测试计划类似 LoadRunner Controller 中的测试场景，同一时刻场景故然只能有一个，。
2、JMeter 脚本在 GUI 中显示时是树型结构，测试计划是根节点，根节点当然只能有一个。
（2）要素二：测试计划中至少要有一个线程组
1、JMeter 负裁是通过线程组驱动的，所以计划中至少要出现一个线程组。
2、JMeter 测试计划支持多个线程组。
3、我们可以在计划下面建立多个线程组，类似 LoadRunner 中的 Group 方式的场景，我们可以把JMeter 计划理解成LoadRmmer 中的 Group 方式场景，把不相关联的业务分布在不同的线程组中( LoadRunner 中的不同 Group)。
（3）要素三：至少要有一个取样器
1、测试的目的就是要模拟用户请求，没有取样脚本就毫无意义。
（4）要素四：至少要有一个监听器
1、测试结果用来衡量系统性能，我们需要从结果中分析系统性能。
注意：敲黑板，敲脑壳啦！！！
测试计划对象具有一个名为“ 函数测试模式 ” 的复选框。如果选择，它将使JMeter记录每个样本从服务器返回的数据。如果您在测试侦听器中选择了文件，则此数据将被写入文件。如果要进行少量运行以确保正确配置JMeter并确保服务器返回预期结果，这将很有用。结果是文件将快速增长，JMeter的性能将受到影响。如果要进行压力测试，则应禁用此选项（默认情况下处于禁用状态）。
如果您没有将数据记录到文件中，则此选项没有区别。
您还可以使用监听器上的“ 配置”按钮来确定要保存的字段。
线程组元素是任何测试计划的起点。所有控制器和采样器必须在线程组下。其他元素（例如，侦听器）可以直接放置在测试计划下，在这种情况下，它们将应用于所有线程组。顾名思义，线程组元素控制JMeter将用于执行测试的线程数。
三种类型线程组：
1) setup thread group
一种特殊类型的ThreadGroup的，可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行。
setUp Thread Group类似于lr的init.可用于执行预测试操作。
2) teardown thread group.
一种特殊类型的ThreadGroup的，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组。
tearDown Thread Group类似于lr的end.可用于执行测试后动作。
3) thread group(线程组).
这个就是我们通常添加运行的线程。通俗的讲一个线程组，可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。
注释：
线程数：这里选择1
Ramp-Up Period：单位是秒，默认时间是1秒。它指定了启动所有线程所花费的时间，比如，当前的设定表示“在5秒内启动5个线程，每个线程的间隔时间为1秒”。如果你需要Jmeter立即启动所有线程，将此设定为0即可
循环次数：表示每个线程执行多少次请求。
3.5采样器(Samplers)
采样器也可以翻译成取样器；用来模拟用户的操作，向服务器（被测系统）发出Http请求、WebService（SOAP/XML-RPC Request）请求或者Java请求等。我们可以把Http请求元件看成是一个没有界面的浏览器，它可以发送Http请求，接收服务器的响应数据。采样器（Sampler）是测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter 原生支持多种不同的sampler 。如 HTTP Request Sampler 、 FTP Request Sampler 、TCP Request Sampler 、JDBC Request Sampler 等。高版本的jmeter支持更丰富的Sampler。
采样器的添加路径：【测试计划】-【线程组】-【采样器】。
采样器告诉JMeter将请求发送到服务器并等待响应。它们按照它们在树中出现的顺序进行处理。控制器可用于修改采样器的重复次数。
JMeter采样器包括：
FTP请求
HTTP请求（也可用于SOAP或REST Web服务）
JDBC请求
Java对象请求
JMS请求
JUnit测试请求
LDAP要求
邮件要求
操作系统进程请求
TCP请求
每个采样器都有几个可以设置的属性。您可以通过向测试计划中添加一个或多个配置元素来进一步自定义采样器。
如果要将相同类型的多个请求（例如HTTP请求）发送到同一服务器，请考虑使用默认配置元素。每个控制器都有一个或多个Defaults元素（请参见下文）。
切记在测试计划中添加一个侦听器，以查看和/或将请求结果存储到磁盘。
如果您有兴趣让JMeter对请求的响应执行基本验证，请将Assertion添加到采样器。例如，在对Web应用程序进行压力测试时，服务器可能返回成功的“ HTTP响应”代码，但是页面上可能有错误或缺少部分。您可以添加断言来检查某些HTML标记，常见错误字符串等。JMeter允许您使用正则表达式创建这些断言。
3.6逻辑控制器(Logic Controllers)
逻辑控制器使您可以自定义JMeter用于决定何时发送请求的逻辑。逻辑控制器可以更改来自其子元素的请求的顺序。他们可以自己修改请求，使JMeter重复请求，等等。
逻辑控制器器的添加路径：【测试计划】-【线程组】-【逻辑控制器】。
要了解逻辑控制器对测试计划的影响，请看一下以下测试树：
- Test Plan
- Thread Group
- Once Only Controller
- Login Request (an HTTP Request)
- Load Search Page (HTTP Sampler)
- Interleave Controller
- Search "A" (HTTP Sampler)
- Search "B" (HTTP Sampler)
- HTTP default request (Configuration Element)
- HTTP default request (Configuration Element)
- Cookie Manager (Configuration Element)
此测试的第一件事是，登录请求将仅在第一次执行。随后的迭代将跳过它。这是由于“ Once Only Controller”的作用。
登录后，下一个Sampler将加载搜索页面（我们可以想象一个测试场景：用户登录到Web应用程序，然后转到搜索页面进行搜索）。这只是一个简单的请求，不会通过任何逻辑控制器进行过滤。
加载搜索页面后，我们要进行搜索。实际上，我们要进行两种不同的搜索。但是，我们希望在每次搜索之间重新加载搜索页面本身。我们可以通过具有4个简单的HTTP请求元素（加载搜索，搜索“ A”，加载搜索，搜索“ B”）来实现。相反，我们使用“Interleave Controller”，该控制器每次通过测试都会传递一个子请求。它保持子元素的顺序（即，它不会随机传递，而是“记住”其位置）。交叉处理2个子请求可能会过多，但很容易会有8个或20个子请求。
注意HTTP请求默认值属于Interleave Controller。想象一下，“搜索A”和“搜索B”共享相同的PATH信息（HTTP请求规范包括域，端口，方法，协议，路径和参数以及其他可选项）。这很有道理-都是搜索请求，都命中了相同的后端搜索引擎（例如servlet或cgi-script）。与其在PATH字段中为两个HTTP Samplers配置相同的信息，不如将这些信息抽象到单个Configuration Element中。当Interleave Controller“传递”来自“搜索A”或“搜索B”的请求时，它将使用HTTP default request配置元件中的值填充空白。因此，对于这些请求，我们将PATH字段留空，并将该信息放入配置元素。在这种情况下，这充其量是次要的好处，但可以证明其功能。
树中的下一个元素是另一个HTTP default request，这次已添加到线程组本身。线程组具有内置的逻辑控制器，因此，它完全如上所述使用此配置元件。它填补了所有通过的请求的空白。因此在Web测试中，将所有HTTP Sampler元件中的DOMAIN字段保留为空白，然后将该信息放入HTTP默认请求元素（添加到线程组中）非常有用。这样，您只需更改测试计划中的一个字段即可在另一台服务器上测试应用程序。否则，您将必须编辑每个Sampler。
最后一个元件是HTTP Cookie Manager。Cookie Manager应添加到所有Web测试中-否则JMeter将忽略cookie。通过在线程组级别添加它，我们确保所有HTTP请求将共享相同的cookie。
逻辑控制器可以组合使用以获得各种结果。请参阅内置逻辑控制器列表。
3.7测试片段（Test Fragments）
测试片段元素是一种特殊类型的控制器，它与线程组元素位于同一级别的测试计划树上。它与线程组的区别在于，除非被模块控制器或Include_Controller引用，否则它不会执行。
此元件仅用于测试计划中的代码重用。它是一个辅助的组件，在此节点下几乎可以放置任何JMeter测试元件，但它一般不会被运行，那么它的作用到底是什么了？
（1）在脚本开发的过程中，可以用来备份元件。
（2）可以被模块控制台调用，我们可以用它模块化请求（是不是有点似曾相识的感觉了，没错就是程序开发中的，将业务封装成一个方法供复用）供模块化控制器调用
3.8监听器(Listeners)
监听器提供对JMeter运行时JMeter收集的有关测试用例的信息的访问。图形结果听者曲线在曲线图上的响应时间。“查看结果树”侦听器显示采样器请求和响应的详细信息，并可以显示响应的基本HTML和XML表示形式。其他侦听器提供摘要或聚合信息。
此外，监听器可以将数据定向到文件以供以后使用。JMeter中的每个监听器都提供一个字段来指示要将数据存储到的文件。还有一个“配置”按钮，可用于选择要保存的字段以及使用CSV还是XML格式。
请注意，所有监听器都保存相同的数据。唯一的区别在于数据在屏幕上的显示方式。
可以在测试中的任何位置（包括直接在测试计划下）添加监听器。他们将仅从其级别或以下级别的元素收集数据。
JMeter附带了多个监听器。JMeter的测试结果需要添加监听器来收集。
监听器的添加路径：【测试计划】-【监听器】
监听器任务
（1）添加监听结果，并且可以保存测试结果到文件中，这些测试结果可以供再次分析使用。
（2）展示结果，JMeter可以以表格以及图形的形式展示测试结果，方便测试人员分析测试结果。我们在开发测试脚本的时候，不可避免需要调试，监听器也提供了辅助（例如：我们查看结果树，我们在其中可以看到请求与响应的数据）。
3.9定时器（Timer）
3.10断言
3.11配置元件
性能测试中为了模拟大量的用户操作系统，我们往往需要做参数化，JMeter的参数化可以通过配置元件来完成。例如：CSV Data Set Config，它可以帮助我们从文件中读取测试数据。另外JMeter也提供了众多函数（通过函数助手可以查看到，后续宏哥会讲到，这里只是简单的提一下）来帮助我们动态的生成数据。当然了配置元件的作用不仅于此，它还可以记录服务器的返回数据，例如：Http Cache Manager，自动记录服务器返回的Cache信息，简而言之就是它为取样器提供预备数据，然后由取样器发出请求。配置元素与采样器紧密配合。尽管它不发送请求（HTTP（S）测试脚本记录器除外），但是它可以添加或修改请求。
配置元素只能从放置该元素的树枝内部访问。例如，如果您将HTTP Cookie Manager放置在简单逻辑控制器中，则您放置在Simple Logic Controller中的HTTP请求控制器将只能访问Cookie Manager（请参见图1）。Cookie管理器可用于HTTP请求“网页1”和“网页2”，但不能访问“网页3”。
而且，树枝内部的配置元素比“父”分支中的相同元素具有更高的优先级。例如，我们定义了两个HTTP请求默认值元素：“ Web默认值1”和“ Web默认值2”。由于我们在循环控制器内放置了“ Web Defaults 1”，因此只有“ Web Page 2”可以访问它。其他HTTP请求将使用“ Web默认值2”，因为我们将其放置在线程组（所有其他分支的“父级”）中。
在用户定义的变量配置元素是不同的。无论在何处放置，都将在测试开始时对其进行处理。为简单起见，建议将元素仅放置在线程组的开始处。
配置元件的添加路径：【测试计划】-【配置元件】。
3.12前置处理器
预处理器最常用于在样品请求运行前修改其设置，或更新未从响应文本中提取的变量。
例如：我们对数据库进行操作前需要建立一个数据库连接，那么前置处理器就可以完成这个功能。
3.13后置处理器
后置处理器一般放在取样器之后，用来处理服务器的返回结果，例如：一个Web应用程序，我们登录之后会返回一个SessionID，这个SessionID在登录之后的业务操作过程中会作为验证条件，验证用户是否合法登录了之后才进行的业务操作。发出采样器请求后，后处理器将执行某些操作。如果将后处理器附加到Sampler元素，则它将在该Sampler元素运行之后立即执行。后处理器最常用于处理响应数据，经常从中提取值。有关执行后处理器的更多详细信息，请参见作用域规则。
3.14执行顺序
- 配置元素
- 预处理器
- 计时器
- 取样器
- 后处理器（除非SampleResult为null）
- 断言（除非SampleResult为null）
- 监听器（除非SampleResult为null）
例如，在以下测试计划中：
- 控制器
- 后处理器1
- 采样器1
- 采样器2
- 计时器1
- 断言1
- 预处理器1
- 计时器2
- 后处理器2
执行顺序为：
预处理器1 计时器1 计时器2 采样器1 后处理器1 后处理器2 断言1 预处理器1 计时器1 计时器2 采样器2 后处理器1 后处理器2 断言1
3.17使用变量对测试参数化 （现在的我还没有理解，也许后面的运用就会理解）
变量不必更改-可以定义一次，并且如果单独保留，则不会更改值。因此，您可以将它们用作测试计划中经常出现的表达式的简写形式。或对于在运行期间保持恒定但在运行之间可能有所不同的项目。例如，主机名或线程组中的线程数。
在决定如何构建测试计划时，请记下哪些项目对于运行是恒定的，但在运行之间可能会改变。为此确定一些变量名称-也许使用命名约定，例如以C_或K_前缀，或仅使用大写字母将它们与测试期间需要更改的变量区分开。还应考虑哪些项需要在线程本地进行，例如使用正则表达式后处理程序提取的计数器或值。您可能希望对它们使用不同的命名约定。
例如，您可以在测试计划中定义以下内容：
主机www.example.com 底线10 圈数20
您可以在测试计划中将它们称为$ {HOST} $ {THREADS}等。如果以后要更改主机，只需更改HOST变量的值即可。这对于少量的测试工作正常，但是在测试许多不同的组合时变得乏味。一种解决方案是使用属性来定义变量的值，例如：
主机$ {__ P（host，www.example.com）}
螺纹$ {__ P（threads，10）}
循环$ {__ P（loops，20）}
然后，您可以在命令行上更改某些或所有值，如下所示：
jmeter…-Jhost = www3.example.org -Jloops = 13
