实际工作中的性能测试介绍

一、文档目的

• 帮助大家了解性能测试流程
• 提高性能测试意识，识别、排查性能隐患

二、性能测试简介

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

八、评审

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

 

以上就是实际工作中的性能测试流程,可供参考。