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平台的性能测试活动必须开展。

性能测试需求分析

与功能测试需求分析一样，性能测试同样需要针对被测对象进行需求分析。

一般而言，用户或产品团队设定性能测试需求时，仅会表述字面意义上的需求，如：

“系统TPS需达到300以上，单笔交易时间不超过3秒”等。需要性能测试工程师结合用户需求及性能测试活动本身需求进行显性与隐性性能测试需求的分解与提取。随着互联网技术的飞速发展，互联网应用架构越来越复杂，运营系统涉及的利益相关方越来越多，因此，在确定性能测试的必要性后，性能测试工程师主要从以下两个用户确定性能测试需求；

业务用户

1、用户频繁使用，且存在大量用户使用的业务流程；

2、交易占比较高，日常占比在80%以上甚至更高的业务流程；

3、特殊交易日或峰值交易占比80%以上甚至更高的业务流程；

4、性能较差且有过调整的业务流程；

5、特殊业务场景；

6、核心业务发生重大流程调整的业务流程。

以上从业务用户层面，考虑的可能需要进行性能测试的点，时间实施过程中，如果可能，可向终端用户调研

项目团队

1、曾经测试过性能后调整了架构设计的业务；

2、逻辑复杂，关键的业务；

3、可能消耗大量资源的业务；

4、与外部系统存在接口调用，且有大量数据交互的业务；

5、调用第三方业务组件，逻辑复杂的业务。

以上从项目开发角度考虑可能需要进行性能测试业务流程，性能测试工程师需对被测对象深入了解，并且需要研发团队配合。

除上述两种用户，还可能包括运营团队，调研未来业务发展规划，系统需满足未来业务需求的可能性。

性能测试需求评审

确定性能测试需求后，如有必要，需要进行某种程度的测试需求评审活动。性能测试需求评审与共测试需求评审类似，都需关注需求本身的可测性、一致性及正确性。

可测性 

软件可测性，通常理解为软件本身是否具备实施测试的条件，是否便于发现缺陷及定位缺陷。在一定的时间及成本范围内，构建测试环境，设计及执行测试用例，测试工程师能够相对便捷的发现、定位缺陷，从而协助研发人员解决对应的缺陷，无论

是功能测试，都需要被测对象具备上述的可测试特性。

性能测试活动与功能测试活动有个显著的特点是被测对象运行环境要求不同。实施功能测试时，主要被测对象能够在合理的运行环境中正常运行即可，即使测试环境与生产环境可能存在较大的差异，性能测试则不同，一定需要模拟尽可能真实的运行环境。当测试环境与实际生产环境差异较大时，性能测试结果往往不被接受，如果在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测对象不具备性能的可测性。

一致性

性能测试需求一致，主要关注用户需求、生产需求，运营需求几个方面。通过对性能测试需求的分析，判断本次测试需求是否满足用户需求规格说明书中明确列出的性能要求项。生产需求，则是关注被测对象运行的真实性，从而在测试结束后能够提供相对准确的数据依据。

运营要求，需以历史数据或者现今运营数据为基础，规划未来业务发展的可能性，从而使得被测对象性能指标具有一定的冗余度。

通过性能测试需求评审活动，确定本次性能需求与上述的关注点一致。

正确性

在可测性与一致性得到保证的基础上，需针对性能测试指标进行校验，从而保证后续实施活动中所关注的各个项目需求、场景及指标的正确性，从而尽量减少返工、重新设计的分险。

通过可测性、一致性及正确的评估、最终确定本轮性能测试需求，并以此作为后续测试实施活动的输入。

性能测试工作实施

1、需求分析与定义

针对本次项目性能测试的必要性评估，敏捷开发团队确定实施该次性能测试活动，并利用开源性能测试工具jmeter开展，根据被测对象的应用特性，获取具体的性能测试需求。

一般而言，被测对象的性能需求，会在用户需求规格说明书中给出，如单位时间内的访问量需达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，性能指标以量化形式给出。

相对规范的产品，产品团队一般会给出性能测试要求：

测试项                   响应时间        业务成功率      并发数          CPU使用率         内存使用率

随机购买商品           <=5秒               100%           100                  <=80%                  <=80%

以上的表给出性能指标非常明确，性能测试活动实施过程中，测试工程师只需收集商品购买业务的响应时间、访问成功率、并发数、CPU使用率、内存使用率等相关指标的监测数据。满足相关指标，则测试通过，若未满足，则需要进行问题分析定位，最终进行调优与回归，直至达到性能测试需求。

有明确性能需求时，测试活动相对来说较为容易开展，但实际工作中，经常会碰到没有明确性能需求的测试要求。因此，测试工程师具备根据不同输入分析，获取性能需求的能力。以本次项目为例，产品团队并未指明性能测试需求，那么测试工程师如何分析提取量化的性能指标呢？

从用户应用角度考虑，被测对象常用业务性能存在瓶颈的话，很容易引起客户的反感。以登录功能为例，输入用户与密码，点击登录按钮到显示成功登录信息，如果耗时1分钟，这样的速度用户绝对无法忍受。用户不常用的功能，比如年度年度报表汇总功能，三个季度甚至是一年才使用，等10分钟或者更长时间也是正常的。不同的应用频率，决定了用户的使用感受，也决定了测试的需求，针对本次ECshoop电商系统而言，商城用户经常使用的功能，且存在大量用户使用的业务为用户注册，登录、随机浏览

商品及购买业务等，而其他功能则相对用户较少，具体的数据如果系统已经运营，则可从系统运营日志分析。如果尚未上线运营，则需要调研用户或根据自身经验进行分析获取。

指标分析与定义

通常情况下，性能测试关注被测对象的时间与资源利用特性及稳定性。时间特性，即被测对象实现业务交易过程中所需的处理时间，从用户角度来说，越短越好。资源利用特性，即被测对象的系统资源占用情况，一般web系统不关注客户端的资源占用情况，仅关注服务端，通常为服务器端的cpu、内存、网络带宽、磁盘等（根据被测对象架构设计，还可分为web服务器、中间件、数据库、负载均衡等）。稳定性，关注被测对象在一定负载情况下，持续稳定性提供服务的能力。

不同的被测对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包含以下几个性能指标：

并发数

并发，即为同时出发，从应用系统架构层面来看，并发意为单位时间内服务器接受到的请求数。客户端的某个具体业务行为包括了若干个请求，因此，并发数被抽象理解为客户端单位时间内发送给服务端的请求，而客户端的业务请求一般为用户操作行为

因此，并发数，也可理解为并发用户数，而这些用户是虚拟的，有可称为虚拟用户。

并发数，广义来讲，是单位时间内同时发送给服务器的业务请求，不限定具体业务类型，狭义来看，是单位时间内同时发送给服务器的相同的业务请求，需限定具体业务类型。在性能测试实施过程中需注意二者的区别。

响应时间

目前大多数的软件系统客户端与服务器交互过程如下图，用户通过客服端（如浏览器）发出业务请求（网络传输时间T1）,服务器接收并处理该请求（服务器处理时间T2），然后根据实际的处理模型返回结果（网络返回数据时间T3），客户端接收请求结果（客户端处理展示时间T4）。在这个处理流程中，涉及到的各个业务节点的处理时间总和T1+T2+T3即为系统响应时间。这个时间的计算忽略用户端数据呈现的时间T4。从用户角度来讲，用户应用客户端发出业务请求，到客户端（通常为浏览器）展现相应的请求结果，这个时间越短越好，即用户视角的响应时间过程所消耗的时间，记录为响应时间，即服务器仅关注T2的处理时间。因此，不同的视角，衡量的响应时间指标也不同。

使用客户端——客户端展示        发送请求T1      服务器处理（T2）

                                                    返回数据T3

通过上述两个不同视角的描述不难发现，用户与服务器所理解的响应时间存在明显的差异。用户关注的是发出请求至看到响应结果的时间，而服务器关注的是接受请求到返回结果的时间，对于用户而言，忽略了浏览器展示的时间，对于服务器而言，则忽略了浏览器展示、网络传输等时间。因此，在实际测试过程中，需明确以什么视角验证被测对象的性能。

大多数的情况下，性能测试主要以用户视角进行，因此在实际测试过程中，通常关注用户行为，所以，响应时间一般指客户端发出请求到接受到服务器端的响应数据所消耗的时间。

需注意的是，性能测试工作中，客户有时可能需要测试公网的系统来验证性能指标，从测试经验来看，最后不要尝试在公网进行性能测试，原因二：

可能影响现网用户。实施性能测试过程中，可能产生大量的压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际业务。

压力模拟可能无法真实体现。性能测试工程师实施性能测试时，利用测试工具，模拟了大量的并发数，产生了大量的业务数据，但因负载生成器所在的网络与服务器所在的网络不同，或者服务器的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败。

有一种情况除外，模拟固定宽带网络访问的场景，可在局域网中使用限制宽带的手段进行测试。遵循一个原则，测试过程中，任何资源都必须可控。

吞吐量

单位时间内系统处理用户请求的数量，可以用请求数/单位时间或者点击数/单位时间，或者字节数/单位时间等方式来衡量，其中通过字节数/单位时间的计算方式，与当前的网络宽带比较，可以找出网络方面的问题。例如：1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=16.7.吞吐量指标直接体现了软件系统的业务处理能力，尤其适用于系统架构选型，做对比测试。

系统资源耗用

系统资源耗用，客户端与服务器系统各项硬件资源的耗用情况，如：CPU使用率、内存使用率、网络宽带占用率、磁盘I/O输入输出量等。一个系统的高效运行，除了软件资源外，硬件资源也是不可缺少的部分，因此在性能测试过程中，需关注系统资源的耗时。

业务成功率

业务成功率意为用户发起了多笔业务请求，成功的比率有多少。例如，测试银行营业系统的并发处理性能，全北京100个网点，中午12:30到13:30一个小时的高峰期里，要求能支持50000笔开户业务，其中成功率不少于98%，也就是需要成功开户49000笔，其它的1000笔可能是超时的，或者其他错误导致未能开户成功。业务成功率展示了在特定压力或负载情况下，服务器正确稳定处理业务请求的能力。

TPS

单位时间内服务器处理的事务数，该指标值越大越好，一般情况下，用户业务操作过程可能细分为若干个事务，单位时间处理

数越多，说明服务器的处理能力越强

根据上述各个指标的概念，结合被测对象本身的业务情况，做出如下测试需求及指标分析。

ECShoop是一个面向广大网络用户在某个时间段访问该电商平台，进行网络购物，但如何确定用户访问的时间段呢？changji

 

场景用例设计

性能测试过程中，首先应该设计测试场景，模拟真实业务发生的情境，然后是针对场景设计脚本。

为了真实的反映被测对象可能存在的性能问题，需要尽可能模拟被测对象可能发生瓶颈的业务场景。测试需求分析过程中已经确定了需要测试的业务类型，在此，则需要设计针对每种或综合业务的测试场景。

性能测试场景通过包括单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务稳定性测试等7种常用测试场景。

单业务基准测试

测试某个具体业务是否满足系统设计或用户期望的性能指标，如用户期望系统支付接口支持50个用户并发支付，如果满足了，则认为基准测试完成，否则失败。基准测试过程中，性能指标的任何一项均需成功，才认为基准测试完成。基准测试可分为并发基准及业务量基准两种，其目的都在于验证是否满足于其目标设定。

单业务压力测试

测试某个具体业务在最大负载下，持续服务的时长，以此验证被测业务的稳定性。压力测试过程中所设计的负载，是以系统基准负载为标准，如系统基准负载为50个并发用户，则压力测试的负载设置为50个，通过运行时长的变化，验证服务器在系统预设负载下持续服务的能力。具体的时长从需求分析、运行日志、系统设计规划等来源获取。

单业务负责测试

测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数，如系统基准负载为50个，则通过多次测试，逐步加大负载，最终获得被测业务的最佳负载。在最佳负载下，系统仍需要满足各项性能指标。

综合业务基准测试

与单业务基准测试类似，但综合业务需考虑业务与业务间的联系，如果相互之间存在资源争用，则需单独组合测试。假设系统需测试的业务有：A、B、C，综合业务基准测试是将ABC一起运行，那么加上A、B、C三个基准测试，共计4个基准测试场景，分别是ABC、A、B、C，但A与C存在资源争用，则需单独将A与B组合，构成一个单独的测试场景，则一共为ABC、A、B、C、AC等5个基准测试场景。

综合业务测试中的数据分配，根据实际业务、用户需求、运行日志、运营规划等分析确定。

假设某银行柜员交易系统，1个小时内有4个柜员进行存款操作，6个柜员进行开户操作，10个柜员进行查询操作，则综合业务的负载比例设置为：

存款业务占比：4/（4+6+10）=20%

开户业务占比：6/（4+6+10）=30%

查询业务占比：10/（4+6+10）=50%

综合业务压力测试

与单业务压力测试类似。

综合业务负载测试

与单业务负载测试类似。

综合业务稳定性测试

综合业务稳定性测试通过为核心业务在基准负载的基础上运行相对长的时间，验证服务器持续提供稳定服务的能力。稳定性场景测试的时间由需求方设定，一般为7*24小时不间断执行。

通过上述分析，根据ECShoop平台业务模型确定本次性能测试的场景主要为登录并发基准测试、登录业务量基准测试、商品随机浏览购买并发基准测试、商品随机浏览购买业务量基准测试等四个场景。

场景设计中需设置线程数，当需求未明确指出时该如何确定呢？

以本次测试为例，要求在2小时内支持5万用户登录，可通过如下计算方式获取线程数。

Total_Thread=BC/(T*60*60/t)

T:考察时间段，如此处的2小时。

t：单位用户单次业务消耗时间，即单个用户完成一次业务过程所消耗的时间，尽可能模拟用户的真实性未。

BC：业务量，如此处的5万。

利用jmeter测试单次业务消耗时间，代入公式即可获得执行2小时5万用户登录所需的线程数。

 如上图所示：ECShoop用户登录系统单次消耗时间采用90%抽样为：88+135=223毫秒，如果加上模拟用户输入用户名及密码、登录成功后等待返回主页、退出后等操作的思考时间，以5秒、3秒、3秒计算，则单用户访问ECShoop登录所消耗时间为：0.223秒+5秒+3秒+3秒=11.223秒。

则代入上述公式。获得模拟2小时5万用户登录所需的线程数为：

Total_Thread=50000/(2*60*60/11.223)=77.88

因线程个数无法为小数，故取整数为78个线程数。

同样方法，计算用户登录后随机选择商品浏览的消耗时间，然后计算出线程数，具体数据如下：

脚本用例设计

性能测试过程中，因测试目的不同，可能存在多个不同的场景，但往往只需设计一个脚本。如针对某个业务进行基准测试、压力测试和负载测试，虽然设计三个场景，但脚步可能只有一个。测试工程师需要根据场景设计，分析所需的测试脚本并开发。

通常情况下，测试工程师可根据被测业务可能存在的约束进行分析，确定脚本优化及增强方案。以本次测试要求，利用jmeter开发脚本为例，登录、随机购买商品业务脚本用例如下：

 

测试数据构造

测试工程师深入了解被测业务交互过程、确定脚本用例后，可能需根据测试需求构造性能测试过程中所需的测试数据。以登录为例，为了更真实的模拟不同用户登录、随机购买商品等行为，可针对登录用户名，随机购买的商品信息进行参数化设计，保证每次登录或购买商品信息都不相同，尽可能模拟真实的业务行为。因此，需在测试开始前系统中存在大量需要的用户信息及商品信息。

以本次测试为例，2小时内5万个用户登录，则意味着escshop内需存在5万以上的可用账号，而系统安装初期并没有提供这么多账号。

测试过程中，测试工程师可利用jmeter构造测试数据，当然，如果能够直接在数据库中利用存储过程生成是最好的方法，因为效率相对较高，但要求对表结构相对熟悉。

本次测试所需的5万以上的可用账号，测试工程师利用jmeter模拟真实用户注册行为，设置30个线程，每个线程进行2000次迭代，即可完成6万个注册账号，便于后期测试使用。构造测试账号后，可将数据备份，便于回归测试。以下详细介绍本次测试账号构造过程。

 

 

 

 

jmeter+badboy压力测试

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

三、Jmeter功能概要

1. Jmeter工具组成部分：

1. 资源生成器：用于生成测试过程中服务器、负载机的资源代码。（LR中的VuGen）
2. 用户运行器： 通常是一个脚本运行引擎，根据脚本要求模拟指定的用户行为。（LR中的Controller）
3.  
4. 报表生成器：根据测试中实时地的数据生成报表，提供可视化的数据显示方式。（LR中的Analysis）
5. 负载发生器：用于产生负载，通常以多线程或是多进程的方式模拟用户行为。（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 来节点的，如 事务控制器、吞吐量控制器。

 

 

举个例子进行操作

1、打开badboy，输入需要录制的地址，点击绿色箭头的图标就可以运行

2、下图就是录制成功啦

3、录制完成之后，导出脚本，保存脚本到指定的文件夹。操作步骤：点击File Export to JMeter，点击“保存”按钮即保存成功。

 

4、保存成功之后，打开jmeter，操作步骤：我的路径如下图

 

5、打开jmeter成功以后，打开badboy的保存脚本，点击“文件”，打开你需要的文件即可

6、可以看到测试计划多了一个，然后线程组就是定义并发数目，step就是压测的步骤，意思就是比如1000个并发，就会模拟1000个人，不断重复刚刚我录制的操作，登录邮箱，退出邮箱这样。

7、双击Thread Group线程组，就可以定义线程数，循环次数，随机间隔时间。想做压力测试，当然线程数越多压力越大，间隔越小越大。

 

8、添加监听器，查看压测的结果，操作步骤：点击Thread Groud,右键添加——监听器(查看结果树、用表格查看结果、聚合报告)

9、最后运行，查看结果数

到这里就是压力测试完成啦！

 

补充知识点：

线程组主要包含三个参数：线程数、准备时长（Ramp-Up Period(in seconds)）、循环次数。

1. 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。
2. 准备时长（单位为s）：设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ，准备时长为10 ，那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。
3. 循环次数：每个线程发送请求的次数。如果线程数为20 ，循环次数为5，那么每个线程发送5次请求。总请求数为20*5=100 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。

HTTP请求

• 特定资源，可以在下方的Embedded URLs must match 文本框中填入需要下载的特定资源表达式，这样，只有能匹配指定正则表达式的URL指向资源会被下载。

用作监视器：此取样器被当成监视器，在Monitor一个HTTP请求有着许多的配置参数，下面将详细介绍：

• 名称：本属性用于标识一个取样器，建议使用一个有意义的名称。
• 注释：对于测试没有任何作用，仅用户记录用户可读的注释信息。
• 服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。
• 端口号：目标服务器的端口号，默认值为80 。
• Timeouts（milliseconds）：设置请求和响应的超时时间
• 协议：向目标服务器发送HTTP请求时的协议，可以是http或者是https ，默认值为http 。
• 方法：发送HTTP请求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
• Content encoding ：内容的编码方式，默认值为iso8859
• 路径：目标URL路径（不包括服务器地址和端口）
• 自动重定向：如果选中该选项，当发送HTTP请求后得到的响应是302/301时，JMeter 自动重定向到新的页面。
• Use keep Alive ： 当该选项被选中时，jmeter 和目标服务器之间使用 Keep-Alive方式(又称持久连接、连接重用)进行HTTP通信，默认选中。
• Use multipart/from-data for HTTP POST ：当发送HTTP POST 请求时，使用Use multipart/from-data方法发送，默认不选中。
• 同请求一起发送参数 ： 在请求中发送URL参数，对于带参数的URL ，jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中，表中的每一行是一个参数值对（对应RUL中的 名称1=值1）。
• 同请求一起发送文件：在请求中发送文件，通常HTTP文件上传行为可以通过这种方式模拟。
• 从HTML文件获取所有有内含的资源：当该选项被选中时，jmeter在发出HTTP请求并获得响应的HTML文件内容后，还对该HTML进行分析并获取HTML中包含的所有资源（图片、flash等），默认不选中，如果用户只希望获取页面中的 Results Listener 中可以直接看到基于该取样器的图形化统计信息。默认为不选中。
• Save response as MD5 hash? ：选中该项，在执行时仅记录服务端响应数据的MD5值，而不记录完整的响应数据。在需要进行数据量非常大的测试时，建议选中该项以减少取样器记录响应数据的开销。

tips 默认时间单位是毫秒 报告输出文件后缀 .jtl

 第三步：设置QPS限制

Jmeter提供了一个非常有用的定时器，称为Constant Throughput Timer （常数吞吐量定时器），该定时器可以方便地控制给定的取样器发送请求的吞吐量。

 

Constant Throughput Timer 的主要属性介绍：

Target throughput（in samples per minute）：目标吞吐量。注意这里是每分钟发送的请求数，实际填的数值为：60*QPS 其次Calculate Throughput based on ：有5个选项，分别是：

1. This thread only ：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的 target Throughput 乘以该线程的数量。
2. All active threads ： 设置的target Throughput 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
3. All active threads （shared ）：与All active threads 的选项基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
4. All active threads in current thread group ：设置的target Throughput将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和All active threads选项的效果完全相同。
5. All cative threads in current thread group （shared ）：与All active threads in current thread group 基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

第四步：添加监视器

脚本的主要部分设置完成后，需要通过某种方式获得性能测试中的测试结果，在本例中，我们关心的是请求的响应时间。

Jmeter 中使用监听器元件收集取样器记录的数据并以可视化的方式来呈现。Jmeter有各种不同的监听器类型，因为上HTTP请求，我们可在添加聚合报告，更为直观的查看测试结果。

添加聚合报告，右键点击线程组，在弹的菜单（添加--->监听器--->聚合报告）中选择聚合报告。

添加查看结果树 （添加--->监听器--->查看结果树）