六、性能测试流程（如何做性能测试？)
根据学习全栈测试博主的课程做的笔记
1、前期准备–
项目初期就开始，业务需求评审时尽量参与,对业务更深刻的认识（确定哪些是核心业务、哪些可能存在并发请求、确定什么地方会出现瓶颈,方便后续性能需求评审时给出建设性建议）
2、性能需求分析、评审（确定性能测试的范围、性能测试的目标是多少）
2.1、确定范围：哪些业务接口
使用多的、核心业务功能
2.2、目标：tps、rt、成功率、资源利用率等
2.3、补充
2.3.1关于需求来源（项目组一起定性能目标）
2.3.1.1迭代项目
1）范围
新增、修改、受影响的功能也是需要放在压测范围内
2）目标
不能低于之前版本的性能
还需要进行容量评估，根据历史数据的请求数据进行统计月增长率是多少
比如现在要做一个容量预估：可以根据增长率（业务、用户增长的情况）预估tps达到多少未来才能满足业务需求，就可以做容量预估
3）业务比例：类似ELK的日志平台来统计
从生产上统计接口的业务比例(其实就是单接口的比例）
这只是统计出接口的比例，但是需要转换成业务比例，评审时就需要将业务比例获取到，最后在jmeter设计场景时要用到。
2.3.2新项目
1）范围：核心业务功能
2）目标值：参考竞品、经验值（产品经理）
若是迭代项目可以和之前的版本性能做对比，也可以通过生产环境的统计日志获得容量tps，新项目就是参考竞品和产品经理的经验。
3）补充：①业务比例（项目组谈论、项目运行后统计）②要测出最大容量Tps，为上线后限流提供参考
迭代项目的业务比例是可以通过类似ELK日志平台拉取数据，看一下压测时间范围内各个接口请求的压测业务比例历史数据统计，新项目没有历史数据，怎么解决？
这种新项目的业务比例只能是项目组进行讨论（不好定的情况，最简单的就是1：1或者就是项目试运行后数据统计比例,少量用户和大量用户使用的tps有差异，业务比例的1偏差不是太大。
对于新项目，一定需要测出最大容量tps，为上线后限流进行提供参考。
3、制定性能测试方案（为后续工作进行指导）
方案很重要(设计相关的、数据的设计、场景的设计、监控的设计等）
3.1、项目背景
描述项目做什么、核心业务什么、出现什么问题，系统架构（用到什么技术栈）
1）背景描述
2）系统架构
了解系统架构、用到什么技术栈、接口的的数据流向、经过了哪些技术栈，才能为后续设计监控提供参考（才知道去监控哪些服务）
3）压测目的
解决当前什么性能问题、还需要测试出系统的最大容量tps(为上线后续的保证服务不挂、限流等）
3.2、术语说明（主要为了避免理解偏差）
1）tps
2）rt
3）并发
4）业务比例
5）单场景
6）容量场景（混合场景）
7）稳定性场景
3.3、测试范围、目标
1）要压测的接口清单以及业务比例
2）各个场景的目标：tps、rt、成功率等
3.4、测试资源
1）人力资源（组织架构）
项目经理(协调压测需要的资源）
性能测试工程师（编写性能测试方案、性能测试脚本、设计压测场景、执行压测、收集监控数据、编写测试报告等)
开发工程师（开发需要配合性能测试进行打对应的压测分支、做性能分析、做性能优化）
运维工程师（配合性能测试部署压测测试环境、协助性能部署测试监控）
2）压测工具（主要是压力端的工具）
jmeter还是loadrunner
压力机（window、linux）
如果对性能要求不高，用window压力机即可，一般用的是linux
3）压测环境：
硬件、软件、部署描述清楚
3.5、压测设计（最重要）
1）数据设计
①参数化数据—数据量–根据业务来
唯一性：tps500，压测时间600s，至少需要30000数据量乘以20%，
非唯一性：tps500，也是时间600s，至少覆盖线上时间被使用到的
如：注册要用不同的用户名，系统要求用户名是唯一，就需要准备不同用户名。
模拟不同的真实用户，发送请求。
参数化数据设计多少？得根据业务来，对数据有唯一性。
若要求tps=500，压测时间10分钟，600s,至少需要30000数据量，但是压力端在发送请求时，不是轮流发请求，假设起了200个线程，jmeter线程关系之间也是有竞争关系，也是要去争夺cpu的执行权限。如果获得cpu的执行权限，就将请求发送出去，可能有的线程获得cpu执行权限多一点，发的请求数也会多，jmeter数据量把,一部分数据分成线程1，线程2，线程3，获得cpu的执行权限不一样，为了避免发的请求更多数据量不够，再算出的数据量再乘以20%或者更多
对数据若没有唯一性。如查询商品，a\bc都可以查询到电脑，商品表有10万个商品，数据量应该设置多少？假设tps=500，压测时间10分钟，600s，至少需要30000数据量，商品表里有10万数据，可以直接用，也可以直接统计线上某一段时间内哪些商品被搜索，再进行参数化，需要与线上覆盖到（实际被使用到的数据）
参数化唯一性数据需要自己造
非唯一性数据在库里存在，若想所有数据都需要参数化数据导出，若想拿某一些热点数据进行参数化，就需要统计线上日志。
②数据库存量
数据库里各个表都存有数据，测时的数据库量级与生产一致，方便复现线上回归压测复现问题，变量太多，尽量保持与生产一致（数据量级、环境差异、软硬配置）
数据库的表和生产量的数据库表的尽量保持一致
2）场景设计（单场景、容量场景、稳定性场景等）
①单场景
单个业务接口进行压测
生产环境有很多的业务功能,一般说系统的tps都是混合容量的tps，为什么还需要对单场景进行压测?单个接口，链路简单，可以发现明显的性能Bug，可以为后续混合场景tps参考（代码逻辑性能Bug、软件配置bug如数据库连接配置，应用代码线程池里的配置）
②容量场景（混合场景）
容量场景一定需要集合业务比例模拟线上真实业务场景，在性能需求评审时不仅要给到目标tps，还需要给到业务比例，因为线上环境，每个接口调用次数不一样。
涉及到有用户登录、查询商品、添加购物差、创建订单接口：若对这些业务做单场景测试，这四个接口就属于压测范围。
单场景就是针对每一个业务(单独的接口）去进行单独指定目标、设计到加压方式、表的数据量，脚本涉及到关键点，以及重点关注相关指标
根据图中的单场景的目标tps是300、500、500、200，一般性能测试中给出的tps都是混合容量的tps。
混合容量tps=800，接口业务占比，可以根据业务比例算出在混合容量场景各个接口的tps。创建订单 业务比例10%，总的tps是800，则创建订单接口的tps为800*10%=80
其他接口也是同样算法：根据混合容量总的tps算出各接口在混合容量场景下的tps
单场景若没有指定目标tps，接口的目标tps至少是需要比混合容量场景中各接口的tps高（有的项目组会告诉单场景的tps，有的项目组则不会告诉单场景的tps，不指定的话根据总混合容量场景tps和业务比例是可以进行算出每个单接口的tps需要达到多少）
图中的业务比例是日志平台统计业务峰值容量tps，分解出来各个接口的比例，在jmeter中设置的时候还需要进行转换(吞吐量控制器）
业务占比用户登录15%，查询商品40%，添加购物车35%，创建订单10%，根据日志平台线上系统进行统计（有并发请求的业务的一个量，后面再根据jmeter的吞吐量控制器进行业务比例转换）
③稳定性场景（防止系统在高峰值时挂）
压测时需要设置一个持续时间,jmter中，循环次数勾选永远，会设置一个持续时间
稳定性压测时间设置多少合理？jmeter中，tps=总请求数/并发时间
并发时间=总请求数/tps
5000万/800=62500s–建议,时间乘以120%
50000万/1000=50000s,建议：时间乘以120%（防止跑到后面后，性能下降后，没有达到5000万的业务量）
稳定性场景的tps用的是混合容量场景测试出来的最大tps1000，用更大的tps跑出更少的时间。
④加压方式
秒杀、抢购----瞬间产生压力
非秒杀、抢购-----逐步阶梯加压
3）监控设计
根据压测接口的链路涉及的技术栈、选择合适的监控工具
比如：链路监控工具是微服务的标配（服务很多，排查问题难）
java项目:通过链路监控工具，进行时间拆分，发现是应用耗时多（对应用接口的调用的方法，通过arthas之类工具看哪个是方法耗时多或者可能是jg在耗时，通过jdk自带的相关命令进行查看，jstack）
系统架构、数据流向、技术栈需要清楚
3.6、测试计划
流程的一个里程碑计划、产出物什么、时间节点、负责人是谁？
3.7、风险评估
根据当前情况罗列出可能的风险（如涉及到外围系统，外围系统也属于外围风险、人力资源缺少、环境差异）
3.8、参考资料
4 、性能测试方案评审
写好后项目组进行评审、性能测试计划、性能测试场景怎么设计的.
根据评审会议的建议进行修改
评审会议通过后需要发送给各项目组的成员
5、申请性能测试环境
简单架构（nginx+2 tomcat +mysql），nginx做反向代理，tomcat容器有两个+mysql，看哪一个服务是影响大的，资源不足的话，对对应的服务等比例缩放进行两次压测，看损耗率。
初步判断，瓶颈在应用层，第一次是一个tomcat，tps是100，两个tomcat的tps是180，此处有20的tps的损耗。换算成损耗率，生产是3个tomcat，预估可以达到多少tps，现在简单架构较少，一般都是复杂架构，复杂架构链路长，涉及的服务多，每一个服务的影响因子性能大小不一样，很难换算。建议项目组进行评估，做好线上的保护，如限流。
大公司一般压测环境不足，一般是直接线上全链路，充分利用线上的资源。
补充：新项目可以直接在线上环境压测
6、性能测试用例编写及评审
性能测试用例设计：一般是对性能测试场景进行设计
对单场景、混合容量场景、长时间稳定性的设计，重点就是各场景里的数值
单场景(目标tps、加压方式、数据量、脚本设计等）混合容量场景（业务比例、目标tps等）
长时间稳定性（总的压测时间、总的目标业务量等）
7、搭建测试环境
参考测试资源压测环境的部署
除了部署应用，还需要部署监控
8 、准备测试脚本、测试数据
8.1、脚本
推荐：开发提供压测环境调通的postman或者jmeter脚本
或者根据接口文档写（swagger）
8.2、场景设计
8.3、准备数据
1）参数化数据
方式，代码生成，从数据库导出
2）数据库存量数据
方式：
复杂表，jmeter跑业务接口
单表：代码，存储过程
9、环境确认测试
9.1、静态测试
确认环境配置（软件、硬件），尽量和生产保持一致
软件（jdbc的配置、线程池的配置等是否和生产保持一致）
9.2、非静态测试
确认环境是否可用（压测的接口是否通、发送请求是否有响应响应结果是否正确等）
10、执行压测并监控
先单场景测试发现明显的性能bug,为容量场景做准备
混合容量场景：模拟真实线上的真实场景
再执行稳定性场景
执行压测监控时，不要一次性打开所有监控，监控也是需要耗费监控资源。先通过jmeter非gui模式下持续阶梯加压跑一下，看一下结果，如不达标后，若是微服务（用skywalking）是哪一个节点耗时多，就着重监控不达标的节点（如果是mysql服务，则将mysql的服务打开），通过mysql监控看是什么问题，若有慢sql，后续就需要出现问题的接口执行的sql，拿出来用explain单独分析sql执行情况
每一步需要哪个监控就开哪个监控
11、分析定位
11.1方法
1）简单架构
查看资源消耗,通过监控发现应用服务器的CPU高，java项目可以进行打栈，看一下线程在做什么，下一步就是代码逻辑。
2）复杂架构
通过分解时间方式（微服务skywalking）
举例：
场景比对：加节点怀疑是服务资源不足，可以进行加节点，
性能提升后就是服务资源不足导致的，服务为什么消耗资源，代码逻辑是否合理。
隔离:这个功能会调另一个功能，先将一个功能去掉后再进行压测。
