再谈性能测试之需求调研

2019-12-02 19:09:13 浏览数 (1)

之前的文章聊聊性能测试开始前的准备工作,聊了一些关于性能测试开始前要做的准备工作。

这篇文章,来谈谈性能测试开始前的需求调研阶段,我们要做什么,关注那些Point。。。

一、基本信息

信息类型

说明

项目名称

项目归属的业务线,项目名称

项目类型

新建、迭代、重构。。。

项目背景

因为什么原因,需要进行性能测试

测试目的

进行性能测试的目的:容量规划、性能验证或者其他原因

测试范围

被测系统业务模块,属于什么业务,有什么特点

里程碑

设立此次性能测试的里程碑,即不同阶段的达成以什么为结束标志,比如:测试方案、环境准备、测试实施等

影响因素

要实施此次性能测试,有哪些潜在问题,影响因素

二、环境信息

信息类型

说明

系统架构图/网络拓扑图

通过系统架构图/网络拓扑图,可以快速直观的了解到系统的结构,数据流

部署方式/部署层级

集群、分布式、微服务/web、app、db层

性能测试环境

PAT、UAT、SIT不同环境对测试结果的影响不同

被测系统环境的软硬件配置

比如服务器是几核几G,有多少台;数据库是几核几G,有多少台

关键参数

线程池、最大连接数、消费者数量、内存分配等

网络

负载机和被测系统的网段、防火墙策略、带宽、CDN等

特殊因素

是否存在某些特殊因素,会影响测试结果

三、应用信息

信息类型

说明

业务模型

比如支付类业务、批量审核或提交、库存业务、查询业务等

业务场景

什么时间什么用户做什么操作

协议/接口

HTTP、Socket、Dubbo。。。

连接方式

长连接、短连接

通信策略

同步、异步

变更策略

参数的加解密、拼接、动态变化、依赖关系等

四、性能指标

指标类型

说明

user

包括注册用户数、在线用户数、并发用户数等

TPS

每秒事务数,包括服务端和数据库

RT

包括ART、%RT、MaxRT、MinRT

吞吐量

吞吐量在一定程度上可以用来衡量系统的容量

交易量

日/月/某个时间段内的交易量,可更好的衡量系统的容量和存在的压力

交易成功率

即事务成功率、请求成功率,根据具体需求设定阈值,一般要求99.99%甚至更细的粒度

资源使用率

包括CPU%、Memory%、I/O速率等

可扩展性

随着并发数的上升,系统的性能表现是否会正比例线性增长

五、测试数据

数据信息

说明

限制条件

用户操作权限、数据引用次数、数据过期设定(次数、绝对时间)

数据量

实际生产环境的数据量为多少,在性能测试环境如何等量代换

数据类型

基础数据、测试数据、特殊数据

数据特点

是否可以复用、是否具有唯一性、自增、加密、拼接、转义等

准备方式

copy真实环境数据、预埋铺底数据、脚本脱敏生成数据

隔离方案

如何避免测试数据的污染?分库分表?环境隔离?标记区分?

六、配置参数

参数类型

说明

测试环境

性能测试环境是否和生产环境保持一致的配置?如不能,如何解决或等量代换?

操作系统

操作系统的版本、超时设置、内存空间等

软硬件版本

尽可能保证和生产环境一致的版本

中间件

比如JVM的内存分配/GC算法、Tomcat连接数/超时时间、MQ的消费者数量等

七、测试模型

模型~交易量

说明

交易占比

测试交易笔数占总业务量的比例(可忽略占比很少的交易数据)

选取思路

①、选取交易量最高的时间段;②、每种交易进行单独的数据统计

异常选择

①、如果各时段的交易比例类似,则可按照生产的配比进行转化;②、如比例差距大,则独立统计

交易配比

单交易统计后,基于各交易的RT,结合并发用户数,使总交易数达到交易占比数

ThinkTime

根据各交易类型和具体场景,选择ThinkTime是统一设定/随机设定/按实际场景设定

以上即为性能测试需求调研阶段,我们要做的事情和关注的Point,仅供参考。。。

0 人点赞