• 0
  • 0
分享
  • 稳定性测试怎么做,这篇文章彻底讲透了!——软件测试圈
  • 曼倩诙谐 2023-01-20 16:17:36 字数 2721 阅读 3644 收藏 0

   稳定性对产品的重要性不言而喻。

  而作为质量保障,在稳定性测试方面的探索也在不断演化。记得两年前我们做稳定性测试还是基于恒定的压力,7*24小时长时间运行,关注的指标无非是吞吐量TPS的抖动、响应时间的变化趋势,以及各种资源是否泄露。稳定性测试的场景设计简单,和线上实际运行有较大的出入。带来的直接结果是稳定性测试发现的问题比较有限,做完之后仍然没有特别大的信心。

  那稳定性测试究竟该如何做?别人在怎么做?性能测试组今年在这方面做了一些思考和改进,虽然称不上很好的解决方案,但是通过努力比以前的做法还是有不少增强。

  一、稳定性测试的三个阶段

  第一个阶段:恒定压力阶段

  目标是为了检验在恒定的大压力下,系统的服务是否稳定,比如是否存在吞吐量TPS指标的波动,响应延迟的抖动、毛刺等。波动情况必须在恒定的压力下进行验证,如果是波动的压力,出现吞吐量波动或者响应延迟的长尾现象会难以捕捉分析,难以区分是业务的问题还是服务的问题,为性能问题定位带来较大难度。

  第二个阶段:基于一定的产品压力模型的,已上线产品

  我们不难观察产品线上的典型业务及业务比例,那么在过去的七天或者一个月的时间内,产品每天的业务模型是什么样的?根据线上监控及统计不难得出。这个阶段就是为了模拟线上的这种业务模型下,也即是存在峰谷变化的压力、典型的一些Web产品每天的压力模型是比较固定的,比如每天早上9点,下午4点,晚上10点都会存在压力峰值。这种方式的模拟会为系统的稳定性带来一定的压力,如用户量突增等情况,会不会导致错误或宕机等。

  第三个阶段:是在恒定压力下,引入异常干扰,注入异常用例

  如CPU波动、网络延迟、主节点挂掉或重启等异常情况的出现,来充分拷打产品的稳定性和可靠性。在google的测试之道中也有提及这种模式,虽然没有更多细节暴漏出来,不过在这方面还是值得探索的。

  二、对稳定性测试三个阶段的定义

  目前稳定性测试采用的性能测试场景设计使用混合场景模式,基于产品业务模型或用户行为来定义场景,包括产品的典型业务、典型业务之间的组合关系、典型业务之间的比例等,这里不详细介绍,有兴趣欢迎联系。另外,关于稳定性测试场景的设计还有比较大的优化和提升空间,这个后面会畅谈下。

  1.恒定压力阶段

  · 定义

  恒定压力阶段顾名思义保持压力大小恒定不变,在恒定不变的压力模式下,评估系统的吞吐量波动、响应延迟情况。

  吞吐量TPS是指服务端每秒或每分钟正确处理的请求数,服务资源比较充足且比较稳定的情况下,通常TPS波动很小;如果TPS波动比较大,如突然下降,或剧烈抖动,则系统肯定存在性能问题,比如某个资源成为瓶颈,或某个缓冲队列堆积或爆掉等情况。

  · 恒压阶段的并发选择

  恒压阶段改如何选择并发?

  恒压阶段并发大小的设置一般参考负载测试阶段的结果,选取性能拐点或资源临界点如CPU使用率80%左右的压力,或接近扩容指标的压力。因为一般情况下线上运行最大压力基本在扩容指标之下,选择这个压力对系统的考验会更加严格

  · 恒压阶段的性能通过指标

  通过指标包括两类,性能指标和资源指标。

  ①性能指标:TPS上下波动率不超过30%,TPS波动率是有个计算公式的;错误率肖武0.1%,且错误影响范围不大。

  ②资源指标:资源指标无异常,如CPU无波动,不均衡等现象;无内存泄露、连接数泄露、句柄泄露等问题。

  2.压力变化阶段

  定义:变压阶段的并发选择则需要根据不同场景的实际线上运行场景,或者几种典型的产品,如Web产品,或后端基础支持类的产品来进行压力定制波峰和波谷。

  我们对压力变化模型的不精确定义为:

  1.初始并发数需要配置,保持时间默认30min

  2.上升时间T需要配置

  3.最大并发数需要配置,默认为初始并发数的2倍

  4.最小并发数需要配置,默认为初始并发数的1/2

  5.最大最小并发数保持时间,需要配置,两段时间相等

  6.周期重复数,需要配置,默认重复两次

  7.下降时间不需要配置,固定为上升时间的2倍

  变压阶段的并发选择

  最大并发数一般选取负载测试时最大TPS对应的压力

  最小并发数为最大TPS对应压力的一半,初始并发选择最大TPS对应压力的80%左右

  变压阶段的性能通过指标

  ①性能指标:TPS波动后能够回到原来的稳定值;在波峰时,响应时间增幅不会过大;错误率小于0.1%

  ②资源指标:资源指标无异常,如在波峰增长阶段CPU不存在大幅度的波动情况;无内存、连接数、句柄数泄露

  变压阶段的实施效果

  当前我们在某些产品的实施过程中还是能发现一些问题的,如在压力上升过程中,在各项资源指标没有成为瓶颈之前,响应时间增幅很大,性能严重下降的情况

  下图为在某个产品上实施的效果,可以看到响应时间是有波动,但这个波动还是可以接受的。

1-1.jpg

  在某产品的稳定性测试的压力变化阶段发现在压力变化时出现少量请求错误,且响应时间增幅很大。

  原因是在压力突增的时候出现数据库连接数不够用,导致请求出现失败。

1-2.jpg

  3.异常干扰阶段

  在进行稳定性测试时,除了压力变化手段之外,应随机增加一些异常,这样做的目的是检验系统在遇到一些异常时能否做出预期的处理和响应,而不是卡死或是不响应,异常撤消后系统能够快速恢复正常服务。

  那么,增加哪些异常手段比较合适呢?

  稳定性测试中选取的异常测试用例主要是一些系统层资源争用的异常,如下所示。主要包括的CPU、内存磁盘、网络异常以及服务故障及恢复等场景。稳定性中增加异常手段的主要目的是为了验证系统在受到一些异常扰动时能否快速做出响应。

  ·异常干扰的并发选择

  同恒压阶段

  · 异常干扰的异常用例设计

  部分异常测试点,非完整测试用例。

1-3.jpg

  · 异常干扰的通过标准

  ①性能指标:随机异常撤销后能够回到原来的稳定值,错误类型分拣,明确错误原因,是否符合预期

  ②资源指标:资源指标无异常(CPU/IO/网络);无内存、连接数、句柄数泄露;程序无挂掉等情况。

  异常干扰测试的实施效果

  基于异常干扰的稳定性测试目前在若干个产品有实施,均能发现一些不稳定的性能问题,如高可用切换问题,异常恢复等问题

  下图为在对存储盘施加一定的磁盘io压力的情况下,应用吞吐量的抖动情况,还是很坚挺的,没有出现失败或服务挂掉的情况。

1-4.jpg

  (上图为TPS、下图为响应时间,TPS图的左坐标轴为TPS,右坐标轴为错误率,响应时间左坐标轴为平均响应时间,右坐标轴为最大响应时间)


作者:程序员小濠    

来源:http://www.51testing.com/html/02/n-7792102.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 我们使用一个电商项目进行演示,在调用登录接口完成登录之后,通过查看购物车接口获取该用户购物车中的信息。也就是说如果需要查看到购物车中的信息,则我们先要是登陆状态,这样的情况下,就需要有Cookie信息的存在了。提示:要获取购物车接口中的信息,需要使用登录后的Cookie保持登录状态。1、在HTTP信息头管理器组件中添加Cookie信息实现步骤:前提我们手动登陆电商网站,地址:http://www.testingedu.com.cn:8000/index.php/Home/user/login.html。然后通过工具获取到登陆后的Cookie数据。把Cookie数据存储到HTTP信息头管理器组件...
            9 9 4627
            分享
          •   本文将概述测试工程师的现状及发展方向,并着重介绍测试开发工程师的发展及所需具备的技能,以及本部门搭建的测试平台的概况和意义。  一、测试工程师的现状  很多测试小伙伴在工作中有时会比较迷茫,不知该怎样突破瓶颈,更好的发展。  那么测试人员究竟该如何打破瓶颈继续向上提升呢?如果你苦于不知所措,又满怀斗志向上的话,不妨一起聊聊。测试职业发展有典型的三种方向:  ·管理方向  · 技术型方向  · 转行  在此重点说下技术型方向的发展。曾几何时,提的bug被否认而倍感无力;曾几何时,遇到一个偶发复现的bug,到上线了都不知道该怎么复现;曾几何时,面对没有前端页面的测试任务,不知该从哪下手测试;曾...
            0 0 891
            分享
          •   场景法用例设计  现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。  这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。  用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。  场景说明  基本流:是流经用例的最重要路径,图中的黑线。  备选流:自基本流开始,之后会在某特定条件下执行。  可能重新加入基本流(备选流1和3)  可能起源于另一备选流(备选流2)  终止用例不再重新加入某个流(备选流...
            0 0 1463
            分享
          • 在以往性能测试中,通常施压机的硬件资源不会成为压力瓶颈,但是在多任务并行的场景中,如果一个任务占用当前机器资源过多,会影响其他任务执行。或者当前用例本身存在问题,导致性能无法进一步提升,影响了性能测试执行。根据以上场景,如果能从监控工程上得到解决自然是最好的。可以实时监控施压机和施压进程的CPU占用、内存使用、GC清空。但是,重点来了,并不是总能拥有一套完美的监控系统。这个时候,就需要自己手动解决一些痛点。经过查阅资源,最终将方案锁定在java.lang.management.ManagementFactory这个类,看名字和路径大概能猜个七七八八了。以上我提到的信息都可以调用这个类的API获...
            0 0 1085
            分享
          • 在软件研发和测试过程中,当测试人员、开发人员以及业务人员沟通测试案例的功能点以及覆盖率时,复杂的功能需求和晦涩难懂的测试案例脚本脱节,让大家很难对测试功能点达到一致,也很难统计测试覆盖率。如果有一种通用语言来描述测试用例,让开发、测试和业务人员都能够很好地理解测试需求,步骤和目标,便可以最大程度避免由于理解偏差带来的不一致性问题,而BDD(全称Behavior Driven Development)技术就是解决这一问题的钥匙。BDD即行为驱动开发,是一种敏捷软件开发的技术,是TDD(全称Test Driven Development)即测试驱动开发的延伸,它用简单易懂的“通用语言”——Gher...
            0 0 3064
            分享
      • 51testing软件测试圈微信