性能测试如何做？从0到1性能测试实战（手把手教）

目录：导读

- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）

前言

什么是性能测试（本质）？

基于协议来模拟用户发送的请求（业务模拟），对服务器形成一定负载。
关注点：时间性能、空间性能
与界面无关

性能测试分类

性能测试（狭义）
性能测试方法是通过模拟生产环境运行的业务压力量和使用场景组合，测试系统性能是否满足生产性能要求。通俗地讲，这种方法就是要在特定的运行条件下来验证系统能力状态。

负载测试
通过在被测系统上进行不断加压，直到性能指标达到极限，例如“响应时间”超过了预定指标或都某种资源已经达到了饱和状态。

压力测试（强度测试）
压力测试方法，测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，及系统是否会出现错误。

并发测试
并发测试方法通过模拟用户并发的访问，测试多用户并发访问同一应用、同一模块或数据记录时，是否死锁或其他性能问题。

配置测试
配置测试方法通过对被测系统软\硬件环境调整，了解各种不同对系统性能影响程度，找到系统各项资源最优分配原则。

可靠性测试
在给系统加载一定业务压力情况下，使系统运行一定时间，来检测系统是否稳定。

常见的性能测试指标

用户数；
并发用户数；
在同一时间向服务器发送请求的用户数量
与每秒的并发请求数不同，一定要确认需求的目的是并发用户数还是并发请求数

吞吐量（Throughput）
说明：单位时间内处理客户端请求数量，直接体现软件系统性能承载能力。
通常情况下，吞吐量用"请求数/秒"或"页面数/秒"来衡量。

提示：
从业务角度看，吞吐量可以用"业务数/小时"、“访问人数/天”、“业务数/天”，“业务访问量/天"去衡量。
从网络角度看，还可以用"字节数/天”、"字节数/小时"等来衡量网络流量。
每秒事务数（TPS）、每秒查询数（QPS）都归属吞吐量，区别是TPS\QPS描述服务器具体性能处理的能力。

并发数
说明：并发测试的用户数

扩展：
并发用户数：某一物理时刻同时向系统发送请求的用户数。
在线用户数：某段时间内访问系统的用户数，这些用户不一定都是同时向系统来提交请求。
系统用户数：系统注册的总用户数据。

响应时间
说明：用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程中所消耗的时间。

点击数
说明：衡量web服务器处理能力的重要指标。
提示：
点击数并不是大家认为的访问一个页面就是1个点击数，点击数是页面中包含的元素（如：图片、链接等）向web服务器发出请求数数量。
通常会用每秒点击次数（Hits per Second）指标来衡量web服务器的处理能力。
注意：只有web项目才有指标。

资源利用率
说明：指系统各种资源的使用情况，使用率=已使用的资源/全部的资源x100%

常见的资源使用率指标：
CPU，不超过80%；
内存，不超过80%；
磁盘，不高于90%；
网络，不超过80%；

如果资源利用率太小，也是造成资源浪费

错误率
说明：指系统各个资源的使用情况，一般使用"资源的使用量/总的资源可用量x100%"生成资源利用率的数据。
提示：通常，没有什么特殊需求的话
不同系统对错误率要求不同，但一般不超过千分之五—（根据实际项目而定万分之五等等）。
稳定性较好的系统，其错误率应该是由超时引起的—超时率。
TPS（Transactions Per Second）
说明：每秒的事务数（单位时间内系统处理客户端请求事务次数）
计算：tps=并发数/平均响应时间

事务：业务站在代码角度的统称，可以理解为一段或多段代码。
提示：TPS归属吞吐量
QPS（Query Per Second）
说明：每秒查询数（衡量web服务器处理能力的一个重要指标）

应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒60qps，服务器的性能各项性能指标是否正常）。

性能测试流程

1、需求分析
测试对象，常用的，核心的，重要的，数据量、并发量
例子：
注册、登录、搜索、添加购物车、下订单、支付

确定性能指标
吞吐量、TPS
服务器每秒处理的请求数量

响应时间
从浏览器发出请求，服务器处理，到收到响应所需要的处理时间

用户数
资源利用率

例子：

例子1：要求每天完成交易额2亿，求每秒钟最大交易数？
客单价：200-500，以300计算
采用28定律换算得出，以24小时计算
2/8原则：80%的用户请求，集中在20%的热点数据上，或时间段
计算公式：(200000000/300*0.8)/(24/0.2)/3600s=30.86个/s

例子2：每天8小时系统支付500万用户访问
500万在8小时内完成，500万/8*3600，一般不采用，除非系统负载比较平稳/平均；
先分析流量分布，再根据2/8定律估算每秒请求；
80%的用户数：500*0.8=400w
20%的时间内：8*0.2=1.6h
计算得出服务器需要支持694次/s--->500*0.8/(8*0.2)/3600s
每小时的平均负载*4（估算，不建议此计算）

测试场景：
单一场景：登录、注册、搜索、添加购物车、下单、支付
混合场景：用户使用场景、系统使用场景

2、测试计划
3、测试方案
4、用例设计
5、测试执行
6、脚本编写
场景监控设计
业务设计
场景搭建
说明：测试场景设计重要的原则就是依据测试用例，把用例设计场景进行展现出来。

提示：
虚拟用户数量及启动虚拟用户方式；
场景相关的设置（如：集合点）；
脚本是否有依赖关系（如：登录与注册）；

运行场景
说明：运行脚本就是运行场景
负载的测试机不能够运行设定的虚拟用户数
没有"预热"过程
没有模拟用户的真实环境
性能用例运行次数过少

监控场景
测试报告

7、定位分析问题
后端：代码、软件（服务）、数据库、应用服务器、硬件
前端
网络：
测试定位问题顺序：硬件问题—>网络问题—>应用服务器、数据库服务器配置问题—>源代码、数据库脚本—>系统架构问题

8、性能调优
性能测试人员经过对测试结果的对比，发现系统性能的瓶颈。
提示：
调优人员：以开发为主导，数据库管理员、系统管理员、网络管理员、性能测试分析人员配合进行性能问题的调优

验证：性能测试验证通常需要很多轮；每轮回归时需要对所有的测试指标进行全方位的对比

系统调优由易到难的顺序：
硬件问题；
网络问题；
应用服务器、数据库服务器配置问题；
源代码、数据库脚本；
系统架构问题；

9、测试报告
对整体性能测试阶段的回顾（覆盖需求、测试不同阶段的进度和产物、性能测试结果的分析）—>技术角度
对整体性能测试阶段风险的管理—>管理的角度
对项目性能测试结果的总结（是否通过，经验、教训）

LoadRunner与Jmeter之间该如何选择？

优选选择Jmeter
Jmeter能解决用Jmeter，Jmeter解决不了的用LoadRunner

性能测试常用术语

性能测试，有些专业术语，为了方便大家的理解，这里用通俗易懂的语言来解释下。

并发：tps
线程数：跑道中参加赛跑的人数
迭代：每人跑多少圈
循环：一次迭代里面，循环跑其中的一条脚本，就是重复来回跑其中一条跑道
参数值：发请求时用的数据
参数化：这是一种策略，上面有介绍到它的具体用法
思考时间：模拟用户等待时间
关联：下一个请求入参依赖上一个请求中的某个返回值
检查点：判断请求的是否成功，一般只有查询请求才会加检查点，也就是断言
集合点：等待所有用户，同一时刻去发起请求，主要应用场景是购物中的秒杀
事务：一般把被测试中某个或者某几个请求一起定义成一个事务，是人为的测试定义，可以是整个下单流程，也可以是下单中的一个请求
负载：服务器的繁忙程度，如果一个服务器，每次可以同时处理8个请求，如果请求数量大，后面请求就排队，排队请求越多，服务器负载就越高
平均响应时间（art）：每个事务处理时间，从发送请求到接收到的响应
tps：每秒处理事务数
每秒点击率（数）：每秒处理请求数，而不是用户每秒发送请求数

性能学习路线

jmeter→java基础→beanshell→架构知识→linux分析调优→各种中间件等定位调优…

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图