压力测试工具JMeter入门教程<转>

1.Jmeter 概要描叙

jmeter 是一款专门用于功能测试和压力测试的轻量级测试开发平台。多数情况下是用作压力测试，该测试工具在阿里巴巴有着广泛的使用，估计是不要钱吧，哈哈，功能上来说，整个平台实现了许多和互联网相关的网络测试组件，同时还保留着很强的扩展性方便用于一些非标准的测试场景，让伟大的程序猿同学来告诉它该如何工作。下面我们开始。

2.Jmeter 基本界面和组件的概念

现在看到了Jmeter的主界面。下面介绍Jmeter中主要组件的功能和作用, 首先我们看看Jmeter在概念上的组件分类如图

1.Threads：这个组件主要用来控制Jmeter并发时产生线程的数量，在它的下一级菜单下只有一个组件（线程组），可以这么理解每个线程就是一个虚拟的用户。所有的其他类型组件必须是（线程组）节点的子节点。

2.配置单元：和Sample组件一起工作，主要用来配置Sample如何来发起请求访问服务器，这个东西的主要特点是可以把一些Sample的共同配置放在一个元素里面方便管理，配置单元是有作用域的。作用域和树的那个关系一样越是上级节点的作用域越大，越是接近叶子节点的

作用域就越小，可以复写上级作用域的配置。

3.定时器 ： 这个主要是用来调节（线程组），控制线程每次运行测试逻辑（比如说：发出请求）的时间间隔。当然这个下面还有很多类型的定时器，他们主要功能就是调节时间间隔，但个个组件之间的策略有很大不同。

4.前置处理器 和 后置处理器类似一个HOOK，在测试执行之前和执行之后执行一些脚本的逻辑。该组件我还没有具体使用过，但大致功能就是这样，非重点组件。

5.Sample ： 可能上图中没有出现Sample，需要在（ThreadGroup）上添加才可以，见图

Sample表示客户端发送某种格式或者规范的请求到服务端，所以大家看到了各种各样的Sample，其中有两个Http 相关的。一般用HttpClient功能和效率将更强。

6.断言： 意思是指对于Sample完成了请求发送之后，判断一下返回的结果是否满足期望。

7.监听器 : 这个组件不同于平时在Web编程的那种监听器，他是伴随着Jemeter测试的运行而从中抓取运行期间的数据的一个组件，经常使用的是聚合报告组件，从里面可以统计到测试的TPS，响应时间等关键测试数据。

3.实例操作

首先在TestPlan下面添加一个ThreadGroup组件，设置线程组组件各项参数

关键参数解释 ：

线程数：最大测试时使用的线程数。

Ramp-Up Period : Jmeter达到指定最大线程数的时间。

循环次数 : 如果是Forever，线程组中的线程将不间断的连续测试系统，当然也可以设置每个线程测试的次数，当完成了规定次数后，该线程将自动退出线程组。

调度器 ： 主要用来指定该测试的一些时间信息，比如从几点到几点运行测试，如果到了指定时间测试没有进行完成，测试也会被停止。

接着在线程组下面添加Sample组件，我们添加一个HTTP Request HTTPClient组件，设置属性如下图:

最后添加监听器组件 ：Aggregate Report， 大功告成！

运行：

好了，一个简单的压力测试例子完成了。大家可以从report中间看到一些性能结果的参数了。下面我们完成一个更复杂的例子。

4.自定义Sample或者协议完成测试

问题：在某些场景下我们会发现Jmeter里面提供的各种Sample不能满足自己的需求，应为这个世界上的压力测试的逻辑本来就是千变万化的，所以这个时候我们如果自己实现一套测试逻辑，这个时候需要使用jmeter 的扩展性。下面我们通过一个简单的例子来看看如何开发这样的一个自定义Sample？ 自定Sample的生命周期是怎样的？

1. package com.alibaba.stress.load;
2. import org.apache.jmeter.config.Arguments;
3. import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
4. import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
5. import org.apache.jmeter.samplers.SampleResult;
6. public class LifecycleJMeterSampleextends AbstractJavaSamplerClient {
7. @Override
8. public Arguments getDefaultParameters() {
9. System.out.println("Get Parameter name! [getDefaultParameters]");
10. return super.getDefaultParameters();
11. }
12. @Override
13. public void setupTest(JavaSamplerContext context) {
14. System.out.println("[setupTest]");
15. super.setupTest(context);
16. }
17. @Override
18. public void teardownTest(JavaSamplerContext context) {
19. System.out.println("[teardownTest]");
20. super.teardownTest(context);
21. }
22. @Override
23. public SampleResult runTest(JavaSamplerContext ctx) {
24. SampleResult result = new SampleResult();
25. result.sampleStart();
26. System.out.println("[runTest]");
27. result.setSuccessful(true);
28. result.sampleEnd();
29. return result;
30. }
31. }

1. package com.alibaba.stress.load;
2. import org.apache.jmeter.config.Arguments;
3. import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
4. import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
5. import org.apache.jmeter.samplers.SampleResult;
6. public class LifecycleJMeterSample extends AbstractJavaSamplerClient {
7. @Override
8. public Arguments getDefaultParameters() {
9. System.out.println("Get Parameter name! [getDefaultParameters]");
10. return super.getDefaultParameters();
11. }
12. @Override
13. public void setupTest(JavaSamplerContext context) {
14. System.out.println("[setupTest]");
15. super.setupTest(context);
16. }
17. @Override
18. public void teardownTest(JavaSamplerContext context) {
19. System.out.println("[teardownTest]");
20. super.teardownTest(context);
21. }
22. @Override
23. public SampleResult runTest(JavaSamplerContext ctx) {
24. SampleResult result = new SampleResult();
25. result.sampleStart();
26. System.out.println("[runTest]");
27. result.setSuccessful(true);
28. result.sampleEnd();
29. return result;
30. }
31. }

1. package com.alibaba.stress.load;
2. import org.apache.jmeter.config.Arguments;
3. import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
4. import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
5. import org.apache.jmeter.samplers.SampleResult;
6. public class LifecycleJMeterSample extends AbstractJavaSamplerClient {
7. @Override
8. public Arguments getDefaultParameters() {
9. System.out.println("Get Parameter name! [getDefaultParameters]");
10. return super.getDefaultParameters();
11. }
12. @Override
13. public void setupTest(JavaSamplerContext context) {
14. System.out.println("[setupTest]");
15. super.setupTest(context);
16. }
17. @Override
18. public void teardownTest(JavaSamplerContext context) {
19. System.out.println("[teardownTest]");
20. super.teardownTest(context);
21. }
22. @Override
23. public SampleResult runTest(JavaSamplerContext ctx) {
24. SampleResult result = new SampleResult();
25. result.sampleStart();
26. System.out.println("[runTest]");
27. result.setSuccessful(true);
28. result.sampleEnd();
29. return result;
30. }
31. }

其中AbstractJavaSamplerClient是从ApacheJmeter_Java.jar 中获得。编写的类文件打包xxx.jar, 把这个Jar放到Jmeter的解压目录下的lib/ext下。重新启动jmeter.

一次先加入线程组，和聚合报告两个组件，在聚合报告组件之前加入一个新的Sample（JavaSample ）, 如图：

运行测试。可以看到控制台的输出。调整几次线程组的线程数目的控制，我们会发现我们的这个自定义类中的teardowntest 和 setupuptest方法都是正对线程组中的某一个线程来执行的，线程组中线程的调用数目其实就是指runtest方法的运行次数。

5.Jmeter的分布式测试（优缺点）

下面是分布式测试的使用方法，即使用一台机器控制多台机器给目标机器产生压力。由于Linux和Windows上的方法有些不一样，这里说下Linux下是怎么来配置的。

首先总控的机器我们叫master,产生压力的肉鸡我们叫JmeterServer，待我们测试的系统我们叫Target.

第一步：启动JmeterServer。我们可以找到Jmeter/bin 目录下的jmeter-server这个脚本，运行即可，当然如果你需要调整这个测试负载产生服务器的内存等性能参数的话，我们修改这个脚本jmeter中的内存参数。

第二步 : 修改Master机器上jmeter/bin目录下的jmeter.properties文件，修改remote_hosts=localhost:1099,localhost:2010这个为你自己的JmeterServer的实际IP，如果有多台可以用逗号分开。

第三步 ： 启动master jmeter，运行测试脚本的时候选：运行 --> 远程运行 --> 选择IP 或者 运行所有远程。JmeterServer就会运行Master机器上设定的运行脚本了。

问题 ： 我在实际使用中发现使用这种模式下的Jmeter在Master观测实际测试结果，发现TPS远远低于使用传统的一台Jmeter来测试所能达到的TPS，我感觉可能是由于Jmeter这种多机器协作中传递信息是使用RMI技术，可能这种技术本身还对Jmeter的性能产生了影响导致压力上去的很慢。该问题还没有得到完全认证，所以我现在如果在一台机器测试产生的压力不够的情况下我直接使用多台机器测把TPS加起来就是结果，比较傻，期待大侠指点迷津。