性能测试流程

 

1、文档目的

• 帮助你们了解性能测试流程
• 提升性能测试意识，识别、排查性能隐患
• 完善公司性能测试流程

2、性能测试简介

1、概念

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

2、目的

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

3、分类

类别	含义
压力测试	模拟大量用户向服务器产生负载，使服务器资源处于极限状态并长时间运行
容量测试	必定用户数，测试数据在不一样数量级的状况下，系统承受的最佳容量
负载测试	测试服务器在知足用户要求的范围内，能承载的最大用户数

如上表格是根据不一样的测试目的来划分性能测试，我认为更简单的归纳应该是：前端性能和后端性能

前端性能：主要表如今页面加载，通常会经过优化加载方式，减小数据传输量来进行。

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

3、性能需求

1、需求来源

性能需求通常是在需求评审会议上由产品、架构师、开发一块儿讨论决定的，能够从如下两个点来展开：

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

2、并发量

• 名词解释

TPS：服务器每秒处理的事务数，在大多数状况下和QPS能够等同；

并发数（VU）：系统同时处理的请求/事务数

响应时间（RT）：等于网络传输时间+应用服务器处理时间+数据库服务器处理时间，通常取90%时间

思考时间（TT）：从业务角度来看，用户在进行操做时，每次请求之间的时间间隔

• 计算公式

常常会遇到“设置多大并发用户数合适”的问题，在没有任何思考时间（TT）的状况下，这里有个公式：

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

TPS计算方法（两种）：

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

二、 以半年或者三个月为区间，提取某一天中接口的峰值访问量，根据现网网卡的流量，分析一天中用户的活跃时间段，而后采用二八原则（即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、接口文档

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

4、性能指标

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

指标	阈值	备注
CPU	<70%	太高会致使系统服务不稳定
内存使用率	<70%	同上
磁盘使用率	<70%	同上
网络带宽	<70%	太高会致使网络延迟，响应时间变长

5、系统架构

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

graph TD

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

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

    C -->D[缓存]

    D -->E[数据库]

6、测试计划

性能测试是一个团队协做完成的项目，须要各个部门配合，所以在测试前充分沟通、作好排期很是重要。

任务	具体内容	责任人	开始时间	完成时间	目前进展	备注
测试方案
测试环境
测试数据
脚本开发
执行测试
分析调优
测试报告

7、测试方案

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

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小时以上）的稳定性测试，考察系统长期稳定运行状况。

8、评审

测试计划、测试指标、测试方案须要拿出来让各个部门共同讨论决定，若是经过则能够进行下一步。

9、被测环境

1、环境要求

• 独立

一、排除其余应用干扰，防止资源竞争；最好是实体机，如果虚拟机须要保证压测时，带宽足够，其余虚拟机最好停用。

 

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

 

三、创建挡板，如如有涉及到外围系统，可根据实际状况，考虑屏蔽或者使用mock接口来模拟

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

一、现实状况中，测试环境很难和线上配置保持一致，此时应当保持测试环境的架构和生产上同样，再按照环境配置的比例大体估算出性能差别。配置比例通常以机器数量、CPU核数、内存数做为衡量指标；

 

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

 

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

• 压测时限制条件去掉

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

二、短信、图形验证码校验须要屏蔽，（目前短信验证经过工具没法绕过，简单的图形验证能够经过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	...	...	...	...
...
...
...

9、压力发起环境

1、压力发起方式

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

2、机器配置

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

压测开始时中先使用一台机器，如若压测机cpu和内存被占满、或者TPS上不去，则再考虑搭建集群，如今咱们广泛用的配置是8核16G， windows2008操做系统。

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

3、搭建环境

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

10、测试帐号和数据

1、测试帐号

压测过程就是模拟大量用户访问系统的行为，所以必然涉及到用户登陆的问题，那么就须要足够的测试帐号。

避免只使用一个帐号来模拟多用户，一个用户发送屡次请求和多个用户发送一次请求，由于缓存的缘由，对系统压力是不同的。

2、服务器帐号

在了解系统架构后，为了监控服务器的各项指标，须要找运维同事申请服务器帐号（操做系统、数据库、redis等），如若由于权限问题不能给到帐号，则须要运维同事帮忙看监控。

3、数据

• 测试数据

测试数据应当尽可能模拟用户的真实操做

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

脚本模拟的是多个用户的操做，所以对于有些参数不是惟一的，就不该该写死，而须要动态传入不一样的值

举例：模拟用户浏览帖子的接口（http://bbs.feidee.com/thread-718207-1-1.html），718207是帖子ID，

由于每一个用户看的帖可能不同，且社区帖子有不少个，那么此处每次请求的参数应该是不一样的帖子ID，可提早在数据库中将帖子ID导出到本地文件中，而后每次请求时依次读取。

• 数据库数据

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

11、测试脚本

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

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

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

12、服务端监控项

在实际压测过程当中，因测试人员没有权限的问题，不少监控项是须要运维、DBA同事来协助，所以这个环节须要大量的沟通工做。

1、服务器硬件资源

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

二、使用命令行，top,iostat ,vmstat，sar

前端nginx做为高性能的反向代理服务器，通常不多有瓶颈，故此处不加监控

2、应用

一、tomcat链接池配置

二、jvm堆内存使用状况，fullGC次数以及时间

三、部署jvisualvm或者jprofiler

3、数据库

一、慢sql

二、缓存命中率

三、全表扫描数

四、链接数

4、缓存

一、内存使用率

二、命令处理数

三、慢命令

四、链接数

十3、执行测试

运行测试脚本， 实时观察聚合报告，如若出现大量错误，须要当即中止，并分析缘由，从新调试；
特殊状况下，有些压测时间须要在凌晨进行，那么能够借助于jmeter的调度器定时启动脚本；

十4、结果分析、调优

将测试结果与用户预期指标进行对比，若是达到则测试经过；若是达不到，则须要提交bug，并进一步分析缘由，待开发修复后，从新执行测试，直到符合指标为止。

1、接口响应时间

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

2、 TPS

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

 

二、jmeter插件：Transactions per Second 看TPS的走势

3、服务端资源利用率

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

4、事务成功率

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

5、分析步骤

• 若是响应时间过长，那么能够按照下面的思路逐步分析：

一、查看tomcat和nginx日志，若有报错，分析错误缘由

 

二、网络缘由，用sar命令或者Zabbix监控查看网络出口、入口流量，排查是不是网络延迟

 

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

 

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

 

五、查看jvm使用状况，看是否有fullGC状况

 

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

 

七、使用jvisualvm、jprofiler的热点分析（或者线程dump），找出耗时最长的代码

 

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

• 若是TPS上不去：

一、压测机的资源消耗状况

 

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

 

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

 

四、考虑搭建集群

6、常见性能问题

一、数据库过多调用

二、数据库资源泄露

三、链接池过小

四、sql未加索引、锁表

五、写log影响IO性能

六、jvm参数设置不合理

七、服务端未启用长链接

十5、性能测试流程

 

十6、测试报告

1、测试结论

根据结果分析的结论，得出这次压测是否知足用户预期指标。

性能测试采用的测试策略是：在测试环境用脚本模拟用户的操做，进而向服务器发起压力，预估是否有性能问题。即便各个测试环节都正确，也和正式环境上用户行为有必定偏差，所以不少状况下，测试结果只能做为参考，不能彻底做为依据。

2、输出报告

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