vlambda博客
学习文章列表

性能测试方案难写吗?

关注 我们,一起 学习+涨薪不掉队!

性能测试方案难写吗?

文|py_welsh


35岁之前,我一直思考:我喜欢做什么,能做什么;

35岁之后,我开始思考:我喜欢做什么,不能做什么。


00
导读
性能测试方案难写吗?


性能测试方案需包含测试测试需求分析、测试对象分析、测试重点分析、测试环境分析、测试场景构建几个关键点,其中:

测试需求分析:测试中涉及的性能指标的定义

测试对象分析:测试中涉及的业务及系统内部模块的定义

测试重点分析:测试执行策略、测试监控策略、测试风险的定义

测试环境分析:测试中涉及到的服务器资源、测试软件、测试数据、测试桩定义

测试场景构建:从性能负载、接口、疲劳角度定义测试场景

定义

测试场景构建:从性能负载、接口、疲劳角度定义测试场景

项目:

我们先定义一个性能测试项目,用户手机连上wifi,然后打开浏览器链接任意一网址,页面被刷新到登录页面,用户输入用户名加密码后点击登录,以此进行下面的性能方案讲解。


01
测试需求分析
性能测试方案难写吗?


可从需求文档、市场调研去收集性能测试指标


性能测试方案难写吗?1.1 需求文档

1.1.1 客户明确需求

通常情况,客户有明确的需求,定义一些性能测试指标,例:每秒用户登录页面刷新多少、每秒登录用户量多少,用户在线总量多少,我们明确性能测试指标。

1.1.2 客户隐形需求

基于客户明确指标下,会有一些隐性指标,例:100万在线用户的查询在5秒响应,我们也许纳入性能测试指标内。

1.1.3 用户模型确定

有了以下的性能测试指标后,我们可以创建我们的用户模型,如下:

1、用户指标:用户登录TPS需达到50、用户登录页面刷新TPS需达到250

2、用户总量:总用户量100万

3、用户模型:系统每天用户在线量在100万左右,平均在早晨8、11点期间登录,其中登录页面刷新与登录比例为5:1


1.2 市场调研

1.2.1 客户无明确需求

也有特殊的情况,客户只会提供一些基础数据,例:2000个机构下,500万的用户总量,我们需要根据这些基础数据提炼出我们的性能指标。

1.2.2 市场调研需求

有了基础数据后,还需要对我们所关心的性能指标做市场调研,最终得出我们的性能指标

例:对其中1个机构1个月的用户登录数进行数据采集(每天早晨8-9点是登录高峰期,每天大约是1小时内登录100人次,平均到每秒100÷3600约为0.027次/秒),然后在推算2000个机构下,用户每秒登录0.027*2000约50次,在根据后台日志推算出,登录与登录页面刷新比例为1:5,登录页面刷新TPS为2500

1.2.3 用户模型确定

确定性能指标后,我们可以创建我们的用户模型,如下:

1、用户指标:用户登录TPS需达到50、用户登录页面刷新TPS需达到250

2、用户总量:根据用户指标推算出用户总量,或者由相关系统推算出用户总量

3、用户模型:系统每天用户在线量在100万左右,平均在早晨8、11点期间登录,其中登录页面刷新与登录比例为5:1


02
测试对象分析
性能测试方案难写吗?


可从测试对象分析、测试模型分析、测试指标分析、模块耦合性分析考虑。


性能测试方案难写吗?


2.1 测试对象分析

测试对象分析从业务流程、后台系统模块分析,然后明确测试对象

性能测试方案难写吗?

2.1.1 按照业务流程拆解

根据业务提炼出用户基础流程:登录页面刷新、登录

2、登录:用户输入用户名加密码,然后点击登录,后台系统进行登录,返回成功或者失败

2.1.2 按照后台系统模块拆解

根据业务分析后台的系统模块,登录页面刷新模块、登录模块。

1、登录页面刷新模块:用户的HTTP请求经过系统层面的中间件处理分发到后台系统,然后被推送模块接收,再进行计算,推送出相应的登录页面,这里的计算可能跟用户类型以及所在机构有关系。

2、用户登录模块:用户输入的用户名加密码请求同样经系统层面中间件处理分发到后台系统,然后登录模块接收,再进行用户名密码的校验(这里可能会到数据库内去进行查询或者更改数据),最后返回结果。

3、最后提炼出关键系统模块:HTTP、中间件、推送模块、登录模块,最后这些系统模块会在性能瓶颈定位中起到方向作用。

2.1.3 明确测试对象

根据业务流程分析与后台系统模块分析,明确测试对象的业务、系统模块、指标。

    1、业务:用户连接wifi后,浏览器访问网页,被重定向到用户登录页面,然后输入用户名+密码进行登录的一种场景

     2、模块:整个流程包括HTTP请求、中间件、推送模块、登录模块

     3、指标:登录页面刷新:TPS250、登录动作:TPS50、在线总量:100万


2.2 测试模型分析

2.2.1 用户模型场景分析

根据用户模型设计出典型应用场景与可靠性应用场景。

性能测试方案难写吗?

典型应用测试主要从常规测试指标、测试环境去分析,例:

1、常规测试指标是登录页面刷新250TPS,登录50TPS,用户量100万。

2、常规测试环境是网络是无限流、无有延迟,测试硬件的CPU、内存、磁盘的正常情况设计场景

可靠性应用场景主要从非常规测试指标、测试环境去分析,例:

1、非常规测试指标是高于指标的20%的情景下验证

2、非常规测试环境是网络存在限流、延迟情况很大,测试硬件的CPU、内存、磁盘受限的异常情况下设计场景

2.2.2 用户模型场景设计

根据用户模型分析设计出用户模型场景,例

1、用户典型应用场景:在10MB/秒限流与20ms延迟网络情况,对CPU16核、内存32G、磁盘10K转/秒的服务器进行TPS250的登录页面刷新动作,以及TPS50用户登录动作,持续时间约5.5小时,最终上线用户量达100万左右

2、用户可靠性应用场景:在1MB/秒限流与100ms延迟网络情况,对CPU4核、内存16G、磁盘7200转/秒的服务器进行TPS300的登录页面刷新动作,以及TPS60用户登录动作,持续时间约5.5小时,最终上线用户量达100万左右


2.3 测试指标分析

2.3.1 提炼出关键指标

根据用户模型提炼出用户关键指标,例:

性能测试方案难写吗?


2.4 模块耦合性分析

根据后台系统模块分析出可能会涉及到的模块耦合性,例:

性能测试方案难写吗?

1、HTTP请求中的cookies贯穿整个业务交互过程,在测试脚本中应该缓存cookies,保证业务正常,同时后台考虑cookies的存取方式,保证大并发下cookies不会出现丢失或者写满的情况

2、中间件反向代理将不同请求分发到内部模块:推送模块、登录模块、其他模块,考虑中间件本身会不会存在瓶颈,对业务照常影响。

(下期:测试重点及环境分析)



无论上课或自学,

你首先需要准备:

每天 2 小时+的学习时间

每天坚持写代码的习惯!

有投入才有产出,

10k+的涨幅需要 1 年以上的努力!

祝你成功!


光荣之路出品