性能测试的稳定性场景如何设计?

发表于:2019-12-31 11:55

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:软件质量报道

  人们谈到测试设计,往往是指功能测试设计,往往忽视性能测试的场景设计,例如,如何进行性能测试时,如何把性能负载加上去,就需要根据业务进行负载发起策略的设计,包括逐步加载、一次性加载和峰谷加载等。
  不管你是否重视,性能场景应该说是在性能测试中非常关键的一个环节。经常在一些场合被问到性能场景的设计问题,但是大部分都是和容量相关的。
  但为什么稳定性问的人少呢?稳定性是不是说在容量场景做好了之后就水到渠成了呢?
  首先稳定性场景的设计应该说比容量场景设计要简单一点。
  如果容量测试结果非常好的话,稳定性场景只要维持较长时间的动作就可以了。但是不要小看这个时间变长的动作,它会让你要准备和思考的内容多出不少。
  下面来庖丁解牛地细化一下。
  1、数据的增加
  数据的增加有两个方面
  参数化数据
  基础数据;
  这里以参数化数据为例:
  拿一个100TPS和稳定性场景来说,假设业务数据不能复用,如果只测试30分钟。需要的数据是100*30*60=180000,也就是18万的参数化数据。但如果要跑12个小时呢?
  就是100*12*60*60=4320000,也就是432万条数据。
  甚至有人还说:我要跑7*24。嗯,很好,那就需要60480000,即6千多万条数据,慢慢准备吧
  如果这些数据是做insert的动作呢?可想而知,对表结构的要求就会多出很多,索引创建的合理性就非常重要了。
  举个例子。同样的一个SQL,在查找基数为5537362的表,都是查一条数据出来。如果是从9万多条的索引命中的数据中找的话,需要0.219s,而在索引命中100多条数据中找的话,只需要0.016s。
  这是14倍的差距
  insert的动作是会被折成insert select的。所以在稳定性中,如果select的基数越来越大,对索引的考验那是可想而知的。
  对update、delete也是一样。
  2. 监控的考验
  如果是自己写监控脚本,稳定性场景中数据量的处理那是非常耗时的。所以在稳定性场景中,基本上不会像容量场景中那样设计监控粒度。
  粒度的扩大导致的另一个问题是毛刺看不到。
  一般容量场景中使用1-3s的监控采样粒度,1s对系统监控还是会消耗些资源,3s不会有太大的影响。但是对稳定性来说,3s却有点短了。可以设置5-10s的监控粒度。5-10的跨度是不是有些大呢?这个取决于系统的稳定程度,对不稳定的tps曲线,可以设置为5s,对稳定的tps曲线,10s其实是够了的。
  监控工具也要选择好,尽量不要用手工生成数据和曲线的工具,费时费力又容易出错。用自动生成图表的工具比较理智,并且要用可以持续保存数据的,像zabbix类型的工具。
  先要设置好监控的计数器。从OS层开始,到应用层、jvm层,再到数据库层。os层一定要监控cpu、memory、io、network这几个基本资源,如果是C/C++的应用,还要有process层的监控。
  在场景结束时,如果发现还有需要的数据没取到,那就悲催了,还要再来一遍,所以场景设计和监控设置时都要认真对待。
  3. 对压力工具的选择
  一般情况下,选择压力工具要注意压力工具本身的稳定性。像loadrunner/jmeter之类的工具已经被普遍接受了,没有什么问题。
  但是jmeter,本地的jvm也是需要关注的。
  尽量不要用压力工具取监控的数据,这种做法会让结果整理比较费力。
  4. 稳定性场景的时长确定
  这应该是稳定性场景中最关键的一个点了。但我看到有不少设计稳定性的时候没有计算过,只是凭感觉。
  那怎么设计这个时长?
  我们可以做一个计算,这个计算有一个前提条件。就是系统在运维的过程中需要稳定运行多长时间。假设在运维中是要三个月做一次正常的维护动作,在这个动作中包括了对一些资源的归档、系统的重启等。那下一步要计算的就是系统三个月内的业务总量。
  我们来做一个假设场景:
  一个系统一天业务量是100万笔。稳定运行要求3个月。那总的业务量就是100万*3*30=9000万。假设系统最大TPS是2000。这时候要设计的稳定性场景时长就是:
  (9000万/2000tps)*3600=12.5h
  下面的图是混合容量场景,看到tps是能加到5000左右,但是在3000以上的时候就出现了tps有下降情况(因为这个文章不是为了分析性能,所以不做下降原因详解)
  根据这个系统的业务需求,稳定运行时间是三个月。线上均值tps是329。
  那业务量在三个月就是:329*3*30*24*3600=2558304000笔业务。
  稳定性场景用80%*最大TPS的压力做的话(这里的稳定性场景的TPS可以灵活设置,不一定都是80%*最大TPS),就是4000tps左右。
  来计算一下:2558304000/4000/3600/24=7.4天
  这样时长就确定下来了。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号