JMETER-性能测试

                                        性能需求分析

需求分析是个繁杂过程，它并非我们想象的那么简单，而性能测试需求除了要对系统的业务非常了解，还需要有深厚性能测试知识。才能够挖掘分析出真正的性能需求。

1、如何获得有效的需求

1.1、客户方提出

客户方能提出明确的性能需求，说明对方很重视性能测试，这样的企业一般是金融、电信、银行、医疗器械等；他们一般对系统的性能要求非常高，对性能也非常了解。提出需求也比较明确。
曾经有一个银行项目，已经到最后的性能测试极端，因为数据库设计不合理，导致性能出现很大的问题，最终不得不把整合项目作废，对于这样的项目，其实从分析设计阶段就应该考虑系统的性能问题。性能测试也一样，对于某些项目来说越早进行越好。当然，前期的性能测试为单元性能测试、接口性能测试，有别系统性能测试。

2、根据历史数据分析

对于一些面向用户的独特产品，比较难定位市场的大小，可以先上一运营一段时间，通过运营可以搜集客户资料，比如，每月、每星期、每天的峰值业务量是多少。用户以什么样的速度在递增中。用户对系统的哪些功能模块使用的最多，他们所点的比例等等。收集到这些数据之后，我们就可评估系统的系统需求指标，从而进行性能测试。

3、需求分析与定位

这里根据前期的需求分析与定位，来分析确定系统性能指标。例如某省幼儿园管理系统。统计全省有多少家幼儿园，系统的使用时间为幼儿到校之后，管理人员对幼儿的到校情况进行录入，以及幼儿的午饭，放学情况的录入时间。经过与需求人员交流分析也能得到比较明确的性能指标。

4、参考历史项目或其它同行业的项目

如果公司之前有类似的项目经验，根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制定出相应的性能指标。
即使本公司没有类似的项目，但其它公司有类似的项目，例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

5、参考其它资料数据

如果你做的是非常独特的产品，市场上没有此类型的产品，而且需求及市场也难以估计，那么只能从与产品相关的资料中寻找痕迹了。不过，相信这样不确定性的产品，老板要承担的风险也是挺大的。

需要说明的是，我上面介绍的方面并非是独立的，可以综合的使用，你可以根据客户提出的指标，再根据历史数据以及参考同类型项目来进行。这样可以更确定你的性能指标是客户（或自己）真正需要的、最符合项目需求的。

2、性能测试点的选取

*　　发生频率非常高的（例如：某核心业务系统中的登录、收发等业务，它们在每天的业务总量中占到90%以上）
*　　关键程度非常高的（产品经理认为绝对不能出现问题的，如登录，扫码，支付等）
*　　资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）

3、常见性能需求

1、接口的响应速度达到300ms以下。
2、系统服务支持50万个在线用户
3、接口成功率达到99.5%以上。
4、在100个并发用户的高峰期，系统的基本功能，处理能力至少达到10TPS
5、这个系统能否支撑200万的vu（每天登录系统的人次）          vu----Virtual user(虚拟用户)

"不成文"的性能需求指标：
80/20原则：又称帕累托效应，比如，某一些系统一天中80%的访问量集中在20%的时间内。

4、下面来分析某移动支付的需求：

按照2018年日交易笔数的目标为1000万笔：

如何得到每秒的交易笔数？

一： 严格的根据2/8原则  ，80%的订单集中在20%的时间生成。

集中订单交易数：  10000000*80%=8000000笔

集中发送的时间：24*20%=4.8小时=17280秒

每秒生成的订单数：8000000/17280=462.9笔/秒

二：另外的200W交易笔数请求分布在另外的23个小时内，因为考虑到半夜之后基本没什么请求量，假设另外的200W次请求分布在10:00-24:00，那么我们另外一个指标是 2000000/14/3600 = 39.68 （稳定支持这样的TPS）

5、性能测试场景设计

峰值场景设计： 设计符合业务场景的高压力场景，比如大量并发集中在半小时-1小时内

稳定场景设计: 8-10小时的长时间稳定压力场景

性能瓶颈压测场景： 逐步增加压力，寻找业务请求瓶颈（适用于没有业务指标，技术优化类）

秒杀类超大并发场景设计: 测试秒杀场景

6、性能测试通过标准

达到目标预期

                                Jmeter性能工具的运用

上一节中，我们根据业务量算出了TPS

1）测试目标接口：扫码接口

2）测试目的是该接口在负载达到462.9TPS 时的响应时间。

TPS 解释

　　TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。

包括了

1）用户请求服务器

2）服务器自己的内部处理

3）服务器返回给用户

　　为了达成预期的测目的，需要需要在jmeter中建立一个测试计划。因为本次测试仅要求完成对目标接口的请求，因此只需要使用HTTP Request Sampler 即可。

建立测试计划

　　启动jmeter后，jmeter会自动生成一个空的测试计划，用户可以基于该测试计划建立自己的测试计划。

 添加线程组

  　　一个性能测试请求负载是基于一个线程组完成的。一个测试计划必须有一个线程组。测试计划添加线程组非常简单。在测试计划右键弹出下拉菜单（添加-->Threads(Users)--->线程组）中选择线程组即可。

 　　jmeter中 每个测试计划至少需要包含一个线程组，当然也可以在一个计划中创建多个线程组，那么多个线程组之间又会怎样的顺序执行（串行还是并行）？在测试计划下面多个线程是并行执行的，也就是说这些线程组是同时被初始化并同时执行线程组下的Sampler的。

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

线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

准备时长： 设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ，准备时长为10 ，那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。

循环次数：每个线程发送请求的次数。如果线程数为20 ，循环次数为100 ，那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。

　　设置合理的线程数对于能否达到测试目标有决定性的影响。在本例中，要求得到接口在462.9TPS 负载情况下的响应时间，如果如果线程数量设置的过小，则很可能无法达到设定的TPS要求。另外，设置合理的循环次数也很重要，除了上面介绍的固定循环次数与永远外；也可以灵活的选择设定测试运行时间。勾选“调度器”，进行调度器配置。

添加HTTP请求

　　添加完成线程组后，在线程组上右键菜单（添加--->Sampler--->HTTP请求）选择HTTP请求。对于jmeter来说，取样器（Sampler）是与服务器进行交互的单元。一个取样器通常进行三部分的工作：

1、向服务器发送请求

2、记录服务器的响应数据

3、记录相应时间信息

 　　一个HTTP请求有着许多的配置参数，下面将详细介绍：

名称：本属性用于标识一个取样器，建议使用一个有意义的名称。

注释：对于测试没有任何作用，仅用户记录用户可读的注释信息。

服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。

端口号：目标服务器的端口号，默认值为80，https默认端口为443