前言
本文的重心放在了前期的分析和策略准备上，也是希望大家先思考后行动，毕竟压测本身也算是个复杂的工程。压测后的问题分析和调优，后续再找机会梳理下。
需求分析
确认性能测试的需求来源，一般有这几种：
日常迭代，性能基线摸底
统一指标，固定环境，主要关注关键指标的变化
重大活动，业务事件前的摸底测试
着重考察高压力情况下的服务表现
摸高测试，找到性能瓶颈点
为水平扩容提供数据依据（即在当前性能表现下，为了要满足**业务需求，我们还需要**机器）
功能首次上线，对系统的首次评估
一般会涉及到一次摸底测试，找到系统极限
同时记录性能基线，为后续巡检提供数据对比
另外针对项目类型，又区分公有云/私有化部署，需要确认部署环境。
常见的几种性能测试类型：
基准测试
基准测试是指模拟单个用户执行业务场景，监控系统的性能指标与服务器资源。严格来说，基准测试不属于性能测试的范畴，它与功能测试其实没有太大的区别。
基准测试的目的更多的是关注业务功能及验证脚本的一个准确性，然后，将基准测试时采集到的结果（各项性能指标及服务器硬件资源）作为后续并发测试性能分析的一个参考依据。
负载测试
负载测试是模拟系统在正常负载压力场景下，考察系统的各项性能指标。这里说的正常负载，主要是指用户对系统能承受的最大负载量的期望值。即预计系统最大可用支持的业务并发用户数。
通过负载测试，可以验证系统是否能满足我们预期的一个业务压力场景。通过负载测试，得到系统的性能拐点（最佳性能点），当达到这个点时，系统的极限与表现能力又是多少。负载测试也经常用于线上流量评估。
压力测试
压力测试是测试系统在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）。在加压策略上，压力测试会对被测系统逐步加压，
在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。
压力测试主要用于测试系统或系统某些部分的极限能力。通过一直增加负载，直到应用的部分功能不能正常工作，压力测试的目的是找到被测系统的容量天花板。
负载测试和压力测试区别
负载测试是验证系统是否满足预期的业务压力场景；而压力测试是找到测试系统的容量天花板。
负载测试是模拟多个用户不同时间段内持续向系统发送请求的，而压力测试是模拟同一时间段内持续不断的向系统发送请求的。
疲劳强度测试
疲劳强度测试与负载测试testing觉得挺接近的，都是对系统模拟出系统能承受的最大业务负载量。
差异在于，疲劳强度测试的侧重点是系统在长时间运行情况下系统各项性能指标的变化情况。例如：系统在运行24 * 3后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等性能问题。
稳定性测试
稳定性测试是指被测系统被用户正常的使用，能持续多长时间运行而不出现错误。
疲劳强度测试是指被测系统可以支持的最大并发数长时间模拟运行业务，通过资源和性能指标侧面分析系统的稳定性。
容量测试
当系统业务越来越复杂的时候，比如双十一、春节等大促。我们应该怎么评估线上的性能？如何去做合理的扩容？这个时候就需要开展相应的容量测试了。
测试策略
明确测试接口和链路
从产品需求中明确需求，熟悉待测试接口。一般区分读接口和写接口，例如媒资上传链路中，涉及到媒资增加和媒资上传完成后的状态查询接口。
读接口
注意是否会触发缓存机制，导致压力到不了数据库
注意本身数据库数据量问题，确认真实业务中库表中数据量级
分库分表场景下注意是否需要考虑热点库表情况
写接口
注意接口是同步返回还是异步返回
注意是否需要构造参数化数据，相同数据写入是否有缓存逻辑，幂等逻辑
注意是否需要有前提数据准备
还有其他比较特殊的
主要体现在业务上为异步处理，不纠结接口响应，重点考核一段时间内的处理能力。典型：视频转码能力（考核倍速指标、**分钟内处理完成**分钟原始视频），视频合成能力（类似转码）
注意考察单节点/集群处理能力的区别
注意是否有调度节点，调度节点是否可能成为瓶颈
注意尝试长时间测试观察稳定性
注意输入数据是否有各种格式区别，可能会影响最终结果
明确测试环境
选择被测试应用是在哪个环境？
case：生产环境
测试导致的业务服务器压力大，是否会对线上用户使用造成影响
测试导致的中间件压力大，是否会对同时使用该中间件的其他业务系统造成影响
测试产生的大量数据，是否可以清理，是否会对下游应用的数据有污染
比如，产生大量的媒资数据，对于数据统计，BI报表，计费流量是否有影响？
case：测试环境
环境是否可以保证稳定可用，测试期间降低部署频率
环境资源配置是否需要提前调整，和线上保持一致or等比例调整
测试链路上的各应用代码版本尽可能保持一致
case：单独的性能环境
部署的应用链路是否完整
测试链路上的各应用代码版本是否是待测试版本
施压机器在什么环境？
访问被测试应用需要是公网访问还是内部访问
施压机器是否会有瓶颈
明确性能指标
重点要关注哪些指标，这些指标的预期值为多少
可以由产品确定
也可以参考之前的性能基线
常见的指标https://blog.csdn.net/zha6476003/article/details/80662603
1、响应时间
响应时间指的是“系统响应时间”，定义为应用系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为用户视角的软件性能的主要体现。它包括网络上的传输时间，web服务器上处理时间，APP服务器上处理时间，DB服务器上处理时间，但不包括浏览器上的内容显示时间，即“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现。
2、最大并发用户数
有两种理解方式，一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。
3、吞吐量
吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。一般来说，吞吐量用请求数/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。
4、性能计数器
性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如，对Windows 系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。
5、思考时间
思考时间（Think Time），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两个操作之间等待一段时间。
6、TPS
TPS:Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。
7、HPS
点击率：HPS，每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标，WEB应用是”请求—响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。
8、资源利用率
资源利用率就是指资源的使用情况，如CPU使用率、内存使用率、网络宽带的使用情况、磁盘I/O的输入输出量等系统硬件方面的监控指标。一个完整的系统是由软件和硬件组成，缺了任何一方都不可能成为一个正常运作的系统，所以资源利用率也是测试人员的一个监控点，并在当前软件的发展趋势下，硬件资源的成本也不可小视。
明确压测时间
一般根据业务情况选择
要考虑执行时对现有用户的影响，线上用户/测试环境中其他在测试的同学
要考虑同时间段有没有其他任务在执行，比如半夜的数据库备份，定时的统计任务等
测试准备
测试工具选择
自研性能压测平台
jmeterhttps://www.cnblogs.com/monjeo/p/9330464.html
locusthttps://www.jianshu.com/p/292c2001ff27
自己写脚本
测试数据准备
请求数据准备
依赖数据准备，例如：账号，数据库中的基础数据（又叫垫底数据）
链路测试时，基于线上各环节的流量漏斗比例设计数据 可以参考 https://zhuanlan.zhihu.com/p/37617672
测试环境的准备
确认环境可用稳定
确认环境中代码是待测试版本
策略评审
评审一定要做！！！
关键责任人：业务方、产品经理、被测试应用开发、相关应用开发（由被测试应用开发确认通知范围）
执行期间
注意观察被压测应用
观察并记录性能指标
出现异常时，及时记录日志 or requestId，不然可能被淹没或者覆盖
出现堵塞或者异常，及时解决
每一轮测试结束后，按计划调整测试参数
*注意观察施压机器，别因为施压机器的资源瓶颈，导致性能指标下降
服务器监控
跳板到对应服务机器，linux top命令
Grafana平台
特殊的是，部分场景，涉及到数据库中捞取一些业务数据用来计算结果
测试结论确定
基于上述的不同的测试目的，得出测试结论
可以参考https://www.cnblogs.com/jackei/archive/2006/11/20/565527.html
对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。
以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。
要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^
而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：
1. 当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；
2. 在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。
对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。
后续推进
主要是在排查和分析性能瓶颈产生原因。
可以参考https://www.cnblogs.com/imyalost/p/10850811.html