一、什么是性能测试

会LR，jmeter等工具的人不一定会性能测试，会性能测试的人不一定会LR或者jmeter。这两款工具都是我们日常使用得比较多的性能测试工具。性能测试时一个复杂的过程，它更像是一个过程的统称。
既然是个过程，那么有必要先对性能测试进行分层，大体上可以分为三层：服务端层、客户端层，网络层。

1、服务端

学习性能测试我们首先要弄清楚两个方向，服务端方向和客户端方向。首先说服务端，无论是web还是app，服务端的性能测试方向大体上都是类似的。大体也可以分为：操作系统、中间件和容器。

2、客户端

客户端性能一般是指具有图形界面的应用程序的性能，能看得到的页面，比如网站的各个页面，app的各个页面等。当客户端出现性能问题时，一般的表现就是应用的操作不流畅，图形界面发生卡顿等。这里要强调一点就是app的性能测试，好多人分不清app的性能测试，首先app的性能测试也是大体分为前端性能测试（即app专项测试）和服务端性能测试，服务端性能测试也就是平常所说的性能测试。

3、区分服务端和客户端的性能问题

当我们发现性能问题的时候，首先要大概区分是服务端的性能问题还是客户端的性能问题，然后再去做相应的分析调优。
一般来说单机应用出现性能问题，大部分都是客户端问题，比如：

• 单机游戏卡顿
• 画图软件打开图片超慢
• web页面切换卡顿，页面加载时间长
  一般来说下面的一些性能问题就有可能是服务端问题或网络问题，比如：
• 微博api访问速度慢
• 数据查询速度慢，比如查询商品或者订单很慢
  还有一些联网的应用出现性能问题，可能是客户端也可能是服务端或网络问题，比如：
• 聊天软件发送信息慢
• 邮件客户端收信发信都很卡
• 直播软件声音卡顿

二、性能测试目的

1、压力测试下系统是否满足预期目标；
2、发现系统存在的瓶颈，为调优指明方向；
3、察看系统承受的最大压力以及最佳压力；
4、系统在长时间的规定压力下是否能正常处理各种请求，
考察系统的稳定性；
5、容量规划，要考虑到未来的用户慢慢增加后系统是否能满足要求。

三、性能测试主要术语

并发数：
LoadRunner 中的虚拟用户数就是并发数，即和系统产生了交互操作，这里注意定义，
是与服务器产生了交互的！

100米比赛，一声枪响，同时起跑。

注册用户数：指系统中全部注册用户的数量

在线用户数：指在相同时间段内都登录了系统，但未必会产生交互操作。别和并发数混了！

响应时间：
客户端的请求响应时间 = N1 + A1 + N2 + A2 +N3 + A3 + N4 + A4 + N5 + A5 + N6：

TPS：

• TPS(Transaction Per Second)俗称每秒通过事务数。即每秒钟系统能够处理的交易或
  事务的数量， 它是衡量系统处理能力的重要指标。你可以理解为每秒地铁的检票机器
  能过多少人。
• TPS 不仅仅是 LoadRunner 中重要的性能参数指标，在其他工具或系统里也是非常重
  要的指标
  他是基于事务统计出来的，所以必须先定义事务
• TPS 不等于吞吐量！！！！不同纬度的统计，吞吐量从网络角度看，指单位时间内网络上传输的数据量（吞吐量 = 吞吐率 * 单位时间）

性能测试中TPS上不去的几种原因浅析

1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

2、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

3、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。

4、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

5、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
事务：事务是性能测试脚本的一个重要特性。要度量服务器的性能，需要定义事务，每个事务都包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。
PV
page view（PV）：页面浏览量或点击量，用户每次刷新即被计算一次。我们可以认为，用户的一次刷新，给服务器造成了一次请求

去并发数

并发数的定义：并发数，计算机网络术语，是指同时访问服务器站点的连接数。
大部分人在刚开始做性能测试的时候都一直在纠结“并发数”，
并发用户数并没有那么重要，也不是衡量的重要指标。
1、假如 1 个用户在 1s 内完成 1 笔事物，tps=1
2、假如某笔业务响应时间是 1ms，1 个用户在 1s 内完成 1000 笔事物，tps=1000；
3、如果某笔业务响应时间是 1s，1 个用户在 1s 内完成 1 笔事物，要想达到 1000tps，至少需要 1000 个用户；
所以，1 个用户可以产生 1000tps，1000 个用户也可以产生 1000tps，无非是看响应
时间快还是慢，用并发数来衡量没什么意义。因此，我们要弱化并发数的概念。
而且如果你加入思考时间，并发数基本可以增加一倍。
再举个例子：
每个地铁口闸机每秒钟只能通过1个人（TPS=1），10个人去排队，想一起通过（并发数=10），那是不行的，只能慢慢排队一个一个通过。把通过闸机的时间压缩，比如刷卡相应很快，0.1s就能通过一个人了。那1秒钟通过的人数就是10了，抑或增加闸机数（相当于加服务器），那每秒钟通过的人数（tps）是不是多了。所以并发更多的是去帮我们找到性能瓶颈的那个点。

• 在性能测试中做上万的用户并发这种情况非常少，如果只需要保证系统处理业务时间足够快，那么几百个甚至几十个足已。日活量有10万，同时在线的有多少？1万？同时对一个接口产生的压力又有多少人（比如同时加入购物车，注意是同时），1千？就算你是同时点击加入购物车，到达服务器的时间也是有差别的哦，中间不是还要经过网络么，所以仔细想想，并发真的需要这么多么。

性能测试典型模型分析

性能曲线模型

• 最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；
• 不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。
• 如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。
• 根据这种性能表现，图中划分了三个区域，分别是较轻的压力区、较重的压力区和用户无法忍受并放弃请求区域。在较轻的压力区和
• 较重的压力区两个区域交界处的并发用户数，我们称为“最佳并发用户数（The
  Optimum Number of Concurrent Users）”。而 较重的压力区 和用户无法忍受并放弃请求区域两个区域交界处的并发用户数则称为“最大并发用户数（TheMaximum Number ofConcurrent Users）”。
• 当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待
• 当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；
• 而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

木桶原理/短板效应

一个木桶能装多少水不是取决于最长的板，而是最短的板。所以在性能测试中我们
应该优先调整最短的那个板，而不是一箩筐都搞！

多角度看待性能测试

从三个不同层面来对性能进行阐述：

• 从用户角度，软件性能就是软件对用户操作的响应时间；
• 从运维人员角度，软件性能表现在系统是否能够提供给用户稳定、可靠、可持续服务，包括服务器资源等；
• 从开发员角度，软件性能表现在如何调整设计和代码的实现，通过调整系统的设置等提高性能；故考虑性能测试，要从不同角度去思考问题，从用户角度和从应用系统角度来看性能测试，理解上会存在一些差异；
  电商网站每年的双 11 活动都是对其服务器性能的挑战。因为在这一天很多商品特价（但其实特价没有只有鬼知道），购物的用户量剧增。做为网站的高层更多的关心是什么指标？对于一名技术人员，我们可能更关心什么指标？

四、性能测试流程

过程分析：
（1）性能需求点获取

• 根据客户的需求由客户方提出

• 根据历史数据分析

• 参考历史项目或者其他同行业的项目

• 业内通用规则

• 确实没有数据，那就根据自己来，然后一边分析
  （2）测试点的提取，常放在客户常用的、重点的模块和功能上

• 用户常用功能，比如登录

• 数据流转向复杂或频繁的地方

• 发生频率高的地方，比如搜索，提交订单，下单结账。

• 关键程度高的（比如产品经理认为绝对不能出现问题的地方，登录、下单等）

• 资源占用非常严重的

• 关键的接口
  （3）测试环境

• 最好能和线上保持一致

• 如果不能那就等比的放大或缩小

• 软件版本应该一致
  （4）测试数据

• 铺底数据的准备：是空库还是有数据量。数据量的选择参考线上的数据量进行
  等比的放大或缩小。

• 最好的数据来源于线上的真实数据，因为分布合理

• 如果涉及到保密的数据，注意数据的脱密处理
  （5）测试过程

• 性能测试时一个需要不断改进的过程，每一次尽量做得更好，多做一点点以前
  没想到的东西，然后不断积累总结，然后你会发现自己对性能测试有了更深的
  理解
  （6）响应时间预估

• 线上监控系统得知

• 业界统一参考标准：2 - 5 - 8
  （7）预估并发用户数

• 系统的性能由TPS决定，跟并发用户数没有多大关系。系统最大的TPS是一定
  的，就好比池塘里装的水是有限的。但是并发用户数不一定，可以通过减小思
  考时间来增大并发用户数。

• 新系统：没有历史数据参考，只能通过业务部门来评估；
  80-20：百分之八十的事物是在百分之二十的时间内完成的。（只知道系统注册用户数 or 在线用户数的时候可选择）

• 旧系统：最好通过日志分析来得出

• 可以选取峰值时刻，在一定时间内（单位：秒）使用系统的人数，并发用户数取 10%，之后可根据实际情况梯阶式增加

前端性能测试

https://blog.csdn.net/qq_40468470/article/details/118310268