首先我接受了一个观点：性能测试是所有性能相关的测试的集合，而压力测试和负载测试就是性能测试的子集。
原始文章地址：性能测试、压力测试和负载测试。
但是对于压力测试和负载测试的区别一直没有很明确的界定，而在实际的工作中使用这两个词越来越模糊，感觉大家说的都是一样的事情。
在完成了固定 QPS 压测模式探索、固定 QPS 压测初试的尝试和探索之后，我觉得在我这个Level上对于这两个词有了新的理解，分享给大家。
压力测试
对应的性能测试模式就是固定线程，通过使用固定线程的模式对服务进行性能测试，或者使用阶梯型的线程递增模式进行性能测试。
通过控制线程数来进行不同场景的测试。
关注指标：处理能力（QPS或者说TPS），平均响应时间（或者总处理时间）。
随着线程增加，处理能力会逐渐增加，然后到达一个瓶颈，接下来会有两种路线：一种是平缓不增不减，一种会掉头向下（这种偏少）。此时线程继续增加，平均响应时间会逐渐增加，直此超时。
公式：
- 处理能力=总次数除/总时间
- 处理能力=线程数/平均响应时间
排除影响测试结果的一些因素以外，处理能力和平均响应时间和线程数是有固定关系的，可以相互印证。由于单线程是串行的所以下一个请求的前置程序只能等到当前请求的后置程序完成之后才能执行。
通常来说，压力测试确定了在繁重的工作负载下应用程序的健壮性和错误处理能力。压力测试是通过考虑更多数据和许多用户来确定压力下系统状态的测试方法。
压力测试的好处
- 帮助验证系统过载时是否会破坏数据
- 确保发现 BUG 和同步问题
- 验证故障期间的数据传递和消息传递功能
- 通过克服软件故障的风险来确保交付可靠的软件
负载测试
对应的性能测试模型就是固定 QPS，通过模拟不同的 QPS 请求量情况下服务器处理请求的能力。
通过控制请求能力来进行不同场景的测试。
关注指标：平均响应时间。
随着请求量的增加，平均响应时间是稳定在某个值，然后随着请求量的增加，平均响应时间逐渐增加，然后就是出现超时情况，此时请求量已经大于服务的最大处理能力。
公式：
- 没有个固定公式，因为不确定请求线程数，而且是异步请求的。
排除影响因素以外，请求量和处理能力是保持一致的，理论上应该是相等的，因为控制了请求量。由于采用异步进行请求，可以模拟流量洪峰，用超过服务器处理能力的请求量来考验服务的应对能力。
负载测试的目的是开发一种在意外的极端负载条件下也能稳定运行的应用软件。这种测试方法也称为耐力测试。可以通过选择合适的自动化工具轻松地执行此操作。
负载测试的好处
- 帮助提高用户满意度
- 确保减少失败引起的成本增加
- 确保提高应用程序的可伸缩性
- 有助于在生产之前确定与性能相关的瓶颈
- 确保将系统停机错误最小化
拙见，有兴趣的可以一起多交流交流！