背景介绍
- 相信很多测试项目上，很多都是身兼多职(既要做功能、自动化、性能啥都要做)；这次依据个人对压测这块的理解，分享一下压测的思路。因为个人以前对压测有很多误区，所以在此分享下避免继续入坑(不喜勿喷，如果还有理解误区求指点,我在来完善);
- 下面就讲下入门级的愚见:1、压力测试重点关注点是什么？2、压力测试怎么做？
一、压力测试重点关注点是什么？
1.1、因为看我以前的同事或者现在测试朋友们get不到重点，都是按照各公司现有的demo去做，用jmeter配置线程数去压。最后都是说支持500并发、1000并发，把聚合报告的指标捞出来再给个结论；但其中的对应关系还是很茫然的。
1.2、先捋一下压测的目的是什么：压测主要目的是结合当前服务资源以及当前环境配置基础下，对应用接口在不同压力场景下得出各指标结果是否满足实际应用需求【所以要优化性能指标的话，除从应用接口的代码逻辑和设计链路去优化的话，还需要结合环境的配置（例：连接数、队列值、jvm配置等）以及本身的物理资源去出发；能调到最合理的、最充分的利用率那就是性能大咖了】；
1.3、对“并发”名词说明：并发这个词在项目中很容易混淆，所以在此先讲解下这个词;并发分为相对并发和绝对并发；相对并发是指在一个时间段内发生的事务（可理解跟tps挂钩），绝对并发是指在同一时刻发生的事情（可理解为跟线程数挂钩，jmeter的“集合点”功能可以实现这种方式）；以下讲的并发都是依据绝对并发来说。
✔所以首先列下重点关注点，根据如下四点去判断压测是否达标通过:
1）、TPS指标:
2）、响应时间:
3）、出错率:
4）、服务资源情况:
✔下述分享个样例：
【测试结果】：
1）、TPS拐点峰值：依据压测结果，在90并发时达到峰值（2277笔/s），而后续持续递增并发数后TPS呈平稳趋势，即保持峰值在2200左右；--【达到预期≥1557笔要求】
2）、接口响应时间指标((以负载并发截图为准)：依据tps峰值下进行并发，平均响应时间为63.83ms,95%百分位响应时间为92ms；--【达到预期≤100ms要求】
3）、出错率：整个梯级压测过程中出现0.29%异常情况，经核查为环境XXXX问题受影响，非业务逻辑或资源问题，即忽略此错误率；--【达到预期99.9%成功率要求】
4）、服务资源消耗：整体服务资源利用正常，内存及CPU利用平稳无异常情况；TPS下降时cpu正常对等下降，压测结束后资源也可正常释放；--【符合预期,详见报告链接】
2.1、先说下TPS指标方面：
1）、TPS是主要是为了测出拐点峰值，得出当前服务环境下最大的事务处理量（例如上述得出2277笔/s）；
2）、TPS峰值达标判断：需要结合本身实际要求（例如上述-结合实际生产要求得出不小于1557笔），那我峰值已经覆盖预期要求，那TPS指标就算满足达标了；
3）、TPS峰值不满足或者需要达到更佳情况下：就要考虑怎么去调优了，主要方向：从业务代码方面优化、服务配置的优化、再到物理资源的提升；
4）、额外说明：关于实际预期要求多少，这个是需要参考生产实际使用量有多少；目前普遍比较多的是有埋点功能，可以统计到调用量；再结合有一定参考价值的二八原则计算（指80%的业务量在20%的时间里完成，另此公式不一定适合所有项目，具体需要结合每个系统项目应用场景）；
2.2、响应时间指标：
1）、需结合要求衡量取哪个响应时间，一般主要关注平均值和95%分位值；如果严谨一点的话可以以99%分位为准(这样情况下确保每个调用都能达标)；
2）、响应时间达标判断：首先先知道指标要求是多少，一般可以从产品经理那给出或者下游调用方超时设置值为参考，这些都算指标要求;另这块一般都是和tps事务处理量 and 并行要求的(例如:上述相当于说在每秒tps不低于1557的时候,并且95%分位要小于100ms)；
2.3、出错率：
1）、出错率也是一个重点关注项，如果都异常了肯定是不可接受的；另对整体的指标可能要考虑是否有价值了，但这块肯定需要结合异常情况去分析，在给出结论（如在压测过程报错，有些业务层面上认为是合理的。但往往比较容易忽略，其实可能隐藏很大的性能问题）：
2）、注意点:当整体压测下出现小部分概率异常，这个需要自身衡量下指标是否有价值，因为那一小部分影响整体指标可能会很大(比如百分98都是在200毫秒左右，百分之二因为异常5毫秒就响应了，导致整体指标影响很大)
2.4、服务资源消耗：
1）、服务资源主要关注施压机(即请求方)和压力机(被请求方)，施压机需要确保自身环境资源够满足（避免因自身请求方机器原因无法满足设置场景，导致未压出真实指标）；
2）、服务资源利用情况常规的需要重点关注下cpu（例如是互联网产品cpu使用率应该不能超50%，内部使用的一般80%；保证预期最大tps下，服务器还是很健康的）、内存（需要关注应用内存，如jvm的内存变化，只关注服务器内存意义不大），磁盘读写、网络接收发送 -->>各资源消耗不合理的变化或者有较大的异常波动需要再结合分析；
3）、这块服务监听的工具还是很多的，jmeter插件的探针工具也有的，虽然不是很强大，勉强能用【插件下载1：jmeter-PerfMon服务监听；服务资源探针2：Stepping Thread Group--提取码：8888 】
二、压力测试怎么做?(以TPS为例)
常规的压测大家基本都会做，这里讲下另一种压测方式，既通过梯度增压方式去找出核心指标：TPS峰值
- 在jmeter中，可以利用【插件下载：Stepping Thread Group】来做到递增压测，直接在一次线程组中找出TPS峰值（详解如下图）
jmeter插件1.png
1.1、配置思路：
①、上述第一点-->最高并发值：可预估一个较高的并发值，确保在最高并发值内找出tps峰值（如果在此预估配置下未找到tps拐点，需设置更大值）；
②、上述第二点-->持续增压（高度）：递增的并发数值需要更准确一点的话，建议设置以最高并发值5-10%区间递增（此处主要避免在递增爬坡的时候出来了tps拐点峰值）；
③、上述第三点-->恒定并发量时间（长度）：此处的设置长度（即时长），如果确保要精确些可以设置时间久一点（这里的设置时长：确保tps是趋向平稳状态，如非平稳状态需设置更长或者可能需要考虑其他因素）
1.2、TPS效果参考图【插件下载：Transactions per Second】
①、确保已经到tps峰值判别：即tps是曲线是横向状态（停止继续上升了）或者tps拐点往下走；
②、tps峰值横向一段时间的解释：到峰值时是在现状资源环境下，可最大处理事务量；横向是后续持续增加处于最大队列内，此时段响应时间相对而言增加会更大（每个服务系统不一样，具体需要对应分析）；
1.3、附上-响应时间插件【插件下载：ResponseTimesOverTime】
结尾语：
1)、未放更多实际已做的压测场景和图片（因为涉及信息安全，你懂的），就直接用jmeter截些图片做讲解了；
2)、后续会持续更新，在继续完善并且补充负载、稳定性方面的点.现先收收尾；
3)、此文章更多分享的是思路，主要对于入门级是怎么构思去做压测，而不至于直接茫然去压；
4)、压测还有一个核心点，除了给出性能指标外还要找出瓶颈点以及分析瓶颈问题。而对于这块需要对综合技术认知以及对业务整体架构、链路要有全面的了解来支撑的；所以需要真正做起性能测试，还任重道远，一步一个脚印来吧
