性能测试概述

一、 什么是性能测试?

  • 通过工具,找出或获得系统在不同工况下的性能指标值
  • 性能测试过程中,重点是找出**性能指标**,而不再是找出 Bug,
  • 性能测试的产出绝对不只是 Bug

案例:

跑步100米,用时多少?运动员的心跳、步伐频率是多少?

  1. 跑步100米:业务场景
  2. 用时多少:响应时间
  3. 运动员的心跳、步伐:性能指标值

性能指标值和响应时间是否满足当前业务场景的最低要求(合格线)

二、 获取基准值

假设当前有一个业务

电商系统,下单业务,目前还不知道系统支持多少人同时下单,那么我们需要找到服务器能正常支持多少人同时下单

性能测试初始阶段(第一次做)

  • 先把基础的性能指标值找出来(第一次性能测试也叫做基准测试)
  • 比如:100个人同时下单系统正常,但120个人同时下单就会出现部分请求的响应时间超长,连接异常
  • 那么100-120范围内的某个值就是当前服务器能达到的性能指标值(基准值)

版本迭代,进行第二次做性能测试,重新跑一遍之前的性能脚本

  • 又会得到一些性能指标值,对比上个版本的性能指标值,看是否有优化(性能变化)
  • 假设这个时候120个人同时下单是正常的,150个人才有异常,那么接口已经有优化了

假设公司是从0开始做性能测试

  • 第一阶段:做好性能测试,得到性能指标值
  • 第二阶段:假设性能比之前差,哪些性能指标值不满足预期值,就需要分析是哪里有问题

三、 负载测试 和 压力测试

1. 概念

  • 负载测试

    • 逐步增加 系统负载(增加“用户数”),测试系统性能变化,并最终确定系统所能承受的最大负载量
    • 通俗理解:看看你几斤几两
  • 压力测试

    • 在较大的性能压力下,持续运行一个比较长的时间,看看系统服务是否正常及系统资源的利用率情况
    • 通俗理解:鸭梨山大!
    • 关键字:较大压力 + 较长时间
    • 注意:不是满负荷压力哦

2. 场景

  • 负载测试

    • 有一个业务,增加到40个人的时候,服务器还能正常使用,没有异常
    • 当你增加到50个人的时候,服务器已经开始有异常了,那么就能确定40-50之间某个值就是系统所能承受的最大负载量【出现性能拐点,找到了服务器性能瓶颈的范围值】
    • 最后减小加压梯度(比如:从40个人开始每次增加1个人、2个人),确认最大负载量【确认性能拐点】
  • 压力测试

    • 问:大家什么时候会觉得工作压力大?
    • 答:996、007;因为你不会觉得955压力山大吧
    • 结论:所以在我们日常工作中,长时间工作强度高,才会觉得压力大;如果你一周就加班一天也说压力大…(那就别干这一行了)

3. 压力测试持续运行时间要多久?

  • 标准性能测试里面,一般是7*24小时,或者是它的倍数
  • 但是实际工作中,并不会这么久,否则成本太高
  • 所以会以小时为单位,比如:4个小时、8个小时…晚上下班之后做,第二天早上上班看结果

4. 先负载测试还是压力测试?

  • 先负载测试
  • 负载测试可以找到服务器性能瓶颈的范围值,若生产环境中系统稳定性较差,再做压力测试
  • 所以压力测试是可做可不做的

四、 性能测试步骤

1. 性能测试准备

  • 需求分析,熟悉业务:确定需要重点关注的点,如TPS、响应时间(确定需要收集的性能测试指标值)
  • 明确性能测试目标(预期性能指标值)和测试范围
  • 了解软件功能、架构
  • 制定测试方案、测试计划,做好工作量评估
  • 制定测试模型(编辑测试用例):比如负载测试,场景要如何设计

2. 搭建性能测试环境

  • 技术准备:选择性能测试工具;测试方案中涉及到的技术问题;测试数据的收集方案实现;如何监控系统资源
  • 被测系统环境搭建(服务器、服务版本更新、数据库数据准备)
  • 网络配置
  • 创建初始数据,如:测试账号(预估并发量)

3. 性能测试脚本开发

  • 选取协议
  • 制作脚本
  • 调试脚本
  • 验证脚本

4. 性能测试执行

真正开始对服务器进行性能测试

  • 试运行
  • 场景执行
  • 收集并整理测试数据

5. 性能测试结果分析与调优

  • 分析依据:结果图表
  • 分析思路:服务器硬件瓶颈>网络瓶颈>服务器os瓶颈(参数配置、数据库、web服务器)>应用瓶颈(sql语句、数据库设计、业务逻辑、算法)
  • 调优
  • 修改脚本或场景
  • 性能回归,和之前的测试数据进行对比,是否有优化

7. 性能测试报告与结果跟踪

  • 性能测试报告:整理调优前后的测试数据
  • 性能测试问题跟踪
  • 构建持久化的性能监听平台,监听线上服务器的系统资源

五、 性能指标

1. 并发用户数(重点)

  • 同一时间点,发出请求的用户数,一个用户可以发出多个请求
  • 场景不一定是同一个
  • 和 CPU、响应时间有关系

和并发的关系

假设有 10 个用户数,每个用户同一时间点内发起 2 个请求,那么服务器收到的请求并发数就是 20

2. 响应时间(Respose Time)

响应时间对于性能测试来说

  • 从发起请求到收到请求响应的时间
  • 包含了:Request Time 和 Response Time
  • 等价于:发起请求网络传输时间 + 服务器处理时间 + 数据库系统处理时间 + 返回响应网络传输时间

对用户所感知的响应时间包括

  • 用户客户端渲染时间(多了这个)
  • 请求/响应数据网络传输时间
  • 应用服务器处理时间
  • 数据库系统处理时间

3. TPS(Transaction Per Second,最主要的指标)

服务器每秒处理事务数,衡量服务器处理能力的最主要指标

知道 T 是如何定义的

  • 在不同的行业、业务中,TPS 定义的颗粒度可能是不同的
  • 所以不管什么情况下,需要做性能测试的业务的相关方都要知道你的 T 是如何定义的

定义 TPS 的粒度

  • 一般会根据**场景的目的**来定义 TPS 的粒度
  • 接口层性能测试:T 可以定义为接口级
  • 业务级性能测试:T 可以定义为每个业务步骤和完整的业务流

4. RPS(Request per Second)

简单理解

每秒请求数,用户从客户端发起的请求数

5. 吞吐量(Throughput)

单位时间内,网络处理的请求数量(事务/s)

网络没有瓶颈时,吞吐量≈TPS

6. 吞吐率

单位时间内,在网络传输的数据量的平均速率(kB/s)

7. 资源利用率

  • 服务器资源的使用程度,比如服务器(应用、服务器)的CPU利用率,内存利用率,磁盘利用率,网络带宽利用率
  • 一般不超过80%