一、需求收集
先需要确认本次测试目的是什么，然后再看我们需要用什么参数来判断这个目的是否能够达成。
1.1 业务性能指标参考：
TPS、QPS、RT、请求成功率（一般请求成功率>=99.99%）
1.2 硬件性能指标参考：
即服务端资源耗用指标，常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。
二、性能测试策略（参考）
基于不同的目的，我们的测试策略选择是各不相同的，此处列举了一些比较常见的，各位可以参考一下～
2.1 并发测试
模拟客户端请求，在单位时间内(S)同时发起一定量的请求，验证系统是否具有并发性的问题。（不要无脑并发）
1)经典公式（仅供参考，具体使用需要在业务实践中代入验证）：
平均并发用户数为 C = nL/T
n是login session(登录用户)的数量，L是login session的平均长度（平均在线时间），T是值考察的时间长度（工作时间）
2)另一种说法，使用并发度跟总用户数评估并发用户
公式：总用户数/并发度=并发用户数
并发度计算方式：1. 统计某时段的当前在线用户数；2. 把所有功能操作的用户数都统计出来；4. 将统计出来的用户数除以在线用户数就知道并发度了。（某个时间点10000个在线用户，100个用户进直播间，那么并发度就是1%）
具体在业务实践中应该参考之前的历史数据，跟开发以及业务方评估本次的预期值进行并发压测。（预期并发数）
2.2 负载测试
不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）；
负载测试（也叫阶梯式压测）一般主要用来寻找性能的拐点，验证系统在既有测试环境不同的请求压力下能否正常运行。示例如下：
2.3 配置测试
不断调整系统各方面的配置（软硬件、参数配置等），验证在性能达到最优时（最优的性能一定是权衡各方面因素找到的平衡点）的最佳配置。
2.4 浪涌测试
验证系统在某段时间内并发突增或请求量波动较大的情况下，系统能否正常稳定的提供服务。
PS：这种测试策略使用的也相对较少，主要针对不确定性的短期的峰值流量涌入场景（比如某微博的离婚、恋爱、分手话题）。
2.5 稳定性测试
以恒定的并发数（根据负载测试的结果，CPU使用率在70%时对应的并发数），验证系统在混合场景下的性能表现。
2.6 批处理测试
验证待测系统在既有环境下，系统的批处理（触发式的job等）业务能力能否满足生产的业务需求指标。
2.7 高可用测试
在集群多节点或分布式的情况下，破坏其中一个或多个集群节点，验证系统能否及时恢复服务能力。
2.8 容错恢复测试
验证系统能否在出现故障的情况下仍能保持正常提供服务的能力或出现故障后的自我恢复能力。（熔断、降级策略）
a1面积越大，说明系统的处理能力越强；a2面积越大，说明系统稳定性越好；a3面积越大，说明系统的容错能力越好
2.9 容量测试
确定系统可处理同时在线的最大用户数。使系统承受超额的数据容量来发现它是否能够正确处理。
采用负载测试策略，验证在现有测试环境下被测系统的最大性能表现（可接受的最大性能表现，不一定是最优性能表现）。
2.10 极限测试
在既有测试环境下，不考虑资源占用率的极限情况（CPU使用率达到95%以上或IO异常繁忙或Load值较高），在系统不宕机的情况下的最大处理能力。
PS：由于被测系统的业务场景各不相同，这种策略，采用率相对较少。
三、性能测试场景建模
根据业务目的，我们可能会同时选择多种策略，来完成一次项目的性能测试，这个没有标准答案，只有一些参考项：
四、聊聊别的
- 性能的测试结果，都只能算是参考结果，很难跟真实场景1:1对应，所以需求分析+场景建模+环境配置，十分的重要，能减少最终结果的误差；
- 要注意数据的存档，避免后续不必要的麻烦；
- 对于压测环境来说，最好喝生产环境同等配置，最小化部署。