「性能测试」如何设计企业交付级别的性能测试方案

用途：

即可用于质量团队自身的性能测试方案参考。

也可用于性能测试的验收，有些公司的性能测试是外包给了第三方。

性能测试包括的范围非常广泛，简单来说可以分为后台性能测试（Linux服务器，mysql服务器，文件服务器等等），客户端性能测试（WEB前端，移动端等）

一般企业的性能测试指的是狭义的后台性能测试，性能测试整个流程如下:

1.性能测试需求与调研

2.设计性能测试方案，并出具文档

3.审核方案，确定后准备性能测试数据，测试环境

4.按照测试方案执行性能测试

5.出具性能测试报告

性能测试需要测试具备的能力（后续博客会持续更新）：

1.常规性能测试工具的使用（Jmeter，Zabbix，jvisualvm，Monyog等等）

2.对性能测试的各层进行测试的能力（一般指的是：OS层，应用层，DB层）

3.设计合理的测试方案的能力（熟悉性能基准指标验证，逐步加压原则，混合压测稳定性验证等方法）

4.Linux等后台系统独立搭建后台测试环境的能力

下面是一个性能测试方案的实例：

目录

1概述3

1.1测试目的3

1.2适用范围3

1.3参考资料3

2测试需求4

2.1测试架构4

2.2测试范围4

2.3相关人员5

2.4计划安排5

3测试方案6

3.1测试策略6

3.1.1压测策略6

3.1.2测试监控策略7

3.2测试用例8

3.3测试准备8

3.3.1测试环境8

3.3.2相关工具9

3.3.3测试脚本9

3.3.4测试数据9

3.4达标出口10

3.4.1软件达标出口10

3.4.2阈值要求11

3.5过程准则12

4附录13

4.1相关术语13

4.3其他13

明确测试范围和目标。

性能出口要求及风险预估。

本文档适用于参与XXXX系统性能测试项目的相关人员。

生产环境物理架构：未提供架构图，架构保证测试环境部署与生产一致（区别仅在机器的数量）

压测环境架构：单机环境

本次测试包含6个场景，对应场景和TPS指标如下：

场景

接口名称

接口描述

协议类型

生产指标

测试指标

备注

编号

TPS/RT

TPS/RT

S01

/XXX-info

获取会话

Http

112/0.3s

47/0.3s

S02

/XXX

获取XXX

Http

112/0.3s

47/0.3s

S03

/XXX

获取当前用户信息

Http

112/0.3s

47/0.3s

S04

/XXX/all?userId=123456

获取所有应用列表

Http

112/0.3s

47/0.3s

S05

/XXX/app/fixed

获取常用应用

Http

112/0.3s

47/0.3s

S06

home

访问首页

Http

112/0.5s

47/0.5s

Tips：本次生产集群指标TPS=5万/3600秒x8倍系数=112tps；

单机环境测试指标TPS=112/（3）=47tps；

角色

姓名

备注

架构

项目经理

开发

测试

序号

阶段

执行人

时间计划

1

性能调研和确认

2

性能方案产出

3

脚本和数据准备

4

执行性能压测

5

性能测试报告产出

本次测试将采用Jmeter工具，通过控制线程数来模拟用户并发。

压测策略说明：

1、指标验证：验证被测交易在测试环境中是否能达到指标要求的TPS/RT，每个轮次持续10分钟。

（单接口指标验证，如果单接口都无法达到指标，无需再进行负载和稳定性测试，不满足最基础的交付目标，需要重点优化。）

注：如接口性能较差时，在压测指标前，先使用1个并发(不加thinktime)压测3分钟，得出一组基准数据，可作为参考依据。

2、负载测试：在指标验证基础至上，对每个接口逐步增大并发，每个轮次持续10分钟。（阶梯性的加压测试，找出性能拐点，压测出当前系统下最大的处理能力，便于对后续容量和风险预估。）

3、稳定性测试：对核心场景按照指标要求进行并发配比后压测，持续时长5-10小时。（混合场景稳定性测试，验证系统整体的资源使用情况、处理能力是否平稳。）

测试执行策略如下：

1、拿到基准数据后，先进行指标验证测试，查看是否可以达到目标TPS；

2、在达标基础之上，使用不同并发，进行多次阶梯性负载验证，找到性能拐点；

3、针对重点场景进行混合，进行稳定性验证。

监控层面

监控工具

说明

OS层

Zabbix/top命令

应用层

Zabbix/jvisualvm

DB层

Monyog

所属

用例

用例名称

并发

重点关注

策略

编号

配置

C01

session-info

47

C02

appkey

47

指标

C03

getUserCurrent

47

47并发，配置thinktime（控制QPS），压测结果满足47/0.3s。

验证

C04

list

47

C05

fix

47

C06

home

47

47并发，配置thinktime（控制QPS），压测结果满足47/0.5s。

C01

session-info

C02

appkey

逐步增加并发

负载

C03

getUserXXXX

测试

C04

listall

C05

fixed

C06

home

稳定性

M01

C01-C06，6个场景，各47并发

282

测试环境布局如下：(同测试架构图)，测试环境硬件信息如下：

类型

生产环境配置

测试环境配置

备注

应用1

x4

4C4Gx1

Nginx，

应用2

x3

4C8Gx1

IT门户

应用3

x4

4C8Gx1

应用服务

应用4

x4

4C8Gx1

租户服务

中间件

x1

4C8Gx1

Redis

DB

x1

24C32Gx1

Mysql

网络环境

公网

内网环境

所有测试应用在同一网段

Tips：应用配置相同，机器数量不同情况下，测试环境单机指标折算公式为

T测单=T生集/(N生产折算系数)

性能测试工具：Jmeter

资源监控工具：APP--ZIBBIX、资源监控器（windows自带的）、Jmeter工具

此次测试的接口均为Http协议的（get方式），故采用Jmeterhttp请求sampler设计测试脚本。

检查点配置：在脚本中设置合理的检查点，保证接口返回的正确性（事务成功率的统计）。

QPS控制（加thinktime）：使用JMeter插件ThroughputShapingTimer控制QPS（LR的话配置pacingtime），便于进行并发压测。

类型

库名

表名

测试

预估生产

是否

说明

数据量

数据量

需要铺底

Mysql

XXX-service-XXXX-auth

XXX_user

1

20万

是

压测前铺底数据20万

XXX_app

18

18万

否

配置表无需铺底

XXX_user

1

15万

是

压测前铺底数据15万

XXX_user

1

15万

是

压测前铺底数据15万

XXX-service-user

user_info

1

15万

是

压测前铺底数据15万

1、指标验证：压测持续10分钟，达到目标TPS指标且成功率达到100%(成功率可根据实际业务场景调整)，实际响应时间=指标要求RT；

2、负载验证：每个阶梯压测持续10分钟，成功率=99.9%。

n指标阈值：指标响应时间要求内的最大处理能力，也是最优处理能力；

n资源阈值：资源占用（cpu/IO/mem）在80%左右时的处理能力；

n性能拐点值：随着并发增加TPS无法增加甚至出现下降时的点。

（负载压测目的就是至少可以得到以上3个值中的某1个。）

3、稳定性测试：运行5-10hours+，事务成功率要高于99.9%，硬件资源占用在阈值要求内。

监控类型

监控指标

阈值要求

资源监控

Loadaverage

CPU核数*2

CPU利用率

物理机80%，虚机/容器75%

系统内存使用

占用80%

磁盘Util%

占用80%

网络带宽

占用70%

Java

Younggc

Younggc频率不超过1s

进程监控

Younggc时间不超过200ms

Fullgc

FullGC的频率不大于1小时，FullGC时间不超过2s。

线程状态

大量的线程blocked

currentThreadsBusy监控

数据库

慢查询

出现慢查询语句

死锁

出现死锁

中间件

Redis

Redis操作耗时1ms

Memcache

缓存命中率80%

日志监控

错误日志

出现严重级别的Error或Exception

业务指标

响应时间

测试结果RT=指标要求

TPS

测试结果TPS=指标要求

成功率

测试结果成功率=99.99%

过程

条件

准入准则

压测环境和机器准备完成（压测机、待测应用服务和数据库、网络环境等）

待测流程的功能测试通过，版本稳定。

待测流程的测试数据和测试脚本准备完毕。

暂停准则

测试中发现问题，需要项目组修改代码或更换版本；

测试中发现服务规划及部署问题，需要重新调整部署方案；

需要调整测试环境资源配置，如加减CPU数目，增加存储等等。

测试环境使用受到干扰，如服务器被临时征用或非压测流量进入性能环境

准出准则

所有测试场景完成执行，对应各场景的测试过程数据和监控数据均已保存和记录。

性能指标达到《性能测试方案》的要求，无遗留性能问题（或评估后可暂时遗留）

测试报告完成。

术语简写

说明

TPS/QPS

每秒事务数或每秒请求数，指服务器在单位时间内能处理的请求的数量。

如100tps，表示系统1秒处理了100个请求。

响应时间

指一个用户的从发起请求到收到响应所用的时间。

并发数

指某一时刻同时发起的请求数量（一般以秒为时间粒度）。

RT

响应时间英文简写，我们所说的RT都是指平均响应时间

PV

无