一切从零开始——性能测试学习笔记之 LoadRunner实战(1)

发表于:2018-1-22 10:10  作者:杨婷 编著   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 性能测试 性能测试工具 软件测试工具 LoadRunner

  提及性能测试,总让人有种高深莫测的感觉,对于已经工作在功能测试方面做过1~2年甚至更长时间的朋友来说,性能测试不是不想做,而是无从下手。在企业里有若干理由可以让你放弃性能测试的学习,技术积累多数也是虎头蛇尾,所谓万事开头难,如果能及时调整状态,理清脉络,那么就会诸事顺遂,心想事成。
  本章主要包括以下内容:
  ●拒绝性能测试的理由;
  ●告别拖延,拥抱变化;
  ●性能测试招聘要求;
  ●本章小结。
  1.1  拒绝性能测试的理由
  在此事上也许你有千百种理由,例如
  理由一:公司有专业的性能测试团队,那里不需要没有经验的人(而自己就是那个被认为没经验的人);
  理由二:公司没有性能测试要求,我不需要学习更多;
  理由三:公司有性能测试需求,但是没有人会,我也无能为力。
  以上3种情况如果非要总结一下,那就是没有人教你如何做性能测试。至于“我不需要学习更多”的说法是明显的自欺欺人,当你拿起这本书的时候,我相信已经证明了我的论证。
  那是时候接触下性能测试了,为了能让你不再感到畏惧,能够轻松突破自己,故事就从一个叫Lucy的姑娘说起。相信故事总是吸引人的,故事的主角同你一样并不是工作狂,也不是一个科技极客,请相信作者的介绍,后续的故事将是这位姑娘陪伴您一同学习和成长。
  个人基本资料
  姓名:Lucy    
  性别:女
  年龄:25岁
  毕业院校:××大学计算机专业
  工作年限:3年
  就职公司:A技术有限公司(主要从事外包业务)
  当前职位:技术部 / 某项目组 / 测试负责人
  Lucy毕业后应聘上了A公司的初级软件测试工程师岗位,在这里工作3年了,主要从事各类外包业务系统的功能测试工作,在繁忙的工作中也算是尽职尽责,目前已经是某个小团队的测试组长。Lucy一直以来都很想接触更有挑战的测试工作,例如性能测试,在半年前就有计划学习性能测试,但繁忙的工作总是让人疲于奔命,重要而不紧急的事项看起来是那么遥遥无期。
  什么是重要而不紧急事项?这是个时间分配的问题,我们来看看经典的时间管理象限图,如图1-1所示。
  “紧急又重要的事项”和“紧急但不重要的事项”占据了你大部分的时间,也就意味着消耗了你大部分的精力,当你无力面对重要而不紧急的事项,就意味着这件事很难完成,而性能测试恰巧就是Lucy重要而不紧急的事项。
  图1-1  时间管理象限
  1.2  告别拖延,拥抱变化
  日子一天天过去,直到有一天张经理(以下简称PM张)找到Lucy,以下是他们的简短对话。
  PM张:Lucy,你来公司有多久了?
  Lucy:大概有3年2个月了。
  PM张:嗯,时间不短呀,听同事们说你做事认真负责,我也非常欣赏。
  Lucy:领导,是有什么新的安排吗?
  PM张:公司计划成立性能测试团队,毕竟业务扩展得比较快,用户的期望也就更    高了。
  Lucy:领导是希望我去做性能测试吗?(略显兴奋)
  PM张:正有此意,只是不知道这么长时间你在性能测试方面有无积累?
  Lucy:我……
  有时候真的很难用语言来形容当下的心情,Lucy和PM张经过一番交流,PM张最终决定给Lucy一次机会,要求在一个月内掌握性能测试基本应用(当然现有的工作依然是重点,不会有任何变化),如果一个月无法达到既定目标此事也就作罢。压力到动力的转化就是一墙之隔,请每天抽点时间和Lucy一起在性能测试的世界漫游。
  第2章性能测试概述
  Lucy翻阅了大量参考资料,将所有内容做了一次整理,但要完全理出头绪还需要借助在HR管理培训时提到的“六何分析法”,即5W1H分析法,这是一种思考方法,可以通过寻找问题和解答问题的思路来学习新技能。
  本章主要包括以下内容:
  ●性能测试的缘由(WHY);
  ●性能测试的开始(WHAT);
  ●项目组成员介绍(WHO);
  ●项目组现有资源(WHERE);
  ●关于时间的要求(WHEN);
  ●性能测试过程(HOW);
  ●本章小结。
  2.1  性能测试的缘由(WHY)
  2.1.1  性能测试典型案例
  我们先来看看WHY的问题,首先我们可以问自己为什么要做性能测试?如果你做过功能测试相信并不会对此有太大的疑惑,Lucy所在的公司做过很多客户项目,其中就有因性能问题而导致出错的典型案例。
  案例一:去年A公司承接了一个办公自动化的项目,Lucy是这个项目的主要测试负责人,项目进展还算顺利,直到快交付使用的时候PM张找到开发和测试,征求是否可以模拟多用户使用的情况,以免上线出现问题。因Lucy没有此方面的经验,而开发也只能是对于关键环节做些预防和检查,此事也就作罢。好在客户方算是人品爆发,系统预上线后要求全体成员在指定时间使用该系统至少15分钟,并反馈使用情况。(要知道这件事情的难度是非常大的,客户方公司大约有2000名员工,没有良好的执行力恐怕难以实现。)结果系统在大规模使用的情况下直接崩溃……
  案例二:今年初Lucy恰巧接手了一个移动端App项目, 该项目公司测试完成后计划在3天后交付用户,而客户方出于谨慎,为了保证软件质量找来了第三方公司进行验收,通过验收测试发现了部分并发(多用户同时使用某种功能)导致的性能问题……
  以上两个案例对于A公司来讲造成了一定损失,这也算是A公司有意组建性能测试团队的重要原因,那么性能测试对我们现实生活又有哪些影响呢?我们来看一些日常生活中的所见所闻:
  (1)“双十一”的疯狂,为何抢不到商品的总是自己
  某宝拥有强大的服务器,技术上也算是业内数一数二的公司,但在面对上亿用户蜂拥下单的情况下依然是力不从心,经过多年改进,在2015年还是难逃服务器繁忙请等待的尴尬。
  (2)12306春运魔咒,为何票刚放出来,还没来得及下单就显示售罄
  12306算是业界调侃的主要对象,但凡春运期间买过票的朋友都会吐槽一番,面对整点放票而涌现的巨大抢票压力,2014年让诸多“抢票神器”(利用自动化技术实现购票的一种不正当手段)风起云涌,黄牛手握多张车票,而真正需要火车票的顾客却苦苦守候也只能接受抢不到票的无奈。
  (3)大型网游宕机,某大型网络游戏服务器为何频繁发生故障
  某大型网游在中国风靡多年,因服务器频繁死机,服务器代理商也出现了易主,2010年因服务器故障导致整个游戏网络瘫痪,甚至部分数据丢失,网络玩家情绪异常激动,集体表示不满。
  (4)迪斯尼开园一票难求,又是一次哄抢导致官网出现崩溃
  2016年上海迪斯尼官网门票上线即被“秒杀”预售,疑似系统故障,据业内人士分析,官网出现系统故障的原因主要是同一时间集中发送购票请求过多,系统不堪重负。
  学习笔记
  多数公司想要开展性能测试相关工作,往往是因为业务需要,许多人总说没有机会,但当机会来临的时候自己却没有准备好。
  2.1.2  测试人员眼中的性能
  在2.1.1小节我们讲了许多案例,无非是想说明以上都和性能测试有关,对用户来讲性能测试最直观的感受就是反应慢或者没有反应,通常我们把这种反应快慢的状况叫作“响应时间”。但作为一名测试人员,我们的理解可以比普通用户更深入些,我们可以看到服务器端的情况,可以了解网络传递的过程,所以我们有更多的视角看待性能问题。
  1.响应时间
  我们往往用时间的快慢来判断系统当前所处的状态,最直观的感受就是我们向服务器发起了某个请求,在没有缓存的情况下,服务器返回请求所花费的时间总和就等于响应时间。例如,我们向51testing论坛发起登录请求,1秒之后我们进入登录成功页面,那么1秒就是我们所花费的响应时间。
  客户感受到的响应时间=客户端响应时间+网络响应时间+服务器响应时间
  如图2-1所示,响应时间= CT+(N1+N2+N3)+(N4+N5+N6)+WT+AT+DT。
  图2-1  响应时间的组成
  (1)客户端响应时间 
  CT=Client Time对于瘦客户端可以忽略不计,对于胖客户端,例如Ajax,HTML5+ AngularJs+Bootstrap,由于客户端内嵌了大量的逻辑处理,消耗的时间可能很长,需要关注。
  (2)网络响应时间
  指网络传输交易请求和交易结果所消耗的时间,可以分为以下两个部分。 
  N1+N2+N3=客户端请求的网络延迟
  N4+N5+N6=服务器响应的网络延迟
  (3)服务器响应时间
  服务器完成交易请求执行的时间,服务器端的响应时间可以度量服务器的处理能力。
  WT=Web Server Time 
  AT=App Server Time
  DT=Database Time                  
  2.并发数
  我们可以通过有多少用户在使用系统了解系统的承载能力,客户总是希望越多越好,但系统总是有极限的。这里有三个概念需要加以区分。
  (1)系统用户数
  可以理解为系统注册用户总数。例如,51testing论坛有超过60万的注册用户,有些用户非常活跃,经常登录并留下“足迹”,而有的用户很少访问,甚至自己都忘记曾经注册过的    账号了。
  (2)在线用户数
  当前统计时正在访问的用户总数。例如,51testing论坛每天有超过12万的在线用户数,但他们不一定会给网站造成巨大的压力,大多数用户只是浏览网页信息,并没有向服务器发起过多请求。
  (3)并发用户数
  同一时刻让服务器产生压力的用户数。例如,51testing论坛的12万在线用户中有20%正在论坛发帖讨论,那么服务器将承受这部分用户的压力。
  3.吞吐量
  严格意义上来讲我们可以把吞吐量分为“吞吐量”和“吞吐率”两个概念讲解。
  (1)吞吐量
  指在一次性能测试过程中网络上传输的数据量的总和,“吞”进去的是请求,“吐”出来的是结果,吞吐量反应的就是服务器的“饭量”,也就是服务器承受的压力。例如,在51testing论坛浏览帖子比发表评论需要更高的网络吞吐量。
  (2)吞吐率
  通常指单位时间内网络上传输的数据量,也可以指单位时间内处理的客户端请求数量/服务器返回的数据量。它的定义相对灵活,在数据库层面,吞吐率指的是在单位时间内,不同SQL语句的执行数量;从用户层面来讲,吞吐率也可以用“页面数/秒”、“业务数/小时”、“访问人数/天”等指标来衡量。
  【特别说明】:吞吐率=吞吐量/传输时间,例如,访问51testing论坛首页,首页大小按2MB计算,如果每秒有1000个首页访问量,那么吞吐率就约等于2GB/s(1GB=1024MB)。
  4.每秒通过事务数(TPS:Transaction Per Second)
  每秒钟系统能够处理的交易或事务的数量,它是衡量系统处理能力的重要指标。
  交易和事务是人为规定的,一个交易或者事务可能包含多个请求,例如,用户注册可以包含多个字段验证请求,而用户注册的TPS等于每秒钟能够注册的用户数量,如果每秒钟能够注册10个用户,那么TPS=10。
  【特别说明】:TPS和吞吐率在性能测试中的曲线呈正相关,以吞吐率的案例来看TPS,如果吞吐率指的就是每秒访问论坛首页的次数,那么TPS=1000次。
  5.每秒单击数
  每秒钟用户向Web服务器提交的HTTP请求数,这是Web应用特有的一个指标。如果把每次单击定义为一次交易,那么单击率和TPS就是一个概念,但事实上一个交易往往由若干请求数组成,请求当中包括页面HTML、css、图片等,甚至可能包括多个页面,也就是说单击数和TPS一般不会一致。
  例如,你想在51testing论坛提交一个登录请求,通俗来讲就是你用鼠标的一次“单击”登录按钮的操作,这个单击操作可能向服务器发出了90多个HTTP请求,但我们只能看作是1个事务。
  6.资源利用率
  指的是对不同系统资源的使用程度,主要针对Web服务器、应用服务器、数据库服务器、网络情况等。
  常见的资源有CUP占用率、内存使用率、磁盘I/O、网络。
  (1)CPU
  CPU就像人的大脑,主要进行各种判断和处理,能反应计算机的繁忙程度,如果CPU占用率达到100%,此时用户就无法做任何操作了。
  (2)内存
  内存就像人的某个记忆区域,将信息收集和存放起来,此区域能够存放的信息量越多,计算机的反应也就越快,但关机后该区域的信息将被清空。(从内存读取数据要比从硬盘上快得多。)
  (3)磁盘I/O
  I/O是指磁盘的输入和输出(Input和Output的缩写),读IO,就是发指令,从磁盘读取某段扇区的内容。指令一般是通知磁盘开始扇区位置,然后给出需要从这个初始扇区往后读取的连续扇区个数,同时给出动作是读,还是写。磁盘收到这条指令,就会按照指令的要求,读或者写数据。控制器发出的这种指令+数据,就是一次IO,读或者写。重点关注的是IO交换频率和磁盘队列长度。
  (4)网络
  主要指网络流量,看是否是网络带宽的瓶颈。例如,论坛首页2GB的吞吐量将消耗掉16Gbps的带宽。
  学习笔记
  笔记一:吞吐量、吞吐率、TPS需要加以区分和理解,但实际工作中三者往往可以相互转换,并没有分得太清楚。
  笔记二:测试人员眼中的性能关注点,也就是未来性能分析的主要关注指标,指标的具体值就体现了当前系统在特定环境下的工作状态,需要理解并记住它们。

本书读者交流QQ群:425860640,欢迎加入~~
本文选自《性能测试学习笔记之 LoadRunner实战》第一章,本站经人民邮电出版社和作者的授权。
版权声明:51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

21/212>

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道