jmeter实践
本文主要介绍性能测试中的常用工具jmeter的使用方式，以方便开发人员在自测过程中就能自己动手对系统进行自动压测和模拟用户操作访问请求。最后还用Linux下的压测工具ab做了简单对比。
1. Jmeter相关概念简介：
JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。
Jmeter每个任务都由测试计划
组成，每个测试计划又包含了各种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的图标结果了。
从结果可以看到，本次测试共发起了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适合……
