Why--为什么要做性能测试
为了更好地从技术上来规避系统上线后的风险，评估线上系统的真实能力，根据业务模型摸底线上能力，以提前应对可能发生的突发状况。
When--什么时候做性能测试
- 新系统上线：在新系统上线前，通过执行性能压测能够对系统的负载能力有较为清晰的认知，从而结合预估的潜在用户数量保障系统上线后的用户体验；准确探知站点能力，防止系统一上线即被用户流量打垮；
- 技术升级验证：在系统重构过程中，通过性能压测验证对比，可以有效验证新技术的高效性，指导系统重构。
- 业务峰值稳定性：在业务峰值到来前，通过充分的性能压测，确保大促活动等峰值业务稳定性，保障峰值业务不受损。
- 站点容量规划：通过性能压测实现对站点精细化的容量规划，指导分布式系统机器资源分配。
- 性能瓶颈探测：通过性能压测探测系统中的性能瓶颈点，进行针对性优化，从而提升系统性能。
综上所述，性能压测伴随着系统开发、重构、上线到优化的生命周期，因此有效的性能压测对系统的稳定性具有重要的指导意义，是系统生命周期中不可或缺的一部分。
What—什么是性能测试
性能压测是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
通过模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。
从测试目的上性能压测又可以划分为负载测试、压力测试、并发测试、配置测试以及可靠性测试。
基准测试
当我们拿到一个性能测试项目的时候，我们会对这个系统架构做个了解，了解最好的方式是做一个基准测试，先谈谈它的基本情况。所以会去定一个小并发，比如5-10个人的并发，先去测一测，看它的响应时间，然后将此作为我们的基准。
负载测试
测试当负载逐渐增加时，系统各项性能指标的变化情况。为了获取性能拐点，我们叫最佳性能。当达到这个点的时候，系统能力、极限能力是多少？这个通常用来做线上流量评估。
压力测试
为了获取极限性能指标。比如可以设置一个3小时压测场景，每10分钟加10个用户，那到3小时后，可能就是180个用户了。这个时候观察，在压力不断增大过程中系统的表现，获得系统能提供的最大服务级别。
并发测试
通过模拟用户并发访问，测试多用户并发访问同一个软件、同一个模块或者数据记录时是否存在死锁等性能问题。
配置测试
通过对被测系统的软/硬件环境的调整，了解各种不同方法对软件系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。如把用户真实会发生的场景放大3-5倍，然后在线上运行24小时，在这个阶段会发现很多稳定性问题， list回收，java list回收，一旦回收出现问题，可能会出现内存溢出，这个在日常测试过程中，是很难测出来的，所以用稳定性测试查出这些问题。
容量测试
当业务越来越复杂的时候，比如一场大促，应该怎么评估线上的性能？如何去做合理的扩容？这个就属于容量测试范畴。
总的来说，性能压测是在对系统性能有一定程度了解的前提下，在确定的环境下针对压测需求进行的一种测试。
性能测试实施过程中关键的技术主要包括：
- 系统环境
- 测试指标
- 业务模型
- 数据量
- 测试模型
- 测试类型、脚本（API）、场景
- 监控
- 瓶颈分析、调优
- 性能测试压测工具
How--如何做性能测试
1、确定性能压测目标
性能压测目标可能源于项目计划、业务方需求等
2.、确定性能压测环境
为了尽可能发挥性能压测作用，性能压测环境应当尽可能同线上环境一致
3、确定性能压测通过标准
针对性能压测目标以及选取的性能压测环境，制定性能压测通过标准，对于不同于线上环境的性能压测环境，通过标准也应当适度放宽
4、设计性能压测
编排压测链路，构造性能压测数据，尽可能模拟真实的请求链路以及请求负载。
形成测试方案，组会评审，直至通过后方开始执行
5、执行性能压测
借助性能压测工具，按照设计执行性能压测
6、分析性能压测结果报告
分析解读性能压测结果报告，判定性能压测是否达到预期目标，若不满足，要基于性能压测结果报告分析原因；调优后继续第5步直至达到预期目标
7、输出整体测试总结报告，涵盖迭代测试步骤、结果、优化方案、最终结果等信息
工具选型对比
对于性能测试来说，工具并不是核心，分析、评估、找出性能问题才是核心，这些是主观因素，工具是客户因素。所以工具选择时我们有几个方面要考虑。
（1）专业、稳定、高效，工业级性能负载工具。
（2）简单易上手，在测试脚本上不用花太多时间。
（3）有技术支持，文档完善，不用在疑难问题上花费时间，集中精力在性能分析上。
（4）要考虑投入产出比。自研或者使用开源不一定比商业工具更省钱，因为要做技术上的投资，时间上的投资。
| 压测工具 | 学习成本 | 安装部署成本 | 是否免费 | 是否支持多协议 | 压测结果是否能够图形化展示 | 是否支持TPS模式 | 是否有链路、场景编排管理支持 | 是否支持场景录制 |
| Apache Bench | 低 | 低 | 是 |
否：针对HTTP协议 |
否：命令行测试工具 | 否 | 否 | 否 |
| LoadRunner | 高 | 高 | 否 | 是 | 是 | 否 | 是 | 是 |
| JMeter | 高 | 高 | 是 | 是 | 是 | 否 | 是 | 是 |
| PTS | 低 | 低 | 否 | 是 | 是 | 是 | 是 | 是 |
Where--何处做性能测试
根据不同的业务场景进行区分，如硬件性能可能需要在特定的实验室开展，软件在专网环境、公网环境下展开，具体情况具体分析。
Who--谁来做性能测试
一般分为如下几种情况
1、公司内部有单独的性能组负责性能测试，项目测试负责人提交性能测试需求，配合对方提供各种资料，开展性能测试工作，具体的方案、脚本、执行、报告均由性能组负责
2、公司内部无单独的性能组，需要项目组功能测试负责，此时方案、脚本、执行、报告均由功能测试承担，所谓能者多劳
3、公司内部项目无测试人员，此时开发人员承担起测试人员的责任，负责方案、脚本、执行、报告，这种情况相对较少
4、公司直接将测试外包给三方，由三方负责
参考资料：