性能测试负载模型(九)

进行执行过程设计之前需要先明确要测试的系统大概的运行曲线,然后根据不同的系统运行曲线来决定我们测试的时候执行过程该如何设计。

系统运行曲线主要可以从几个不同的角度去归类:一种是业务类型,不同的业务有不同的业务处理周期,因此业务高峰期和日常运行期都有所不同,譬如业务系统大多在月初、月中或月末存在一个业务的集中处理期,而如金融系统、互联网产品则很少有这种规律的高峰期,任何时候都可能产生高峰;另一种角度是用户操作习惯,不同的企业或者不同的用户使用同样的系统,都会因为不同的操作习惯而导致系统的运行曲线不同。

这里我们提出一种根据不同的用户心理来分类系统运行曲线的方法,主要是按照几种可能的心理习惯来分析系统运行的曲线。从用户心理来说,主要分为三类:保守型、投机型、懒惰型。

保守型

大多数业务系统的用户都属于这种类型。这类用户大多人都是朝九晚五类固定时间内才会使用系统,业务处理主要在上班后半小时开始,中午休息半小时前结束,下午上班后半小时开始,下班前半小时结束。

如下图所示:

这类系统运行曲线可以看到,大多都是有规律的出现业务高峰,每次业务高峰持续的时间也大多相同,这类系统运行曲线我们可以截取包括某一个业务高峰在内的前后一段时间内进行执行过程的设计基本能覆盖系统大部分的使用场景。

投机型

主要是一些涉及个人利益且负载较高的系统,如购票系统、交费系统、报名系统之类的系统,这类系统大多伴随着高并发,而其使用用户又因为急于完成个人的业务操作,大多会选择避开可能的业务高峰进入系统操作。这里用户的投机心理有两个:一个是认为系统刚开始允许进入和即将终止进入的两个时间段自己可以避开其他用户;另一个是认为只要自己不断的尝试,有可能恰好在某一个系统空闲点进入系统。这两种投机心理就造成系统的高峰反而会出现在首尾两端,而且中间时间段的系统负载也保持在高位,并不定时的会出现某一个业务小高峰。

就如下图所示:

这类系统运行曲线可以看到,整个系统运行过程中大多时候都处于高并发的业务高峰,单纯一个业务高峰的模拟很难证明系统在长时间运行过程中不会出现问题。因此,这类运行曲线的系统在执行过程设计的时候就需要考虑长时间的运行,并且整个执行过程中包括几个业务高峰的迭代才可以。

懒惰型

这类系统主要是一些信息采集系统、调查报告以及一些报名系统,通常只有一个结束时间点的要求,从大多数人的心理来说,多是事不关己高高挂起,所以都是拖延到最后一刻填报应付。因此就导致该类系统的压力集中在业务期的末端。

这类系统运行曲线可以看到,系统的运行负载是逐渐增加,到运行末期则迅速增长到业务高峰,这类运行曲线的系统在模拟的时候先逐渐增加负载一段时间后,再运行业务高峰的模拟。

时间: 2024-10-14 05:27:11

性能测试负载模型(九)的相关文章

性能测试负载模型(五)

我们上一篇文章说到了性能测试负载模型落地时的建模方法,这里我们先就第一种也是最常用的一种方法说起: 原始数据分析法 业务场景建模主要就是说明用户如何使用系统,因此根据系统使用的原始数据也就是日志进行分析建模是最有效最准确的方法.所谓日志就是指用户操作系统的痕迹,根据记录信息时的不同视角,一般分为两类:一类视角是基于用户,我们称之为操作日志,这类日志主要以用户为观察实体,记录用户从登录系统到离开系统的每一个动作:另一类视角基于系统,我们称之为访问日志,这类日志主要为应用系统为观察实体,记录系统的输

性能测试负载模型(八)

神神叨叨的多了,就成了习惯,所以继续摇头晃脑装夫子. 我们前面性能测试负载模型的理论有了,如果落地建模也有了,那么正确我前面对一次新人考核的感触中所说,如何算是脚本的正确执行. 这里就又引出了一个概念,就是执行过程设计,我们前面所说的应该都属于场景设计. 执行过程设计与场景设计有什么不同呢: 我们之前讲到的场景设计,主要就是针对某一个关注的剖面进行抽象化设计.一个系统运行的过程是动态的,场景设计是将动态的运行过程进行抽象化成一个静态的剖面.场景设计的要素主要包括负载量.负载对象和运行时间,前面我

性能测试负载模型(十)

性能测试从测试目的来说分为三类:评估型测试.确认型测试.调优型测试. 评估型测试主要是在评估某种条件下运行的性能状况.如测试系统在不同环境下的性能状况,随用户数量的变化或者数据量的变化情况下软件的性能变化状况.评估型测试往往并没有特别明确的通过目标,而是根据测试结果的分析和对比给出本次评估内容的一些结论. 确认型测试主要是为了验证系统是否满足规定的性能指标要求.通常测试目的中都或有测试系统在某一条件下的平均响应时间,或者吞吐率,或者并发用户数等是否满足规定的要求.确认型测试一定有很明确的通过标准

性能测试负载模型(四)

我们前面说了性能测试负载模型的概念,那么在实际落地的时候,到底该如何进行负载模型的建模呢,这里大概总结一下我认为的建模方法: 在进行场景建模的时候,最方便也是最常用的就是项目已经上线运行过一段时间,有足够过的日志作为数据源来进行分析,这类情况下一般都有比较固定的方法通过对日志进行分析来获得准确的模型数据:另一种是准备上线的项目,这类项目还没有任何日志可供参考,这种情况下一般都是与已在运行的近似项目进行类比,找到最接近的项目来进行仿真模拟:最后一种则是新业务或者新产品,既没有历史数据也没有类比的项

性能测试负载模型(六)

对于一些准备上线或者刚刚上线的项目,系统中并没有足够的日志可以提供给我们进行分析,这时候,我们前面所说的原始数据分析法就不再适用了,对于此类情况,我们比较常用的方法就是找到一个和该项目近似的系统,通过这种仿真模拟来评估项目可能的使用模型. 类比仿真 对于一些准备上线或者刚刚上线的项目,系统中没有足够的日志可以提供给我们进行分析,对于此类情况,我们比较常用的方法就是找到一个和该项目近似的系统,通过这种仿真模拟来评估项目可能的使用模型. 由于用户使用系统的模式存在各种变数,因此这种仿真的建模结果是否

性能测试负载模型(七)

很多情况下,我们要梳理业务场景的系统,是一个全新的产品或者全新的业务.这种情况下在进行 场景建模的需求分析的时候,别说什么原始数据,即便是可类比的同类系统也没有,这时候我们就没有数据数据可参考.这个时候,我们就只能观察这个产品或者业务的功能模块和使用用户,结合经典的数学建模方法进行建模.我把这种观察方式成为旁观者视角建模方法. 旁观者视角 这种旁观者视角通常都是以某一个关注点为中心去观察系统的某一个侧面.例如对于一个系统,我们可以以系统功能模块为中心.以用户活动为中心.以系统角色为中心等视角.我

( 转)性能测试--地铁模型分析

( 转)性能测试--地铁模型分析 地铁模型分析 和绝大部分人一样,小白每天都要乘坐地铁上下班,那么就拿地铁来分析,再次深刻理解下性能.早上乘坐地铁上班,最典型的就是北京地铁1.5.10.13号线等,人多得简直没法形容!为了方便理解分析,先做如下假设. 某地铁站进站只有3个刷卡机. 人少的情况下,每位乘客很快就可以刷卡进站,假设进站需要1s. 乘客耐心有限,如果等待超过30min,就会暴躁.唠叨,甚至选择放弃. 按照上述的假设,最初会出现如下的场景. 场景一:只有1名乘客进站时,这名乘客可以在1s

性能测试分层模型-选自书籍:小强软件测试疯狂讲义

百度搜索:小强测试品牌 新书推荐 本书终于在前段时间出版了,现在已经可以在各大网店购买了,搜索书名即可.书籍购买地址:https://detail.tmall.com/item.htm?id=547310727717 这里我特别提前说一句:任何东西都有一定的受众群体,世界上也没有任何东西可以让所有人100%满意.So,本书也是.只要本书中有一个篇章的内容给你带来了影响那就是这本书的价值!感谢大家的支持. 引子 我为什么会把这个话题放到最开始呢?就是因为这些年在企业工作中.在教育领域培训中接触过不

( 转)性能测试--地铁模型分析

地铁模型分析 和绝大部分人一样,小白每天都要乘坐地铁上下班,那么就拿地铁来分析,再次深刻理解下性能.早上乘坐地铁上班,最典型的就是北京地铁1.5.10.13号线等,人多得简直没法形容!为了方便理解分析,先做如下假设. 某地铁站进站只有3个刷卡机. 人少的情况下,每位乘客很快就可以刷卡进站,假设进站需要1s. 乘客耐心有限,如果等待超过30min,就会暴躁.唠叨,甚至选择放弃. 按照上述的假设,最初会出现如下的场景. 场景一:只有1名乘客进站时,这名乘客可以在1s的时间内完成进站,且只利用了一台刷