性能测试相关理解---性能测试流程（二）

六、性能测试流程（如何做性能测试？)

根据学习全栈测试博主的课程做的笔记

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）

举例：
场景比对：加节点

怀疑是服务资源不足，可以进行加节点，
性能提升后就是服务资源不足导致的，服务为什么消耗资源，代码逻辑是否合理。

隔离:这个功能会调另一个功能，先将一个功能去掉后再进行压测。

12、性能优化

13、性能回归

14、编写性能测试报告

14.1、测试过程详情以及对应的分析

14.2、测试问题总结及建议

14.3、问题汇总

14.4、风险评估

14.5、优化清单