性能测试从零开始实施指南——测试计划篇

最近有些同窗找我咨询关于性能测试计划相关的问题，缘由是他们公司要作性能测试，Leader要求写一份性能测试计划，苦于以前没作过相关工做，无从下手。

这篇博客，结合我我的的一些经验和总结，聊聊如何制定一份较为全面的性能测试计划。。。

 

1、测试背景

首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具有什么特色，为何要进行性能测试，预期的一些指标等等。

好比：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。

核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。

 

2、测试目的

测试的目的要根据测试背景来分析设定，好比：

一、线上服务因为流量太高某部分应用挂了，那测试目的就是：定位瓶颈、分析调优验证；

二、运营作了拉新和新的渠道拓展，那测试目的就是：评估系统性能是否知足新的线上业务；

三、系统架构由集群技改成微服务，那测试目的就是：验证稳定性、可用性、单实例容量，为线上服务扩容提供容量规划数据；

 

3、测试范围

经过需求调研，分析用户使用场景，对业务数据量增加变化趋势及峰值活跃用户等数据作定量分析，肯定被测系统的应用范围，好比订单+购物车+商品+支付服务。

业务归属模块	业务涉及场景
订单	建立订单
	取消订单
购物车	添加购物车
	删除购物车
商品	商品列表
	商品详情
支付	余额支付
	支付宝支付
	微信支付

 

4、术语约定

这里的术语指的是：涉及本次性能测试相关的一些专业术语说明，目的是统一口径，作解释说明，便于参与本次性能测试的相关人员理解。常见术语以下：

术语名称	术语释义
并发	单位时间内（S）模拟客户端发起的请求数量
稳定性	验证系统在长时间（24h/48h）负载状况下的性能表现
高可用	验证系统在一部分服务宕机后可否正常提供服务以及服务恢复速率
TPS	每秒事务数，即系统单位时间内（S）的请求处理能力
RT	响应时间，及系统处理一笔请求所耗费的时间
请求成功率	在测试过程当中，系统成功处理请求占总请求数的百分比

PS：术语约定以实际状况为准，还要考虑性能测试计划的受众对于性能测试的了解程度，本约定旨在统一描述的口径，下降沟通成本。

 

5、环境说明

通常来讲，进行性能测试的环境都是在UAT或者独立的性能测试环境，但为了准确描述环境类型和配置，以及测试环境和生产环境的区别，建议对生产环境和测试环境进行对比说明。

一、生产环境

①、系统架构

PS：上图只是一个简略的微服务类型系统架构，只作示意，理解便可。

②、服务配置

服务名称	数量	配置	备注
gateway server	10	2C3G	网关服务，身份验证和请求转发
web server	3	2C3G
app server	5	2C3G
Redis	3	4G	哨兵模式，一主两从
DB	2	8C16G	一主一从

二、测试环境

①、系统架构

②、服务配置

服务名称	数量	配置	备注
gateway server	5	2C3G	网关服务，身份验证和请求转发
web server	2	2C3G
app server	2	2C3G
Redis	2	4G	哨兵模式，一主一从
DB	2	8C16G	一主一从

三、负载机配置

负载机（machine）即模拟客户端发送请求的机器，通常状况下，说明负载机的硬件配置，数量，IP，发压策略便可。

四、网络

即负载机和性能测试环境的网络情况，好比国内公网/同一VPC内网，防火墙策略等。

 

6、需求分析

需求分析通常有这几个阶段：需求接入→需求收集→需求分析，主要内容以下：

一、业务模型

以下是一个典型的电商平台核心业务链路图，涉及到登陆、首页、商品、购物车、支付、分享等模块。

二、性能指标

这里的性能指标包含以下两项：

①、业务性能指标

即预期的TPS、RT、请求成功率（通常默认请求成功率≥99.99%）。

②、硬件性能指标

即服务端资源耗用指标，常规的资源监控指标有：CPU使用率、Memory使用率、系统IO、网络IO等。

 

7、测试策略

本次性能测试所采用的测试策略，好比：

探测系统性能拐点，须要阶梯式压测；

探测系统在可接受的性能指标下最大的处理能力，须要采用负载、容量测试策略；

验证系统的稳定性和高可用，须要采用稳定性、高可用测试策略；

验证系统在不一样配置下的性能表现，通常采用配置测试策略；

一、测试策略及场景

①、容量测试

场景名称	01_登陆 02_首页
执行时间	10min
业务配比	100%
测试策略	容量测试
测试目的	不断增长负载，验证系统单节点的最大性能表现

②、稳定性测试

场景名称	混合场景
执行时间	24h
业务配比	按生产业务配比，等比缩放
测试策略	稳定性测试
测试目的	验证系统长期运行的稳定性以及是否存在OOM之类的问题

PS：如上表格描述，依然做为一个示例来讲明，主要内容包括：场景编号、测试类型、涉及业务场景、业务配比、执行时间、测试目的。

二、测试监控策略

监控对象	指标范围	监控工具
CPU	≤90%	nmon、zabbix
Memory	≤70%
网络IO	无明显IO瓶颈
JVM	无频繁FGC状况	jmap、jstat

 

8、准备工做

准备工做主要包含以下几项：

准备事项	准备内容	责任人	预计完成时间
工具准备	负载工具、监控工具、分析工具	测试/运维	0.5工做日
脚本准备	测试脚本	测试	0.5工做日
环境准备	机器配置、服务部署联调、脚本调试	运维/开发	1工做日
数据准备	铺底数据、测试数据、参数化数据、缓存数据	DBA/开发/测试	1工做日

 

9、组织架构

组织架构即本次性能测试涉及到的团队各角色成员，主要包含这些：PM角色、测试、开发、运维、DBA、网络、基础架构。示例：

 

10、风险分析

罗列开始执行前会影响本次性能测试工做开展的风险项以及应对方案，好比：

风险类型	风险描述	风险级别	应对方案
交付风险	UAT阶段发现较严重的功能缺陷	高	测试时间顺延，或增长对应人员
变动风险	临时需求变动、新增需求	高	需求评审是否加入本次测试范围，阶段性交付
数据风险	数据脱敏耗时较长、测试数据不可用	中	从新拟定数据准备方案，小范围数据验证
环境风险	部署出现问题，联调进度缓慢、网络带宽瓶颈	中	更换环境、增长资源配置、扩展带宽

 

11、交付清单

在性能测试计划中，须要说明本次性能测试各阶段的交付物，主要包含这几项：性能测试计划&方案、测试脚本、性能缺陷统计、轮次小节、性能测试报告。

 

12、阶段进度

这里主要指的是从需求阶段到结束，各个阶段的工做进展以及资源安排，建议采用看板的方式，及时更新进度，方便推动工做的开展。示例以下：

阶段	事项	开始时间	结束时间	状态	责任人
需求阶段	需求评审			完成	多方参与
	系统架构图			完成	开发
	需求调研			完成	性能测试人员
准备阶段	环境交付			完成	运维、开发
	应用部署			完成	运维、开发
	数据准备			完成	开发、DBA、测试
	脚本开发			完成	性能测试人员
实施阶段	执行压测			未完成	性能测试人员
	服务监控			未完成	运维、测试
	数据收集			未完成	性能测试人员
结束	报告评审			未完成	多方评审

 

如上，就是一个较为完整的性能测试计划内容，固然，完成性能测试计划并评审经过后，就能够进入测试执行阶段了。。。