性能测试-基础篇

╰+哭是因爲堅強的太久メ 2024-03-23 19:40 33阅读 0赞

每个人眼里对性能理解不一样，但是我们如果从一个App的维度来看：

用户眼中的性能：

1、App使用崩溃，卡顿，延迟

2、App反应慢，使用页面无反应

那开发眼中的性能：

1、数据库设计是否合理

2、代码逻辑、算法是否可以优化

运维眼中的性能：

1、服务器资源使用是否合理

2、服务是否需要拓展

那我们测试眼中的性能是什么？

测试的任务是保证质量，所以咱们测试考虑性能应该上述都要考虑

### 1. **什么是性能测试** ###

定义：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。加上性能分析调优

简单来说，自动化的测试工具就是我们用各种工具，比如JMeter 、LoadRunner...

正常、峰值以及异常负载条件就是我们的一系列方法，可以分为性能测试的分类

### 2. **性能测试方法（分类）** ###

<table> 
 <tbody> 
 <tr> 
 <td> 负载测试 </td> 
 <td> 通过逐步加压的方法，找到预期性能指标，确定系统所能承载的饱和状态，如90％的用户响应时间不超过5s,cpu使用率不超过70%，是我们常用的一种测试 </td> 
 </tr> 
 <tr> 
 <td> 压力测试 </td> 
 <td> 与负载测试一样，压力测试也是同样逐步加压的方法，与负载测试不同的是，压力测试没有具体的性能指标，目的就是看什么条件下可以把系统压崩溃 </td> 
 </tr> 
 <tr> 
 <td> 并发测试 </td> 
 <td> 同一个时间内，多个虚拟用户同时访问同一个模块、同一功能，测试是否有性能问题 </td> 
 </tr> 
 <tr> 
 <td> 容量测试 </td> 
 <td> 是指数据库层面的，目标是获取数据库的最佳容量的能力，具体方式是在一定并发用户，不同的基础数据量下，查看数据库的处理能力，获取数据库的性能指标 </td> 
 </tr> 
 <tr> 
 <td> 可靠性测试 </td> 
 <td> 也叫稳定性测试或疲劳测试。指系统在高压情况下，长时间的运行系统是否稳定，如cpu使用率在70％以上，运行7*24小时，系统是否稳定 </td> 
 </tr> 
 <tr> 
 <td> 异常测试 </td> 
 <td> 也叫失败测试，系统架构方面的测试，如果在负载均衡架构中，要测试宕机、节点挂掉等情况系统的情况 </td> 
 </tr> 
 </tbody> 
</table>

出几道测试题，判断下是哪种测试：

1、用户上传10M以内的文件，响应时间不能超过3s

2、双十一期间，购物App是否可以承受大量用户使用功能

3、高并发下，系统运行24小时，系统是否稳定

4、对登录接口进行阶梯型性能压测，看最大的并发量是多少

### 3. **性能测试目的** ###

验证是否达到预期性能指标，找出性能瓶颈

### 4. **性能测试流程** ###

[![4b4b409ce6c5c35a6ffb29eb3a860100.png][]][4b4b409ce6c5c35a6ffb29eb3a860100.png 1]

**1.需求分析，制定指标**

很多人觉得这一步很琐碎，其实很关键的，我们做功能测试的时候都需要知道预期结果，所以在性能测试中不能直接开干，也得需要分析，确认好指标

**2.脚本开发，场景设置**

这块包括一些准备工作，包括硬件、网络、操作系统，中间件，数据库、测试数据，监控工具等。  
然后录制、开发、优化脚本

**3.场景设置，监控部署好，执行测试**

根据已经设计好的场景执行脚本，记录测试结果，根据监控得出各个性能指标

**4.性能分析、性能调优**  
对性能进行分析，如果性能有问题，进行调优

**5.再次执行测试，性能分析。性能报告**

调优后再次执行测试，看我们的调优是否符合，是否成功，没啥问题，得出测试报告

小问题：

1、在我们做性能测试前，我们必须先确认什么？

2、我们怎么知道性能是否有问题？

3、性能监控有什么作用？

### 5. **性能测试场景** ###

有三个比较重要的场景：**基准场景**、**单接口负载场景**、**混合场景负载场景**

**1、基准场景**

指单线程或者少量线程下对单接口进行测试，测试结果作为基准数据

目的：

验证测试脚本及测试参数的正确性，同时也可以验证脚本数据是否能够支持重复性测试等；

通过少量线程访问系统获取结果数据，作为对比参考基准；

根据测试结果，初步判断可能成为系统瓶颈的场景，并决定是否进行后续的测试；

**2、单接口负载场景**

指通过模拟多线程对单接口进行负载测试

选用线程数，逐步加压，得出相应的指标

[![e4ec41a85038ec29c5501c8e019ea274.png][]][e4ec41a85038ec29c5501c8e019ea274.png 1]

**3、混合场景负载测试**

指的是增加线程数找出多个接口 TPS 的和对应的峰值

比如有人在浏览榜单，有人在抽奖，是最模拟真实环境下用户访问情况，多用户同时访问系统会调用系统各个接口，对各个系统产生并发压力

**4、稳定性测试**

系统在高压情况下，长时间的运行系统是否稳定，如cpu使用率在70％以上，运行7\*24小时，系统是否稳定

**5、异常测试**

系统架构方面的测试，如果在负载均衡架构中，要测试宕机、节点挂掉等情况系统的情况

小问题：以用户登录、抽奖、奖励查询操作，按照上述测试场景来设计实际场景

<table> 
 <tbody> 
 <tr> 
 <td> 序号 </td> 
 <td> 业务 </td> 
 <td> 场景 </td> 
 <td> 场景类型 </td> 
 </tr> 
 <tr> 
 <td> 1 </td> 
 <td> 登录 </td> 
 <td> 单接口，单用户并发压测 </td> 
 <td> 基准场景 </td> 
 </tr> 
 <tr> 
 <td> 2 </td> 
 <td> 抽奖 </td> 
 <td> 单接口，单用户并发压测 </td> 
 <td> 基准场景 </td> 
 </tr> 
 <tr> 
 <td> 3 </td> 
 <td> 奖励查询 </td> 
 <td> 单接口，单用户并发压测 </td> 
 <td> 基准场景 </td> 
 </tr> 
 <tr> 
 <td> 4 </td> 
 <td> 登录 </td> 
 <td> 单接口，梯度递增线程并发测试 </td> 
 <td> 单接口负载场景 </td> 
 </tr> 
 <tr> 
 <td> 5 </td> 
 <td> 抽奖 </td> 
 <td> 单接口，梯度递增线程并发测试 </td> 
 <td> 单接口负载场景 </td> 
 </tr> 
 <tr> 
 <td> 6 </td> 
 <td> 奖励查询 </td> 
 <td> 单接口，梯度递增线程并发测试 </td> 
 <td> 单接口负载场景 </td> 
 </tr> 
 <tr> 
 <td> 7 </td> 
 <td> 登录-抽奖-奖励查询 </td> 
 <td> 多接口，梯度递增线程并发测试 </td> 
 <td> 混合场景负载测试 </td> 
 </tr> 
 <tr> 
 <td> 8 </td> 
 <td> 登录-抽奖-奖励查询 </td> 
 <td> 多接口，性能瓶颈下80%以内的线程下，稳定并发24小时，系统稳定情况 </td> 
 <td> 混合场景负载测试 </td> 
 </tr> 
 <tr> 
 <td> 9 </td> 
 <td> 登录-抽奖-奖励查询 </td> 
 <td> CPU占有80%情况下，多接口的响应情况 </td> 
 <td> 异常测试 </td> 
 </tr> 
 </tbody> 
</table>

### 6. **性能常见指标** ###

**1、系统性能指标**

**事务**：客户端发起的一个或多个请求（请求组成一个完整的操作），客户端接受从服务端返回的响应

比如：银行转账，银行1给银行2转账发起请求，银行2返回转账成功，银行2账户加钱，银行1收到成功返回，银行1账户扣钱，这一整个过程算一个事务

**响应时间**：

*  请求响应时间：客户端发起一个请求，到客户端接受从服务器返回的响应，整个过程的时间。响应时间一般随着并发用户数上升而不断升高
 *  事务响应时间：可能是由一个或多个请求组成，主要针对用户而言

**并发：**

*  并发：是指一个时间范围内，比如1s内或2s内，多用户在系统进行同一操作
 *  绝对并发：同一时刻，同一时间点，并发用户同时发送请求
 *  相对并发：一段时间内，比如1s，并发用户同时发送请求
 *  并发用户数：同一单位时间内，对系统发起请求的用户数量，简称并发数。并发数越多，系统的负载就越高

**吞吐量：**

*  吞吐量：单位时间内系统成功传输的数据量。吞吐量是数据层的指标，以MB、GB为单位

**TPS/QPS：**

*  TPS：每秒钟处理的事务数，事务数并不等于请求数。tps是网络协议层的指标
 *  QPS：每秒查询率,只有查询，不建议用作性能指

--------------------

> 1、tps和吞吐量的区别？
> 
> tps是网络协议层的指标，指每秒钟处理的事务数。吞吐量是数据层的指标，指单位时间内系统成功传输的数据量，在很多时候，我们把tps当成性能监控数据，因为tps高的则吞吐量就会高

> 2、tps和qps的区别？
> 
> tps是每秒处理事务数，qps是每秒查询率。qps基本类似于tps，不同的是每访问一个页面（一个过程），会形成一个TPS，但是一次页面请求，可能会对服务器多次请求（资源、图片），这多次请求可以计入QPS。
> 
> 比如，对一个接口压测，接口内部不再请求其他接口，那么tps = qps
> 
> 简单来说，t可以是一个接口,也可以是一个业务的流程

### 7. **了解：常用系统分层架构** ###

[![2e971e3b717c5400ea44abc066bd0f8b.png][]][2e971e3b717c5400ea44abc066bd0f8b.png 1]

系统的架构分层各不相同，但是对于我们来说，只需要关注上述三层即可，我们必须要先了解系统的分层架构，才能分块排查问题，不至于分析调优的时候不知道如何下手

那如果我们不知道如何下手的情况下，可以从底层到最外层的顺序排查。首先进行数据库测试，有问题就sql调优或数据库配置调优。数据库测好了，测api层，以此类推

[4b4b409ce6c5c35a6ffb29eb3a860100.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/3c75e27b2ca2484394842875c9de5013.png
[4b4b409ce6c5c35a6ffb29eb3a860100.png 1]: https://img2023.cnblogs.com/blog/1519108/202308/1519108-20230807180539224-1568438679.png
[e4ec41a85038ec29c5501c8e019ea274.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/431b9203af614f9d882da8b969a4aa25.png
[e4ec41a85038ec29c5501c8e019ea274.png 1]: https://img2023.cnblogs.com/blog/1519108/202308/1519108-20230807180539223-2134016738.png
[2e971e3b717c5400ea44abc066bd0f8b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c3919557607b4e8e9c618db24f9fc36c.png
[2e971e3b717c5400ea44abc066bd0f8b.png 1]: https://img2023.cnblogs.com/blog/1519108/202308/1519108-20230807180539319-1349781737.png