性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
4054 人已学习
课程目录
已更新 24 讲 / 共 30 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
第二模块:性能测试工具及性能场景篇 (9讲)
07丨性能测试工具:如何录制脚本?
08丨案例: 手把手教你编写最简单的性能脚本
09丨关联和断言:一动一静,核心都是在取数据
10丨案例:在JMeter中如何设置参数化数据?
11丨性能脚本:用案例和图示帮你理解HTTP协议
12丨性能场景:做参数化之前,我们需要考虑什么?
13丨性能测试场景:如何进行场景设计?
14丨性能测试场景:如何理解业务模型?
15丨性能测试场景:如何进行监控设计?
春节策划 (2讲)
春节策划丨性能评估和性能分析试题,等你挑战!
春节策划丨快来挑战一下自己的分析逻辑吧!
第三模块:性能监控分析工具篇 (6讲)
16丨案例:性能监控工具之Grafana+Prometheus+Exporters
17丨CentOS:操作系统级监控及常用计数器解析(上)
18丨CentOS:操作系统级监控及常用计数器解析(下)
19丨Java & C ++:代码级监控及常用计数器解析(上)
20丨Java & C ++:代码级监控及常用计数器解析(下)
21丨Tomcat:中间件监控及常用计数器解析
性能测试实战30讲
登录|注册

13丨性能测试场景:如何进行场景设计?

高楼 2020-01-13
我们在前面屡次强调了场景的重要性,今天终于到了要把实际场景拿出来解析的时候了。
在本篇文章中,为了保证数据的连续性,我用之前的项目资料来作明确地说明。同时为了模糊关键业务信息,以及让场景的描述更通用性,我会把所有的业务名隐去。
根据之前我们所说的,基准性能场景是为了测试出单业务的最大容量,以便在混合容量场景中判断哪个业务对整体容量最有影响。
今天的场景设计需要说明两个前提条件:
这些业务都是实时的业务,不涉及批处理、大数据等业务。
因为本篇着重讲场景的设计和具体项目的操作,所以不加系统资源的分析,避免信息混乱。
在这个场景设计中,首先,我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。
在这个项目中,响应时间指标是统一的,就是不大于 100ms。
其实我们在做项目的时候,经常会这样制定一个统一的响应时间指标,这样做也不是完全因为懒,更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道,这显然是不对的,因为业务不同,响应时间指标也应该不同,合理的做法是给出每个业务的响应时间指标。下面我们还会遇到响应时间定得不够细致的问题。
有了这个列表,下一步就是做基准性能测试了。

基准性能场景

有很多人做接口测试的时候,觉得接口的 TPS 真是高呀,于是就按照最高的 TPS 跟老板汇报。但我们一定要知道的是,接口的 TPS 再高,都无法说明容量场景的情况,除非这个服务只有这一个接口,并且也只为了测试服务,这时就不必有混合的情况了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • 律飛
    听完本次课,对性能测试有了更进一步的理解,对以往迷惑的地方有了一些模糊的澄清,还需要继续努力学习。谢谢老师!另外有一些地方请教老师:
    1.在基准性能场景测试时,有哪些好的途径和方法来获取所需的业务比例、业务目标TPS和响应时间?
    2.容量测试场景中,实在没有弄明白线程递增数据是怎么获得的?我看老师在回答其他人的问题时说后续在业务比例设计中会讲到。如果是这样,很期待早日听到该课程!

    作者回复: 1. 业务比例和目标tps是业务指标中的关键部分,这是要业务部门提的。要不你看下业务模型那篇是否可以回答得了这个问题。
    2. 递增数据的数据在这篇中已经说了吧。就是看响应时间是快还是慢,如果响应时间快就少一点线程上升。

    2020-01-16
    1
  • rainbowzhouj
    高老师,您好。以下是我对两个思考题的回答。
    第一个问题:
    性能场景设计前应了解实际场景中对应业务的目标值。然后查看对应业务的组成,采用先局部后整体的思想进行性能场景设计。具体而言,就如文章中所述先将单业务的基准性能测试结果得出,再进行混合业务的性能测试。值得一提的是通常情况下时间是稀缺资源,所以进行性能场景设计时,应时刻谨记以终为始的理念,得出结果后判断是否能满足业务目标。
    第二个问题:
    二八法则好比万金油,换句话说就是可有可无,进行稳定性场景的测试就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。此时已经了解了对应业务的目标值,那么只要系统在正常处理,资源没有出现问题,也没有报错下,业务目标能满足,而且更确信,这样会更好。

    作者回复: 理解的挺正确。

    2020-01-14
    1
  • kubxy
    老师,我一直有一个疑问。在做业务的性能测试时,是只测实现这个业务逻辑的接口,还是要测完成这个业务时访问的所有接口?比如,登录业务。在接口文档里只是一个登录接口,但使用JMeter录制登录操作,还会请求其他接口。

    作者回复: 你这个问题的前提是:你想做的是什么场景?
    只有分析了你要做的场景,才能判断出应该如何访问接口。
    比如说,你的目的是只测试登录,那就完全没必要请求后面的接口。即使是录制实现了登录,并且连带了后面的接口请求。也应该把后面的接口请求给删掉。

    2020-01-13
    1
  • Geek_65c0a2
    高老师,我有个小白问题哈。为什么容量测试的结果会比单业务测的结果高呢?😄

    作者回复: 走的路径不一样。单业务涉及到的机器也没有容量场景涉及的机器多。

    2020-01-13
    1
  • Geek_f93234
    老师,文中的这段话:在这个示例中,业务 + 运维部门联合给出了一个指标,那就是系统要稳定运行一周,支持 2000 万业务量。运维团队每周做全面系统的健康检查。当然谁没事也不用去重启系统,只要检查系统是否还在健康运行即可。大部分时候运维是等着系统警告的。那么针对前面给出的容量结果,容量 TPS 能达到 3800(业务 1 到业务 6 的容量测试结果 TPS 总和)。所以稳定性场景时间应该是:20000000/3800 = 1.46 小时。
    不明白稳定性场景时间为什么要这么计算?能详细分析一下吗?
    还有我之前看到的很多都是这么来确定稳定性场景的执行时间的:一般来说,对于正常工作日(8小时)运行的系统,至少应该能保证系统稳定运行8小时以上,对于7*24运行的系统,至少应该能够保证系统稳定运行24小时以上。
    2020-02-09
  • 杜艳
    感觉还是没有很基础
    2020-02-07
  • 杜艳
    还是不会做这些结果图啊,能对应jmeter讲解具体点吗?知道怎么分析了,不知道这些数据图怎么来的。

    作者回复: 这个专栏没有规划要讲jmeter的基本使用,所以不清楚你要讲的jmeter具体功能是什么,如果呼声高的话,后面,我可以加餐。

    2020-02-07
  • 小老鼠
    稳定性性能场景中100%最大TPS出现了error,而80%正常,如何判断稳定性性能测试是否有Bug。

    作者回复: 没看懂这个问题,请描述多些。给些具体的数据。

    2020-01-30
  • songyy
    思考题
    - 性能场景应该按什么样的逻辑设计: 了解目标要支持多少流量,峰值流量如何,最大月份共计需要支持多少流量。然后用总计流量,除以峰值流量,可以得到以峰值流量进行性能测试的时间
    以及在稳定性场景中,为什么不用最大 TPS 的 80% 来做:因为80%就太高了,CPU的抖动会比较大,很难控制变量

    作者回复: 第二个理解的不对哦。80%也不一定就会有抖动。
    而应该是只要用稳定的TPS就可以了。

    2020-01-17
  • flightless bird
    拿到基准测试的结果后,您是如何按照业务比例设计出容量性能场景的,这块弄不懂,文中也没有计算的过程,不知道基准测试结果起到说明作用,老师能否详细说明。

    作者回复: 业务比例在容量场景中直接通过控制tps来体现就可以了。后面说了工具中各用什么功能来控制。不知道你的具体疑惑点是什么呢?
    基准测试起到的作用就是先把最基本的瓶颈解决掉。我这里已经给出的是优化后的基准测试结果。其实这个过程中遇到的瓶颈很多。 只有先把这些问题解决,基准测试的响应时间和tps才能对容量测试有比对的作用。

    2020-01-17
  • 律飛
    第一个问题,性能场景应该按什么样的逻辑设计吗?
    第一步,通过调研分析以及经验等途径获得并列出需要测试的业务、业务比例、业务目标TPS和响应时间指标;如果没有以上数据,也可采用头脑风暴法,也就是俗称的拍脑袋法,来获取相关信息,当然,这时测试过程会延长,需要通过想法、验证、修正等步骤,逐步获取较为精确的数据。
    第二步,开展基准性能场景测试,获得每个业务的最大TPS和响应时间。
    第三步,开展容量性能场景测试,在场景不断和控制比例的要求下,设计合理的各业务参数,测试后分析数据。
    第四步,开展稳定性性能场景测试。在容量场景测试的基础上,确定综合业务TPS和时长。
    第五步,开展异常性能测试,在全面分析架构图的基础上,根据测试目标选择压力参数,设计运行场景。
    第二个问题,在稳定性场景中,为什么不用最大 TPS 的 80% 来做?
    二八原则适用于头脑风暴法,也就是没有分析数据,没有经验值,自己拍脑袋的话,还不如采用这种方法,至少说起来还有一定的依据。😅
    但是按第一个问题的回答,在稳定性场景测试时,我们已获取了需要的信息,因此没必要采用这个法子了。

    作者回复: 第二个问题的理解没有说到关键点。

    2020-01-16
  • 志富
    老师那个业务占比是用来干什么的?得到业务占比是为了后面的什么用途需要呢?

    作者回复: 为了混合容量场景中设置比例。

    2020-01-15
  • ldm
    高老师,好,请教个小白的问题,jmeter按照梯度运行,每个阶梯的数据可以像LR一样截取出来吗?
    例如:按照10、20、30线程各运行10分钟,可以把每个梯度的数据截取出来吗?

    作者回复: 从技术操作上来说,可以截取出来。
    可是为什么要截取出来?

    2020-01-15
    1
  • qiaotaoli
    老师,你上面讲的场景设计是开篇已经有了各个业务的比例以及各个业务的TPS指标,对于没有明确指标数据的系统如果去定这些指标呢?比如有个用券兑换礼品的系统,用户就说我有500w张券,用券兑换礼品的活动持续时间是1个月,需要做个性能测试保证这个1个月内系统不要出问题。对于这样的情况,该如何去定指标并完成整个性能测试呢?

    作者回复: 没有业务统计数据参照,只能找有经验的人拍脑袋了。

    2020-01-14
  • nana
    弱问老师线程数递增图和响应时间图是怎么生成的?谢谢
    当前的测试都是分开的,比如10 threads 对应的响应时间t1, 20threads对应的响应时间点t2。记录了这两个场景的值

    作者回复: 场景执行时连续。生成的结果报告自然就是那样了。

    2020-01-14
    1
  • 村夫
    老师,有几个问题和想法。首先场景不断这个应该怎么理解?其次是老师例子中的业务一到六是一个接口还是多个接口?再次是控制业务比例,如果可以拿jmeter举例子会好很多,让我们能把您的想法落地,前面那几篇工具篇能匀一篇说业务比例如何设计该多好。最后是容量场景下最大tps应该怎么看?我看您的图都是曲线图,难道是看曲线图约摸着得出一个结果?

    作者回复: 场景不断,就是从低到高线程递增。
    业务1到6,都是有业务含义的,后端会有很多个接口。
    控制业务比例的过程通常是这样的:1. 先是拿线程数和TPS、响应时间来计算业务比例来做;2. 当运行过程中出来业务比例偏差时,就调整线程数;3. 在jmeter中可以有控制吞吐量的控制器。
    业务比例设计的后面有一篇是专门描述这个的。
    最大TPS,我是通过曲线图的一段来做计算的,你要是“约摸”这个词,也不是不可以。哈哈。

    2020-01-13
  • 米儿
    高老师,jmeter中您是怎么来控制业务比例?我自己在实际压测的过程中很难做到比例的精确,多个线程组的话,每个业务的响应时间又都不相同,求赐教

    作者回复: 你可以用吞吐量控制器。

    2020-01-13
  • 🐻
    高老师 有个问题想问一下。如果没有业务指标情况下 想要跑压测之类 有没有一些常规的指标?或者要怎么去定线程数之类的

    作者回复: 没有业务指标是可以测试出最大tps的哇。只要有业务比例即可。线程数是根据业务比例来的。

    2020-01-13
  • Geek_a98085
    如果是新的项目,没有拿到比例的情况,是不是可以按默认1:1:1的比例来执行容量场景?

    作者回复: 做为尝试场景,可以这样做。只是要知道这个结果对线上没有参考价值。

    2020-01-13
  • Imaginary
    答:
    1、性能测试场景应该有预期的测试指标并且符合实际的生产场景,按照生产的业务比例模拟真正的业务,以达到我们所真正需要的结果。
    2、稳定性场景就是为了知道会不会由于长时间处理业务而引发潜在瓶颈。至于用多大的 TPS 来运行,又有什么关系?这个系统用最大 TPS 能跑下来,业务一直很正常,稳定性目标能达到,为什么不能用最大 TPS 来跑呢?只要系统在正常处理,资源没有出现问题,也没有报错,那这个场景就是有效的,目标也是能达到的。

    作者回复: 理解的非常对。

    2020-01-13
收起评论
21
返回
顶部