性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
3501 人已学习
课程目录
已更新 7 讲 / 共 30 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
性能测试实战30讲
登录|注册

04丨JMeter和LoadRunner:要知道工具仅仅只是工具

高楼 2019-12-23
做性能测试工作的人总是离不了性能测试工具,但当我们刚开始接触这类工具或者压测平台的时候,总是难免处在一种顾此失彼,焦虑又没想法的状态。

性能工程师的三大学习阶段

在我看来,对性能测试工程师本身来,多半会处在以下三个大的阶段。

性能工具学习期

JMeter 和 LoadRunner 是我们常用的两个性能测试工具。曾经有人问我,应该学 JMeter 还是 LoadRunner 呢?我反问的是,你学这样的工具需要多久呢?一般对方因为初学并不清楚要多久,然后我会告诉他,如果你是认真努力的,想要全职学习,那么我觉得一个工具,纯从功能的使用的角度来说,自学两个星期应该就差不多了。如果你是在工作中学习,那就更简单了,工作中需要什么就学习什么,不用纠结。
而应该纠结的是什么呢?当你把 JMeter、LoadRunner 的基本功能学会了,你会发现这些工具其实就做了两件事情,做脚本和发压力。
但问题在于,脚本的逻辑和压力场景的逻辑,和工具本身无关,和业务场景有关。这时你可能就会问,场景怎么配置呢?
这才进入到了另一个阶段。
通常在这个阶段的时候,你会觉得自己有非常明确的疑问,有经验的人可能一句话就可以指点你了,解决掉你的疑问,就是告诉你选择什么工具,如何来用。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

  • @zzw
    第一个问题:
    大概会考虑怎么几个方面:
    - 学习成本:对人员的水平要求,培训时间成本等;
    - 脚本编写:能否录制测试脚本,是否支持GUI操作等;
    - 安装部署成本:是否支持一键安装,是否支持docker等;
    - 是否免费:开源工具一般都是免费的;但是很多收费工具也的确物有所值;
    - 是否支持多协议:比如是否支持 HTTP 协议、RPC 协议等等
    - 测试场景:是否有链路、场景编排管理,支持支持将请求编排成业务场景,即常见的一串联场景;
    - 流量控制:支持纵向的,上下游链路的请求量逐渐减少,整体呈现一个漏斗模型;也可以是横向的;
    - 压力控制:指压测时并发用户数、 TPS 的控制等;
    - 数据驱动:大量的测试数据的参数化;
    - 分布式支持:支持压力机集群;
    - 测试报告:压测结果是否能够图形化展示,提供美观且丰富的测试报告;
    - 二次开发的成本:由于时间或人力关系,也需要考虑二次开发成本;
    - 性能开销:执行机开销、软件可靠性、执行效率、业务处理能力等。
    ....

    第二个问题:
    我觉得一个好的监控系统大概需要包括以下几个方面:
    - 全栈系统监控是前提;
    - 关注于整体应用的 SLA:主要从为用户服务的 API 来监控整个系统;
    - 关联指标聚合:把有关联的系统及其指标聚合展示。主要是三层系统数据:基础层、平台中间件层和应用层。并提供一个全局的系统运行数据大盘,帮助快速找到系统瓶颈。
    - 快速故障定位:快速定位问题需要对整个分布式系统做一个用户请求跟踪的 trace。

    只有做到了上述的这些关键点才能是一个好的监控系统,而显然目前的测试工具监控是不满足的。

    另外测试工具本身在做监控也有其局限性,如 jmeter 在压测量较大的情况下回传测试结果 Master 节点会成为容易成为瓶颈。

    作者回复: 嗯,你说的很对。
    我竟没有啥子可以补充的。

    2019-12-23
    1
    10
  • 小老鼠
    要测试一个在线运行的网站性能,应该使用什工具比较好?设置的被测网站的IP地址可以是公网IP吗?

    作者回复: 使用什么工具取决于什么样的工具最适合应用场景。如果是HTTP协议的,那有很多工具都适用。没有谁比谁更好,只有哪个应用在团队中成本最低。
    关于压力工具我从来不纠结,就算自己写一个多线程工具也无所谓,只要能让我看到TPS、响应时间、错误率之类的数据就可以。

    从技术上说,不管是公网IP、内网IP,对性能测试的过程来说都无所谓,只要路由可达就可以测试。
    只是用公网IP要考虑出口流量,以及架构上的各种网络设备,像WAF、SLB、广域网设备等。并且如果是按流量付费的带宽,还要先计算下费用。 还有客户端如果也在公网上,还要考虑客户端的出口带宽。 但是这些都和性能测试技术本身无关。

    2019-12-24
    1
  • 村夫
    老师请教一个问题。关于事物的定义,假如有一个兑奖的活动,进去活动页面会请求三个接口,一个个人积分接口,一个是任务列表接口,还有一个是兑奖列表接口。在页面点击兑奖按钮会去请求兑奖接口,兑奖成功页面会去调用用户接口刷新用户当前积分。这样的情况应该怎么去定义事物?

    作者回复: 这就是之前的一个文中所写的。
    事务的定义取决于测试的目的:
    1. 如果你想测试的是单个接口的容量,那显然,一个接口一个事务,并且都是直接连接口就行了。但是要注意的是,其实在测试兑奖接口的时候,后面的几个接口也都会调到,所以这时会把后面几个接口都压了。这时,如果你的目标只是测试兑奖接口本身,并不想测试关联的其他接口,那就mock掉。
    2. 如果你要测试的兑奖的这个流程,那显然是从兑奖接口进去。事务定义到兑奖整个流程上。

    2019-12-24
    1
  • 私人领域
    现在在公司做的还是不太顺利,概念不理解,大家对并发的不理解,这包括开发,产品,项目,部分运维可以理解;还有就是无理要求要求8000并发,这个怎么跟他们解释都无用,一说就是客户要求的,这8000并发发包出去就几g的流量了,真不明白他们怎么想的,这做技术的人一点基础都没有,真的很难工作

    作者回复: 要是你职位高,可以强势一点沟通。如果从历史数据中算到并发度并不高。(就是拿当前的用户和业务的TPS做比对就可以知道并发度。)
    那完全可以算得出来。

    现在不懂技术的人说的并发,大部分是说的在线。之前我算过一个要支持1000万基础用户(也就是数据库里总共只有1000万用户),再计算到日活,再计算到时、分、秒,才需要200TPS。

    2019-12-24
    1
    1
  • 心怡
    选工具考虑的方面,1.明确企业所做的系统性能指标是什么 2.性能测试的目标是什么3.哪个工具可以做?4.这个工具如果在做的过程中无法实现这个目标怎么办

    作者回复: 是的,适合的工具就是最好的。

    2019-12-26
  • 玉面小肥猫
    老师您好,“比如说压力策略,应该用一秒 Ramp up 10 个用户,还是 20 个用户,还是 100 个用户?这应该怎么判断呢?”可否回答一下,最近正在纠结这个问题,谢谢!

    作者回复: 等你看到场景设计的那篇的时候,估计你就不会有这个疑问了。

    2019-12-24
  • Eight Baby
    我们公司基本普及了jmeter 覆盖了自动化和性能了(基本人人都会),确实jmeter用起来效率高,开源不少协议都自己写。我觉得性能会工具和会压测完全两码事...

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

    2019-12-24
  • 月亮和六便士
    高老师,推荐几款监控Java语言接口和方法执行时间的工具,比响应时间细分到Java某个工程的jar包,我怎么监控这个jar包里的接口执行时间,方法执行时间,还有算法执行效率,等等

    作者回复: 这有很多呀。像jvisualvm/jmc/arthus/btrace......。开源免费。

    2019-12-24
  • calm
    高老师,能否推荐一些性能测试这方面的书籍?

    作者回复: 这个就比较麻烦了。除了写性能测试工具之外,性能测试基本上没有自己的书籍。
    但是写工具也不算是完整的性能测试。
    如果你要看的话,我建议你这样开。
    OS、DB、存储、语言(java、go、python)、架构等各找一本性能相关的书看。比如说linux性能优化、java性能优化、mysql性能优化,这类的书。

    2019-12-24
  • 月亮和六便士
    高老师,推荐几款可以监控接口和方法执行时间的工具,

    作者回复: 你说的是什么语言?到了这样的级别就要看语言和架构了。

    2019-12-24
  • 高老师,什么时候更新啊?希望尽快看到你后面的章节

    作者回复: 更新的频率取决于极客编辑小姑娘的心情。哈哈。

    正常的安排是一三五更新。

    2019-12-24
  • Geek_081377
    支持高老师,希望听完能成为公司的性能大牛,哈哈

    作者回复: 要是完全能在工作中落地的话,那就不是大牛了,是猛牛。哈。

    2019-12-24
  • JustRunning
    第一个问题:
    1、常规工具看测试场景需求:比如一般测试接口性能和找系统瓶颈,用jmeter,轻量开源可自定义扩展插件。如果业务整体场景流程基准测试并有要求输出完整报告,一般选loadrunner,毕竟图表好看,界面脚本录制方便,对局方(甲方认可工具)有说服力。
    2、云平台测试选择(自建还是购买):
    2.1权衡场景,公司是否业务需求到这量级,不为测试而测试。
    2.2短期长期思考:短期或没成熟测试团队,可购买过渡,长期推荐自建,完成技术栈积累。
    第二个问题:
    推荐监控用专业监控去处理,避免监控与测试互相干扰,尤其流量方面。但是比如内部小流量业务平台,没完整监控体系,可以直接使用工具集成的~

    作者回复: 理解的完全正确。

    2019-12-24
  • 律飛
    第一个问题:
        企业选择性能测试工具无外乎两种策略,一是性价比优先,花最少的钱最快地完成最多最需要完成的任务,比如租用云压测平台,属于头痛医头,脚疼医脚的临时策略,小公司、发展初期公司等常采用的策略,可以快准稳完成压力测试。二是结合长期发展目标,分阶段规划测试工具购买及测试人员培养,甚至自己开发测试工具,积累并形成自己的压测能力。这个策略与公司测试人员以及测试团队能力也有很大的相关性。其实老师已经讲得很清楚了。
    第二个问题,我个人认为不应该在测试工具中做监控。现在处于一个分工很细的世界,术业有专攻,专业人做专业事,一来可以保持工具的简洁,二来可以保持工具的通用性,增加使用的灵活性。当然这对做性能测试的人的能力要求就更高了。不过工作的乐趣不就在于此吗?

    作者回复: 理解的非常到位。完全领会了精髓。

    2019-12-23
  • Bi
    第一个问题:
    首先需要根据企业的业务场景、目标选择合适的工具;
    其次需要考虑工具的使用成本:资金成本,学习成本,人员成本,适用范围等;
    然后还要看看是不是符合企业未来的发展方向,比如如果有需要,是否方便向后兼容,做成一个性能平台......
    第二个问题:
    对这一点没有太好的想法,只能说根据企业情况来吧,有时候你自己知道搭建全栈的监控,好处很多,但是现实往往不允许,,,这个真的很无奈.

    作者回复: 面对现实,分析现实,改变现实,超脱现实。

    2019-12-23
  • 苦行僧
    我们单位基本用jemter来压测,主要的测试为接口级测试,接口基本为数据给出接口,属于查询类事务

    作者回复: 测试目标如果明确,怎么实现都是阔以滴。

    2019-12-23
收起评论
16
返回
顶部