性能测试简介

Posted 2021-02-20 wheelcode

性能测试简介

性能测试的类别

1. 基于协议级接口的性能测试：模拟大量客户端请求发送给服务器，评估服务端的负载处理能力，硬件的使用效率等，具体参见性能测试的核心概念
2. 基于代码级接口的性能测试，原理上与协议级别的接口类似，是利用API通过线程并发的方式向Server端发送请求
3. 单击应用程序的性能测试：移动APP对终端的资源消耗等，或web端对javascript运行效率等

性能测试的核心技术原理

• 基于协议
• 多线程
• 模拟真实场景

系统负载模型图

常用术语

• 最佳用户数：系统能够承受的最佳负载，表示系统在此负载下各方面情况良好，软硬件资源不存在浪费，一般资源利用率在60%~80%
  • 系统长时间运行而无有效的垃圾回收机制导致系统处理能力降低
  • 系统用户增加而导致软件件资源短缺
• 最大用户数：系统能够承受的最大负载，是衡量一个系统能否正常运转的临界值
  • 系统响应不及时，资源利用率过大，但系统不至于崩溃，但影响用户体验
  • 用户吞吐量和资源利用率都大，条件一般限于用户数量
  • 会造成内容泄露，宕机，无响应或堵塞等情况
• 在线用户数：一般在线用户数不能表示系统的负载（没有向系统发送请求）
• 并发用户数：同时对服务器产生请求的用户数（时间段并发）
• 系统用户数：系统额定的用户数量

性能测试的核心概念

1. 性能测试

   Performance Testing 一定的负载情况下，系统的响应时间等是否满足特定的性能需求，一般目的不是找BUG，而是排除系统的瓶颈（木板原理）

2. 负载测试

   Load Testing 一定的软件，硬件，网络环境，通过改变系统的负载方式/增加负载等来发现系统中所存在的性能问题，一般用于测试在用户的要求范围内，确定系统能承载的最大用户数，最大有效用户数，关注不同用户数下的系统响应时间及服务器的资源利用率

3. 压力测试

   Stress Testing 一定的软件，硬件，网络环境，模拟大量的虚拟用户是服务器资源处于极限状态下长时间运行，测试服务器能否在高负载情况下稳定工作，目的是找出服务器失效反应及易失效点

4. 容量测试

   Volume Testing 向数据库或硬盘中构建大量数据记录

5. 配置测试

   Configuration Testing 通过运行多种业务在一定的用户并发数量下获得不同配置的性能指标，从而得出最佳的设备及参数配置

性能测试的实施过程

1. 技术层面上来说，性能测试是基于自动化测试脚本已经完成的情况下
2. 实施层面上来说，需要分析性能测试结果并找到定位瓶颈，需要考虑软硬件环境
3. 运营层面上来说，性能测试需要时间的基类，与功能性测试不同
4. 分析和设计层面上来说，性能测试需求较为模糊

模拟用户实用场景的注意点

• 页面资源（web页面资源加载/渲染）
• 请求数量（严格模拟用户请求发送流程）
• 参数化（防止缓存或后台影响）
• 思考时间（人类行为）
• 带宽（实际场景）
• 并发用户数（原则上不以并发用户数定义性能指标，而是单纯以多线程设置对应策略）
• 数据库容量（数据库数据增加导致数据库操作的效率降低，需要大量数据模拟）
• 缓存的使用（内存，web端页面缓存）
• 请求数据的大小（模拟实际场景，而非自己图方便随意撰写）
• 负载生成器与被测试服务器分离

性能测试场景设计

门型场景

并发用户数直接上升到最大用户数，持续一段时间后全部停止，一般用于压力测试或可靠性测试

拱形场景

并发用户数逐渐上升，持续一段后慢慢下降，从而确定当前配置的系统环境能够支撑的最大/最佳用户数

复杂场景

模拟还真是服务器访问情况，需要大量历史数据作为支撑

混合场景

综合利用上述场景

性能测试指标分析

1. 响应时间（response time）从开始到完成某项工作所需时间，响应时间随负载的增加而增加
2. 吞吐量（throughput）反应系统处理能力，单位时间内完成工作，系统中最慢的点决定了整个系统的吞吐率，为瓶颈
3. TPS事务处理能力（transaction per second）
   1. 业务的响应时间
   2. 处理业务的成功率
   3. 单位时间内处理的业务量
4. 资源利用率（utilization）->CPU Time/queue length 内存 频率 磁盘使用率，带宽等
5. 数据库性能
6. web前端性能等