性能测试基本概念入门

一、什么是性能测试

性能测试是通过各种测试工具模拟多个人同时使用功能，观察各项性能指标情况，再分析指标数据背后的意义，分析可能存在的性能问题。

驱动：多个人同时使用（并发）
中间过程：看指标的结果，然后分析指标数据的背后意义（结果分析）
产出：可能存在的性能问题、性能指标数据、编写性能测试报告（性能问题瓶颈分析、调优，性能测试报告）

二、企业为什么要做性能测试

（1）为了合理评估是否需要硬件的更新升级，减少不必要的硬件投入成本

• 比如上线后出现崩溃，没有做性能测试的时候，花钱购买好服务器，CPU、内存、磁盘等，硬件设备升级，费钱
• 性能测试：代码问题+数据库设计+sql+cpu+内存垃圾回收等；修复代码+配置+SQL等改好问题，可以解决问题且不需要花钱

（2）进行日常迭代版本的性能测试可以尽早发现一些性能隐患，避免线上严重问题，影响用户体验

• 性能测试一般是在功能测试稳定之后再进行，一般在功能测试完成后，预发布环境之后，所以性能测试会在每个版本迭代后期做性能测试
• 提醒：全链路压测（阿里方案）在线上环境做，要求技术很高

思考：做性能测试每个项目的每个模块是否都要做性能测试？

• 不是每个项目和每个接口都要做性能测试，因为性能测试花费很多时间和人力，讲究性价比
• 哪些要做：做性能业务需求分析（性能测试是要懂业务的）
  ① 核心的主要模块：用户量比较大的模块，门户网站登录
  ② 挣钱的模块：主要经济来源模块，重点关注：下单、支付
  ③ 近期有大型活动的模块：秒杀、12306抢票

三、性能测试分类

1、按端分

1.1 前端

有界面的：web端、app端、PC端、H5、小程序等

* 前端性能：用户界面响应时间 = 界面数据渲染时间+接口获取数据时间
* 页面渲染时间：跟终端设备关系很大（如手机系统版本、浏览器版本、电脑系统、网络等）

做前端性能需要考虑各种设备的情况，性价比很低、成本高，所以在公司很少做，所以我们日常说的性能测试，普遍指的是接口性能测试

1.2 后端

服务器接口性能测试

* 获取数据时间：通常接口去服务器里获取，调用接口，跟前端没任何关系

性能测试关注接口性能最有价值，所以在大部分公司都会区做性能测试

2、按策略分

按照策略分类：并发测试、基准测试、负载测试、性能测试、压力测试、稳定性测试、容量测试等

2.1 并发测试

模拟多个人同时向服务器发起请求，测试服务器在一定时间内能够处理多少请求量

并发：同一个时间点（单位时间内1s）发起请求，这个请求可以是相同请求，也可以是不同的请求
秒杀：真正同一时间的相同请求

2.2 基准测试

基准测试就是一个参考点（基准线）

# 有如下的目标喝需求，都可以做基准测试
* 1)、当项目还没做过性能测试时，所有的性能指标数据都没有，就把第一次正式执行性能测试，得到的性能指标数据作为以基准。这第一次正式的性能测试就叫做基准测试。

* 2)、比较不同硬件、软件版本或者配置的性能差异，辅助决策，例如：
---JDK：1.8版本得到指标，RT、TPR、错误率等一组数据可以作为基准数据
---升级JDK:22版本，再次压同样的脚本，得到一组指标数据，跟上次进行对比

* 如果数据下降了，不升级jdk
* 如果数据上升了，升级jdk

* 3)、跟踪系统升级或优化后的性能变化，验证改进效果
比如代码架构调整、服务器升级等操作，可以先做基准测试，等升级完之后，再做一遍测试，两次数据进行对比，确认本次升级对性能的影响

* 如果性能有提升，可以决定升级
* 如果性能下降了，可能不调整

2.3 负载测试

逐步增加并发用户数，向服务器发起请求（并发测试），观察各种性能指标数据，通过这些指标数据的分析，判断出服务器最大可接受的并发用户数或最大并发用户数，这个数据叫做拐点。

* 如果去执行负载测试，可以使用jmeter的阶梯压测的模型去实施
* 指标：关注TPS、响应时间、错误率等，觉得有异常到了系统的极限了，或者系统崩溃了，这个时候的用户数就是系统最大的并发数

问题：最大并发用户数和最大可接受的并发用户数有什么区别？

最大并发用户数：当服务器出现了持续的报错，资源利用率非常高的时候，系统已经崩溃，没有办法处理请求，此时的用户数是最大并发用户数  【系统崩溃】

最大可接受的并发用户数：如TPS开始持平不增加，RT开始超过标准了，但是系统此时是可以正常使用的，此时的并发用户数是最大可接受的并发用户数  【性能变差】

**行内标准**
1）平均响应时间 < 1.5s，如果刚超过1.5，这个用户数是可接受的最大并发用户数

2）错误率 < 0.1%，几乎没有失败的请求，

3）资源利用率 < 80%，包括内存、磁盘、CPU

并发测试、性能测试都是先用负载测试找到系统能接受的最大并发用户数，然后基于这个用户数做性能测试

2.4 性能测试

通过负载测试找到最大可接受的并发用户数，持续请求一段时间，获得性能指标数据，通过这些指标数据，判断是否存在性能问题，如果有性能问题，则进行性能分析、调优，再测试验证。

执行时间：几分钟–几十分钟左右

2.5 压力测试

通过施加超出正常操作范围的并发用户请求，找到系统的性能瓶颈和极限，观察系统在高负载条件下的响应和验证恢复能力

**问题：使用一定量的并发用户数来请求，用户数具体多少？时间一般压多久？**

用户数：超过最大可接受的用户数，逐步增加，知道系统无法正常响应或者崩溃【通过负载测试系统承受最大并发，100，+10...】
先做负载测试，得到系统承受的最大并发用户数

运行时间：几分钟--几十分钟

关注点：压力停掉后，系统自我恢复能力，释放资源、内存释放

使用场景：项目应对高并发、高流量需要做压力测试，如：电商、社交媒体等对突发流量的场景

2.6 稳定性测试

验证系统长期运行的稳定性和可靠性，确保系统在正常负载下，长期运行时没有性能下降、内存泄漏或其他问题。
观察系统在长时间运行后的资源使用情况，发现长期运行中，可能出现的性能问题和资源耗尽问题。

**问题：长时间运行的时间具体多久？用户数一般是多少？**
* 运行时间：模拟真实环境下长期使用，运行时间从几天到几周不等
    如【7*24】小时，具体时间看项目和场景再定

* 用户数：基于负载测试得到的最大承受的并发用户数而定--拐点

* 使用场景：需要长期稳定运行的项目 ，如银行、证券交易等，要求对故障容忍度很低

2.7 容量测试

在一定的软硬件条件下，服务器的数据库数据量级在不同情况下，对系统读写比较多的业务进行测试，从而货得不同数据量级的性能指标

数据库表的数据：
  10万级数据，例如：查询订单的接口--关注响应时间、吞吐量等
  100万级数据，例如：查询订单的接口--关注响应时间、吞吐量等
  1000万级数据，例如：查询订单的接口--关注响应时间、吞吐量等
  
  使用场景：数据量比较大的项目业务，大数据业务等