压力测试是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，是通过搭建与实际环境相似的测试环境，通过测试程序在同一时间内或某一段时间内，向系统发送预期数量的交易请求、测试系统在不同压力情况下的效率状况，以及系统可以承受的压力情况。然后做针对性的测试与分析，找到影响系统性能的瓶颈，评估系统在实际使用环境下的效率情况，评价系统性能以及判断是否需要对应用系统进行优化处理或结构调整。并对系统资源进行优化。
以上四种性能指标主要可分为系统资源利用率和系统行为（响应时间、吞吐量等）两个方面。它们之间存在一定的相关性，共同反映出性能的不同方面。比如，响应时间、最大并发用户数、吞吐量和资源利用率可以分别用来衡量软件的及时性、扩充能力和容量、处理能力、运行状态。响应时间越短、承受的并发数越多、吞吐量越大、占用的资源越少，表明系统性能越好，反之性能越差。
压测任务需求的确认
压测前要明确压测功能和压测指标，一般需要确定的几个问题：
- 固定接口参数进行压测还是进行接口参数随机化压测？
- 要求支持多少并发数？
- TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
- 压服务器名称还是压服务器IP，一般都是压测指定的服务器
压测设置
- 线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
- Rame-Up Period(in seconds):表示JMeter每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是20，准备时长为10，那么需要10秒钟启动20个数量，也就是每秒钟启动2个线程。
- 循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数=线程数*循环次数
- 调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。
压测结果查看
运行完后，聚合报告会显示压测的结果。主要观察Samples、Average、error、Throughput。
- Samples:表示一共发出的请求数
- Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
- Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
- Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好。
压测结果的分析
-
有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；
-
Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
-
压测结束，·登陆相应的web服务器查看CPU等性能指标，进行数据的分析;
-
最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。
- 最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
- 压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。
- 影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。
一个很好的压测教程：
https://blog.csdn.net/tomoya_chen/article/details/80626212
https://www.cnblogs.com/stulzq/p/8971531.html
接口测试例子：
https://www.cnblogs.com/heiyexiaoguai/p/6387675.html
Jmeter websocket采样器插件下载：https://download.csdn.net/download/tomoya_chen/10467755