性能测试基础

1 性能测试介绍

1.1 概述

概念

性能测试是通过工具/代码模拟正常/峰值/异常的负载条件,对系统的各项性能指标进行测试和评估的过程

是服务端的性能测试,不包括客户端性能

性能测试的目的

• 评估当前系统能力,如: 新出的手机都有人做跑分测评对比

  • 如有不足,则寻找性能瓶颈,进行优化

• 评估软件能否满足未来的需求

分类

小故事

• 有一个农夫决定买一匹骡子,他认为这个骡子至少得能打动3袋大米(相当于性能需求)，他来到农贸集市上,试了好几匹骡子,都不合适,最后终于有一匹骡子能够比较轻松的扛动这3袋大米,而且还滿洒的走了几步(相当于性能测试通过)
• 然后农夫高兴地牵着这匹骡子回家,因为想看看它到底能有多强,所以农夫决定,让它扛着4袋大米走回家(加压,相当于负载测试)，这骡子虽然没那么酒了,但也能正常赶路(相当于负载测试结束,测试结果中骡子的最大负载是4袋大米)
• 因为集市离家比较远,骡子走了8个小时后,就开始两步一歇了(高负荷长时间运行,相当于稳定性压力测试),再走一会儿,终于到家,农夫心想:"这骡子路上光驮大米了,没有驮我,我也得坐上去”(相当于破坏性压力测试)，结果骡子不堪重负,连同农夫和大米都摔倒了(相当于系统崩溃）
• 后来骡子…

• 性能测试: 验证系统性能是否满足某些用户场景，是负载测试和压力测试等的统称

  此外还有并发测试/可靠性测试/容量测试等

  • 负载测试: 加压，查看系统运行情况,甚至找出系统能承受的最大负载
  • 压力测试
    • **稳定性压力测试:**高负载下长时间运行,找出系统稳定运行的时长
    • **破坏性压力测试:**高负载下继续加压,直到导致系统崩溃,关注极限负裁和系统恢复能力

示例: 进一步理解性能测试

需求: 电梯从1楼到5楼的运行时间不超过20s，需做性能测试得出乘客人数,作为警示标识

测试步骤:

• case1：1人乘坐电梯，从1楼到5楼，运行时间为15s基准测试通过(单人时)
• case2：5人乘坐电梯，从1楼到5楼，运行时间为15s
• case3：10人来坐电梯，从1楼到5楼，运行时间为18s---->找出最大负载
• case4：13人乘坐电梯，从1楼到5楼，运行时间为215
• case5：16人乘坐电梯，从1楼到5楼，运行时间为24S
• case6：19人乘坐电梯，从1楼到5楼，运行过程中绳子断了…------> 电梯崩溃, 找出极限负载

1.2 性能需求

常见性能需求

• web首页打开速度在3s以内
• 邮箱系统需支持100万在线用户,每秒至少需要能处理1000个发邮件的请求
• 某系统需支持每天1000万人次的访问
• 系统需要在实际运行压力2倍的情况下,稳定运行24小时

需求来源

• 客户方提出

  • 一般金融，银行，电信，医疗等企业，对性能有明确需求

• 内部提出

  • 产品： 一般会基于核心业务提出需求
  • 开发：一般会基于编码实现复杂度或资源占用较高的功能提出需求
  • 测试：
    • 参照竟品
    • 参照自己：根据历史运营数把进行分析,找出用户量,用户增长,用户频繁使用的功能

测试人员往往面对的是不太明确的需求,需要通过分析得到具体需求

一般需要进行性能测试的系统,用户量大,需要优先保证核心业务的性能

核心业务示例

• 商城: 登录→浏览商品→添加商品到购物车→下单→支付→查看订单
• 直播软件: 登录→搜索直播间 → 进入直播间→观看直播 →发送弾幕 →赠送礼物
• WMMS:登录→查看入库信息/新增入库信息,编辑入库信息/湖除入库信息→出库等

性能测试的对象

• 单一功能[必须掌握]
  • 商城: 并发下单,高频下单
  • 直播软件: 并发看直播,高频发弹幕
  • WMS:高频更新入库信息
• 混合业务[了解]，更接近真实场景

性能测试场景小结

**高并发:**大量用户在同一时刻访问服务器,如

• 淘宝双十一、12306抢票、商城秒杀活动、主播开播瞬间涌入大量观众等等

高频率: 大量用户在一个时间段内高领访问服务器,如

• 商城黄金时段下订单,外卖软件返点时间段下单,上班打卡,直播弹幕等等

用户量分析

有了核心业务还不够,如已知需要对 商城秒杀 或 wms更新入库信息 这两个功能做性能测试 具体需求是什么?

可以看出如果没有用户数据,无法得出具体条件,数据的来源可以是客户/产品/开发/运营等

分析过程示例

• 商城秒杀: 属于高并发场景,关键是需计算出今年将参与秒杀活动的人数

  • 去年参与秒杀的人数

  • 用户增长率

    如,去年参与秒杀1W人 用户增长10%,计算出性能测试需模拟1.1W人并发参与秒杀活动

• WMS更新入库信息:属于高频率场景,关键是需要计算出服务器每秒需要处理的请求数

  • 跟单员的人数

  • 需要跟单的时间段

如,公司有500名跟单员,每周一早上集中更新入库单信息(平均每人10单),高峰期是周一早上9:00-9:20

# 此处计算需要借用一些算法--二八原则
# 二八原则:指80%的业务量需在20%的时间内完成
# 计算过程:业务量:5000时间:20*60 = 1200秒服务器应达到的处理能力“(5000*80%)/(1200*20%)16.7个/秒职整17个/秒

说明

• 实际上,请求的分布是一个正态分布,最高峰肯定高于平均值

• 二八原则的计算结果是系统需要达到的处理能力(吞吐量)

• 如果你的系统性能要求高,也可以使用一九原则或更严格的算法,二八原则只是比较通用,大家要灵活

练习

• 判新哪个足并发用户数

  1. 某商城，注册用户3亿

  2. 某商城，当前登录用户数为1000万

  3. 某商城，目前正在选购商品的用户数为200万

• 某网站每日的总访问人数为10%,其中搜索业务占20%,浏览商品占30%,登录+购买业务占50%(每天按9小时计
  算1计算股务周应达型的吞吐量

搜索业务:(100000*20%80) / (8*3600*20%) = 2.78          取整为3浏览商品:(100000*30%*80%）/(8*3600*20%）= 4.17        取整为5登录 + 购买:(100000*50%*80%) / (8*3500*20%) = 6.94       取整为7

• 系统每年的业务集中在8个月完成,每个月平均有20个工作日，每个工作日9小时

  • 去年全年处理业务约100万笔

  • 其中15%的业多处理中的笔业务备对应用服务器提交7次清

  • 其中70%的业务处理中每笔业务需对应用服务察提交5次清

  • 剩余15%的业务处理中的统业务需对应用服务县提交3次湾或

  • 相病以往的统计结票，每年的!务增长目为15%

  • 考虑到今后3年的业务发展需亚,测过需被现有业务目的两进行计

每年总清求效:(109万15%7+100万*70-5-100万15%3)*2=1000万(100000000*80%) / (8 * 20 * 8 * 3600 * 20%) = 8.68  取整为9

1.3 性能能标

内容

• 平均响应时间
• 吞吐量
  • QPS（Queries Per Second）：服务器每秒处理的请求数
  • TPS（Transactions Per Second）：眼务器每秒处理的事务数
• 错误率
• 各种硬件指标
  • CPU占用本
  • 内存占用率
  • 硬盘 I / O
  • 网络 I / O

1.4 PV和UV[扩展]

PV和UV是运营人员常用的数据，软件测试人员只需要了解

PV概念

Page View 指页面访问量, 即每个页面的浏览次数,每次刷新都算1次

UV概念

Unique Visitor 独立访问的访问数,也就是访问的用户数,1个用户多次访问, 只算1次【PV的用户去重】

补充

• 某网站每日的总访问数10w，其实说的是PV
• 如需衡量产品的健康程度，还需借助UV
  • 如：PV高，UV低，说明只有少数老客户在高频使用，产品看起来没有健康发展
  • 如：PV低，UV高，说明使用的用户多,但是用户操作太少，产品粘性不够，也是不健康的
  • 只有PV和UV数据都发展得比较好，才能说明软件是健康发展的

1.5 测试流程

什么时候做性能测试?

功能测试通过之后

测试流程

1. 性能需求分析
2. 制定计划 (资源分配, 通过标准,技术实现,风险评估…)
3. 设计测试用例和发起用例评审
4. 搭建性能测试环境[可选]
5. 执行性能测试
6. 输出报告
7. 性能结果分析和调优[进阶]+再次测试

性能测试用例示例

2 单接口性能测试

场景

对单个功能有性能需求是最常见的情况,而功能的实现离不开后端的接口,所以需要对单接口做性能测试

• 性能测试需模拟的用户场景无非是高并发和高频率
• 在jmeter中,模拟性能测试场景需要用到定时器

常用定时器

• 同步定时器(用于模拟高并发)
• 常数吞吐量定时器(用于模拟高频率)

2.1 高并发模拟

同步定时器

以100个用户并发访问百度首页为例

1. 用于模拟并发

   • 工作原理: 线程组创建线程,同步定时器集合线程,再统一释放

2. 在需要并发的请求下添加

3. 同步定时器的设置项中,"模拟用户组的数量"就是并发数,同时也需要设置线程组中的"线程数”

需求

创建入库单功能需支持100个用户同时提交保存

• 要求平均响应时间小于3s,错误率为0,吞吐量大于34个请求每秒

• 要求CPU和内存占用率小于70%

步骤

1. 搭框架: 注意需设置线程数为100,模拟100个用户

2. 核心: 通过同步定时器控制所有用户同时访问

3. 运行并查看结果

   • 聚合报告可以查看平均响应时间,错误率,吞吐量

   • 硬件指标如何查看?

   • Windows,可以使用任务管理器

   • Linux,可以使用命令(如 top),也可以使用工具 ( dstat）

     • mdstat安袭,yum install dstat

     • dstat 命令，dstat-cndr分别代表CPU,内存,磁盘，I/O

   • 通用办法，使用imeter性能插件

     • 服务路上运行server-agent播件

     • 客户端添加监听器jp@gc-PerfMon Metrics Collector,即可看到服务器的硬件指标

2.2 高频率模拟

常数吞吐晕定时器

以用户每秒20次访问百度,持续15S为例(假设是一个用户)

1. 用于模拟固定的请求频率
2. 在需要控制频率的请求下添加
3. 常效吞吐量定时器的设置项中,“目标吞吐量”就,是用每秒请求数*60,同时线程组中尽量使用1个用户,总请求数设置为”括环次数"

需求

创建入库单功能需支持用户每秒20次访问,要至少能坚持15s

• 要求平均响应时间小于3s,错误率为0,香吐星不低于20个请求每秒

• 要求CPU和内存占用率均小于70%

步骤：

1. 搭框架: 注意需设置线程组的"循环次数"为300

2. 核心: 通过常数吞吐量定时器控制访问频率

3. 运行并查看结果

遇到问题:

创建入库单的请求,春吐量上不去，达不到20

1. 解决思路,先把有常数香吐量控制的百度请求打开,看看是否控制请求频率会受其他清求影响(结论是不会)
2. 判断当前请求本身出了问颗,那么增加线程数为3,循环次数改为100,总请求数依然维持300不变
3. 再次请求并查看香吐量能不能达到20

2.3 阶梯式加压

应用场景

• 除了性能测试的高并发和高频率两个基本场景外,我们注意到负载和压力测试都需要高负载,且高负载从技术和事实的角度,都不是一下子产生的,需要一个过程

• 在负载测试和压力测试中,经常需要用到阶梯式加压

常用组件介绍-ConcurrencyThread Group

如百度的使用高峰期有60s,高峰期有100个用户持续访问首页

需求

创建入库单功能使用高峰期有60s,60s内一直都有100个左右的用户不断的调用接口,要求系统支持

• 要求平均响应时间小于3s,错误率为0,吞吐量???(此时由于请求数不明确,可不计算吞吐量)

• 要求CPU和内存占用率均小于80%

**注意:**如果出现 HttpHostConnectException 错误, 是受自身电脑性能影响导致的,不属于bug

推荐解决方法: HTTP请求 ->高级 ->客户端实现 ->Java(默认是HttpClient4 更真实,Java 实现具备连接池

服务器的最佳用户数和最大用户数

2.4 登录用户数[扩展]

性能测试中,登录的账号到底是单个还是多个?从以下几个维度进行思考

• 需求方面
• 技术方面
• 数据方面

需要多账号登录的性能测试的实现思路

1. 准备多个登录账号 (调用注册接口或直接把数据插入数据库都可以)
2. 分别用这些账号登录,获取token,并把token保存到csv文件中
3. 读取csv文件中的token,并完成对应功能的性能测试

1. 准备多个登录账号

# mysq1阶段讲过的存储过程CREATE PROCEDURE d () BEGIN   -- 存储过程的开始DECLAREi INT DEFAULT 1;      -- 定义变量i，初始值为1WHILEi <= 10000 DO         -- 接下来是需要执行的语句INSERT INTO USERVALUES(i，concat(“张三”，i)，13000000000+i，“123456”);SET i = i + 1;END WHILE;
END    --   存堵过程的结束

# 把上面的存储过程拿来改改，增加账号的同时赋予账号角色
CREATE PROCEDURE d() BEGIN   -- 存储过程的开始DECLAREi INT DEFAULT 1:--定义变量i，初始伯为1WHILEi <= 100 D0--接下来是需要执行的语句INSERT INTO ms. sys_userVALUES(250+i,100,concat( "jay",i),'boss','00','111@163.com','15888888888' 52a510$8b7k/oR.h9vbun9k]TPp4eyvfHI92QPQTgpPXnoexFc59Pm77cPau','0",58.101.33.0"，NULL，1，NULL，NULL，NULL，'备注');INSERT INTO WmS .sys_user role WALUES(250+i. 100);SET i=i+ 1;END WHILE;
END   -- 存储过程的结束

# 最后习惯性清理烈试数据1 删除用户角色表中的测试数据selete from sys_user_role where sys_user_role.user_id inselect user_id fromselect a.user id from sys_user a inner join sys_user_role b on a.user id= b.user idwhere a.user_name like"%jay%")c)
2 圳除用户表中的汉试数据selete from sys_user where user name ike "xjay%";

2. 保存token到csv文件

// 打开流
Filewriter fstream = new Filewriter("D://token.csv", true);
Bufferedwriter out=new Bufferedwriter(fstream);// 获取token，并写入文件
out.write(vars.get("token"));// 换行
out.write(System.getProperty("line.separator"));// 关闭流
out.close();
fstream.close();

3. 读取token完成脚本

3 混合业务性能测试

混合业务组成

对服务造成压力的实际情况比较复杂，一般是由各种核心业务混合组成

• 如: 商城，登录-> 浏览商品-> 添加到购物车->下单> 支付-> 查看订单

  • 混合形式: 登录10%,浏览商品30%,玩购物车20%, 下单30%,支付10%

• 如: WMS，登录 -> 创建入库信息 /查询入库信息 /更新入库信息 / 出库

  • 混合形式: 登录5% ->入库的创建/更新/查询 各占30%->出库5%

示例

WMS高峰期1小时,平均每秒会产生100个请求(请求是混合了各种业务,入库单的创建/更新/查询 各占三分之一) (1小时太长,以30s为例)

4 分布式性能测试

4.1 概述

应用场景

单台测试机不能产生足够的线程数,需要多台测试机协作测试服务器的性能

**概念：**分布式测试: 多台测试机协作,以集群的方式共同完成测试任务

**作用：**产生海量用户

4.2 原理

4.3 实现

环境搭建步骤

1. 搭建物理环境(准备一个集群)
2. 搭建软件环境 (操作系统,防火墙,JDK, jmeter…)
3. 配置集群内的jmeter(配置控制机和执行机的jmeter)

• 控制机和执行机,需开启远程访问,配置jmeter,properties文件,设置server.rmi.ssl.disable=true

• 执行机,需设置通信端口号,配置jmeter.properties文件,设置server_port,指定一个端口号

• 控制机,配置jmeter.properties文件,设置remote hosts=localhost:xxxx,localhost:xxxx

分布式演示步骤

1. 启动集群中的测试机

   • 控制机:正常启动jmeter.bat

   • 执行机:启动imeter-server.bat

2. 在控制机编写测试脚本,关键点在于线程数的设计: 线程数=总线程数 / 执行机的数量

3. 在控制机下,菜单栏->运行 ->远程启动所有

5 常见的性能问题

业务问题(如数据唯一校验功能在并发下容易失效)

• 现象: 在井发条件下,软件系统的业务功能会收到冲击,如数据唯一校验会失效的问题

• 原因: 在修改数据时,数据没有进行锁数据的操作,导致多个请求同时操作同一数据,会出现数据错舌

• 解决方案: 数据库加锁

错误率飙升问题

• 现象: 持续加压,当请求数超过某个限制后,错误率飙升,

• 一般是数据库连接超时错误

• 原因: 常见原因是受限于数据库连接池中的连接数有限

• 解决方案:

  • 后端代码增加队列机制

  • 优化数据库的连接数

内存泄漏/内存溢出问题

• 现象: 持续加压 或 高频率请求,内存越来越少,请求结束后也没有还原

• 原因: 程序运行时使用的内存,在运行结束后依然没有释放

• 解决方案: 优化后端代码,控制内存资源的回收

平均响应时间长,吞吐量不够，CPU/内存占用高,网络/硬盘I0高等问题

• 解决方案

  • 优化后端算法

  • 加服务器

面试题

1. 什么是香吐量
   吞吐量是服务器的一个性能指标，指的是服务器每秒处理的请求数或事务数，代表着服务器的处理能力

2. QPS和TPS有什么区别

   • 二者都属于代表服务器性能的吞吐量的指标

   • (事务，就是业务)其中一个事务可以对应一个或多个请求

     • 一个事务对应一个请求时：QPS = TPS
     • 一个事务对应n个请求时：QPS = TPS*N

3. 吞吐量和平均响应时间是什么关系?[3]

   • 吞吐量越大，说明服务器处理能力越强，处理得越快，平均响应时间就会越短
   • 吞吐量越小，说明服务器处理能力越弱，处理得越慢，平均响应时间就会越长
   • 二者基本是成反比的关系

4. 在性能测试中,通常需要关注哪些性能指标?[3]

   • 服务器的处理能力

   • 平均响应时间

   • 吞吐量

   • 错误率

   • 服务器的资源瓶颈问题

   • CPU占用率

   • 内存占用率

   • 网络带宽的消耗情况

   • 硬盘读写速度情况等

5. 你们做性能测试的通过标准是什么?怎么样才算性能测试通过?[3]

   • 平均响应时间
     • 3-5-8原则
     • 对比同类产品 或 站在用户体验的角度
   • 吞吐量：需经过计算的服务器应该达到的处理能力(吞吐量 = 需要处理的请求数 / 平均响应时间)
   • 错误率：一般在1%以下，推荐0容忍
   • 各种硬件指标: 阈值设定大概在80%，超过阈值会导致系统不稳定

6. 性能测试的测试环境有什么不一样?[3]

   • 性能测试环境和系统测试的环境以及验收测试的环境都不一样
   • 性能测试环境需尽量与生产环境保持一致
     • 硬件环境: 包括服务器配置,网络带宽等
     • 软件环境: 包括操作系统,数据库,被测应用等,在版本和配置上都尽量一致
     • 使用场景: 基础业务数据和业务操作流程尽量一致
   • 最后就是客户端环境, 我个人经常使用Jmeter, 并且还要根据并发量来计算是否需要集群

7. 聚合报告一般看(包含)哪些内容?[2]
   我们主要看的性能指标有平均响应时间,错误率,吞吐量

8. 性能测试常见那些性能问题?[3]

   • 错误率

     • 当并发量超过某个限制后,错误率升,比如原本是0%,飙升后会达到50%

     • 最可能出现此问题的原因是因为数据库连接池里的连接数限制,导致大量请求超时报错

     • 解决的方向一般是

       • 优化数据库的连接数

       • 后端服务增加队列机制,让不能及时处理的请求进入等待队列,这样可以避免大量报错

   • 吞吐量

     • 常遇到的问题是吞吐量不达标,例如要求目标吞吐量500,实际测试只能达到400

     • 本质原因就是服务器处理得比较慢

     • 解决的方向一般是

       • 优化后端算法,让处理更快

       • 优化数据库，让数据查询过程更快

   • 平均响应时间

     • 并发量超过某个限制后,平均响应时间飙升,比如要求3s内,飙升到5s以外

     • 原因一般是后端服务器超负荷运行,处于性能崩溃区

     • 解决的方向一般是

       • 优化后端算法,让处理更快

       • 优化数据库,让数据查询过程更快

       • 提高服务器硬件水平

   • 硬件资源消耗

     • 这里硬件资源一般指CPU,内存,硬盘,网络等

     • 可能出现的情况是并发量达到一定值，CPU/内存占用率趋于100%,服务的能力达到瓶颈

     • 解决方向一般是

       • 升级服务器硬件或者优化后端算法

9. [项目结合问题]说说你实际做过的性能测试,属于什么场景,当时怎么做的,发现了什么问题,如何定位和解决的?[3] 【以WMS为例】

   • 1)当时我们对wms项目的核心业务 创建入库单 做了性能测试,入库单是有唯一校验的,但是在并发的场景下,我发现的bug是并发增加入库单时,唯一校验失效了,初步怀疑是数据处理的策略问题,后来查了资料并且和开发沟通过程中发现,在并发操作下,通过对表数据加锁能有效防止这种情况的发生,后来经过验证,bug得到了修复

   • 2)当时我们有个需求,wms项目的高峰期大概每周一会有两个小时,看日志发现大概有100个跟单员反复操作出入库数据,我就根据日志提取出来的比例,模拟了一个场景,100个用户平均每秒各请求1次,操作类型包括查询入库单,入库,跟单编辑入库信息,导出入库单等,后来发现了一个内存泄漏的问题,经过反复测试发现是导出入库单功能用到了文件的流式写入,但是后端代码中并未关闭写入流,后来增加了关闭代码就好了

10. 性能瓶颈有哪些?[1]

    1. 压测机瓶颈,jmeter单机的负载能力有限, 超过自身能力后,会卡顿
    2. 程序实现机制瓶颈,业务复杂度高或算法较为复杂都可以涉及到需要优化的问题
    3. JVM瓶颈,申请的内存没有及时释放,造成内存泄漏的问题
    4. 数据库瓶颈,如: 慢查询，连接池太小导致连接排队的现象等
    5. 服务器资源瓶颈

11. **[概念补充]什么是集合点?什么是检查点?**

• 集合点 ->同步定时器

• 检查点 ->断言