详情
本书通过具体的示例介绍如何使用JMeter测试Web应用程序。本书共7章。第1章介绍性能测试的基础，第2章讨论如何通过浏览器录制测试计划，第3章详细讲述表单提交，第4章介绍在测试计划中如何通过JMeter管理Web会话，第5章讨论如何利用JMeter监控服务器资源，第6章阐述如何通过JMeter进行分布式测试，第7章展示一些提高测试效率的技巧。
本书适合测试人员和开发人员阅读，也可供相关的专业人士参考。
书名：【抢鲜版】-JMeter 性能测试实战（第2版）
ISBN：978-7-115-52523-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 巴约·艾林勒（Bayo Erinle）
译 黄 鹏
责任编辑 谢晓芳
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2015 Packt Publishing. First published in the English language under the title Performance Testing with JMeter, Second Edition. All rights reserved. 本书由英国Packt Publishing公司授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。 版权所有，侵权必究。
Bayo Erinle是一位作家，同时也是一位在软件开发、测试和架构设计领域有丰富经验的高级软件工程师。他曾经从事过贸易、经济和医疗卫生等行业的软件开发工作。因此，他参与过大量应用的规划、开发、实现、集成及测试，包括多层级应用、独立应用、分布式应用以及基于云的应用。他是一位对编程、性能、可扩展性以及其他IT技术充满热情的人。他常常沉迷于新技术，并且热衷于学习新东西。
目前他定居在美国马里兰州，在不研究新技术的时候，他乐于将时间留给自己的妻子Nimota以及3个孩子Mayowa、Durotimi和Fisayo。
Vinay Madan是一位质量分析顾问，拥有信息系统专业的硕士学位。他在软件测试、质量保证和测试管理（包括手动的和自动化的）方面拥有超过8年的工作经验。
他曾参与过智能卡发行、支付网关和数字化学习终端等方面的项目。他精通功能和性能自动化测试工具，如Selenium、QTP、Cucumber、JMeter以及Load Runner，同时还是一位孜孜不倦的学者。
过去几年，他致力于研究各种测试方法论，包括针对Windows、Web和移动应用的敏捷、Scrum以及定制化的瀑布式流程。
Satyajit Rai是一位对设计和开发大规模分布式系统有着浓厚兴趣的工程师。他设计并开发过大型复杂的公司级系统以及因特网规模的系统。他能够在各种平台上用各种语言进行开发。他对开发方面的实践有浓厚的兴趣，非常注重系统的性能、可靠性、可维护性以及可操作性等方面。
目前他供职于印度的Persistent Systems公司，从多方面提高各种平台上系统的性能，包括架构、设计、部署、性能评估及调优。他在这些系统中应用自己所学提高了许多系统的性能。在Persistent Systems公司，他同时也致力于推动建立AWS云平台上基于JMeter的大规模性能测试服务。
Ripon Al Wasim目前是Cefalo的一名高级软件工程师。他拥有超过13年的软件开发经验，精通软件开发和测试。同时他还担任Java和测试方面的培训师。
他是Sun公司认证的Java程序员（Sun Certified Java Programmer，SCJP），同时通过了JLPT（Japanese Language Proficiency Test, 日本语能力测试）3级考试。
他是Stack Overflow社区的活跃者。他同时也是Selenium WebDriver Practical Guide的审校者，这也是Ripon在Packt Publishing的第一份正式 工作。
性能测试是一种评估在给定的工作负载下系统或应用的响应速度、可靠性、吞吐量、互操作性以及可扩展性的测试。这对任何软件产品的成功运行和维护来说都是不可缺少的关键部分。同时性能测试也是衡量应用是否可以支持更大用户群的重要手段。
JMeter是一个免费、开源、跨平台的性能测试工具，于20世纪90年代后期面世。这是一个成熟、健全且具有高度可扩展性的工具。JMeter有大量的用户，并提供了大量用于测试的插件。
这是一本基于如何根据测试需求使用JMeter的实践指南。本书首先简单介绍了性能测试，然后快速进入正题，包括录制测试脚本、监控系统资源，同时扩展介绍了JMeter的几个元件，以及使用云进行测试，通过插件扩展JMeter的功能等。在这个过程中，你将会编写部分代码，学习使用Vagrant、Tomcat这些工具，并学习在测试工作中需要用到的所有相关知识。
无论你是开发人员还是测试人员，本书都介绍了一些非常重要的知识，这些知识对你将来从事的测试工作会有很大帮助。
第1章介绍性能测试的基础知识以及JMeter的安装和配置。
第2章介绍如何录制你的第一个JMeter测试脚本，并分析JMeter测试脚本的细节。
第3章介绍表单提交的细节。该章讨论各种HTML表单元素（复选框、单选按钮、文件上传和下载等），以及JSON数据与XML的处理。
第4章介绍会话管理，包括使用Cookie和URL重写两种方式。
第5章介绍如何监控测试执行过程中的系统资源活动，并讨论如何启动一个服务器以及通过插件扩展JMeter。
第6章深入探究如何使用云进行性能测试。该章将会介绍Vagrant和AWS这类工具，并探索目前已有的云测试平台BlazeMeter和Flood.io。
第7章介绍一些有用的小贴士，并给出在JMeter使用方面非常有效的方法和建议。
为了能够成功运行本书中提供的示例代码，你需要准备：
此外，针对第5章，你还需要准备Tomcat（参见Apache网站）。
针对第6章，你还需要准备：
书中也会结合以上所需设置提供一些其他有用的网站。
本书主要的目标读者是开发人员和测试人员。如果你是一位对性能测试感兴趣并想接触性能测试的开发人员，你会发现本书非常有用，通过练习本书中的实例，你将大幅度提升测试技能。
本书对测试人员也会非常有益，本书将指导他们解决在测试现代Web应用程序过程中遇到的实际问题，本书提供的丰富知识将使他们成为更优秀的测试人员。此外，在他们的实际测试工作中，本书中涉及的测试工具将随时派上大用场。
本书采用以下版式约定。
代码块如下所示。
name=firstName0lastName0
name_g=2
name_g0="firstName":"Larry","jobs":[{"id":1,"description":"Doctor"}],"
lastName":"Ellison"
name_g1=Larry
name_g2=Ellison
server=jmeterbook.aws.af.cm当我们希望突出代码块中的某些部分时，相关行或相关代码将会加粗，如下所示。
name=firstName0lastName0
name_g=2
name_g0="firstName":"Larry","jobs":[{"id":1,"description":"Doctor"}],"
lastName":"Ellison"
name_g1=Larry
name_g2=Ellison
server=jmeterbook.aws.af.cm所有的命令行输入和输出都将如下所示。
vagrant ssh n1
cd /opt/apache-jmeter-2.12/bin
./jmeter --version
表示警告或重要的提醒。
表示提示和技巧。
非常欢迎读者的反馈。请让我们知道你对本书的看法——不论是否喜欢。读者反馈对我们非常重要，可以帮助我们开发更多符合市场需求的选题。
可以通过发送邮件至feedback@packtpub.com提供反馈，请在反馈信息中说明本书的书名。
如果你有兴趣写书，请查看packtpub网站上的作者指南。
尽管我们已经努力确保内容的准确性，但是错误是不可避免的。如果你发现了本书中的错误（也许是文字或代码的错误），并且能提交勘误，我们将非常感谢。这不仅可以使其他读者少走弯路，还可以帮助我们改进本书随后的版本。如果你发现任何错误，请访问packtpub网站，选择你的图书，单击Errata Submission Form链接，然后输入错误的具体内容，从而提交勘误。一旦你提交的勘误被确认，这条勘误信息将上传至我们的网站或添加至本书Errata部分已有的勘误表中。
通过访问packtpub网站，输入书名，可以查看之前提交的勘误。勘误信息将会出现在Errata部分。
因特网上图书的版权问题从来就没间断过。Packt非常重视版权和授权。如果你在因特网上发现任何盗版的Packt图书，请把网址或网站名称发送给我们，便于我们及时采取补救措施。
如果怀疑是盗版书，请通过copyright@packtpub.com联系我们。
非常感谢你为保护我们的版权所做的努力，我们也将尽力提供有价值的 内容。
关于本书的任何问题，都可以通过questions@packtpub.com联系我们，我们将尽全力解答你的问题。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您所在学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
软件性能测试用于评估计算机、网络、软件系统或设备的速度或效率。这个过程涉及实验室中的定量测试，比如，测量某个系统功能的响应时间或者每秒百万条指令（Millions of Instructions Per Second，MIPS）的数值。
——维基百科
考虑一个案例分析。Baysoft Training是一家正在不断崛起的初创企业，重新定义了如何通过软件为IT领域内各行业的人群提供更多培训。这家公司为了达到这个目标，推出了一系列的产品，包括在线的课程、线上培训，以及线下的培训。该公司的旗舰产品之一TrainBot是一个纯粹用于培训课程的网站应用，旨在帮助客户达成职业生涯的目标。只要注册一个账号，客户就能够在上面学习一系列在线课程。
之前一段时间，TrainBot仍在进行内部测试，并且暂时只开放给少量客户，所以流量一直在可承受范围内。所有功能都运转正常，系统响应也非常快。为了庆祝TrainBot的发布并推广自己的在线培训课程，Baysoft Training公司将所有的培训课程以二五折销售。然而，这次促销给TrainBot造成了一次远远超出公司预期的流量涌入。Web流量达到之前的300%，运行状况越来越糟糕。网络资源也开始无法正常访问，服务器CPU和内存的占用率达到90%～95%，数据库服务器由于高的I/O速率和大量争用问题勉强正常运行。结果，大部分Web请求的响应开始变慢，大部分第一次访问TrainBot的客户完全无法访问网站。之后没过多久，服务器因为不堪重负而彻底崩溃。
这对Baysoft Training公司总部来说是一个漫长的夜晚。这一切是怎么发生的？是否可以避免？为什么应用和系统无法承受这样的负载？为什么不对系统与应用做足够的性能和压力测试？是应用的问题、系统资源的问题还是两者共有的问题？管理层将工程师团队聚集到会议室，希望得到这些问题的答案，工程师团队包括软件开发工程师、网络和系统工程师、负责质量保证（Quality Assurance，QA）的测试工程师以及数据库管理员。房间里充满了相互指责和抱怨。在一阵头脑风暴后，整个团队意识到应该确定之后需要怎么做。应用和系统资源应该经过全面而严格的测试。这包括应用的各个方面以及所有支撑的系统资源，包括但不限于基础设施、网络、数据库、服务器和负载均衡器。这个测试应该可以帮助研发团队发现性能的瓶颈并解决问题。
性能测试是一种评估在指定工作负载下系统或应用的响应能力、可靠性、吞吐量、互操作性以及可扩展性的测试。性能测试也可以定义为一种评估计算机、网络、软件应用或设备的速度或效率的过程。可以对软件应用、系统资源、目标应用元件、数据库等进行性能测试。通常测试会包含一个自动化的测试套件，该测试套件能够很容易地反复模拟各种正常值、峰值以及异常负载的情况。这种形式的测试可以评估一个系统或应用是否能达到供应商所声明的规格要求。测试过程可以比较应用在速度、数据传输率、吞吐量、带宽、效率或可靠性等方面的变化。性能测试也作为评估瓶颈和单点故障的诊断工具。通常性能测试在一个可控的环境下进行，与压力测试同时进行。性能测试也是评估系统或应用在恶劣条件下仍能保持一定级别效率的能力的过程。
为什么如此麻烦？从Baysoft的例子中我们就可以看出，为什么这么多公司会花大力气来进行性能测试了。如果在发布之前做了充足有效的性能测试，TrainBot可能就不会变成一团糟，进而演变成一场灾难了。
接下来，我们将继续探究有效的性能测试的其他优点。
从宏观上看，性能测试可节约成本，树立公司的品牌。性能测试的实施标志着软件应用的发布已经准备就绪，网络和系统资源充足，架构稳定，应用的可扩展性强等。在发布应用之前收集评估应用和系统资源的性能特性，可以帮助提前解决问题，并为项目干系人提供有价值的反馈，帮助他们做出关键的战略决策。
性能测试覆盖了几乎所有范围，例如：
几乎所有领域之间都互相关联，几乎每一方面都关系到项目干系人的整体目标。然而，在正式进入性能测试之前，让我们先了解一下性能测试实施过程的几个关键活动。
准备测试计划：使用测试工具录制计划好的测试场景。不少免费和商业测试工具都可以非常好地完成这个工作，每一个工具都有优点和 缺点。
可用的工具包括Load Runner（HP公司的产品）、NeoLoad、LoadUI、Galting、WebLOAD、WAPT、Loadster、LoadImpact、Retional Performance Tester、Testing Anywhere、OpenSTA、LoadStorm、The Grinder、Apache Benchmark和HttpPerf等。其中一些工具是商业工具，其他一些在成熟度、可移植性和可扩展性方面都不如JMeter。以HP的Load Runner为例，尽管它能够提供更优秀的图表接口和监控功能，但如果不额外购买许可证，模拟线程的数量被限制在250以内，并且相对来说比较昂贵。Gatling是这个领域的新生代，免费且看起来前途光明。Gatling目前处于初期阶段，致力于弥补JMeter的一些短板，包括用更简单的测试领域特定语言（Domain-Specific Language，DSP）来替代JMeter冗长的XML，以及使用更美观、更易于理解的HTML格式的报告等。然而，只有少量用户愿意使用Gatling来替代JMeter，并且不是所有人都习惯用Gatling的特定语言Scala来建立测试计划。Gatling可能会更受程序员的青睐。
本书中我们选择使用JMeter来进行演示，读者从本书书名应该能看出这一点。
运行测试：脚本录制完成后，在轻量负载下运行测试计划，验证测试脚本和输出结果的正确性。如果测试脚本里输入的测试数据用于模拟真实数据（后面的章节会讲到），也需要验证测试数据。在测试计划执行过程中另外一个需要关注的点是服务器日志。通常可以通过监控服务器的资源监控代理获取这些日志。重点需要关注警告和错误。例如，出现频度高的错误可能代表测试脚本、被测应用或系统资源有问题，也可能三者都有问题。
性能测试中的关键活动如图1-1所示。
图1-1 性能测试中的关键活动
性能测试通常需要各个角色合作完成，包括业务干系人、企业架构师、开发人员、测试人员、数据库管理员、系统管理员以及网络管理员。要在测试实施中获得准确、有效的测试结果，这些角色的相互合作是非常必要的。在不断的调优过程中监控网络占用率、数据库I/O、等待时间、高级查询以及调用次数可以帮助找到瓶颈或找到值得进一步关注的区域。
性能测试和调优的关系非常紧密。通常，端到端的测试会揭示系统或应用的瓶颈，这些瓶颈导致无法达到项目要求的目标。一旦发现瓶颈问题，大多数团队随后会进行各种调优，以提升应用性能。
调优工作包括但不限于以下内容：
即使应用性能已达标，如果团队希望削减使用的系统资源数量，减少硬件数量或进一步提升系统性能，则也需要进行调优。
经过调整（或一系列调整），重新执行测试以查看性能是否因此而提高。即使性能结果已达到可接受的目标，这个过程仍会继续。测试-调优循环的结果通常会产生一个基线。
基线是为评估系统或应用连续调整的效果而获取性能指标数据的过程。除为了对比性能而特意变化的特征和配置之外，保持相同的特征和配置对于有效对比某个调整（或一系列调整）在性能调优中的正面作用非常重要。对于系统设置或应用的调整之后，对应的测试结果可以与基线结果比较，以确定调整是否有意义。在收集基线数据时需要考虑如下几点。
负载测试是给系统加压并测量其响应的过程，主要用于确定系统能承受的最大负荷。压力测试是通过给系统施加比正常情况下高出很多的负载并判定其响应能力的过程。压力测试与性能测试有所区别，性能测试的唯一目的是确定系统的响应和有效性，即系统有多快。因为都关注负载对系统响应的影响，所以性能测试通常几乎都会和压力测试同时进行。
前面几节介绍了性能测试的基础。性能测试的其中一部分就是测试工具。你通过什么工具给系统或应用加压呢？从免费工具到商业解决方案，非常多的测试工具可以完成这个工作。然而，本书重点关注的是JMeter，由Apache软件基金会发布的一款免费、开源、跨平台的桌面应用。JMeter从1998年问世以来的历史变更可通过它的官方网站查看，经过变迁，它已经成为一款成熟、功能健全且可信赖的测试工具。成本原因也促进了JMeter的广泛使用。小公司通常不会为商业测试工具支付费用，而且这些商业测试工具还有各种限制，例如，对同时并发的用户数有限制。我第一次接触JMeter正是因为这个限制。当时我在一个小公司工作，公司购买了一个商业测试工具，但是在测试过程中，为了模拟真实的测试计划，我们需要并发的用户数超出了许可的限制。而JMeter是完全免费的，我们试用了JMeter，它免费提供的大量功能真的让我们喜出望外。
以下是JMeter的部分功能。
JMeter可以模拟应用上多个并发的用户请求，这可以帮你达到本章前面提到的目标，例如，获取基线、识别瓶颈等。
JMeter将帮助你回答类似以下问题。
然而，不应该把JMeter和浏览器混淆（更多内容请参考第2章以及第3章）。JMeter无法执行所有浏览器支持的操作，尤其是JMeter无法执行HTML页面中的JavaScript代码，也无法像浏览器那样提交HTML页面。然而，通过各种监听器，你可以查看HTML格式的请求和响应，但是时间控制不会包含在任何请求中。此外，同一台机器上的并发用户数有限制。这依赖于机器性能（如内存、处理器个数等）以及运行的测试场景。根据我们的经验，在一台拥有2.2GHz处理器和8GB RAM的机器上可以支持250～250个并发用户。
现在，安装和运行JMeter。
通过JMeter的包文件安装它非常简单。最好在有防火墙的企业环境中或非管理员特权的机器上安装JMeter。首先，可以通过Apache网站获取最新发布的二进制文件。编写此书时，最新发布的版本是2.12。Apache网站也提供了扩展名为.zip和.tar的安装包，可以选择扩展名是.zip的文件，但如果你喜欢.tgz文件，也可以免费下载。
下载完成后，将文件解压到指定的目录下。在本书中，这个文件解压的目标路径将指定为JMETER_HOME。确保JDK/JRE正确安装并设置了JAVA_HOME环境变量。所有准备工作完成后，就可以开始运行JMeter了。
图1-2展示了JMeter安装目录的结构。
图1-2 JMeter安装目录的结构
以下是图1-2展示的Apache-JMeter-2.12的部分目录。
根据以下步骤安装Java JDK。
（1）访问Oracle网站。
（2）下载与你的系统适配的Java JDK（非JRE）。编写本书时，最新版本是JDK1.8（update 20），这也是本书中所使用的版本。
（3）双击可执行文件，并根据屏幕上的提示逐步操作。
在Windows系统中，JDK的默认安装目录是Program Files。这本来是没问题的，唯一的问题是这个目录名称包含空格，在设置路径或通过命令行运行像JMeter这种依赖JDK的程序时可能会有问题。因此，建议修改JDK的默认安装路径，例如修改为C:\tools\jdk。
以下是在Windows和UNIX操作系统上设置JAVA_HOME环境变量的 步骤。
出于讲解需要，假设你已经在C:\tools\jdk中安装了JDK。
（1）进入控制面板。
（2）单击“系统”，打开“系统属性”对话框。
（3）在“系统属性”对话框中，单击“高级”选项卡，并单击“环境变量”按钮，打开“环境变量”对话框。
（4）把“变量名”设置为JAVA_HOME。“变量值”设置为“C:\tools\jdk”。
（5）选中Path（在“系统变量”下面，位于界面中部）。
（6）单击“编辑”按钮。
（7）在已有的Path值（如果有的话）末尾添加%JAVA_HOME%/bin。
出于讲解需要，假设你已经在/opt/tools/jdk中安装了JDK。
（1）打开一个终端窗口。
（2）导入JAVA_HOME=/opt/tools/jdk。
（3）导入PATH=$PATH:$JAVA_HOME。
建议将这个设置添加到shell配置文件（对于bash用户是.bash_profile；对于zsh用户是.zshrc）中，这样就不用每次打开新的终端窗口时都需要重新设置一遍。
JMeter安装好后，JMETER_HOME下的bin目录下包含了所有可执行脚本。根据JMeter所在的操作系统，要么在UNIX/Linux系列操作系统上执行shell脚本（.sh文件），要么在Windows系列操作系统上执行批处理脚本（.bat文件）。
把JMeter文件另存为扩展名为.jmx的XML文件。本书中把JMeter文件称为测试脚本或JMX文件。
这些脚本包括以下几个。
要在UNIX/Linux系统上启动JMeter，首先打开一个shell终端，切换到JMETER_HOME/bin目录，然后运行如下命令。
./jmeter.sh在Windows系统下运行如下命令。
jmeter.bat
稍后在配置代理服务器时，将能看到JMeter的GUI。可以花点时间研究一下GUI。把鼠标指针悬停在每一个图标上面，可以看到这个图标的功能。JMeter团队已经把GUI设计得非常出色了。大多数图标与你之前使用过的相似，这将降低你的学习成本并缩短适应时间。部分图标（如停止和关闭）目前是禁用的，直到场景设置完结/测试正在进行时才启用。在下一章中，当录制我们的第一个测试脚本时，我们将会学习GUI的更多细节。
在终端窗口中，你可能会看到Java 8的一些警告，一些Java选项（PermSize和MaxPerSize）可能被忽略。不用惊慌。JDK 8有着更出色的内存管理功能，一些之前用于启动JMeter的默认的Java选项不再是必要的了，所以可以忽略它。可以从Dzone网站和InfoQ网站了解更多信息。
JVM_ARGS环境变量可用于覆盖jmeter.bat或jmeter.sh脚本里的JVM设置。可以参考如下例子。
export JVM_ARGS="-Xms1024m -Xmx1024m -Dpropname= propvalue"当以错误的选项运行JMeter时会显示使用信息。可用选项如下。
./jmeter.sh - -h, --help print usage information and exit -v, --version print the version information and exit -p, --propfile<argument> thejmeter property file to use -q, --addprop<argument> additionalJMeter property file(s) -t, --testfile<argument> thejmeter test(.jmx) file to run -l, --logfile <argument> the file to log samples to -j, --jmeterlogfile<argument> jmeter run log file (jmeter.log) -n, --nongui run JMeter in nongui mode
以上只是其中一部分命令行选项（非完整列表），可以使用相关命令查看完整列表。本书后面会介绍其他的选项，但是也不会全部介绍。
因为JMeter是100%的纯Java应用，所以它能够实现大部分测试用例。然而，有时可能需要引入非默认的第三方库中的功能或自己开发的其他功能。因此，JMeter提供了两个路径来放置第三方库，使通过环境变量可自动引入。
如果你工作的地方设置了企业级防火墙，你可能需要通过配置代理服务器地址和端口号来使用JMeter。JMeter提供了启动时的附加命令行参数来达到这个目的。部分参数如下。
./jmeter.sh -H proxy.server –P 7567 -u username -a password在Windows平台下，运行jmeter.bat文件。
不要把这里提到的代理服务器和JMeter内置的HTTP代码服务器混淆，内置的HTTP代理服务器用于录制HTTP或HTTPS的浏览器会话。在下一章中录制第一个测试场景时，会介绍相关内容。
JMeter GUI如图1-3显示。
图1-3 JMeter GUI
如上所述，JMeter也可以以非GUI模式运行。在你希望远程运行或希望通过减少运行GUI的额外开支优化测试系统时，这是非常必要的。通常可以通过默认GUI模式准备测试脚本并在低负载条件下运行，但是高负载情况下应该以非GUI模式运行。
可以使用以下命令行选项。
此外，也可以像之前看到的那样使用-H和-P选项指定代理服务主机与 端口，如下所示。
./jmeter.sh -n -t test_plan_01.jmx -l log.jtl
通常在进行分布式测试时会使用服务器模式，这需要使用更多的测试服务器以在系统上产生更大的负载。具体命令如下。在服务器模式下在每个远程服务器（从服务器）上都会启动JMeter，在主服务器上也会启动一个GUI，用于控制所有的从节点。第4章会详细介绍这部分内容。
./jmeter-server.sh
如果你希望单个测试结束之后退出服务器，则可以指定JMeter属性server.exitaftertest=true。默认情况下这个属性设置为false。
JMeter提供了两种方式来重写Java、JMeter和日志属性。一种是直接编辑JMETER_HOME/bin目录下的jmeter.properties。第一眼看到这个文件，你会看到大量可重写的属性。正因为如此，JMeter才如此强大和灵活。大多数情况下，不需要重写默认属性，因为通常默认值都是非常合理的。
另一种重写属性的方式是在启动JMeter时直接通过命令行指定。
可用的选项包括以下几个。
./jmeter.sh -Duser.dir=/home/bobbyflare/jmeter_stuff \
-Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG
一旦通过命令行选项对日志系统进行了设置，就无法通过-J标记更新log_level或log_file的属性了。
在测试过程中，JMeter会默认将所有的错误记录在jmeter.log文件里。这个文件位于启动JMeter的文件夹下。就像大多数配置一样，这个日志文件的名字也可以通过jmeter.properties或通过命令行参数-j <name_of_log_file>配置。如图1-4所示，在运行GUI时，错误数会显示在右上方（用箭头标出），即，位于测试中运行的线程数的左边。单击错误数会直接在GUI的底部显示日志文件的内容。日志文件会清晰地显示测试运行时JMeter的详细情况，帮助你确定错误发生的原因。
图1-4 JMeter GUI中显示的错误数
如果要定制JMeter的默认值，可以编辑JMETER_HOME/bin目录下的jmeter.properties，或复制一份配置文件，并将其重命名（例如，my-jmeter. properties），然后在启动JMeter的时候作为命令行选项指定它。
可配置的部分选项包括以下几个。
命令行选项按以下顺序处理。
接下来，初始化日志。
接下来，加载user.properties（如果有）。
接下来，加载system.properties（如果有）。
最后，处理其他命令行选项。
本章介绍了性能测试的基础，同时也讨论了一般性能测试中涉及的关键概念和活动。此外，本章还讲述了如何安装JMeter并成功启动它，也探索了部分可用配置，并介绍了JMeter的一些选项，正是这些配置使JMeter成为一款强大的工具。JMeter的强大之处在于免费、成熟、开源、易扩展、可定制、完全扩平台，并且有一个非常强大的插件生态系统，拥有一个庞大的用户社区，具有内置的GUI，支持录制，支持不同测试场景的验证。和其他性能测试工具相比，JMeter有其独到之处。
在下一章中，我们将录制第一个测试场景并继续深入理解JMeter。
JMeter内置了一个测试脚本录制器，用于录制测试计划，测试脚本录制器也称作代理服务器。一旦设置成功，测试脚本录制器将会观察你在网站上的各种操作，为它们创建测试请求样本，并最终存储在你的测试计划（即JMX文件）中。此外，有些重要测试场景的录制非常困难，所以JMeter提供了另外一种手动创建测试计划的方式。使用代理录制器录制测试脚本只需要花很少的时间，这将节约大量的时间。
为了录制第一个测试，我们将录制用户通常访问JMeter官方网站的过程。为了使代理服务器能够观察到你的动作，需要配置代理服务器。主要分为如下两步。
（1）配置JMeter的HTTP(S)测试脚本录制器。
（2）配置浏览器使用的代理。
第一步是配置JMeter的代理服务器。整个过程分为以下步骤。
（1）启动JMeter。
（2）右击Test Plan，选择Add→Threads(User)→Thread Group，添加一个线程组。
（3）右击WorkBench，选择Add→Non-Test Elements→HTTP(S) Test Script Recorder，添加HTTP测试脚本录制器。
（4）修改端口号为7000（在Global Settings下面）。
（5）如果需要，也可以选择其他端口。重要的是，需要选择一个目前没被机器上的已有进程使用的端口。默认端口是8080。
（6）在Test plan content部分，从Target Controller下拉框中选择选项Test Plan>Thread Group。
（7）使录制的操作面向步骤（2）中创建的线程组。
（8）在Test plan content部分，从Grouping下拉框中选择Put each group in a new transaction controller。
（9）将一组请求组成一次页面加载。本章后面将进一步探讨该主题。
（10）单击Add suggested Excludes（在URL Patterns to Exclude下）。
（11）使代理服务器不录制与测试运行无关的请求的一系列元素。这包括JavaScript文件、样式表及图片。庆幸的是，JMeter提供了一个非常方便的按钮，用于排除不需要的元素。
（12）单击HTTP(S) Test Script Recorder底部的Start按钮。
（13）单击OK按钮，接受Root CA certificate。
经过这些设置之后，代理服务器将在端口7000启动，监控经过这个端口的所有请求，并使用默认录制控制器把这些请求录制到测试计划中。要了解更多细节，请参考图2-1。
图2-1 设置JMeter HTTP(S)测试脚本录制器
在JMeter以前的版本（2.10版之前）中，现在的HTTP(S)测试脚本录制器叫作HTTP代理服务器。
我们已经手动配置好了HTTP(S)测试脚本录制器，JMeter的较新版本 （2.10及之后的版本）为常见的任务提供了一个预先绑定的模板，这使配置容易多了。使用绑定的录制器模板，通过单击几个按钮可以就完成脚本录制器的配置。可以单击工具栏中的New File按钮右边的Templates按钮。然后从SelectTemplate下拉列表中选择Recording。修改端口为你想指定的端口（例如，7000），然后单击Create按钮。具体操作可参考图2-2。
图2-2 通过模板录制器配置JMeter HTTP(S)测试脚本录制器
要配置浏览器代理服务器，有几种方式可供选择。本节将介绍最常见的两种方式——使用浏览器扩展程序和修改系统配置。
Google Chrome和FireFox有一个活跃的浏览器插件生态系统，可以通过安装插件来扩展浏览器的功能。要设置代理，可以使用FoxyProxy。这个整洁的浏览器插件可以帮助你完成各种代理设置，不会与机器上的系统设置混淆并可以自由切换各种设置。这简化了这个工作。幸运的是，FoxyProxy有Internet Explorer、Chrome和FireFox的插件。如果你正在使用，建议继续用下去。
对于一些更喜欢配置操作系统级别的代理的测试人员，本节提供了在Windows和Mac系统上配置的步骤。
在Windows系统上，按照如下步骤可完成代理设置。
（1）单击Start，选择Control Panel。
（2）单击Network and Internet。
（3）单击Internet Options。
（4）在Internet Options对话框，单击Connections标签。
（5）单击Local Area Network (LAN) Settings按钮。
（6）勾选Use a proxy server for your LAN(These settings will not apply to dial-up or VPN connections)复选框，启用代理服务器，如图2-3所示。
（7）在Address文本框中，输入localhost作为IP地址。
（8）在Port文本框中，输入7000（与之前你设置的JMeter代理的端口一致）。
（9）如果你希望跳过本地IP地址的代理服务器，勾选Bypass proxy server for local addresses复选框。
（10）单击OK按钮完成代理配置过程。
图2-3 在Windows 7上手动配置代理
在Mac系统上，参考如下步骤配置代理，如图2-4所示。
（1）打开System Preferences对话框。
（2）单击Network选项。
（3）单击Advanced按钮。
（4）选择Proxies标签。
（5）勾选Web Proxy (HTTP)复选框。
（6）在Web Proxy Server文本框中输入localhost。
（7）端口设置为7000（与你之前设置的JMeter代理一致）。
（8）参考以上步骤配置Secure Web Proxy (HTTPS)。.
（9）单击OK按钮。
图2-4 在Mac OS上手动配置代理
对于其他操作系统，请参考相关的操作系统文档。
现在一切准备就绪，连接也已经建立了，下面我们通过如下步骤开始录制。
（1）访问Apache网站。
（2）单击About下的Changes链接。[1]
（3）单击Documentation下的User Manual链接。
（4）通过单击Stop按钮停止HTTP(S)测试脚本录制器，这样它不再录制其他活动。
（5）如果你正确完成以上步骤，你的动作将被录制在测试计划中。详情请参见图2-5。
图2-5 在测试计划中录制的动作
恭喜你！你已经成功录制了你的第一个测试。诚然，我们刚刚接触的只是测试计划录制的皮毛，但是我们已经有了一个好的开始了。在本书接下来的几章中，我们将录制一些更复杂的测试计划。
refName_matchNr：匹配的数字，可以是0。refName_n：n是模板生成的字符串，比如，1、2、3等。refName_n_gm：m是用于匹配的组的编号，例如，0、1、2等。refName：设置为默认值（如果有）。refName_gn：没有设置。现在我们可以直接回放或者运行我们刚刚录制的测试场景，但是在那之前，我们先要添加一个或两个监听器，用于向我们反馈运行结果。我们将会在第5章讨论资源监控时介绍监听器，但是现在我们只需要知道它们是可以展示测试运行结果的元件就行了。单个测试计划可使用的监听器的数量没有限制，但是我们通常会使用1～2个。
这里要为测试计划添加3个监听器来说明用途。按照如下步骤添加一个Graph Results监听器、一个View Results Tree监听器和一个Aggregate Report监听器。每一个监听器会收集不同的指标数据来帮助我们分析性能测试结果。
（1）右击Test Plan，选择Add→Listener→View Results Tree。
（2）右击Test Plan，选择Add→Listener→Aggregate Report。
（3）右击Test Plan，选择Add→Listener→Graph Results。
为了能观察到更多有意思的数据，我们按照以下步骤变更线程组的部分设置。
（1）单击Thread Group。
（2）在Thread Properties中设置属性。
这样设置后，根据测试计划将运行10个用户，所有用户将在15s内启动，并且每一个用户将执行30次录制的测试场景。执行测试前，先单击工具栏中的“保存”按钮，保存测试计划。
保存测试计划后，单击“开始”图标（菜单栏上的三角形图标），然后观察测试的运行情况。测试开始运行后，可以单击Graph Results监听器（或另外两个监听器），观察实时收集的结果。这是JMeter的诸多功能之一。
通过Aggregate Report监听器，可以推断针对changes链接和user manual链接分别有600条请求。同时，我们可以看到多数用户（90% Line）都在200ms内接收到正确的响应。此外，我们可以看到各个链接每秒的吞吐量，并且在测试运行的过程中没有出错，如图2-6所示。
图2-6 通过Aggregate Report监听器看到的结果
通过View Results Tree监听器，可以看到changes链接失败的请求以及失败的原因。这些信息对开发人员或系统工程师诊断错误的根本原因非常有价值，如图2-7所示。
图2-7 通过View Results Tree监听器看到的结果
图2-7展示了View Results Tree监听器中的内容。如果你在测试运行的时候单击View Results Tree监听器，你将在发出请求时看到实时图形。图形的含义一目了然，几条线分别代表平均值、中值、偏差以及吞吐量。Average、Median和Deviation分别表示每分钟样本的均值、中值和偏差数量，而Throughput表示测试过程中网络上包的平均传输速率（以bit/s为单位）。请查阅相关网站（例如维基百科）来进一步详细了解以上概念的含义。图形是交互式的，可以选择显示/不显示所有相关/不相关数据。例如，我们可能最关注均值和吞吐量。取消勾选Data、Median和Deviation复选框之后，你就会看到只剩下Average和Throughput的曲线。详情见图2-8。
图2-8 通过Graph Results监听器看到的结果
通过之前录制的小场景，你已经了解了组成一个JMeter测试计划的几个主要部分。接下来我们录制另外一个场景，这一次将使用另一个应用，这个应用允许我们输入表单的值。我们将在下一章深入了解这部分知识，但现在先睹为快。
Excilys依赖于它所创建的网站，是一家专注于提供IT技术和服务的公司。这是一个用于说明测试场景录制的轻量级银行Web应用。参考之前的步骤，新建一个测试计划，设置脚本录制器，然后开始录制，如图2-8所示。
执行以下操作。
（1）访问excilysbank网站。
（2）在登录表单中输入如下用户名user1和密码password1。
（3）单击PERSONAL CHECKING链接。
（4）单击Transfers标签。
（5）单击My Accounts。
（6）单击Joint Checking链接。
（7）单击Transfers标签。
（8）单击Cards标签。
（9）单击Operations标签。
（10）单击Log out按钮。
（11）单击Stop按钮终止代理服务器。
这样场景就录制完了。现在可以如之前一样添加监听器来收集运行结果并回放录制的场景。之后的结果可能会让你感到惊讶（如果我们没使用自带的录制器模板）。登录之后会有几条失败的请求，这是因为我们没有添加管理会话和Cookie的元件，必须有这个元件才能成功回放这个场景。幸运的是，JMeter正好就有一个这样的元件，叫作HTTP Cookie管理器。在登录后，一旦客户端与服务器端建立起连接，这个看起来简单但实际功能强大的元件就可以通过HTTP Cookie帮助你保持对话一直有效。一旦成功认证Cookie，就存储Cookie并传递给后续请求，以便后续请求能够顺利通过，这项工作由HTTP Cookie管理器保证完成。每一个JMeter线程（也称为用户）都有自己的Cookie收集区。这一点至关重要，因为你肯定不希望一个用户使用另一个用户的身份访问网站。在我们测试多个用户需要认证和授权的网站（如刚才我们所录制的那个一样）时这会非常常见。通过右击Test Plan并选择Add→Config Element→HTTP Cookie Manager为测试计划添加这个元件。
在添加完这个元件后，就可以成功地运行测试计划了。现在，可以通过增加线程组级别的线程数来模拟更大的负载。执行结束后，我们会发现测试计划执行成功了，但是这个结果并不真实。我们本质上只模拟了一个用户重复5次。所有的线程使用的都是user1的凭证，这意味着所有线程都作为user1登录系统。这不是我们希望的。为了使结果更真实，我们需要做的是把每一个线程作为应用的不同用户进行验证。在现实中，银行会为你创建唯一的用户，只有你才有权查看你的账户详情。与你同一条街道的邻居，即使使用了同样的银行，也无法访问你的账户（至少我们希望不能）。考虑到这一点，我们稍微调整测试以适应这种场景。
可以为测试计划添加一个CSV Data Set Config元件（选择Test Plan→Add→Config Element→CSV Data Set Config）。因为运行时需要消耗大量CPU和内存资源，所以在运行时生成特有的随机数代价昂贵，建议在前期生成数据。CSV数据集配置元件从文件中读取数据并将它们分别作为测试计划的输入。JMeter允许你将这个元件设置在测试计划上。通常你会在HTTP请求级别添加这个元件，用于需要输入的请求。在这里的例子中，在登录的HTTP请求中，要输入用户名和密码。还可以在线程组级别添加这个元件，作为线程组的直接子节点。如果一个特定的数据集只应用于一个线程组，建议在这个级别添加。除了前面两种情况之外，还可以在测试计划的根级添加这个元件。如果一个数据集应用于所有执行的线程，那么就可以在根级添加这个元件。在我们看来，这使测试计划的可读性更高，可维护性更高，因为根级上的元件比其他级别上的元件更容易看到，所以检查或者排错更简单。针对这里的测试场景，在测试计划的根级添加这个元件。
添加进测试计划后，也可以通过拖曳的方式移动元件。
添加完之后（见图2-9），如果输入文件包含数据头，你仅需要输入Filename（文件名）。例如，如果输入文件是这样定义的，只需要输入Filename项。
user, password, account_id
user1, password1, 1图2-9 添加的CSV Data Set Config元件
如果不填写Variable Names字段，则JMeter会使用输入文件的第一行作为变量名。如果文件中不含数据头，则可以在这里输入变量名。另外一个比较有趣的设置是Sharing mode。默认的共享模式是All threads，表示所有运行的线程都可以使用同一个数据集。所以如果你有两个运行的线程，线程1将使用第1行数据作为输入，而线程2则使用第2行数据作为输入。默认情况下，Recycle on EOF设置为True，表示如果线程数超出输入数据行数，则从文件的第1行开始重用。Sharing mode的另外两个选项分别是Current threadgroup和Current thread。前者用于某一线程组特有的数据集，而后者用于每一个线程特有的数据集。元件的其他属性都一目了然，更多信息可以在JMeter的在线用户指南上找到。
现在已经添加了元件，我们可以通过文件（或csvconfig元件）中定义的变量名来参数化HTTP登录请求，这样在测试执行过程中，相关的值就可以动态绑定了。我们分别将HTTP登录请求的用户名修改为${user}，密码修改为${password}，如图2-10所示。
${}中的值与输入文件中定义的数据头或CSV数据集配置元件的Variable Names项中的输入一致。
图2-10 HTTP请求中参数值的绑定
现在可以运行测试计划了，运行结果应该和之前一样，只是这一次的值是根据之前的配置动态绑定的。目前为止，我们都针对单个用户运行。我们可以提升线程组数量，针对10个用户运行，30s内启动完毕，只循环一次。现在重新运行测试。观察测试结果，我们会发现部分请求失败了，返回状态码403，这表示拒绝访问。这是因为我们试图访问一个非当前登录用户的账号。在该示例中，所有的用户请求都发往账户4，但是账户4只允许一个用户（user1）查看。可以通过添加一个View Results Tree监听器跟踪测试计划和返回的结果。
如果你仔细观察View Results Tree监听器中的Request选项卡中的某些HTTP请求，你会注意到如下请求。
/private/bank/account/ACC1/operations.html
/private/bank/account/ACC1/year/2013/month/1/page/0/operations.json
…细心的读者应该已经注意到，输入数据文件也包含了account_id列。也可以对这一列进行调整，参数化所有包含账号的请求，获取所有已登录用户正确的账号。为此，可参考如下这行代码。
/private/bank/account/ACC1/operations.html修改后的代码如下所示。
/private/bank/account/ACC${account_id}/operations.html再看如下代码。
/private/bank/account/ACC1/year/2013/month/1/page/0/operations.json修改后的代码如下所示。
/private/bank/account/ACC${account_id}/year/2013/month/1/page/0/
operations.json对其他代码也做类似修改。对于所有类似请求，也可参考以上操作。修改完成后，重新运行测试计划，这次，所有逻辑都正确，正常运行。测试执行结束后，可以通过观察View Results Tree监听器来确认一切是否符合预期，单击一些账户请求的URL，把请求展示方式由文本变为HTML，你将可以看到除ACCT1之外的其他账号。
我们来看看另一种场景。有时候，与其把响应作为输入数据的一列发送，不如解析响应来获得所需信息。解析的响应可能是任意的文本格式。其中包括JSON、HTML、TXT、XML和CSS等。这将使测试计划更健壮。我们在之前的测试计划中已经用到这个功能，解析响应以获得需要的用户账号，而没有作为输出参数发送响应。解析响应获得账号后，可以保存账号并用于后续的其他请求。我们继续参考之前的操作录制一个新的测试计划。为了从响应数据中提取变量，我们需要用到JMeter的后置处理器元件之一，即正则表达式提取器（Regular Expression Extractor）。这个元件作用于每个样本请求，通过正则表达式提取请求的值。然后生成一个模板字符串，把结果存储至一个变量名中。这个变量名再用于参数化，例如，我们之前在CSV Data Set Config元件中看到的。
我们添加了一个Regular Expression Extractor元件作为/login请求下/ private/bank/accounts.html HTTP请求的子元素。不像我们之前看到的CSV Data Set Config元件，这个元件直接作为请求的子元素，因此它是一个后置处理器元件。它的配置如图2-11所示。
图2-11 通过View Results Tree监听器来验证响应数据
在配置Regular Expression Extractor元件时，每一项的设置如下。
图2-12展示了设置以上所有项之后元件的外观。
配置完成后，像我们之前做的那样用${account_id}变量参数化其他账户请求。现在，可以重新运行测试计划，我们将得到和之前填入一个带account_id列的数据集的类似表现和输出。你现在已经看到了创建测试计划时两种获取同样信息的方式。尽管你的使用场景可能和这里看到的完全不同，但是原理相同。
图2-12 配置Regular Expression Extractor元件
以下是Regular Expression Extractor元件的各种配置变量的简要介绍。
0：表示JMeter随机使用匹配的值。N：表示使用第N个匹配的值。refName：表示模板的值。refName_gn：表示匹配的组，例如，n可以取1、2、3等。refName_g：正则表达式中组的序号（不含0）。
注意，当没有匹配的内容时，变量refName_g0、refName_g1和refName_g都被移除，把refName（如果存在）的值设置成默认值。
通过前面的例子，我们已经了解了JMeter大致的结构。我们已经清楚了一个JMeter测试计划主要的构成。本章剩余部分将介绍一个JMeter测试的分解及构成，如图2-13所示。
图2-13 一个JMeter测试的分解及构成
测试计划是JMeter脚本的根元素，其中可以包含其他元件，例如，线程、配置元素、定时器、前置处理器、后置处理器、断言以及监听器。同时，测试计划也提供了一小部分自己的配置。
首先，可以定义用于脚本中的用户变量（键-值对）。然后，可以配置测试计划所含的线程组应该如何运行，即，指定线程组是否同时运行。随着时间的推移，一个测试计划通常会有多个线程组。通过这个选项决定线程组如何运行。默认所有线程组同时运行。刚开始的时候一个比较有用的选项是Functional Test Mode。检查结束时，每个样本返回的服务器响应都会被记录下来。对于小的模拟运行，确保JMeter设置正确且服务器端返回了预期的结果是非常有用的，但是不好的地方是JMeter的性能会恶化且文件非常大。这个选项默认是关闭（off）的，在模拟真正的测试场景时通常是不会选中的。另一个比较有用的选择是添加第三方库的能力，这可用于为测试用例提供额外的功能。当你的模拟测试场景需要JMeter默认自带库以外的其他库时就用到这个选项了。通常，你都会通过这个选项来添加 JAR文件。
线程组是所有测试计划的入口点。它们代表了JMeter用于运行测试计划的线程/用户的数量。一个测试的所有控制器和采样器都必须放在线程组下面。在你想把其他元素（如监听器）应用于所有线程组时，可以直接把这些元素放在测试计划下，如果它们只应用于一个线程组，就放在指定的线程组下。线程组设置提供的选项包括指定用于测试计划的线程个数、所有线程启动要花的时间以及测试将会运行的次数。每一个线程都将完全独立于其他线程运行测试计划。JMeter将多个线程拆分开来模拟对服务器的并发连接。注意，启动所有线程的时间应该设置足够长以避免在测试开始时负载过大，过大的负载可能导致网络饱和，测试结果失败。如果你希望模拟系统中的X个活跃用户，最好慢慢提升并增加迭代次数。最后一个设置选项是调度器。通过调度器可以设置测试执行的开始时间和结束时间。比如，可以在非高峰时段启动测试，可以精确到小时。
控制器负责驱动测试的运行，包括取样控制器和逻辑控制器。
一方面，取样控制器向服务器端发送请求。其中包括HTTP、FTP、JDBC、LDAP等请求。尽管JMeter有一系列取样器，但因为我们主要关注Web应用的测试，所以本书主要关注的是HTTP请求取样器。
另一方面，逻辑控制器可以定制用于发送请求的逻辑。例如，循环控制器可以用于重复执行指定次数的操作，选择控制器可以用于选择性执行请求，同时条件控制器会持续执行请求，直到某些条件不满足等。在本书写作的同时，JMeter 2.12集合了16种不同的控制器，分别用于不同的用途。
取样器用于向服务器发送请求并等待响应。所有树上的请求会依次处理。JMeter包含以下类型的取样器：
这些取样器的属性可以根据需求进一步调整。多数情况下，可以使用默认的配置。为取样器增加断言，可以对服务器响应进行基本验证。通常在测试过程中，服务器端都会返回状态码200，代表请求是成功的，但是可能无法正确显示页面。在这种情况下，断言可以帮助你确保请求是成功的。
逻辑控制器帮助我们定制用于决定请求如何发往服务器的逻辑。其中可能涉及修改请求，重复发送请求，交错发送请求，控制请求执行的时间，切换请求，测量请求执行所花的总时间等。在本书创作的时候，JMeter已经配备了16种逻辑控制器。请参考Apache网站上的JMeter在线用户指南来了解每一种逻辑控制器的详细说明。
测试块是专门用于测试计划中代码重用的一种特殊的控制器。它们在测试计划树上与线程组处于同一级，除非被包含或被模块控制器引用，否则它们不会执行。
监听器主要用于收集用于进一步分析的测试执行结果。此外，监听器也可将数据直接写入文件，供下一步使用。此外，监听器还可以定义保存哪些字段以及使用CSV格式还是XML格式。所有监听器都会保存相同的数据，唯一不同的是展现在屏幕上的方式。监听器可以在测试的任何地方添加，包括直接加在测试计划下面。监听器只会收集同级或下级元素的数据。
针对各种不同的用途，JMeter包含了18种不同的监听器。虽然你可能经常只会用到其中的一部分，但是建议你熟悉它们，知道在什么时候使用。
部分监听器（如Assertion Results、Comparision Assertion Visualizer、Distribution Graph、Graph Results、Spline Visualizer和View Results Tree监听器）都非常占内存和CPU，在实际测试运行过程中都建议不要使用。它们通常用于调试或功能测试。
默认JMeter线程组在发送每个请求的过程中不会暂停。建议为线程组添加一个定时器，用于指定一个短暂的延时。这将使测试计划更接近实际使用场景，真正的用户不可能同时发送多个请求。定时器用于使JMeter在发送每个请求前暂停固定的时间。
断言用于判断从服务器端接收到的响应。从本质上说，通过断言可以判断应用的功能是否正确以及服务器端是否返回预期结果。断言可在XML、JSON、HTTP以及从服务器端返回的其他形式的响应上运行。因为断言也会占用大量资源，所以在实际测试运行期间不要使用断言。
配置元件通常和取样器一起使用，可以修改或添加请求。只有在放置元件的分支里面，才能访问树中的配置元件。配置元素包括HTTP Cookie管理器、HTTP头管理器等。
顾名思义，前置处理器在发出请求之前会执行一系列操作。前置处理器通常用于在请求执行前修改请求设置或更新那些不是从响应文本中提取出来的变量。
后置处理器会在发出请求后执行一系列操作。后置处理器通常用于操作响应文本并从中提取相关数值。
本章不仅介绍了如何配置JMeter以及如何通过浏览器来录制测试计划，还讲述了一些内置元件，这些元件可以帮助我们为测试计划添加数据或从服务器响应中提取数据。此外，本章还讨论了如何构成一个JMeter测试计划。
下一章将进一步讨论表单提交并探索更多的JMeter元件。
[1] 最新版本网站已经去掉这个链接，可用其他链接替代。——译者注。
