• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

如何建立软件性能测试模型

发布: 2009-8-07 12:36 | 作者: 网络转载 | 来源: 领测软件测试网 | 查看: 159次 | 进入软件测试论坛讨论

领测软件测试网

如何建立软件性能测试模型 

今天和大家分享的是一个相对宽泛的设计思路,有兴趣的朋友可以再补充和细化。在以往的模型设计中,我一般会遵循这个设计步骤:信息调研—场景分析—模型设计。

 

  • 信息调研

 

按照上线情况将应用系统分为未上线和已上线两类。

 

对于未上线的系统的信息调研比较困难(由于各类系统差异较大,今天对于未上线系统的调研与分析就不作深入探讨了)。在没有参考案例的情况下,更多的是与系统的最终用户和系统设计人员进行沟通。沟通的范围一般包括:

  • 应用系统的类型,如:交易型系统、管理型系统、数据处理型系统等;
  • 应用系统的操作人群,以及他们经常操作的哪些功能,也就是依靠系统处理的业务;
  • 固定人群的操作习惯,如:哪些人会在哪个时间段集中处理哪些业务;
  • 固定操作人群的用户量有多少;
  • 系统设计的最大并发用户数、最大在线用户数等信息
  • 初步预计,系统上线后日处理业务量有多少
  • 对于后台系统,需要关注系统的前端渠道,以及各个渠道的交易请求规律和交易量

 

对于已经上线的系统,可以方便的从运维部门获取相关数据信息。生产环境下的交易场景复杂多变(取决于市场表现),不能够仅对一个特定时期的业务量信息进行调研。如果你对这个系统还不够了解,我建议采样一个周期较长的时间段的交易量信息,有条件的情况下,可以把全年的交易量信息收集一份。

 

无论是已上线和未上线的系统调研工作,建议大家事先准备好调研表,很多刚刚接触这方面工作的朋友或许准备起来比较困难,我这里有一份整理过的供大家参考。各位在自己定制调研表时,要记得不断更新不断增加调研的内容,从而使得调研工作更加充分。

 

类别

属性

用户信息

这个系统的操作人群有哪些?

操作人群的用户量有多大?(万人)
系统设计时的最大的在线用户数量有多大?

历史上,这个系统承载的最大并发用户数是多少?
对本系统期望能够承载的最大并发用户数是多少?(本次测试需求

交易信息

历史上这个系统处理的每日最大交易量是多少?

一天中,系统业务处理高峰都发生在哪些时段?

历史上这个系统处理的每秒峰值交易量是多少?

已上线交易的平均响应时间是多少?(ms)
一般交易对于平均响应时间的需求是多少?
特殊交易对于响应时间的需求是多少?(需要根据个别交易进行罗列)

每日交易量占比最高的前20支交易分别是哪些?
除此20支交易外,还有哪些属于重要交易?(在性能测试中需要纳入的,如:业务路径特殊、业务规则特殊)
上述20支交易是否能够覆盖本系统80%的业务量?如果不能,还需要涵盖哪些交易?

这个系统的前端系统有哪些?
后端系统有哪些?
各个前端系统的交易量比例是多少?

该系统是否存在批量业务?
批量业务发生在哪些时段?
批量业务每次处理的业务量有多大?
最长会持续多长时间?

批量业务处理是单进程?还是多进程?
最多可以多少个进程同时处理?
生产过程中,批量业务触发的最大进程数量是多少?

该系统运行过程中,是否存在特殊交易日?分别是哪些?(如:投资理财系统有一般交易日、基金发行日、债券发行日和集中赎回日,不同时期的总交易量、峰值交易量、以及各个交易之间的数量比例都有很大差异)

 

  • 场景分析

所谓场景分析,就是对不同交易场景进行分类,大多数情况下,每一个应用系统都存在多个典型场景。这些典型场景或许不全是交易量的峰值情况,它们具体体现为交易的类别与交易比例上的差异。之所以需要分析多个场景,是因为在不同的交易类别、比例情况下,系统的处理能力存在着较大的差别,有可能在一个交易量不大的特定场景下,应用系统已经趋于资源占用的最大负荷,或者会产生未知的影响,比如大量报错等。针对典型场景的选取,请大家参考如下:

 

 

如上图所示,我们可以看出有4~5个交易量较高的交易日,就可以尝试从这个几个日期入手进行分析,对具体某一天的分析如下:

 

 

通过对场景的分析,我们已经初步得到每个交易日的特定场景发生的具体时间,要知道,每个场景的背后一定有一个刺激因素在支持,我们需要根据当日的相关信息进行判断其发生的原因以及未来再次发生的几率性。

 

  • 模型分析

在圈定特点场景后,就可以对业务(交易)的模型模型进行分析了。很多人分析到这个步骤时,往往采用“小时交易量(笔)/3600(秒)”来计算TPS,然后进行一个加权算法。个人认为这种非常不精确,当然,如果基础信息数据无法再精确,很多时候也只能采用这个算法。在有条件的情况下,尽量获得更详细的调研数据,如:每10分钟(5分钟)的交易量汇总统计数据。我在以往的工作中会调研到这个微粒度:

 

 

然后,采用该“10分钟的交易量/(10分钟*60秒)”,然后再根据情况进行适当的加权计算,从而得到TPS值。剩下的工作就是分析业务(交易)占比了,根据以往的经验,典型交易的选取一般遵循如下原则:

  • 采用TOP 10或TOP 20依次筛选占比较高的交易,直至筛选总量超过基础数据总量的80%;
  • 重要的交易不按照TOP方式选取,可直接选入典型交易范围;什么是重要的交易呢,一般认为交易的优先级较高,交易在历史过程中易发生错误,或是一支新交易,我们对他了解甚少,需要纳入测试范围。

这里给出一个选取的样例,请大家参考:

 

 

基于上述的样例,共筛选了12支交易作为初步的典型交易,共计占比81%。如下:

 

 

接下来的工作就是反推出测试模型的各支交易占比了,反推结果如下:

 

 

到了这个步骤,测试模型的分析工作基本就结束了,需要特别说明的是,在选取典型交易过程中,你会发现有部分典型交易不具备可测试性,当然,原因就很多了,比如:数据不具备重复利用性、或者这支交易本身存在问题。对于这种情况,我们需要对模型进行适当的调整,调整的方法很多,如:

  • 放弃这支交易,增加一支性质相同的交易的比重;
  • 放弃这支交易,重新选择一支新的交易来替代。

 

对已模型调整,应当采取谨慎、科学的方式,在不了解各支交易特点的情况下,不建议随便进行调整。这份模型分析,仅作为一份指南,希望对大家有所帮助,在很多性能测试个案中,这份指南也有很多不适应性,希望大家酌情参考,也希望各位多多给意见,我们一同提高。(

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 模型 软件 性能测试


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网