一种基于代码方法级的压力测试方法与流程

1.本发明涉及代码测试技术领域，尤其涉及一种基于代码方法级的压力测试方法。


背景技术：

2.压力测试，通常指的是后端压力测试，一般采用后端性能测试的方法，不断对系统施加压力，并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈点。所以，压力测试往往被用于系统容量规划的测试。还有些情况，在执行压力测试时，我们还会故意在临界饱和状态的基础上继续施加压力，直至系统完全瘫痪，观察这个期间系统的行为；然后，逐渐减小压力，观察瘫痪的系统是否可以自愈。压里测试测目的是为了观察当前系统的负载能！压测的结果一般情况可以通过吞吐量与并发数的比例来观察，吞吐量与并发数呈正相关关系，在一定并发数的情况下，吞吐量越高，说明系统性能越好。压力测试需要对吞吐量(tps)、qps、并发数、响应时间(rt)进行关键指标的测试；
3.响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
4.吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间(或者系统响应时间和应用延迟时间)可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
5.并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。
6.每秒查询率qps是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
7.现在压力测试基本都是提交完代码，然后用压测工具测试，一般常用的工具：如jemeter/loadrunner。基本都是基于http协议，像一些rpc远程调用接口测试相对特别麻烦。需要研发自己做一些定制的修改。增加研发和测试的工作量。


技术实现要素：

8.有鉴于此，本发明的目的是提供一种基于代码方法级的压力测试方法。
9.本发明提供了一种基于代码方法级的压力测试方法，具体按以下步骤执行：s1：在
需要压测测试系统中，引入jar包；
10.s2：编写单元测试类；
11.s3：在测试类的代码中加上注解@stress；
12.s4:启动测试,打印相关输出信息，启动的时候注册到zookeeper上并监听对应的配置节点，监听对应的队列，用来和主控制进行消息通信；
13.s5：从配置节点上获得对应要执行的参数，包括启动的线程，对应的每个线程执行的时间间隔和汇报通知时间；
14.s6：接收任务执行；
15.s7：通过队列，通知对应主控节点进行通信，通信协议包括本节点对应信息，任务执行的阶段信息；
16.s8：任务执行完成通过队列汇总到主控。
17.进一步，在步骤s4中，具体包括每秒并发处理能力、最大响应时间、最小响应时间、总请求数、成功响应次数、失败响应次数、总共的次和完成的总时间。
18.进一步，s3.1：任务通过jar包的样式分发到各个节点，放置在lib目录下；
19.s3.2：新任务使用定制的classloader从lib上加载对应的jar包；
20.s3.3：对应实现的业务的jar包要高度抽象成一套可扩展的接口。
21.进一步，压测结束，登陆相应的web服务器查看cpu等性能指标，进行数据的分析：具体查看最大的tps、最大的并发数、数据库、应用程序、中间件、网络和操作系统信息。
22.本发明的一种基于代码方法级的压力测试方法的有益效果：该方法提供一个jar包给研发人员，研发人员可以通过注解的方式或者编写单元测试代码进行压力测试，在提交给测试人员之前，能够方便快速的进行压力测试，迅速的掌握系统性能情况并进行代码优化。
附图说明
23.图1是本发明的任务执行流程图；
具体实施方式
24.以下将结合附图和具体实施例对本发明进行详细说明，显然，所描述的实施例仅仅只是本申请一部分实施例，而不是全部的实施例，基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
25.如图1所示，本发明的一种基于代码方法级的压力测试方法，具体按以下步骤执行：
26.s1：在需要压测测试系统中，引入jar包；
27.s2：编写单元测试类；
28.s3：在测试类的代码中加上注解@stress；
29.s4:启动测试,打印相关输出信息，启动的时候注册到zookeeper上并监听对应的配置节点，监听对应的队列，用来和主控制进行消息通信；
30.s5：从配置节点上获得对应要执行的参数，包括启动的线程，对应的每个线程执行
的时间间隔和汇报通知时间；
31.s6：接收任务执行；
32.s7：通过队列，通知对应主控节点进行通信，通信协议包括本节点对应信息，任务执行的阶段信息；
33.s8：任务执行完成通过队列汇总到主控。
34.本实施例中，在步骤s4中，具体包括每秒并发处理能力、最大响应时间、最小响应时间、总请求数、成功响应次数、失败响应次数、总共的次和完成的总时间。
35.本实施例中，s3.1：任务通过jar包的样式分发到各个节点，放置在lib目录下；新任务使用定制的classloader从lib上加载对应的jar包；对应实现的业务的jar包要高度抽象成一套可扩展的接口。
36.本实施例中，有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数(线程数)，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
37.压测结束，登陆相应的web服务器查看cpu等性能指标，进行数据的分析；
38.最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。
39.最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90％以上，则可以说明服务器有问题，压力机没有问题。影响性能考虑点包括：数据库(重点)、应用程序、中间件(tomact、nginx)、网络和操作系统等方面。
40.以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的宗旨和范围，其均应涵盖在本发明的权利要求范围当中。本发明未详细描述的技术、形状、构造部分均为公知技术。