一、性能测试说明
1.jmeter≠性能，切记！！！性能和jmeter并非强关联性，jmeter、Loadrunner仅仅是并发测试工具，测试工具很多。可用其他的工具或者自己写并发代码模拟并发。
2.性能的侧重点是：监控、分析、调优
3.性能分析进阶：编写脚本、并发代码、性能监控、常见问题的性能定位调优、性能自动化预警监控、容量规划
4.工具及技术学习：技术栈基础（linux、nginx、tomcat、mysql、jvm、分布式消息中间件、分布式存储中间件、分布式框架、微服务）--监控、分析及工具--全链路--性能自动化；性能最好能看懂开发的代，java至少要了解。拓展：maven、jenkins、Docker、kubernetes；监控工具：Nmon Grafana Zabbix Prometheus
二、性能理解
1.性能测试：通过逐步 增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态来获得系统能提供的最大服务级别的测试。
2.负载测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。
3.容量测试：测试系统能够处理的最大会话能力。确定系统可处理同时在线的最大用户数，通常和数据库有关
4.递增测试： 指每隔一定时间段加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。
5.可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%~90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，通常可以测试出系统是否有内存泄露等问题。
三、压测的目的
压测的目的是为了观察当前系统的负载能力，考察系统高负载的稳定性。
1.给出系统当前的性能状况
2.定位系统性能瓶颈或潜在性能瓶颈
3.关注点：执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可拓展性。
四、什么是并发
1.点层面的理解：大家在同一个时间点做同一件事情（比如大家在1点整的时候同事点击登录）
2.线层面的理解：大家在同一个时间段内做不同的事情（比如大家在10点-12点之间做不同的事情）同样都对服务器产生压力
五、QPS、TPS、RPS、HPS、RT区别和理解
1.TPS就是吞吐量，服务端每秒处理事务率
2.QPS就是数据的每秒查询率
3.RPS是阿里提出比较重要的性能指数，是每秒处理事务率
4.HPS是用户每秒发起的请求率
5.RT是响应时间
- 注释：RPS（Requests per second）模式主要是为了方便直接衡量系统的吞吐能力TPS（Transaction Per Second，每秒事务数）而设计的（站在服务端视角），按照被压测端需要达到TPS等量设置相应的RPS，应用场景主要是一些动态的接口API，例如登录、提交订单等等
六、性能测试场景设计要素
- 注释：性能测试的场景是为了要实现特定的测试目标而对应用执行的压测活动，场景的设计与执行是整个性能测试活动的核心与灵魂，没有完整的场景设计就无法达到我们的测试目的，没有合理的场景设计就不会发现系统的性能缺陷。
1.被测的脚本
2.延时策略
3.运行时长
4.加压策略
5.并发用户数量
6.执行时长
7.终止方式
8.资源监控策略
以上场景需要根据实际环境和业务需求进行调整。
七、性能测试工作
1.性能需求分析（需求评审）
a、明确性能测试范围、目标
- 注释：可引导需求、产品和开发给定压测目标（单场景、混合场景、稳定场景），该目标且要合理，达成一致后，让产品或相关负责人把最终评审结果以邮件的方式发送给项目领导和项目组成员。
性能目标一般有：TPS（每秒处理事务数，这里都是通过的事务）、ART（平均响应时间）、并发数；CPU、IO、Memery、Network等
2.熟悉系统架构、业务逻辑
a、做性能测试必须要熟悉项目系统架构，连接各个框架的优缺点以及中间件的使用
b、业务逻辑也是必须要熟悉的，不然没办法对业务系统进行分析和搭建监控
c、此阶段可和开发以及架构进行沟通了解更多的系统架构信息。
d、Mysql、Kafka、Linux、Redis、Nginx、Jvm等等
3.申请性能测试环境
a、此阶段和需求分析阶段同步进行
b、确保性能测试环境和生产环境软硬件配置一致，这样测试结果更接近真实环境
4.制定性能测试方案
a、结合测试范围以及测试目标准备单场景、混合场景、稳定场景测试方案
b、可根据测试方案模板进行填写
c、包含压测脚本、监控、分析工具以及其他的分析辅助工具
d、明确性能测试开始和结束标准以及整个方案的时间点
5.搭建测试环境、准备测试数据
a、搭建测试环境要熟悉运维技能，也可寻找运维的帮助
b、准备基础数据和业务数据
c、基础数据：一些基本的配置信息确保功能正常运行没问题
d、业务数据：比如商品库存和商品类型；
e、测试数据包含一些新用户数据和压测中需要用到的数据
6、开发压测脚本
a、根据压测范围进行准备压测脚本
b、对脚本进行调整：参数化、关联、事务、检查点、思考时间、信息头管理等
c、调试脚本确保每一个脚本都能正常运行
7、预压测（基准测试）
a、多脚本进行调试，在压测环境进行预压查看能否正常通过。例如10分钟
b、压测的过程中可观察各个节点的监控是否正常，监控是否生效
c、预压测的同时可评估压测时所需用到的参数化数据量
8、执行并监控
a、场景设计好之后就可以开始压测，开始时间节点要记录
b、开始压测，同时并监控各项指标，是否满足需求
c、如不满足可结合表象或者经验预估瓶颈点和问题点；看日志
d、排查时从易到难逐一排查，从请求开始，一步一步排查请求流经的节点，包括服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题；
e、最好会linux命令，自行查看服务资源使用情况
9、分析定位
a、基于上一步的监控数据进行分析，定位
b、性能问题分析原则：把事实与推测分开，用实际证据推测。没有足够的证据之前，不对程序进行优化。优先验证简单的假设。日志文件没有错误不代表真的没有错误。从系统到应用，从外到内层层剥离，缩小范围。缩小范围后，在切分小单元进行反复验证压测，直至确定问题点。
10、性能优化
a、在用用系统的设计开发过程中，应始终把性能放在考虑范围内
b、确定清晰明确的性能目标是关键
c、必须确保优化后的程序运行正常
d、系统的性能更大程序上取决于良好的设计，调优技巧只是一个辅助手段
e、调优过程是迭代渐进的过程，每次调优的结果都要反馈到后续的代码开发中
f、性能调优不能以牺牲代码的可读性和可维护性为代价
11、性能回归验证
a、当定位到问题后，交予开发修改完成之后，再次进行压测验证确保最终结果和目标一致
b、验证结果同样要记录，为以后回溯整理时查看方便
12、编写性能测试报告
a、编写报告同样要如实编写
b、对测试时遇到的问题和解决时间进行记录
c、对测试结果进行整理归档
d、对本次压测结果进行整理分析
e、测试结果是多少？测试是否通过？发现什么性能问题？原因是什么？如何解决？解决之后性能提升多少？统统整理并记录
f、最终把性能测试报告整理发送给项目组领导和成员知晓。
g、同时把优化同步到各个环境中
