软件性能测试的本质

?

  淘宝网每年的双11活动都是对其服务器性能的挑战。因为在这一天所有商品半价,购物的用户量剧增。做为淘宝网的高层更多的关心在线用户数,用户交易量,总交易金额等,做为一名技术人员,我们可能更关心当天系统的吞吐量、每秒钟点击率以及系统资源的消耗情况等,对!这就是系统的性能。那么性能的本质是什么呢?我试抓住一些点来解释。
   基于用户体验的性能测试
   但对于一个用户来说,他可以不关心上面这些(系统的性能参数),大约有一部分的消费者会因为网站过于技术化或者性能问题而选择了离开。换言之,如果你的网站速度太慢客户就会离去。这是所有的互联网用户都熟知的道理。这时你的第一想法不是“哎呀,不知道站点的吞吐量怎样”,而是“简直太慢了!我可没有时间在这里等,到别处去吧”。现在想想,人们离开你的站点是否因为性能问题?所以,在做性能测试的时候除关注吞吐量、点击率这些参数外,我们更需要站在用户的角度来测试实际的性能感受。如果你经过测试声称网站可以承受更多的用户同时访问,但实际的用户体验性非常差,那么做你的性能测试又有什么意义呢? 
   现在市场上有大量的书讨论如何设计良好的性能,还有更多的书把重点放在如何使得站点更加直观、生动和易于炒作上。关于速度的好处也讨论过,但如何真正并优化系统来提高用户体验呢?那就是直接的用户体验测试了。有两点方法可以做一这点。一是可以把站点直接投入到能够进行数据采集和系统调优的生产环境中,并祈祷你的网站不会太慢或崩溃。另一个种明智的选择是模拟真实的用户活动,进行重复的测试和调优,最后再投入到生产环境。 
   “明确”的性能需求 
   当测试人员进行性能测试工作时,真正让他们感到困难的不是测试工具如何使用,也不是如何对测试数据进行分析与系统调优(对于一个经验丰富有性能工程师来说,这真的不难)。让他们感到困惑的是如何得到准确的量化的需求,比如: 
   A.网站可以支撑多少在线用户数 
   B.网站可以支持多少用户同时交易 
   C.电子邮件系统每秒种可以处理多少封邮件 
   D.可以支持多少人同时浏览网页 
   类似于这样的数据会出现客户对系统的性能需求中,好吧,有了这些需求,我就开始性能工作了,这些需求真的很明确么? 
   我们来看下面的例子,一个购买汽车的用户想知道: 
   这辆汽车开100公里的耗油是多少升。(对,就是他坐在里面试驾的那辆车) 
   如果你是一个严谨的汽车销售,不会马上会说这辆车每公里的耗油是多少。而是在大脑中快速的列出的汽车驾驶环境: 
   1、车上坐几个人? 
   2、车上带多重的物品? 
   3、路况如何,是高速还是拥挤的市区? 
   4、天气如何,温度如何,要开空调码? 
   5、驾驶时间是白天还是晚上(如果是晚上要开车灯)? 
   6、驾驶习惯是怎样的? 
   你唯一能做的就是继续向客户确认更明确的需求,很多时候其实客户也无法给出精确的需求。这个时候你就要多参考常规的情况下,参考同类产品,或尽量引导用户去明确具体的需求,尽量与客户达到统一的共识。 
   “假设”的测试环境 
   现在是不是觉得性能测试有太多的前置条件,它们或大或小的影响着测试的结果。 
   关于这些前置条件,或者我们称之为假设(assumption),我把一些做法归纳为三个阶段。 
   一:做了假设却不知道自己做了假设
   比如前面提到的那个耗油的问题,有人的做法是我就开100公里看看,得出来是多少就是多少,比如9L。然后就告诉别人这个车的100公里耗油是9L。 
   问题是这样的结果对你是OK,因为你有切身的的体验,知道遇到的状况,可是测试的报告是要给别人,甚至你都无法直接面对或者沟通的人参考。这就会很容易误导别人,即便这不是你的本意,而且你自已也确定你是真实的记录了结果。这里的问题在于你并不清楚自己所做的假设,因为我们一直在做这样的假设。 
   二:做过多的假设
   “当路面平坦,无任何红绿灯,风速5km/h只有一名70kg的乘客,时速稳定在70km/h,良好驾驶习惯,....的情况下,耗油是7.1L/100km。” 
   这样可能很严谨,但是对你的报告的读者而言,这样的数据有多大意义,因为他们没有你这么幸运,有这么良好的环境。 
   三:做必要和合理的假设
   生活有时候是需要一些妥协和折衷,如果这些折衷是必要的和合理的。因为跳出来看,我们的测试需要提供有价值的信息,所以为了这样有价值的信息,做出必要和合理的假设是可以接受的。 
   好吧,也许这不是你想要的答案,但它是我目前给自己的解释和安慰。 
   性能测试环境需要在严格独立监控下管理,尽量保持与真实生产环境的一致性能。 
   “精确”的测试数据
   对于一个严谨的测试员,我们的测试结果的描述也相当精确,如:用户每个用户的访问时间为2.8729秒,10分钟系统处理请求8634个。我以前一直认为,只要我把测试环境描述的很详细,我的测试结果就是精确的。 
   实际上功能测试很容易得到测试结果,而性能测试很难得到精确的量化结果,我买了一辆汽车,开车去上班,去时车的各个功能非常正常,回来的时候车的功能也非常正常。我们通过功能测试很容易得出,这个车的功能没有问题。 
   那么性能测试呢?再来看耗油情况,我去时上耗油3.29升,回来时耗油3.42升,同样的一条路,同样的人开同样的车,那么是不一样的耗油结果?如果我再试一遍,可能情况还会有变化。所以,我们很难得到精确的数据,但是这丝毫不影响我们测试结果的参考价值。 
   “宏观/围观”的性能测试
   这也是一个有趣的对立。在做性能测试,特别是整个产品的性能测试的时候,我们看到的是产品的核心功能和主要的大的功能模块,比如数据库、web服务器、核心的daemon等等。在脑海里,我们有一个架构图,哪怕你没有把它画出来。所以有时候,我们会想,性能测试对于产品的视角是宏观的,看大的组件,而不是具体的细节的东西。果真是如此吗?看看下面的例子: 
   1.把daemon的log级别改为debug(log_level从2改到5)之后,性能下降了差不多一半。 
   2.关掉一个cache选项 
   3.打开keepalive选项 
   4.打开DNS反向查询 
   ..... 
   上面都是些细枝末节的设置,一个配置项而已,藏在DB的某张表或者某个ini里面。但是改变之后,得到的性能结果可能大不相同。这些都是否改变了我们以往的看法。 
   Scott Barber(性能测试方面的专家)在他的一篇文章里讨论了这个话题。 
   “Macro-and Micro-tests,macro strategies and micro-plans,macro-level application usage and micro-level usage implementation details,macro-level result summaries for executives and micro-level test results for developers...it sounds like a day in the life of a performance tester to me.” 
   摘自他为Software Test &Performance杂志写的一个系列文章,叫做Peak Performance,其中的2006年9月的一期,文章名是Macro to Micro And Back Again Macro to Micro And Back Again,嗯,很好的诠释。
   亚里士多德说世上的道理不是被讲一遍两遍而是成千上万遍,是的,因为Weinberg也讲了一遍,就在上面提到的那本书里面。请原谅我再次引用他的话,粉丝嘛。“Although it‘s necessary to have an overview of the problem,the big picture often turns on one critical detail.” 
   critical detail,对,就是这个term。其实不光是这里说的测试,工作和生活中的很多事情都是一样,不是要不要关心细节,而是它是否critical。 
   那么,怎么区分一个细节是不是critical或者怎样找到critical的detail呢? 
   嗯...,这是个好问题,不过不好意思这个不是这里要讨论的范畴。 
   所以,你还认为性能测试只是学习如何使用性能工具么?它需要一个长期的个技术的积累,我们的路还很长。也许,我讲的不够本质,但性能测试这个领域,看到太多的新手在整天问工具的使用,学会了工具的使用就大言“我会(精通)性能测试!”。太多的公司叫新手的做性能测试,环境神马的也不提供,你找个工具对软件加压一下吧!哎~!这未免是太贬低“软件性能测试”了。

本文选自:http://www.spasvo.com/news/html/20141217174341.html

?

时间: 2024-10-18 00:12:48

软件性能测试的本质的相关文章

软件性能测试的几个术语

响应时间 我把“响应时间”的概念确定为“对请求作出响应所需要的时间”,把响应时间作`为用户视角的软件性能的主要体现.响应时间划分为“呈现时间”和“系统响应时间”两个部分.其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间.而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间.软件性能测试一般不关注“呈现时间”,因为呈现时间很大程度上取决于客户端的表现.在这里我们没有使用很多软件性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客

广州八神软件性能测试课程最新大纲

发帖纪念下本人最近开设的一门软件性能测试方面的课程全部录制完毕, 课程URL是:http://edu.51cto.com/course/course_id-2218.html. 课程注重实战和对重要概念的剖析,整个课程时间超过2000分钟. 同时,也可以加入QQ群:319406535 一起讨论学习. 也可以通过http://www.dataguru.cn/myclassnew.php?mod=new_basicforlesson&op=basic&lessonid=323方式学习,两种方式

软件性能测试的基本概念和计算公式(转发)

一.软件性能的关注点 对一个软件做性能测试时需要关注那些性能呢? 我们想想在软件设计.部署.使用.维护中一共有哪些角色的参与,然后再考虑这些角色各自关注的性能点是什么,作为一个软件性能测试工程师,我们又该关注什么? 首先,开发软件的目的是为了让用户使用,我们先站在用户的角度分析一下,用户需要关注哪些性能. 对于用户来说,当点击一个按钮.链接或发出一条指令开始,到系统把结果已用户感知的形式展现出来为止,这个过程所消耗的时间是用户对这个软件性能的直观印象.也就是我们所说的响应时间,当相应时间较小时,

STM 软件事务内存——本质是为提高并发,通过事务来管理内存的读写访问以避免锁的使用

对Java程序员来说,我们对面向对象的编程(OOP)自然都是烂熟于胸的,但语言也极大地影响了我们构建面向对象应用程序的方式.(现在的OOP已经和Alan Kay当初创造这个词时候的初衷大不相同了,他的主要思想是采用消息传递并消灭所有状态数据(他认为,系统是由一些类似于生物细胞那样的对象构成的,这些对象通过消息传递进行通信,且无需持有任何状态)--go语言) 对于Java程序员来说,当我们顺着指针或引用找到某个实例的时候,实际上是登录到了持有其状态的一块内存上,于是在那个位置上操纵数据也就成了自然

【转】这些年,我的软件性能测试

很早之前就说好好总结一下自己的职业,一直忙于一些乱七八糟的事,现在这个时间难得偷得空闲,趁着有感觉,赶紧进行敲下“这些年,我的软件性能测试”来祭奠我这IT行业的几年...... 记得第一次做性能测试项目,心情是 忐忑的,觉得,性能测试,做不好就背包滚蛋了都可能,不过当时带我做项目的老大给了我很大的信心和支撑,我在做的过程中,遇到的疑问,他都会耐心的给我以 解答或者给我一个方向,让我去前行,解决,随着一个个问题的出现和解决,自己每一天也过的感觉很充实.也是在这个项目里面,这个老大告诉我,作为性能测

广州八神软件性能测试课程优秀学员作业-第1课-抓包不求人

本文档是广州八神软件性能测试课程学员DI da'da di的第1课-抓包不求人的课后作业.感谢DI da'da di同意分享.作业质量高,有价值,分享给大家共同进步和学习. 课程讨论群:319406535 也可以查看课程的免费部分学习: http://edu.51cto.com/lecturer/index/user_id-387113.html http://www.dataguru.cn/myclassnew.php?mod=new_basicforlesson&op=basic&le

软件性能测试与可靠性测试

性能测试:1.软件性能测试包括三个目标:①发现缺陷:②性能调优:③能力检验与规划 2.软件性能的主要指标有:响应时间.系统响应时间和应用延迟时间.吞吐量.并发用户数.资源利用率 3.系统的响应时间通常是指该系统所有功能的平均响应时间或者所有功能的最大响应时间 4.对于无并发的应用系统而言,吞吐量与响应时间成严格的反比关系 5.吞吐量不能无限的增大,关键原因在于资源利用率不能无限的提高 6.资源利用率可以为性能调优提供很大帮助 7.在压力测试时,软件通常会处于性能下降曲线的哪个区间:性能轻微下降区

浅谈软件性能测试中关键指标的监控与分析

浅谈软件性能测试中关键指标的监控与分析 一.软件性能测试需要监控哪些关键指标? 软件性能测试的目的主要有以下三点: Ø  评价系统当前性能,判断系统是否满足预期的性能需求. Ø  寻找软件系统可能存在的性能问题,定位性能瓶颈并解决问题. Ø  判定软件系统的性能表现,预见系统负载压力承受力,在应用部署之前,评估系统性能. 而对于用户来说,则最关注的是当前系统: Ø  是否满足上线性能要求? Ø  系统极限承载如何? Ø  系统稳定性如何? 因此,针对以上性能测试的目的以及用户的关注点,要达到以上

关于举办“高级信息安全技术专业人员培训班”和“高级软件性能测试工程师培训班”

大家好!       我中心于2016年2月27日举办“高级信息安全技术专业人员培训班”和2016年3月19日举办“高级软件性能测试工程师培训班” 如有疑问请您及时与我们联系, 感谢您的支持! 如有软件测评服务业务合作,如软件登记测试,确认测试,验收测试,等保测评,渗透测试,风险评估等项目服务,期待您的合作,再次感谢您的支持!           如有培训需求,可以联系我们,劳烦您转发给您相关可能有需求的培训同事,多谢. 祝您工作顺利,健康快乐每一天! 中国赛宝实验室软件评测中心 工业和信息化部