1. Jmeter相关概念简介：
Jmeter每个任务都由测试计划
组成，每个测试计划又包含了各种elements，通过不同的elements之间的组合来完成测试计划。一般常用的elements如下：
组成，每个测试计划又包含了各种elements，通过不同的elements之间的组合来完成测试计划。一般常用的elements如下：
thread group:包含一组线程，每个线程独立地执行测试计划。
sampler:采样器，有多种不同的sample实现，用来发起各种请求，如http请求，jdbc请求，javaTest请求等等。
logic controller:逻辑控制器有多种不同的实现，可以决定每个sample的执行顺序。
listener:有多种不同的实现，主要用于统计测试接话运行中的数据并展示，如可以进行图形化方式展示响应时间。
timer:定时器，有多种不同的实现，可用作每个请求见的停顿时间。
assertions:断言，有多种不同实现，可以测试sample请求后返回的内容是否符合期望值。例如可以判断html返回的内容是否符合期望。
configuration elements:配置元素，主要用作对sample的请求的参数做配置。 由于每个controller可以相互嵌套，并且具有作用域（如配置元素只在最近嵌套的一个controller中生效），所以通过上述几个元素的相互组合就可以组装出不同的测试计划。
2. 应用实例：
a) 场景一：多用户并发数压测系统。
这个场景中，100个用户并发访问系统，每个用户循环10次访问系统。
首先在jmeter新建一个测试计划，然后如下图所示把各个元素新建完毕。（图标旁边都是各elements的实例命名）
接着，对各个元素的配置进行设置：
i. 100并发：这个是一个线程组，进行如下配置：
在本例中设置了100个线程进行测试，RampUpPeriod是在制定秒数内均匀地把线程启动完毕，设置0则是同时启动，循环次数为1.
ii. 循环控制器：这是一个循环类型的逻辑控制器，它设置了其作用范围内的行为均循环10次——每个线程将循环发起10次http请求。循环控制器配置如下：
iii. HTTP请求：这是一个Sampler，是最本次测试中最核心部分，负责发起http请求。在该http sampler中，可以设置：服务器地址、访问路径、访问参数、请求方式（Get/post/etc..）等属性。因为该sampler嵌套在循环控制器内，所以将会循环10次发起请求。部分配置如下：
Figure1 http采样器配置
iv. 响应断言：这个是response断言，可以设置响应条件，然后满足断言的话返回成功或失败，后续统计结果可以用到该值。配置如下（本例子中的success是http返回的response data结果，所以只要包含success就判断断言为true）：
Figure2 断言配置
v. http请求参数设置：这是配合httpsampler使用的，就是为了单独把需要频繁配置的内容写到这里，配置方式和http sampler类似。其参数生效作用于在于最近一个嵌套控制器中。
vi. Summery Report：这是一个listener，它对测试计划中的sampler发起的请求进行统计，可以对断言成功的部分统计也可以全部统计。效果如下：
Figure3 summery report报告
因为本例只有1个http sampler，所以结果第一行就是该sampler的统计结果。
Samples表明有1000个请求发起了，Average是平均响应时间（ms），Throughput是吞吐量，其余参数望文生义基本可以明白，具体可查看jmeter参考手册。
vii. 图形结果：这是另一个listener，它对统计的结果进行图标展示，是和SummerReport相独立的另一项统计，效果如下：
Figure4 图形结果报告
图例参数基本和SummeryReport中的数据一致
这样，测试计划就完成配置了，然后就是进行测试计划启动了。
点击工具栏的
或者菜单栏的运行>启动，测试计划开始执行。执行完成后，就可以看到Figure3，Figure4的图标结果了。
或者菜单栏的运行>启动，测试计划开始执行。执行完成后，就可以看到Figure3，Figure4的图标结果了。 从结果可以看到，本次测试共发起了1000个http请求，平均每个请求的时间是24毫秒，吞吐量是318.1/秒
b) 场景二：多用户登录多步骤访问系统。
这个场景中，2个用户分别先登录系统，然后静止1秒，再依次访问2个页面。
按上面的步骤先把测试计划配置好：
Figure5测试计划2
在这个测试计划中，有2个线程组A和B，每个线程组各代表1个用户，每个用户首先各自在知识库登陆页面登陆，然后跳转到会员中心，最后访问机器列表。
这个测试计划引入了cookie管理器，这个管理器可以在登陆后把用户的cookie保存到线程中。同时在cookie管理器你可以另外设置cookie。
还引入了仅一次控制器，这个控制器可以保证线程在多次循环跑得情况下只登陆一次。
另外，登陆Fragment和页面访问Fragment是2个独立的模块，他们可以分别被2个线程组引用，达到复用的目的而不需要为2个线程组各自设置请求。
具体详情可以在附件的jmeter测试计划文件中了解到。
通过以上的基本要素，你就可以为你的应用进行基本访问行为的模拟和并发测试了。还是很方便的。
3. Ab（ApacheBench）对比
Ab也是apache下的另一个压测工具。Ab压测的并发结果和jmeter的并发测试结果会有怎么样的联系呢，我们可以对比下。在下面的例子中，在一个tomcat服务器上运行了一个简单的servlet，该servlet只是睡眠100毫秒，然后返回success给response。
Jmeter和Ab的测试结果如下表所示：
Figure6 jmeter和ab的并发压测对比
其中红色的是有错误出现，并且结果不太稳定没有继续往下再压。
可以看到，在线程数100以下时，jmeter的avg（每个线程的平均响应时间）和ab的Time per request，throughput与request per second基本是一致的，但是之后就开始相差比较大了。具体原因未明，也许是jmeter有更多的东西需要处理和基于gui的缘故，有知情者请不吝赐教。但是，如果jmeter每个线程的循环数设置到无限时候，数据显示性能就会有所提升。
综上所述，我们一般所说的QPS，TPS，对应到jmeter应该就是throughout，对应到ab应该是requestper second，结合2者，就能大致推算出应用的吞吐量大概在哪个范围了。在本例中应该在1200~1400左右。
最后再小结下。
本文主要了简述了jmeter的基本使用方式，并结合2个场景讲解了测试计划如何配置，为开发使用做了入门介绍。最后又对一个demo应用，在jmeter和ab的压测下，对结果进行了比较。最后再利用下stackoverflow的一段问答介绍两者的使用场景：
Jmeter告诉你每个请求实际上耗费多长时间。AB只是简单的用数学方式统计平均值。所以从准确性来说，jmeter比ab更准确，更多如数据处理。但是ab的速度更快，更轻巧。如果性能测试的目的在于更真实的表现被测应用，那么jmeter更佳。但如仅仅是用最少的机器资源产生最多的访问请求，那ab适合……
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
