软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13370 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

29 | 聊聊性能测试的基本方法与应用领域

茹炳晟 2018-09-03
你好,我是茹炳晟。今天我和你分享的主题是:聊聊性能测试的基本方法与应用领域。
在上一次分享《带你一起解读不同视角的软件性能与性能指标》这个主题时,我介绍了衡量软件性能的三个最主要的指标:并发用户数、响应时间和系统吞吐量,和你分享了这个指标的内涵和外延。
所以,今天我会先继续上次的话题,和你分享并发用户数、响应时间和系统吞吐量这三个指标之间的关系和约束;然后,我会再和你分享性能测试七种常用方法,以及四大应用领域。
由于性能测试是一个很宽泛的话题,所以不同的人对性能测试的看法也不完全一样,同样一种方法可能也会有不同的表述方式。但是,从我亲身经历的实践来看,我们最关键的还是要去理解这些方法的本质和内涵,这样在面对实际问题时才能处变不惊,灵活应对。
虽然关于概念、方法和原理的内容会有些枯燥,但是掌握了这些看似枯燥的内容后,你会发现自己的性能测试知识体系越发完善了。当然,在这些看似枯燥的理论讲解中,我也会通过类比的方式,帮助你理解。如果你觉得不过瘾,还想知道一些更细节的实现,欢迎你给我留言,我们一起来讨论。

并发用户数、响应时间、系统吞吐量之间的关系

并发用户数、响应时间、系统吞吐量,这三个名词的含义可能就已经让你感觉云里雾里了,因此我会通过一个我们日常生活中的体检为例,再来解释一下它们到底是什么,以及它们之间的关系和约束。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(17)

  • sylan215
    感觉目前专门的服务端开发,应该都会考虑到性能的问题,特别是并发和吞吐量,而且他们对不同系统的不同性能指标都会有一个大概的了解,如果配置专门的服务端性能测试的话,技能要求其实和开发水平都相当了,甚至更高。

    反而是客户端团队,对这块的关注并不够,大部分人主要都是关注的功能实现,就算有关注性能的,也没有明确的性能指标,因为这块主要考虑的就是响应时间,而每个人对于响应时间快慢的感知并不一致,只要不是延迟的太明显,大部分人还是可以接受的。

    除了用户量级特别大的业务外,现在是不是很多公司都使用云服务啦,这样做业务的公司就不需要去考虑服务器的复杂部署和维护的问题了,专业的事情都交给专业的人去做了,如果这时候涉及性能测试,应该也是更专业的啦。

    以上,欢迎沟通交流,公众号「sylan215」

    作者回复: 好的性能专家基本都是架构师级别的水平,要求很高。

    前端性能优化小公司一般都不会去做,但是大的产品一般都有做,而且是采用全公司共享的性能专家团队模式,比如hp就有自己的性能专家团队PCoE。
     
    上云之后,基础架构这一层面的性能的确不同特别关注了,但是全链路压测还是要做,另外应用自身的性能瓶颈以及扩展性问题还是要关注的。

    2018-09-03
    5
  • Cynthia🌸
    代码级性能测试的方法,学到了!的确这种从上而下的排查方式极为缓慢,如果在单元测试的时候用这种方法测过,真是ROI很高的一件事呀!

    作者回复: 是的,单元阶段直接改一下单元测试框架,代价非常小,但是收益会很大,我很推荐这个方法

    2018-09-03
    5
  • 萨拉热窝的棒小伙儿
    代码级的性能测试,对于测试人员具体应该怎么执行?管开发把代码要过来,装一个ide能执行代码环境,然后在代码外部写一个循环1000次,,掐算一下时间?

    作者回复: 不是的,直接在ut框架的基础上加上循环执行和时间统计的功能,然后在ci里面触发,一般测试的过程不需要额外的工作量,但是问题分析还是需要开发工程师

    2019-01-12
    1
  • fekgih
    目前负责的项目性能测试比较花精力在后端性能测试,并发测试,压力测试和可靠性测试。本人很想花点精力在前端性能测试这方面,不过这方面经验还没有,而且项目组比较关注后端方面的性能。貌似一说起性能测试,对于前端方面,只有页面响应不太延迟就觉得不需要放太多精力关注,反而后端方面,都是花大部分精力在上面,而且各种工具也很成熟完善。看到后面老师有专门一篇介绍前端性能测试工具,顿时很开心。说到后端性能测试,对于接口性能测试方面,推荐wrk这个工具。

    作者回复: 希望后面前端性能的文章对你有直接的帮助,一般公司都关注后端性能,只有大型的公司才会有专门的前端性能团队,不过前端性能调优相对简单,有成熟的套路

    2018-09-08
    1
  • Jaime
    请教一下老师,那最后的性能测试报告需要进行开会讨论? 如果需要讨论的话,主要关注点是什么?
    2019-11-12
  • dingdongfm
    并发用户数=系统吞吐量*响应时间,就对应的是Little's Law;刚开始响应时间基本恒定,提高并发用户数,系统吞吐量会相应提高;当遇到拐点后,响应时间迅速增大,它的增速大于并发用户数的增速(可以认为等式左边是个常量,此时响应时间增大,吞吐量必然是下降的),此时继续增加并发用户数,系统吞吐量是反而是下降的。请问我的理解是否正确?另外,请问这里的并发用户数是否就是jmeter中的“线程数”?系统吞吐量就是jmeter中的Throughput?
    2019-09-27
  • 任欣
    之前在做后端开发的时候,有做过sql数据库的压力测试,查看单台服务器所能容纳的数据量,以及数据库中单表的数据容量。看了您的文章之后对整个测试有了一个系统性的认知。
    2019-05-19
  • 口水窝
    自己做过后端性能测试,压力测试,配置测试,并发测试,遇到的问题不是说不会测试,而是不会设计测试场景,在产品、需求人员都不知道要达到什么要求的时候,前面的测试场景比较混乱,思路不好。当然,这几种测试中,有些边界容易混淆,导致测试场景的设计像这个,又像那个的感觉。以后遇到类似情况,还是要多跟产品需求了解情况,然后在根据不同的测试方法设计场景,这个过程中做好备注比较好。
    2019-04-24
  • 「」
    老师,您好,请问一下,假如,一套服务器部署两个项目,如果要对其中一个项目进行压测,那么如何对待另一个项目的影响呢,因为日常就是两个系统一起运行,仅压测其中一个是不是结果会不准
    这里转不过弯儿来了,麻烦老师解答,谢谢。
    2019-04-12
  • 苦行僧
    老师能不能讲讲开源软件的性能测试指标,比如根据什么指标选择相应开源组件,比如我们工作中用的activemq中间件
    2019-02-01
  • 陈子文
    前端性能测试,YSLOW就没有装成功过,有没有啥建议?
    2018-12-13
  • 人心向善
    从接触这份工作到现在也有很长时间了,一直关注的都是响应时间、并发数量、系统资源使用,比如mem、cpu这些,然后只关注这些方面的最大问题就是系统出现瓶颈时不知如何下手,最多也就是先从硬件到软件的分析方式去逐步分析,而硬件和软件又分很多层面,每一个层面又涉及到更多的知识,除了真实项目中的不断深入了解也就是不断的学习了,再看到老师的单元测试的时候感受颇深,确实是这样,很多时候分析来分析去最终发现是底层的问题,但是不是所有所有的客户方都会选择单元测试,从遇到的到现在为止,十有八九都是做做压力测试关注下响应时间、系统资源利用率罢了,最多也就是稳定性测试,这样的话单元测试在这种情况下就没有了任何意义,不过治病先治根是对的,但要以实际为主了!

    作者回复: 高质量的留言,我也深有同感

    2018-10-08
  • Robert小七
    最想知道的如何设计测试用例

    作者回复: 性能测试的用例设计是要根据你的测试目标来的,只要是确定用户行为已经负载模型,在后面实例的讲解文章中还会涉及

    2018-09-04
  • 老师,性能基准测试如何做,哪些指标及多大的指标值可以作为性能测试的基线?

    作者回复: 基线本身可以作为参考指标,去衡量后续迭代对原有性能的影响,至于基线里面应该使用哪些指标取决于被测应用,但是吞吐量,响应时间,系统资源占用率都是最基本的

    2018-09-03
  • 涟漪852
    老师也讲讲jmeter

    作者回复: 文章本身不会去讲具体工具的使用,而是想要讲清楚工具的原理,后续文章有基于loadrunner来讲的实际案例,jmeter使用还是推荐阅读官方文档

    2018-09-03
  • hyeebeen
    简单可操作,之前有些点没考虑到。可以实践一下了

    作者回复: 嗯嗯,能有收获就好,后面还有完整的实例讲解,希望可以帮到你

    2018-09-03
  • 风子夕👀
    我是一个开发,这两天正在给领导写一份关于在开发过程中推进单元测试和性能测试的建议。
    就我个人最近的经历来看,正好贴合了今天课程里所提到的几点,比如通过性能测试了解系统的稳定性,可靠性,以及有没有潜在风险,特别是某些代码中隐藏的性能缺陷。
    为了推进这块,在最近完成的项目中,我自己写了个模拟并发用户的简单框架,生成用户数据,简单模拟用户常用的场景。通过这样的并发模拟来检验稳定性和响应时间。
    感觉不综合测几轮,心里没谱。

    作者回复: 嗯嗯,不错的实践,执行过程中如果有任何问题,可以随时交流

    2018-09-03
收起评论
17
返回
顶部