性能测试流程

Posted lynnetest

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了性能测试流程相关的知识,希望对你有一定的参考价值。

 

一、文档目的
  • 帮助大家了解性能测试流程
  • 提高性能测试意识,识别、排查性能隐患
  • 完善公司性能测试流程

二、性能测试简介

1、概念

模拟并发用户访问系统,根据监控的指标来评估系统的性能。

2、目的

  • 验证上线功能点是否满足性能指标
  • 找出服务器的承压能力,作为优化和扩展的评估资料
  • 减少宕机风险,提高用户体验

3、分类

类别

含义

压力测试

模拟大量用户向服务器产生负载,使服务器资源处于极限状态并长时间运行

容量测试

一定用户数,测试数据在不同数量级的情况下,系统承受的最佳容量

负载测试

测试服务器在满足用户要求的范围内,能承载的最大用户数

如上表格是根据不同的测试目的来划分性能测试,我认为更简单的概括应该是:前端性能和后端性能

前端性能:主要表现在页面加载,一般会通过优化加载方式,减少数据传输量来进行。

后端性能:主要涉及到接口的处理逻辑优化、服务器参数配置、硬件资源消耗等。

三、性能需求

1、需求来源

性能需求一般是在需求评审会议上由产品、架构师、开发一起讨论决定的,可以从以下两个点来展开:

  • 新系统
  • 产品、架构师在前期需求调研时,预估出可能造成大并发的点(大量用户同时请求,大量计算型任务、频繁操作数据库等场景);
  • 旧系统
  • 根据生产环境日志(ELK),统计出高频访问接口(动态资源),以此确定对应的业务场景
  • 线上曾经出现过性能问题的点,可作为参考
  • 大型活动,例如抢红包,直播,秒杀活动等
  • 主观感受,功能测试时请求时间较长的点

2、并发量

  • 名词解释

TPS:服务器每秒处理的事务数,在大多数情况下和QPS可以等同;

并发数(VU):系统同时处理的请求/事务数

响应时间(RT):等于网络传输时间+应用服务器处理时间+数据库服务器处理时间,一般取90%时间

思考时间(TT):从业务角度来看,用户在进行操作时,每次请求之间的时间间隔

  • 计算公式

经常会遇到“设置多大并发用户数合适”的问题,在没有任何思考时间(TT)的情况下,这里有个公式:

VU(并发压测用户数) = TPS(每秒执行事务数) × RT(响应时间)

TPS计算方法(两种):

1、ELK中kibana组件可以实时统计出线上接口访问情况,选取三个月内访问量最大的一天,然后缩小时间范围,精确到半小时以内,进而计算出每秒最大峰值访问量

2、 以半年或者三个月为区间,提取某一天中接口的峰值访问量,根据现网网卡的流量,分析一天中用户的活跃时间段,然后采用二八原则(即80%的访问是在20%的时间内完成),随后计算出每秒的访问量,即TPS

举例:

假设理财社区半年内浏览帖子的日访问量峰值是500万(从日志中提取);

现网网卡流量来看,每天社区活跃时间区间为早上八点到晚上十点(08:00-22:00),共计14小时。

根据二八原则,400万(500*80%)的访问量是在2.8小时(14*0.2)内完成的,转化成秒,

即TPS = 4000000/(2.8*3600) = 396

假设用户每次打开帖子的响应时间是2秒,那么此时并发数为792

注:实际测试过程中,为了模拟更多用户,会在脚本中加大思考时间,这样得到的并发用户数就会变大,也更加仿真。

第一种方法更为精确(推荐使用),第二种可能会有一定误差。

3、接口文档

在确定了具体的业务场景后,开发人员需要提供该业务的接口文档,以便测试人员预估脚本的开发难度,准备测试数据等;

四、性能指标

  • 响应时间,理想情况,单个接口响应时间低于1秒,最多不能超过3秒
  • TPS是否达到预期值
  • 事务成功率不能低于98%
  • 服务器资源利用率

指标

阈值

备注

CPU

<70%

过高会导致系统服务不稳定

内存使用率

<70%

同上

磁盘使用率

<70%

同上

网络带宽

<70%

过高会导致网络延迟,响应时间变长

五、系统架构

后端性能测试是基于接口来进行,了解系统架构,有利于我们知道接口的处理逻辑、数据流向,大概知道哪些地方可能会有瓶颈,因此也会在相应的地方添加监控。

graph TD

    A[客户端]-->B[HTTP服务器]

    B -->C[应用服务器]

    C -->D[缓存]

    D -->E[数据库]

六、测试计划

性能测试是一个团队协作完成的项目,需要各个部门配合,因此在测试前充分沟通、做好排期非常重要。

任务

具体内容

责任人

开始时间

完成时间

目前进展

备注

测试方案

           

测试环境

           

测试数据

           

脚本开发

           

执行测试

           

分析调优

           

测试报告

           

七、测试方案

根据具体的需求分为单场景和混合场景,单场景主要是测试某个接口的性能极限,混合场景主要是更加仿真,尽最大可能模拟真实环境。

1、单场景

对单个业务场景进行基准测试,采用压力逐步递增的方式,找到性能拐点。

举例:

场景

并发数

加压时间(分)

平均时间(秒)

90%时间(秒)

TPS

浏览帖子

10

10

1

1.5

10

浏览帖子

20

10

     

浏览帖子

30

       

2、混合场景

对所有业务场景进行阶梯式压力发起,得到最佳处理能力(需要保持背景压力和实时业务压力不变)。

举例:

场景

并发数

加压时间(分)

平均时间(秒)

90%时间(秒)

TPS

浏览帖子

10

10

1

1.5

10

发帖

20

10

     

回复帖子

20

       

举例:一个系统除了浏览帖子这个场景外,还有其他的访问压力(发帖,回帖),在逐步对浏览帖子这个场景施压的时候,需要把其他的压力加上

3、稳定性测试

以混合场景,日常交易量的压力对系统进行长时间(24小时以上)的稳定性测试,考察系统长期稳定运行情况。

八、评审

测试计划、测试指标、测试方案需要拿出来让各个部门共同讨论决定,如果通过则可以进行下一步。

九、被测环境

1、环境要求

  • 独立

1、排除其他应用干扰,防止资源竞争;最好是实体机,若是虚拟机需要保证压测时,带宽足够,其他虚拟机最好停用。

 

2、压测不能在生产上进行。

 

3、建立挡板,如若有涉及到外围系统,可根据实际情况,考虑屏蔽或者使用mock接口来模拟

  • 和生产环境架构、软件版本保持一致

1、现实情况中,测试环境很难和线上配置保持一致,此时应当保持测试环境的架构和生产上一样,再按照环境配置的比例大致估算出性能差异。配置比例一般以机器数量、CPU核数、内存数作为衡量指标;

 

 参考公式:n =公倍数((生产环境web服务器/测试环境web服务器),(生产环境app服务器/测试环境app服务器))*(生产服务器内存/测试服务器内存)

 

2、服务器软件版本和生产环境保持一致(nginx,tomcat,jdk,redis,mysql等)

  • 压测时限制条件去掉

1、为了模拟大并发,我们的请求全部都是从一台机器上发送的,可能为了防止DDos攻击,对访问的IP的次数和频率都有限制,此时应该从代码层将限制去掉

2、短信、图形验证码校验需要屏蔽,(目前短信验证通过工具无法绕过,简单的图形验证可以通过OCR技术识别,复杂的可借助于深度学习)

2、部署环境

需要开发、运维、DBA协助来进行,部署最新的代码(功能测试通过后的),并加上相应监控项。

3、环境清单

需要从运维那里拿到生产环境和测试环境的配置信息。

举例:

IP

机器用途

操作系统

软件版本

机房

配置

192.168.1.100

数据库

centos

mysql5.6

北京

CPU: E5-2620 2.0GHz 6核 *2

内存:8*24G

硬盘:8*300G

192.168.1.101

...

...

...

...

     

...

             

...

             

...

             

九、压力发起环境

1、压力发起方式

  • 使用工具来发送大量HTTP请求,如Jmeter,Loadrunner,Locust
  • 依赖第三方的jar包或者库,用Java或者Python编写代码
  • 实时拷贝线上流量,借助于TCPCopy、gor等,将线上流量导入到被测环境中

2、机器配置

  • 一台机器的带宽、最大文件句柄数都有系统级限制,为了能发起更大压力,测试过程中可能需要多台机器组建集群来同时施加压力

压测开始时中先使用一台机器,如若压测机cpu和内存被占满、或者TPS上不去,则再考虑搭建集群,现在我们普遍用的配置是8核16G, windows2008操作系统。

  • 机器应当尽量和被测环境在同一网段内,这样才能避免因网络延迟导致并发压力上不去的状况。

3、搭建环境

  • 配置jdk
  • 安装jmeter及其插件
  • 调整jvm参数
  • 部署集群

十、测试账号和数据

1、测试账号

压测过程就是模拟大量用户访问系统的行为,因此必然涉及到用户登录的问题,那么就需要足够的测试账号。

避免只使用一个账号来模拟多用户,一个用户发送多次请求和多个用户发送一次请求,因为缓存的原因,对系统压力是不一样的。

2、服务器账号

在了解系统架构后,为了监控服务器的各项指标,需要找运维同事申请服务器账号(操作系统、数据库、redis等),如若因为权限问题不能给到账号,则需要运维同事帮忙看监控。

3、数据

  • 测试数据

测试数据应当尽量模拟用户的真实操作

举例:用户在论坛发帖,假设发帖的字数平均在100字左右,但是脚本中发送的却只有10个字,那么在数据传输过程中,对带宽以及数据库存储空间的消耗是不一样的。

脚本模拟的是多个用户的操作,因此对于有些参数不是唯一的,就不应该写死,而需要动态传入不同的值

举例:模拟用户浏览帖子的接口(http://bbs.feidee.com/thread-718207-1-1.html),718207是帖子ID,

因为每个用户看的帖可能不一样,且社区帖子有很多个,那么此处每次请求的参数应该是不同的帖子ID,可提前在数据库中将帖子ID导出到本地文件中,然后每次请求时依次读取。

  • 数据库数据

数据库中应该用足够的数据,避免“空库测性能”,可依据生产环境中的数据存量按照一定的缩小比例来决定数据量。

十一、测试脚本

分析完压测需求后,拿到对应的压测接口文档,根据对应的Url、参数,通过工具来模拟大量用户发送请求;本文中以jmeter举例;

  • 搭建jmeter运行环境
  • 部署分布式压测集群
  • 设置并发线程、脚本运行时间
  • 使用jmeter发送http请求
  • 添加监听器(聚合报告、TPS)
  • 调试接口
  • 脚本试运行。

注:接口调试成功后,可以设置多个线程,运行时间设置为5分钟,打开查看结果树,运行脚本,看是否有报错。没有的话则压测脚本编写完成。

十二、服务端监控项

在实际压测过程中,因测试人员没有权限的问题,很多监控项是需要运维、DBA同事来协助,因此这个环节需要大量的沟通工作。

1、服务器硬件资源

1、使用监控系统:Zabbix,Cacti,NMON, jmeter-Agent,监控cpu,内存,IO,网络等使用情况

2、使用命令行,top,iostat ,vmstat,sar

前端nginx作为高性能的反向代理服务器,一般很少有瓶颈,故此处不加监控

2、应用

1、tomcat连接池配置

2、jvm堆内存使用情况,fullGC次数以及时间

3、部署jvisualvm或者jprofiler

3、数据库

1、慢sql

2、缓存命中率

3、全表扫描数

4、连接数

4、缓存

1、内存使用率

2、命令处理数

3、慢命令

4、连接数

十三、执行测试

运行测试脚本, 实时观察聚合报告,如若出现大量错误,需要立即停止,并分析原因,重新调试;
特殊情况下,有些压测时间需要在凌晨进行,那么可以借助于jmeter的调度器定时启动脚本;

十四、结果分析、调优

将测试结果与用户预期指标进行对比,如果达到则测试通过;如果达不到,则需要提交bug,并进一步分析原因,待开发修复后,重新执行测试,直到符合指标为止。

1、接口响应时间

从jmeter的聚合报告中看平均时间和90%响应时间

2 TPS

1、jmeter聚合报告中的吞吐量

 

2、jmeter插件:Transactions per Second 看TPS的走势

3、服务端资源利用率

从Zabbix监控上看服务器的资源利用率(包括应用、数据库、缓存)

4、事务成功率

从聚合报告上看各个接口的错误率,不能超过2%

5、分析步骤

  • 如果响应时间过长,那么可以按照下面的思路逐步分析:

1、查看tomcat和nginx日志,如有报错,分析错误原因

 

2、网络原因,用sar命令或者Zabbix监控查看网络出口、入口流量,排查是否是网络延迟

 

3、查看数据库慢sql日志,看是否有耗时较长的sql

 

4、查看redis慢命令以及命令处理数,看是否有耗时较长的命令

 

5、查看jvm使用情况,看是否有fullGC情况

 

6、查看tomcat与nginx、redis、mysql的连接数是否设置足够

 

7、使用jvisualvm、jprofiler的热点分析(或者线程dump),找出耗时最长的代码

 

8、各个服务器硬件资源是否达到瓶颈

  • 如果TPS上不去:

1、压测机的资源消耗情况

 

2、查看压测环境jmeter堆内存设置、最大文件句柄数

 

3、聚合报告中带宽消耗是否达到瓶颈

 

4、考虑搭建集群

6、常见性能问题

1、数据库过多调用

2、数据库资源泄露

3、连接池太小

4、sql未加索引、锁表

5、写log影响IO性能

6、jvm参数设置不合理

7、服务端未启用长连接

十五、性能测试流程

技术分享图片

技术分享图片

 

十六、测试报告

1、测试结论

根据结果分析的结论,得出此次压测是否满足用户预期指标。

性能测试采用的测试策略是:在测试环境用脚本模拟用户的操作,进而向服务器发起压力,预估是否有性能问题。即使各个测试环节都正确,也和正式环境上用户行为有一定误差,因此很多情况下,测试结果只能作为参考,不能完全作为依据。

2、输出报告

将以上性能测试的全流程(包括压测结果、相应服务器截图、发现的性能bug、遇到的问题)整理好文档后,用邮件的方式发送给相对应开发、产品、运维、DBA、测试,并抄送上级领导。

 


以上是关于性能测试流程的主要内容,如果未能解决你的问题,请参考以下文章

性能测试流程简介

性能测试流程

性能测试--测试流程篇

性能测试性能测试的基本流程

一个完整的性能测试流程

干货|一次完整的性能测试,测试人员需要做什么?