系统性能测试，如何做系统性能测试

本文讲述了系统性能测试，如何做系统性能测试。

常见的性能问题

资源泄漏、系统内存泄漏、线程阻塞（死锁）、查询速度变慢、CPU利用率达到100%

为什么要进行性能测试？

进行基准的性能测试，获取系统性能的基准性能指标（新系统）

测试系统是否满足了系统的性能需求（用户期望系统达到的性能指标）

系统是否可以处理预期的并发用户数量并且有盈余能力

看系统是否达到要求的性能指标

系统是否可以处理期望的事务数量

系统在预期和非预期的用户数量下，都可以稳定的运行

系统在任何情况下，用户可以有良好的体验

当系统出现性能问题时，可以找出系统的性能瓶颈

进行性能测试（配置测试），可以帮助系统规划硬件设备

系统性能测试的流程

系统性能的需求

根据性能需求，分析出系统性能指标要求（量化）

根据性能需求分析出进行的性能测试的类型，确定性能测试场景

运行性能测试场景，得出性能测试报告

根据性能测试报告找出系统性能瓶颈

如何确定性能测试需求 --> 确定性能测试指标

关键性能指标的分析

关键业务分析（用户频繁使用、计算量大的业务）

软件系统性能相关人员

软件开发人员：系统架构；算法效率；资源分配不合理的问题；并发设计是否合理；数据库设计是否合理

运维人员：系统的容量；系统长期稳定运行；服务器及各种资源分配是否合理；可扩展性

用户：用户体验（响应时间快，稳定）

测试人员：以上都要考虑

常见的性能指标

系统/事务的平均响应时间

事务处理效率TPS（Transaction Per Second）

吞吐率

每秒点击次数（Hits Per Second）

服务器资源占用情况，内存和CPU使用率

软、硬件配置是否合适（容量规划/硬件选型）

性能测试术语

并发用户数

系统用户数量：注册系统的用户数

并发用户数量：同一时刻向服务器发送请求数

业务层面并发数：同一时刻向服务器发送请求的用户数量

后端服务层面并发数：同一时刻向后台服务发送的请求的数量

响应时间：用户发出请求，到前端页面渲染出所有数据展示到用户面前所需要的时间

事务响应时间：服务器处理完一个事务所需要的平均时间

平均每秒处理的事务数：服务器平均每秒处理多少个事务，衡量系统关键性能指标（TPS：Transactionn Per Second）

点击率（HTTP Per Second）：每秒处理的HTTP请求的个数

吞吐量：服务器单位时间处理的信息量（HTP、TPS、Byte/s ）

思考时间：模拟用户思考时间

资源利用率：系统运行时占用的资源的情况（CPU、内存、硬盘、网络等）

性能测试方法（类型）

基准测试：对于一个全新的系统，需要了解这个系统的性能，就要进行基准测试，获取系统的性能指标

提高系统的性能指标，或者评估新开发的功能对系统的性能的影响的时候，需要用基准性能指标做参考

并发测试：同一时刻向系统的服务器发送请求，看在并发情况下系统的性能的表现，是否会出现资源竞争不合理、内存泄漏、死锁等性能问题

压力测试：不断给后端服务器施加压力（增加请求数量），看系统处理临界饱和状态下，服务器的各种性能指标是否在正常范围内，看下系统是否会出现性能问题

配置测试：测试系统在不同的软硬件环境的配置下系统性能的表现，找出适合系统运行的软硬件环境配置。

操作系统、JVM版本、服务器指标、数据库、网络、内存

可靠性测试：并发情况下，长时间运行系统（24h、一周、一月），看系统的性能指标是否稳定，是否会出现问题。

一、性能测试的概念

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。性能测试也有其他叫法，压力测试、容量测试、极限测试等。

二、性能测试的要素

指标(tps、响应时间、资源利用率等)、模型（真实场景的抽象、策略）、监控（系统级cpu、memory、i/o、network、system、swap等、数据库监控、tomact中间件监控、代码级监控、链路监控）、预定的条件（软硬件环境、测试数据、测试执行策略）、场景、分析调优、结果报告；

三、性能测试基本流程

（一）压测场景收集

首先，从产品经理处收集压测场景及用户行为数据；

从需求获取压力场景：10个租户，每个租户平均日常工单量为100，日常在线用户60个，每个租户平均用户数200个，全天工作时间分布在8:00-18:00，平均每个工单业务周期为3天；

举例：

（二）制定测试方案

第一步：根据原始需求场景确定以下压力测试场景、测试点及估算相关指标：

1. 平均并发：10个租户，每个租户200个用户，根据业务量1000单/天，与需求确定，每用户每天2单计算，每天有500个用户上线系统，且上线和登录时间为整天工作时长，则平均并发用户=500*8/8=500；

2. 并发峰值：用户并发峰值= 平均并发+3*根号平均并发=567；

3. 平均响应时间：单点效率小于2秒，并发场景下平均响应时间小于3秒；

4. 估算TPS：根据需求提供场景，设备服务各业务从时间分布上没有密度的差异（需后续通过日志统计用户行为确定），所以根据并发用户数和间隔时间估算出TPS(每秒事务数)

TPS=并发用户/（操作间隔+平均响应时间）

第二步：确定单点业务压测策略；

总体策略：考察单项业务的最大负载能力，单项业务达标是混合业务压测的基础；采用阶梯压测，缓慢上线用户，以便检测监控TPS、事务平均响应时间与上线用户的关系；基础并发为50，极限并发为100，每秒上线1个用户，运行120分钟；

操作步长：模拟上线用户实际可以提交的最大业务量，设置操作步长为1秒；

思考时间：根据实际测算统一为5秒；

第三步：确定混合业务场景压测策略

总体策略：模拟实际业务场景，考察系统整体业务运行下的负载能力，采用阶梯压测，缓慢上线用户，以便与监控TPS、事务平均响应时间与上线用户的关系，设计总用户数为567个，每秒上线1个用户，运行时间8小时；

操作步长：1.工单流程（创建工单-确认-派工-接收-签到-完工）包括：移动端-服务申请、移动端-快速工单、小程序端-故障报修/调试申请、PC端-安装工单，操作步长为7200秒；

2.查询流程：操作步长为3600秒；

思考时间：根据实际测算统一为5秒；

注：1、压力测试并发用户数量：

模拟真实再现用户并发数量

2、步长：

每个虚拟用户在一个事务执行结束到下个事务执行开始之间的等待时间

3、思考时间：

用例回放时各个事务点之间的停顿时间

4、QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

5、TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

QPS = req/sec = 请求数/秒

TPS =事务数/秒(每秒事务数)

（三）测试准备

1、工具准备

测试工具：jmeter等；

系统监控工具：Grafana等；

链路监控工具：Pinpoint等；

2、环境准备

测试前要确定被测试应用的资源情况，这样做的目的：

1. 在既定的软硬件资源下进行测试，修改和调优前后的性能指标才有对比性；

2. 根据性能测试结果，得出系统资源基本配置和推荐配置

3. 动态调整资源，需要有一定的规则；比如特定并发验证符合性能指标，并且cpu资源平均负载在70%-80%以下，可以选择继续增加并发，直到cpu平均负载超过80%，再考虑增加资源；

以某被测系统为例，应用资源池为7台主机组成，数据库服务器为1台主机，均采用容器化部署

3、数据准备

准备租户、准备基础数据、被功能验证通过

（四）录制和调试脚本

使用工具：Fillder+jmeter

（五）执行测试

1.查看测试结果（事务通过数，失败数，tps曲线等）

以某工单功能为例

Tps最高上3.74，通过事务平均响应时间(秒)：12.365，用户并发到达80有大量事务报错，无法满足性能指标要求；

分析发现以下情况

上线用户增加到25-30左右时，TPS会有一个比较明显的下落，并且后续随着上线用户增加TPS没有增加的趋势，说明上线用户到达30时，系统性能已经出现瓶颈；

说明系统对于创建工单的最大用户容量大概在60个，最高TPS为3.7；

2.分析工具（链路分析，慢sql，系统资源监控等）

（六）测试报告

整理形成测试报告

上文就是小编为大家整理的系统性能测试，如何做系统性能测试。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)睿象云智能运维平台软件分析、比较及推荐。