• 性能测试场景


    一、普通性能场景

    普通线程组设置并发用户数

    线程数:需要设置的并发用户数
    并发用户数: 受cpu的主频、分配的内存大小、操作系统(允许打开文件数量、开放的端口数量)的影响,一台电脑,大概能支持 1500并发用户数以内(http协议)

    ramp-up时间: 在多长时间内启动所有的线程。
    注意:只是说明,在第n秒结束时,会产生m个并发用户数,并不代表每秒会产生多少个并发用户数
    已经产生的并发用户数,就会调用 取样器,进行请求。请求循环次数用完,这个并发用户数的资源就会释放,这个并发用户数就会消失。

    循环次数:

    • 最少为1。
      没有勾选“永远”,就是每个并发用户都会循环的次数
    • 勾选 “永远” 不配置其他, 一直运行下去,直到点击 ‘停止’才会停止
      手工点击停止,会导致不可中断的请求被强行停止而报错,所以 一般不会只勾选永远,会配合调度器一起使用

    调度器:

    要想调度器生效,一定要勾选永远。
    持续运行时间: 会一直运行多长时间后自动结束

    接口性能测试: 一般的标准是,响应时间要小于1.5s秒

    1.5s的来由: 性能测试行业标准 Apdex

    • 500ms以内是满意
    • 500ms ~ 1.5s内 能接受
    • 大于1.5s不能接受

    二、负载测试---阶梯场景

    负载测试: 逐步增加并发用户数,找到我们的最优并发用户数的区间

    最优并发用户数:接口未大量报错且平均响应时间在目标时间内的最大并发用户数

    使用线程组:jp@gc stepping thread group

    plugin manager下载插件: jpgc "apply changes and restart jmeter"

     
    监听器
    活跃线程数Active Threads Over Time
     
    响应时间图Response Times Over Tim
     
    tps图Transactions per Second
     
    获取最大(最优)并发用户数的方法

    1、先设定一个比较大的范围值 普通线程组+ 聚合报告执行较短时间,通过聚合报告中的,异常率 + 平均响应时间来判断。

    • 如果异常率为0, 就看平均响应时间,有没有超过目标值(1.5s),说明猜测的并发数少于可能的实际值
    • 如果时间已经超过了说明猜测的并发数大于可能的实际值
    • 如果平均响应时间很小,说明并发用户数还可以调整很大, 可以看吞吐量的值,大概估计最大并发用户数可以达到吞吐量的数字

    2、设定合适的步长,运行一轮 阶梯场景 观察tps图中是否有报错、在某一并发用户数范围的时响应时间,与目标响应时间对比, 从而找到一个最大并发用户数的区间。
    3、缩小范围,设定 起始值、最大值为上一步的区间值,步长根据实际情况来设定 首先看 tps 有没有错误(连续性报错),如果连续报错,说明此时的并发用户数已经超过了最大并发用户数 没有错误,就看响应时间图 ,看平均响应时间符合目标值的时间点,然后对照活跃线程数Active Threads Over Time,同样的时间点的活跃线程数,就为最大(最优)并发用户数

    三、压力测试场景

    用一定量的并发用户数,持续运行一段比较长的时间,来看服务器的稳定性。

    关键点:一定量的并发用户数,运行时间要比较长

    压力测试场景流程

    1、负载测试-阶梯场景,找到最大并发用户数
    2、最大并发用户数进行普通性能场景测试
    3、如果出现服务不稳定的情况,再进行压测试场景

    四、波浪型

    请求会在一段时间集中爆发,然后趋零,然后再爆发的周期性请求场景,有时间规律的请求

    外卖,饭点请求很多,然后降低,下一个饭点请求很多,周期性 使用线程组:Ultimate Thread Group

     

    关键点:下一个波浪的起始时间,大于等于上一个波浪的所有时间之和

    五、混合场景

    定义:不同数量的并发,对不同接口向服务器发起请求,模拟真实的请求场景

    要点

    • 不同数量的并发:线程组才能设计不同数量的人, 所以需要有多个线程组

    • 多个线程组,跨线程组传参
      - 设置和调用属性方法
      - 文件嫁接
      - jdbc数据存储

    • 多个线程组,可以使不同类型的线程组
      举例(登录,查看商品列表,下单)每个接口的访问量不同 设置3个线程组,分别对应3个接口,设置不同的线程数模拟并发 接口间通过合适方式进行传参,实现功能的正常 分析每一个接口的测试结果

    六、面向目标测试场景

    面向TPS

    期望某个接口系统的处理能力不低于 200 次/秒,问你,这样的场景,你如何设计?

    类似场景:秒杀,模拟服务器要能在1秒钟处理1000个事务,实际上是要求tps大于等于1000就可以了

    利用插件管理器,下载 jpgc 插件。然后添加 bzm - Arrivals Thread Group 线程组

     

    使用说明

    • target rate:目标,每秒钟多少个请求数
    • ramp up time(sec):达到目标需要的时间
    • ramp-up steps count:达到目标需要多少步
    • hold target rate time(sec):保持目标时间
    • thread iterations limit:线程迭代次数限制,如果我们只需运行每个用户一次以模拟用户的实际行为,则设置为1;设置为空,表示每个用户将运行不确定的迭代,直到调度结束。
    • log threads status into file:将线程状态记录到文件
    • concurrency limit:最大并发数限制

    对照监听器,查看达到设定tps,稳定运行状态的接口响应时间,以判断是否满足要求

    面向并发用户数

    Concurrency Thread Group


     

    使用说明:

    • 目标并发(线程数)
    • 加速时间(整个测试)
    • 加速步骤计数
    • 保持目标并发时间(时间单位 - 分钟或秒钟)
    • 线程迭代次数限制(循环次数)
    • 将线程状态记录到文件(将线程启动和线程停止事件保存为日志文件)

    实际使用阶梯线程组并无太大区别




    链接:https://www.jianshu.com/p/eafad7694693

  • 相关阅读:
    Linux脚本中使用特定JDK
    redis 模糊匹配批量清理 keys
    git push 本地项目推送到远程分支
    extentreports报告插件之extentX之服务搭建(三)
    extentreports报告插件与testng集成(二)
    extentreports报告插件与testng集成(一)
    初识ios自动化(一)
    css 选择器
    appium移动端测试之滑动(二)
    使用appium进行ios测试,启动inspector时遇到的问题(一)
  • 原文地址:https://www.cnblogs.com/superbaby11/p/15613137.html
Copyright © 2020-2023  润新知