企业化的性能测试简述---如何设计性能测试方案

时间 2019-11-25

标签企业化性能测试简述如何设计方案栏目系统性能繁體版

原文原文链接

性能测试简介：

性能测试包括的范围很是普遍，简单来讲能够分为后台性能测试（Linux服务器，mysql服务器，文件服务器等等），客户端性能测试（WEB前端，移动端等）前端

通常企业的性能测试指的是狭义的后台性能测试，性能测试整个流程以下:java

1. 性能测试需求与调研mysql

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

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

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

5. 出具性能测试报告windows

性能测试须要测试具有的能力（后续博客会持续更新）：api

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

1 概述

1.1 测试目的

本方案用以描述 XXX系统的性能测试过程内容，用以指导测试人员准备并执行性能测试，发现系统中可能存在的性能问题，提出优化建议并解决，以下降或避免因为性能问题带来的系统风险，为系统的稳定运行提供保证。主要关注点以下：

明确测试范围和目标。
确认测试过程细则：测试环境、测试场景、测试策略、过程关注等。
性能出口要求及风险预估。

1.2 适用范围

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

1.3 参考资料

2 测试需求

2.1测试架构

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

压测环境架构：单机环境

2.2测试场景

本次测试包含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/（3x0.8）=47tps；

2.3相关人员

角色	姓名	备注
架构
项目经理
开发
测试

2.4计划安排

序号	阶段	执行人	时间计划
1	性能调研和确认
2	性能方案产出
3	脚本和数据准备
4	执行性能压测
5	性能测试报告产出

3 测试方案

3.1 测试策略

3.1.1 压测策略

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

压测策略说明：

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

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

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

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

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

测试执行策略以下：

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

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

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

3.1.2 测试监控策略

监控层面	监控工具	说明
OS层	Zabbix/top命令	关注硬件的实时使用状况
应用层	Zabbix/jvisualvm	关注java应用线程和堆内存状况
DB层	Monyog	关注mysql在压测过程当中出现的慢查询和锁

3.2 测试用例

所属策略	用例编号	用例名称	并发配置	重点关注
指标验证	C01	session-info	47	47并发，配置thinktime（控制QPS），压测结果知足47/0.3s。
	C02	appkey	47
	C03	getUserCurrent	47
	C04	list all	47
	C05	fixed	47
	C06	home	47	47并发，配置thinktime（控制QPS），压测结果知足47/0.5s。
负载测试	C01	session-info	逐步增长并发	基于指标验证用例，进行阶梯性并发压测（如50、100、150），每一个阶梯压测10分钟，关注系统在各个并发下实际处理能力。
	C02	appkey
	C03	getUserCurrent
	C04	list all
	C05	fixed
	C06	home
稳定性	M01	C01-C06，6个场景，各47并发	282	根据指标要求将全部场景进行混合，持续压测10小时，关注整个压测过程当中系统的稳定性和资源使用状况。

3.3测试准备

3.3

3.3.1 测试环境

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

类型	生产环境配置	测试环境配置	备注
应用1	x4	4C4G x1	Nginx，
应用2	x3	4C8G x1	IT门户
应用3	x4	4C8G x1	应用服务
应用4	x4	4C8G x1	租户服务
中间件	x1	4C8G x1	Redis
DB	x1	24C32G x1	Mysql
网络环境	公网	内网环境	全部测试应用在同一网段

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

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

3.3.2 相关工具

性能测试工具：Jmeter

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

3.3.3 测试脚本

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

检查点配置：在脚本中设置合理的检查点，保证接口返回的正确性（事务成功率的统计）。
QPS控制（加thinktime）：使用JMeter插件Throughput Shaping Timer控制QPS（LR的话配置pacing time），便于进行并发压测。

3.3.4 测试数据

类型	库名	表名	测试数据量	预估生产数据量	是否须要铺底	说明
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万

3.4达标出口

3.4

3.4.1 软件达标出口

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

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

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

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

　　n 性能拐点值：随着并发增长TPS没法增长甚至出现降低时的点。

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

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

3.4.2 阈值要求

监控类型	监控指标	阈值要求
资源监控	Load average	<CPU核数*2
	CPU利用率	物理机<80%，虚机/容器<75%
	系统内存使用	占用<80%
	磁盘Util%	占用<80%
	网络带宽	占用<70%
Java 进程监控	Younggc	Younggc频率不超过1s
	Younggc	Younggc时间不超过200ms
	Fullgc	FullGC的频率不大于1小时，FullGC时间不超过2s。
	线程状态	大量的线程blocked
	线程状态	currentThreadsBusy监控
数据库	慢查询	出现慢查询语句
数据库	死锁	出现死锁
中间件	Redis	Redis操做耗时<1ms
中间件	Memcache	缓存命中率>80%
日志监控	错误日志	出现严重级别的Error或Exception
业务指标	响应时间	测试结果RT<=指标要求
	TPS	测试结果TPS>=指标要求
	成功率	测试结果成功率>=99.99%

3.5过程准则

过程	条件
准入准则	压测环境和机器准备完成（压测机、待测应用服务和数据库、网络环境等）
	待测流程的功能测试经过，版本稳定。
	待测流程的测试数据和测试脚本准备完毕。
暂停准则	测试中发现问题，须要项目组修改代码或更换版本；
	测试中发现服务规划及部署问题，须要从新调整部署方案；
	须要调整测试环境资源配置，如加减CPU数目，增长存储等等。
	测试环境使用受到干扰，如服务器被临时征用或非压测流量进入性能环境
准出准则	全部测试场景完成执行，对应各场景的测试过程数据和监控数据均已保存和记录。
	性能指标达到《性能测试方案》的要求，无遗留性能问题（或评估后可暂时遗留）
	测试报告完成。

4 附录

4.1相关术语

术语简写	说明
TPS/QPS	每秒事务数或每秒请求数，指服务器在单位时间内能处理的请求的数量。如100tps，表示系统1秒处理了100个请求。
响应时间	指一个用户的从发起请求到收到响应所用的时间。
并发数	指某一时刻同时发起的请求数量（通常以秒为时间粒度）。
RT	响应时间英文简写，咱们所说的RT都是指平均响应时间
PV	page view，即页面浏览量。用户对网站中的某个网页访问1次均被记录1PV。用户对同一页面的屡次访问，访问量累计。通常对web测试时关注。

4.2其余

无