jmeter性能测试

1、性能测试需求分析

性能测试需求分析与传统的功能测试需求有所不同，功能测试需求分析重点在于从用户

层面分析被测对象的功能性、易用性等质量特性，性能测试则需要从终端用户应用、系统

架构设计、硬件配置等多个纬度分析系统可能存在性能瓶颈的业务。

2、性能测试必要性评估

任何项目在开展性能测试活动之前都需要进行必要性评估。通过必要性评估活动，确认被测

对象是否必要实施性能测试活动，千万不可为了性能而性能。

通常情况下，必要性评估可以通过设定不同条件、不同权重进行分析，将评估项分为关键评估项

和一般评估项两种。关键评估项，只要有一项符合，则必须开展性能测试，而一般评估项，可通

过加权计算，超过60分，则序开展性能测试。

软件测试活动中，根据测试要求可分为功能测试与非功能测试。非功能测试，通过指的即是性能测试。

当然，具体情况具体分析。

常见性能测试关键评估项如下：

1、被测对象需通过主管部门或监管单位审查、认可，需提供性能测试报告。目前，很多企业的软件产品在正式上市

对外销售、应用时，政府机关、主管部门或监管单位，可能需求其出具功能测试报告，性能测试报告，甚至是第三方

测试报告，这种情况下，必须进行性能测试；

2、涉及财产生命安全的系统。通常情况，电商系统、金融业务系统、医疗健康评估，涉及用户或姓范自己交易，生命

安全类的，需要进行性能测试；

3、首次投入产的大型系统，具有大量用户使用的核心业务；

4、系统核心数据库、业务逻辑、软硬件升级。与历史系统对比，系统核心数据库、业务逻辑调整、软件硬件

设备升级，同样需要实施性能测试；

5、历史版本存在重大非功能缺陷或风险较大的未评估项；

6、业务量、用户量、节点增长30%以上。系统升级后，业务量、用户量、应用节点，增长量在30%以上的，

具体数值可根据实际情况调整。应用节点增长一般指甲方因业务需求，增加应用节点，银行拓展分行、分中心、分公司

营业网点等；

7、系统架构发生重大变化。不同的系统架构可能存在较大的性能差异，因此在系统架构发生变化后，

必须实施性能测试，并且在此过程中，无法通过类推的思路推断架构变化后的系统性能；

8、生产环境非功能严重缺陷修复后，生产环境在使用过程中产生重大非功能性缺陷成功修复后，

需重新开展性能测试活动，以验证修复活动是否对生产环境造成不良影响。

以上仅仅列出笔者在日常性能测试活动参考的关键评估，对于不同行业，不同测试对象可能存在的不同的关键评估

，读者可自行增减。

常见的性能测试一般评估项，主要从单次版本考虑，如果是平台性的，则为关键评估项，如果是单次版本，单个组件或业务，则从以下几个一般评估项评估权重；

1、是否在平台中处于核心位置（15分）

2、是否有升级、且升级内容中包含了外部系统对接接口、支付接口、web service调用接口等与其他系统关联接口（20分）

3、是否存在部署方式调整或优化（15分）；

4、是否增加了性能分险较高的调整（20分）；

5、是否存在客户要求必须测试的组件或业务流程（20）；

6、是否涉及多个功能缺陷的修复，且流程发生较大变化（10）；

如果上述一般评估项，总计分值超过60分，则需进行性能测试。

以本ECShop平台为例，通过针对上述关键评估项及一般评估项的评估，满足关键评估项中的第三条：

首次投产的大型系统，具有大量用户使用核心业务，因此本ECshop平台的性能测试活动必须开展。

jmeter+badboy压力测试

bin：可执行文件目录
jmeter.bat：windows的启动文件
jmeter.log：日志文件
jmeter.sh：linux的启动文件
jmeter.properties：系统配置文件
jmeter-server.bat：windows分布式测试要用到的服务器配置
jmeter-serve：linux分布式测试要用到的服务器配置
docs：接口文档目录
extras：扩展插件目录
lib：所用到的插件目录，里面全是jar包，JMeter 会自动在 JMETER_HOME/lib 和 ext 目录下寻找需要的类
Licenses jmeter证书目录
printable_docs用户使用手册

三、Jmeter功能概要

1. Jmeter工具组成部分：

资源生成器：用于生成测试过程中服务器、负载机的资源代码。（LR中的VuGen）
用户运行器：通常是一个脚本运行引擎，根据脚本要求模拟指定的用户行为。（LR中的Controller）
报表生成器：根据测试中实时地的数据生成报表，提供可视化的数据显示方式。（LR中的Analysis）
负载发生器：用于产生负载，通常以多线程或是多进程的方式模拟用户行为。（LR中Load Generators）

Test Plan (测试计划)：用来描述一个性能测试，包含与本次性能测试所有相关的功能。也就说本的性能测试的所有内容是于基于一个计划的。（相当于lr的一个测试场景）

2.Threads (Users)线程用户

A. setup thread group

　　一种特殊类型的ThreadGroup的，可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行。类似LR的init( )

2) teardown thread group.

　　一种特殊类型的ThreadGroup的，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组。类似于LR中的end( )

3）thread group(线程组).

这个就是我们通常添加运行的线程。可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。类似LR的action() ●

3.测试片段（Test Fragment）

测试片段元素是控制器上的一个种特殊的线程组，它在测试树上与线程组处于一个层级。它与线程组有所不同，因为它不被执行，除非它是一个模块控制器或者是被控制器所引用时才会被执行。

以下是线程组的8类可执行元件

4.配置元件（Config Element）

配置元件（config element）用于提供对静态数据配置的支持。如CSV Data Set config 可以将本地数据文件形成数据池（Data Pool）。

5.定时器（Timer）

定时器（Timer）用于操作之间设置等待时间，等待时间是性能测试中常用的控制客户端QPS的手端。类似于LoadRunner里面的“思考时间”。JMeter 定义了Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。

6.前置处理器（Per Processors）

用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如，HTTP URL重写修复符则可以实现URL重写，当URL中有sessionID 一类的session信息时，可以通过该处理器填充发出请求的实际的sessionID 。

7.后置处理器（Post Processors）

用于对Sampler 发出请求后得到的服务器响应进行处理。一般用来提取响应中的特定数据（类似LoadRunner测试工具中的关联概念）。

8.断言（Assertions）

断言用于检查测试中得到的相应数据等是否符合预期，断言一般用来设置检查点，用以保证性能测试过程中的数据交互是否与预期一致。

9.监听器（Listener）

是用来对测试结果数据进行处理和可视化展示的一系列元件。图行结果、查看结果树、聚合报告。都是我们经常用到的元件。注意：这个监听器可不是用来监听系统资源的元件。

JMeter有两种类型的控制器：取样器（sample）和逻辑控制器（Logic Controller），用这些原件来驱动处理一个测试。

10.取样器（sample）

取样器（Sample）是性能测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter 原生支持多种不同的sampler ，如 HTTP Request Sampler 、 FTP Request Sample 、TCP Request Sample 、JDBC Request Sampler 等，每一种不同类型的 sampler 可以根据设置的参数向服务器发出不同类型的请求。

11.逻辑控制器

逻辑控制器，包括两类无件，一类是用于控制test plan 中 sampler 节点发送请求的逻辑顺序的控制器，常用的有如果（If）控制器、switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织可控制 sampler 来节点的，如事务控制器、吞吐量控制器。