Jmeter(三) - 从入门到精通 - 测试计划（Test Plan）的元件（详解教程）

1.简介

上一篇中宏哥已经教你如何经过JMeter来建立一个测试计划（Test Plan），那么这一篇咱们就将JMeter启动起来，建立一个测试计划（Test plan），而后宏哥给你们介绍一下测试计划（Test Plan）有哪些元件组成的。

2.测试计划（Test Plan）要素

本节主要描述测试计划的不一样部分要素。JMeter中一个脚本就是一个测试计划（Test Plan），也是一个管理单元。JMeter 的请求模拟与并发数(设置线程数，一个线程表明一个虚拟用户)设置都在脚本文件中一块儿设置。JMeter 不像 LoadRunner 把脚本与虚拟用户设置分开。

2.1测试计划要素以下：

（1）要素一：脚本中测试计划只能有一个
　　一、Jmeter 测试计划相似 LoadRunner Controller 中的测试场景，同一时刻场景故然只能有一个，。
　　二、JMeter 脚本在 GUI 中显示时是树型结构，测试计划是根节点，根节点固然只能有一个。
（2）要素二：测试计划中至少要有一个线程组
　　一、JMeter 负裁是经过线程组驱动的，因此计划中至少要出现一个线程组。
　　二、JMeter 测试计划支持多个线程组。
　　三、咱们能够在计划下面创建多个线程组，相似 LoadRunner 中的 Group 方式的场景，咱们能够把JMeter 计划理解成LoadRmmer 中的 Group 方式场景，把不相关联的业务分布在不一样的线程组中( LoadRunner 中的不一样 Group)。
（3）要素三：至少要有一个取样器
　　一、测试的目的就是要模拟用户请求，没有取样脚本就毫无心义。
（4）要素四：至少要有一个监听器
　　一、测试结果用来衡量系统性能，咱们须要从结果中分析系统性能。

3.测试计划（Test Plan）元件

打开Jmeter页面：包括测试计划+工做台。

注意：敲黑板，敲脑袋啦！！！最新版的jmeter去掉了工做台。不要大惊小怪的导出截图问，个人JMeter为何没有工做台，我同事的有工做台，若是你是在想要就下载一个低版本的JMeter安装好启动之后，就能够看到你的JMeter也有工做台了。

3.1测试计划（Test Plan）

Test Plan (测试计划)：用来描述一个性能测试，包含与本次性能测试全部相关的功能。也就说本的性能测试的全部内容是于基于一个计划的。
右键单击“测试计划”弹出菜单：
它用来描述一个测试方案，包含与本次性能测试全部相关的功能。也就说本次测试的全部内容是于基于一个计划的。

注意：敲黑板，敲脑袋啦！！！

测试计划对象具备一个名为“ 函数测试模式 ” 的复选框。若是选择，它将使JMeter记录每一个样本从服务器返回的数据。若是您在测试侦听器中选择了文件，则此数据将被写入文件。若是要进行少许运行以确保正确配置JMeter并确保服务器返回预期结果，这将颇有用。结果是文件将快速增加，JMeter的性能将受到影响。若是要进行压力测试，则应禁用此选项（默认状况下处于禁用状态）。
若是您没有将数据记录到文件中，则此选项没有区别。
您还可使用监听器上的“ 配置”按钮来肯定要保存的字段。

3.2线程组Threads （Users）

线程组元素是任何测试计划的起点。全部控制器和采样器必须在线程组下。其余元素（例如，侦听器）能够直接放置在测试计划下，在这种状况下，它们将应用于全部线程组。顾名思义，线程组元素控制JMeter将用于执行测试的线程数。线程组的控件使您能够：

• 设置线程数
• 设置加速时间
• 设置执行测试的次数

每一个线程将完整地执行测试计划，而且彻底独立于其余测试线程。多个线程用于模拟与服务器应用程序的并发链接。
加速期告诉JMeter将“加速”到所选线程的总数须要多长时间。若是使用了10个线程，而且启动周期为100秒，那么JMeter将花费100秒来启动和运行全部10个线程。每一个线程将在上一个线程开始后10（100/10）秒开始。若是有30个线程，启动周期为120秒，则每一个连续线程将延迟4秒。
加速须要足够长的时间来避免在测试开始时工做量过大，而且还必须足够短以使最后一个线程在第一个线程完成以前开始运行（除非有人但愿这种状况发生）。
从“上升=线程数”开始，而后根据须要向上或向下调整。
默认状况下，线程组配置为在其元素之间循环一次。
线程组还提供了调度程序。单击“线程组”面板底部的复选框以启用/禁用其余字段，您能够在其中输入测试的持续时间，启动延迟，运行的开始和结束时间。您能够配置持续时间（秒）和启动延迟（秒）来控制每一个线程组的持续时间以及启动后的秒数。当测试开始时，JMeter将在启动线程组的线程以前等待启动延迟（秒），而后运行配置的持续时间（秒）。请注意，这两个选项会覆盖“ 开始时间”和“ 结束时间”。
另外，您也可使用其余两个字段Start time和End time（尽管不建议这样作，由于它不太灵活）。测试开始时，若有必要，JMeter将等待直到达到启动时间。在每一个周期的末尾，JMeter会检查是否已达到结束时间，若是已结束，则运行将中止，不然，将容许测试继续进行直到达到迭代限制。

线程组的添加路径：【测试计划】-【THreads（Users）线程组】

3.2.1添加线程组

选中要添加线程组的测试计划（Test Plan），右键点击“Add”，选中“Threads（Users）”，咱们目前能够看到三个线程组。

虽然有三个添加线程组的选项，名字不同， 建立以后，其界面是彻底同样的。以前的版本只有一个线程组的名字。如今多一个setUp theread Group 与terDown Thread Group
1) setup thread group
一种特殊类型的ThreadGroup的，可用于执行预测试操做。这些线程的行为彻底像一个正常的线程组元件。不一样的是，这些类型的线程执行测试前进行按期线程组的执行。
setUp Thread Group相似于lr的init.可用于执行预测试操做。
2) teardown thread group.
一种特殊类型的ThreadGroup的，可用于执行测试后动做。这些线程的行为彻底像一个正常的线程组元件。不一样的是，这些类型的线程执行测试结束后执行按期的线程组。
tearDown Thread Group相似于lr的end.可用于执行测试后动做。
3) thread group(线程组).
这个就是咱们一般添加运行的线程。通俗的讲一个线程组，能够看作一个虚拟用户组，线程组中的每一个线程均可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程当中是不会发生改变的。

3.2.2线程组界面介绍

这个就是咱们一般添加运行的线程。通俗的讲一个线程组,，能够看作一个虚拟用户组，线程组中的每一个线程均可以理解为一个虚拟用户。
Ramp-Up Period：单位是秒，默认时间是1秒。它指定了启动全部线程所花费的时间。若是你须要Jmeter当即启动全部线程，将此设定为0便可
循环次数：表示每一个线程执行多少次请求。

名称：就如字面意思，起个有意义的名字就行
注释：
线程数：这里选择1
Ramp-Up Period：单位是秒，默认时间是1秒。它指定了启动全部线程所花费的时间，好比，当前的设定表示“在5秒内启动5个线程，每一个线程的间隔时间为1秒”。若是你须要Jmeter当即启动全部线程，将此设定为0便可
循环次数：表示每一个线程执行多少次请求。

3.3拓展

这个是关于阶梯加压线程组，后期关于这部分会详细介绍，这里先提一下，有兴趣的本身能够研究一下，很简单的须要给JMeter下载安装一个插件就能够了。

注意：Stepping Thread Group 可用于模拟阶梯加压！

3.4控制器(Controllers)

JMeter有两种类型的控制器：采样器和逻辑控制器。用这些元件来驱动测试的进行。
采样器告诉JMeter将请求发送到服务器。例如，若是您但愿JMeter发送HTTP请求，则添加一个HTTP Request Sampler。您还能够经过将一个或多个配置元素添加到采样器来自定义请求。有关更多信息，请参见 采样器。
逻辑控制器使您能够自定义JMeter用于决定什么时候发送请求的逻辑。例如，您能够添加一个Interleave Logic Controller在两个HTTP Request Samplers之间交替。有关更多信息，请参见逻辑控制器。

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的测试结果须要添加监听器来收集。

监听器的添加路径：【测试计划】-【监听器】

3.8.1监听器的任务

（1）添加监听结果，而且能够保存测试结果到文件中，这些测试结果能够供再次分析使用。
（2）展现结果，JMeter能够以表格以及图形的形式展现测试结果，方便测试人员分析测试结果。咱们在开发测试脚本的时候，不可避免须要调试，监听器也提供了辅助（例如：咱们查看结果树，咱们在其中能够看到请求与响应的数据）。

3.9定时器（Timer）

默认状况下，JMeter线程按顺序执行采样器而不会暂停。咱们建议您经过将可用计时器之一添加到线程组来指定延迟。若是不添加延迟，JMeter可能会在很短的时间内发出太多请求，从而使服务器不堪重负。这就是咱们一般说的负载，为了足够真实的模拟用户负载，咱们有时候会须要模拟这些请求在同一时刻发送，就好像把你们集合在同一块儿跑线上，而后扣动发令枪的扳机，同时向终点（被测试系统）冲去。
计时器将致使JMeter 在其范围内的每一个采样器以前延迟必定的时间。
若是您选择在一个线程组中添加多个计时器，JMeter将使用计时器的总和，并在执行该计时器所适用的采样器以前暂停该时间。能够将计时器做为采样器或控制器的子级添加，以限制将它们应用到的采样器。
要在测试计划中的单个位置提供暂停，可使用Flow Control Action Sampler。

定时器的添加路径：【测试计划】-【线程组】-【定时器】。

3.10断言

说到断言对于咱们一个测试来讲应该很熟悉了吧。断言用来验证结果是否正确，说白了就是用一个预设的结果（指望值、表达式、时间长短等条件）与实际结果匹配，匹配到成功，反之失败。断言使您能够断言有关从被测试服务器收到的响应的事实。使用断言，您基本上能够“测试”您的应用程序正在返回指望的结果。
例如，您能够断言对查询的响应将包含一些特定的文本。您指定的文本能够是Perl样式的正则表达式，而且能够指示响应包含文本，或者应与整个响应匹配。
您能够将断言添加到任何采样器。例如，您能够将断言添加到HTTP请求中以检查文本“ </ HTML> ”。而后，JMeter将检查该文本是否出如今HTTP响应中。若是JMeter找不到文本，则它将标记为失败的请求。
请注意，断言适用于其范围内的全部采样器。要将声明限制为单个采样器，请将该声明添加为采样器的子代。
要查看断言结果，请将“断言侦听器”添加到线程组。失败的断言还将显示在树视图和表侦听器中，并将计入错误百分比，例如在“汇总”和“摘要”报告中。

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”，由于咱们将其放置在线程组（全部其余分支的“父级”）中。

图1-显示配置元素可访问性的测试计划

在用户定义的变量配置元素是不一样的。不管在何处放置，都将在测试开始时对其进行处理。为简单起见，建议将元素仅放置在线程组的开始处。

配置元件的添加路径：【测试计划】-【配置元件】。

3.12前置处理器

预处理器在发出“采样器请求”以前执行一些操做。若是将预处理器附加到Sampler元素，则它将在该Sampler元素运行以前执行。预处理器最经常使用于在样品请求运行前修改其设置，或更新未从响应文本中提取的变量。有关执行预处理器的更多详细信息，请参见做用域规则。这块宏哥举一个使用这个元件的测试场景：在测试脚本的开发过程当中，咱们在请求发送以前可能会作一些环境或者参数的准备工做，那么咱们能够在前置处理器中来完成这些工做。例如：咱们对数据库进行操做前须要创建一个数据库链接，那么前置处理器就能够完成这个功能。

前置处理器的添加路径：【测试计划】-【前置处理器】。

3.13后置处理器

后置处理器通常放在取样器以后，用来处理服务器的返回结果，例如：一个Web应用程序，咱们登陆以后会返回一个SessionID，这个SessionID在登陆以后的业务操做过程当中会做为验证条件，验证用户是否合法登陆了以后才进行的业务操做。发出采样器请求后，后处理器将执行某些操做。若是将后处理器附加到Sampler元素，则它将在该Sampler元素运行以后当即执行。后处理器最经常使用于处理响应数据，常常从中提取值。有关执行后处理器的更多详细信息，请参见做用域规则。

到此，咱们已经简单了解了jmeter的基本组成原件，咱们后序的测试工做也就是使用这些元件来完成测试任务。

3.14执行顺序

0. 配置元素
1. 预处理器
2. 计时器
3. 取样器
4. 后处理器（除非SampleResult为null）
5. 断言（除非SampleResult为null）
6. 监听器（除非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.15范围鉴定规则

JMeter测试树包含分层和有序的元素。测试树中的某些元素严格地是分层的（侦听器，配置元素，后处理器，预处理器，断言，计时器），而有些则主要是有序的（控制器，采样器）。建立测试计划时，您将建立样本请求的有序列表（经过Samplers），该列表表示要执行的一组步骤。这些请求一般在也已排序的控制器中组织。给定如下测试树：

示例测试树

请求的顺序将为一，二，三，四。

某些控制器会影响其子元素的顺序，您能够在组件参考中阅读有关这些特定控制器的信息。

其余元素是分层的。例如，断言在测试树中是分层的。若是其父项是一个请求，则将其应用于该请求。若是其父级是Controller，则它将影响该Controller的全部后代请求。在如下测试树中：

层次结构示例

断言1仅适用于请求1，而断言2仅适用于请求2和3。

另外一个示例，此次使用Timers：

复杂的例子

在此示例中，对请求进行命名以反映其执行顺序。计时器＃1将应用于请求二、3和4（请注意顺序与分层元素无关）。断言1仅适用于请求三。计时器2将影响全部请求。

但愿这些示例能够清楚说明如何应用配置（分层）元素。若是您想象每一个请求都在树枝上传递给它的父级，而后传递给它的父级的父级，等等，而且每次收集该父级的全部配置元素，那么您将了解它是如何工做的。

配置元素的标题管理器，Cookie管理器和受权管理器与配置默认元素的处理方式有所不一样。“配置默认值”元素中的设置被合并为采样器能够访问的一组值。可是，管理器中的设置不会合并。若是在一个采样器的范围内有多个Manager，则仅使用一个Manager，可是目前没法指定使用 哪一个  Manager 。

3.16属性和变量

JMeter 属性在jmeter.properties中定义（有关更多详细信息，请参见入门-配置JMeter）。
属性对于jmeter是全局的，而且主要用于定义JMeter使用的某些默认值。例如，属性remote_hosts定义JMeter将尝试远程运行的服务器。能够在测试计划中引用属性-请参阅功能-读取属性 -但不能用于特定于线程的值。

JMeter 变量是每一个线程局部的。每一个线程的值能够相同，也能够不一样。
若是某个变量由线程更新，则仅更改该变量的线程副本。例如，正则表达式提取器后处理器将根据其线程读取的样本设置其变量，这些变量稍后可在同一线程中使用。有关如何引用变量和函数的详细信息，请参见函数和变量

请注意，在启动时，将使 “ 测试计划” 和“ 用户定义的变量”配置元素定义的值可用于整个测试计划。若是同一变量由多个UDV元素定义，则最后一个变量生效。线程启动后，会将初始变量集复制到每一个线程。其余元素（例如 用户参数预处理器或正则表达式提取器后处理器）可用于从新定义相同的变量（或建立新变量）。这些从新定义仅适用于当前线程。

所述的setProperty函数能够用来定义JMeter的属性。这些对于测试计划是全局的，所以能够用于在线程之间传递信息-若是须要的话。

变量和属性都区分大小写。

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

4.小结

 好了，今天有关测试计划（Test Plan）的元件就分享到这里，后边后对这些元件进行详细的介绍和说明，以及会涉及到部分元件的实际应用。灰常感谢您阅读到这里，若是您以为不错，就帮忙点个推荐呗。

您的确定就是我进步的动力。若是你感受还不错，就请鼓励一下吧！记得随手点波  推荐  不要忘记哦！！！

别忘了点 推荐 留下您来过的痕迹