1、性能测试的目的

• 目的在于测试系统相关性能能否满足业务需求。
• 找各种bug，找bug的途径如下
  • 高压力
  • 长时间
  • 与功能测试的区别在于量的不同
• bug的表现
  • 系统挂掉
  • 系统性能持续快速下降/周期性变化
  • 系统响应缓慢且压力下降后没有恢复
  • …………

2、需求分析

• 测试对象
  • 要测啥？
  • 有没有必要测？
  • 通常，可以从以下几个方面考虑：
    • 是否核心功能，是否要求严格的质量
    • 是否常用、高频使用的功能
    • 可能占用系统较多资源的功能
    • 使用人数多还是少
    • 在线人数多还是少
• 拆分对象
  • 先从业务上来分，实现这个完整的功能包含哪些流程、环节
  • 比如：购买商品
    • 登录->搜索商品->提交订单->支付订单->退出
  • 然后从功能实现上来看，怎么实现这个完整功能的。通常这些业务功能操作都对应着一个或多个请求(可能能是不同类型的请求，比如 http, mysql 等)，我们要做的是找出这些操作对应的请求，请求之间的顺序是怎么样的。
• 指标分析
  • 分析性能需求指标（如“支持 300 人并发登录”）是否合理
  • 有没有必要测试这个需求，考虑需求指标是否合理？有没有数据支撑？
  • 通常，支撑数据可以从以下方面考虑：
    • 采样时间段内系统使用人数
    • 采样时间段内系统在线人数
    • 采样时间段内系统(页面)访问量
    • 采样时间段内请求数
    • …………
  • 常用分析思路：
    1. 2/8 法则
       • 2/8 法则：80%的业务量在 20%的时间里完成。这里，业务量泛指访问量，请求数，数据量等
    2. 正态分布
    3. 按比例倍增
    4. 响应时间 2-5-8
       • 就是说，一般情况下，当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；当用户在 5-8 秒以内得到响应时，会感觉系统的速度很慢，但是还可以接受；而当用户在超过 8 秒后仍然无法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。
    • 注意：这个要根据实际情况，有些情况下时间长点也是可以接受的，比如购票网站
    • 举例：
      • 某公司后台监控，根据一段时间的采样数据，分析得出日高峰时段(11:00-14:00)用户下单请求数平均为1000，峰值为 1500，根据这个计算并发请求数。
      • 时段：3 个小时 -> 3 x 60 x 60 = 1080s
      • 业务量：1500
      • 吞吐量：1500 * 80% / (1080 * 20%) = 5.56 请求数/s
    • 注意:
      • 2/8 原则计算的结果并非在线并发用户数，是系统要达到的处理能力（吞吐量）
      • 如果要求更高系统性能，根据实际情况，也可以考虑 1/9 原则或其它更严格的算法
      • 以上估值只是大致的估算，不是精确值
  • 数据生命周期：
    • 一般来说，数据都是有一定的生命周期的，时间的选取需要结合数据周期考虑。这里假设 3 年后系统性能仍然需要满足业务需求。
  • 数据增长率：
    • 如果是老项目，可以考虑对应功能主表历史数据存放情况
    • 这里假设按年统计，比如第一年 10000，第二年 15000，第三年 20000，第四年 25000，那么我们得出，以第一年为基准，数据增长率分别为 0.5，1，1.5，每年在上一年的基础上，以 5000 的速度增长。预估 3 年后，数据增长率为 3，需要测试数据量为 （1+3）x 10000 = 40000
    • 注意：
      • 实际数据一般是没上面举例那么规律的，只能大致估算数据增长率。
      • 一些大数据量的性能测试除了和数据量相关，还涉及到数据分布等，比如查询，构造数据时需要结合实际，尽量贴近实际。
      • 不同业务模块，涉及表不一样，数据量要求也是不一样的，需要有区别的对待。
    • 如果是新项目，那就比较不确定了，除非能收集相关数据。

3、理发店模型

• 一个理发店有三位理发师傅
• 每位理发师傅服务一位顾客需要一小时
• 顾客从进理发店起最多只能等待三小时

理发区
|h| |h| |h|
|_| |_| |_|

等待区                    红色报警区
|w| |w| |w| |w| |w| |w| |w| |w| |w|
|_| |_| |_| |_| |_| |_| |_| |_| |_|

• 最佳用户数:3
• 最大用户数:9
• web模型

|-------------------------tomcat -------------------------|--------- nginx ----------|
|----------处理中-------------|----------排队中-------------|---------排队中------------|

• 没有排队的server
  • pop3,imap,smtp

|-------------------------server ------------------------| |--------- client ----------|
|------------------------处理中---------------------------| |-----------等待中-----------|

4、系统分析

• 结合需求分析，分析系统架构。
  1. 请求顺序、请求之间相互调用关系
  2. 数据流向，数据是怎么走的，经过哪些组件、服务器等
  3. 预测可能存在性能瓶颈的环节（组件、服务器等）
  4. 明确应用类型 IO 型，还是 CPU 消耗性、抑或是内存消耗型 -> 弄清楚重点监控对象
  5. 关注应用是否采用多进程、多线程架构 -> 多线程容易造成线程死锁、数据库死锁，数据不一致等
  6. 是否使用集群/是否使用负载均衡
• 通常建议测试时先不考虑集群，采用单机测试，测试通过后再考虑使用集群，这样有个比较，比较能说明问题。

5、业务分析

• 明确要测试的功能业务中，功能业务占比，重要程度。目的在于
  • 明确重点测试对象，安排测试优先级
  • 建模，混合场景中，虚拟用户资源分配，针对不同业务功能施加不同的负载。
• 明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题，因为那块需求分析时可能
  只是大致估算下，评估指标是否合理，需要认真再分析下

6、用例设计

• 系统业务特点和用户行为分析– 测试对象
• 系统性能指标分析– 测试目标
• 性能测试执行策略分析– 测试执行

用例设计–系统业务特点和用户行为分析

• 使用高峰时段分析
• 高峰期业务应用分析
• 高峰时段统计方法
  • 按时间进行分类
    • 工作日，节假日
    • 每日的上班时间，下班时间
  • 统计粒度建议1小时
• 业务分析统计方法
  • 统计特定时间段业务调用次数
  • 按倒序排列
  • 计算各业务数量占比
• 如无真实环境
  • 使用类似功能的其他环境统计

用例设计–系统性能指标分析

• 并发用户数量设计
  • 按既定目标设计
  • 逐步提升数量，找到合适的数量
• 事务平均响应时间–3，5，8秒（具体看实际情况而定）
  • 3秒以内用户会认为响应时间较快；
  • 5秒以内用户认为可以接受；
  • 超过8秒，一般用户会认为响应太慢

用例设计–性能测试执行策略分析

• 单业务测试
  • 核心模块对应的业务
  • 频繁使用的业务
• 混合业务测试
  • 按比例组合各个单业务进行测试

事务定义

• 根据用例合理的定义事务，方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。
  比如，购买商品，我们可以把下订单定义为一个事务，把支付也定义为一个事务。

场景监控对象

• 针对每条用例，结合“系统分析”第 4）点，明确可能的压力点（比如数据库、WEB 服务器），需要监控的对象，比如 tps，耗时，CPU，内存，I/O 等。

7、测试策略

1. 先进行混合业务功能场景的测试，再考虑进行测试单业务功能场景的测试
2. 负载测试 -> 压力测试-> 稳定性测试-> 强度测试
3. 逐步加压
   • 比如开始前 5 分钟，20 个用户，然后每隔 5 分钟，增加 20 个用户。
   • 好处：不仅比较真实的模拟现实环境，而且在性能指标比较模糊，且不知道服务器处理能力的情况下，可以帮我们确定一个大致基准，因为通常情况下，随着用户数的不断增加，服务器压力也会随着增加，如果服务器不够强大，那么就会出现不能及时处理请求、处理请求失败的情况下，对应的运行结果图形中，运行曲线也会出现对应的形态，比如从原本程一条稳定直线的情况，到突然极限下降、开始上下波动等，通过分析我们就能得出服务器大致处理能力，供后续测试参考。
4. 单点并发
   • 比如使用集合点，单独针对某个环节的并发测试，通常是针对某个环节的性能调优时使用。

• 常识：
  • 负载测试
    • 保证系统能正常运行(通常是满足某些系统性能指标)的前提下，让被测对象承担不同的工作量，以评估被测对象的最佳处理能力、最大处理能力以及存在缺陷而进行的测试。
  • 压力测试
    • 不保证系统能否正常运行的前提下，让被测对象承担不同工作量，以评估被测对象能提供的最大处理能力及存在的缺陷而进行的测试，方便知晓系统响应何时退化和失败。
  • 稳定性测试
    • 测试系统的长期稳定运行的能力。同疲劳强度测试的区别是，稳定性测试的压力强度较小，一般趋向于客户现场日常状态下的压力强度，当然在通过时间不能保证稳定性的状态下，需要加大压力强度来测试，此时的压力强度则会高于正常值。
  • 强度测试
    • 通常模拟系统在较差、异常资源配置下运行，如人为降低系统工作环境所需要的资源，如网络带宽，系统内存，数据锁等等，以评估被测对象在资源不足的情况下的工作状态。
    • 注：疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如 7×24 小时的压力测试。

8、各种指标

各种指标–系统性能指标

• TPS（Transaction per Second）
  • 系统每秒处理交易数，单位是笔/秒。越大越好 ↗
• VU（Virtual User）
  • 虚拟用户，并发数。
• RT（Response Time）
  • 交易响应时间，低于5秒。越小越好↘
• FR（Failure Ratio）
  • 错误率，低于 6‰。越小越好↘
• 90%响应时间
  • 有90%的事务的响应时间低于此。越小越好↘

各种指标–硬件性能指标

• CPU占用

  • user
  • sys
  • wait
  • 如果 CPU 有 100％ 利用率，那么应该到达这样一个平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time（仅供参考）。
  • 如果User值大于 80%，说明可能存在CPU资源不足。
  • 上下文切换应该和 CPU 利用率联系起来看
    • 比如system time（sy）很高，而 user time（us）很低，而且加上高频度的上下文切换（cs），则说明正在运行的应用程序调用了大量的系统调用（system call）
    • user time（us）一直保持在 80％ 以上，而且上下文切换较低（cs），则说明某个进程可能一直霸占着 CPU。
  • 可运行队列 run queue（r），每个可运行队列不应该有超过1－3个线程（每处理器，即每个核数），比如：双处理器系统（单CPU的双核系统）的可运行队列里不应该超过6个线程。

• 磁盘

  • 占用：nmon中的 Disk Busy，iostat中的 %util（表示磁盘忙碌情况）
    • 如%util接近100%，表示磁盘产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
  • TPS：nmon中的 DISKXFER ，iostat中的tps（即为磁盘的 IOPS）
    • tps：每秒向磁盘设备请求数据的次数（每秒从物理磁盘 I/O 的次数），包括读、写请求，为rtps与wtps的和。出于效率考虑，每一次IO下发后并不是立即处理请求，而是将请求合并(merge)，这里tps指请求合并后的请求计数。
    • 在测试工作中，我们主要关注 IOPS 和吞吐量以及磁盘的 busy% 这三个数值。如果 IOPS 和吞吐量均很低，磁盘的 busy% 也很低，我们会认为磁盘压力过小，造成吞吐量和 IOPS 过低；只有在 IOPS 和吞吐量均很低，磁盘的 busy% 很高（接近 100%）的时候，我们才会从磁盘 I/O 方面分析 I/O 性能，磁盘 I/O 可能存在瓶颈。

• 内存

  • 操作系统会最大化利用内存，利用率高并不是问题
  • 需要观察是否有大量的swap

• 网络

  • 可能有些有些环境是百兆网，存在带宽不足
  • 可能受防火墙，负载均衡影响

各种指标–稳定性指标

• 最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。
  • 对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。
  • 对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
• TPS曲线稳定，没有大幅度的波动。
  • 需要排除系统定时任务造成的波动
• 各项资源指标没有泄露或异常情况。

各种指标–瓶颈，分析

• 木桶原理
  • 一只木桶盛水的多少，不取决于桶壁上最高的那块木块，而恰恰取决于桶壁上最短的那块
  • 推论一
    • 只有桶壁上的所有木板都足够高，那木桶才能盛满水
  • 推论二
    • 只要这个木桶里有一块不够高度，木桶里的水就不可能是满的。
• 观察硬件指标中哪个满载，哪个就是瓶颈
  • cpu 100%
  • 磁盘占用（DISK busy 100%）
  • 网络带宽满了
  • 大量使用swap时，可能是内存不够
• 如果所有资源都很空闲
  • 可以进一步提升压力
  • 程序需要优化
• 系统性能表现应该与压力相符
  • 正常的表现
    • 压力上升，TPS，CPU，磁盘同时上升
    • 压力平稳，曲线平稳
    • GC表现正常
  • 不正常的表现
    • 压力平稳， 内存占用持续增长， CPU持续增长
    • 压力上升，CPU下降
    • 压力不大，但GC表现不正常，如频繁full GC

9、并发数 vs TPS

• 衡量系统性能的两种标准

  • 用户角度：系统支持xxx并发用户
  • 服务器端角度：系统每秒处理xxx个事务

• 相互换算

  • TPS=VU / RT

• 通过TPS估算VU

  • 最大VU：TPS*5S
  • 最佳VU：TPS*3S
  • 例外：
    • VU超过系统最大线程数+等候队列数
    • SMTP，POP3，IMAP没有排队机制
    • nginx配置了max_conns

• 例子

  • 系统a支持5000并发用户
  • 系统b支持3000并发用户
  • 系统a的RT=2秒
  • 系统b的RT=1秒
  • 系统a的TPS=2500
  • 系统b的TPS=3000

• 系统的性能由TPS决定，跟并发用户数没有多大关系。

• 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。（与响应时间有关）

• 混合场景中如何实现各业务按指定比例运行?

  • 并发数比例 ≠ TPS比例
    • 不同事务的响应时间不一样
  • 日志统计需要区分并发数与TPS
  • 用vu的比例来模拟TPS的比例比较困难
  • 可采用JMeter函数助手中的__counter函数实现

10、基准/版本测试

• 基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。
• 有一套固定硬件，一套测试场景
• 在此固定硬件上按测试场景进行测试，并记录测试结果
  • 以此结果作为系统在此硬件上的参考性能
• 用途
  • 不同版本系统性能参考
  • 配置相似的硬件的性能参考
• 比较原则
  • 尽可能减少变更内容，减少干扰项
    • 如：软硬件只改变一个
• 与上一版本的性能对比
• 本版本的稳定性
• 不同硬件的性能估算
  • 木桶原理
    • 增加非瓶颈性能并不会提高整体性能
    • 只有提升瓶颈性能才能提升系统性能
  • CPU是瓶颈
    • CPU处理器个数与性能大致上是线性关系
  • IO是瓶颈
    • 与实际的IO性能IOPS有关系，但未知是否线性
  • 内存
    • 一般只有容量够和不够的区别，内存速度一般不成为瓶颈

11、统计学相关

• 统计学相关–x%平均响应时间
  • 通常取90%作为整体的参考时间
• 统计学相关–曲线平稳

  • 变异系数，又称“离散系数”（coefficient of variation），是概率分布离散程度的一个归一化量度，其定义为标准差与平均值之比

      变异系数 C·V = 标准差 SD / 平均值Mean 
    

• 统计学相关–排队论
  • 排队论(Queuing Theory) ，是研究系统随机聚散现象和随机服务系统工作过程的数学理论和方法，又称随机服务系统理论，为运筹学的一个分支。
  • 单位时间访问服务器的用户数服从泊松分布，其概率密度函数可百度查看
  • excel 公式：POISSON(x,mean,cumulative)
  • POISSON 函数语法具有下列参数：
    • X 必需。 事件数。
    • Mean 必需。 期望值。
    • cumulative 必需。 一逻辑值，确定所返回的概率分布的形式。 如果 cumulative 为 TRUE，则 POISSON 返回发生的随机事件数在零（含零）和 x（含 x）之间的累积泊松概率；如果为 FALSE，则 POISSON 返回发生的事件数正好是 x 的泊松概率密度函数。