《应用程序性能测试的艺术(第2版)》—第1章 1.1节从终端用户角度看性能

第1章 为什么要做性能测试
应用程序性能测试的艺术(第2版)
快过极速子弹!

——动作漫画,超人
欢迎开启性能测试之旅!在开始探索性能测试的基础知识之前,我想在第1章里花点时间探讨一下什么是我们认为的好性能、什么是差性能以及为什么性能测试是整个软件生命周期(Software Development Lifecycle,SDLC)当中至关重要的一个环节。性能糟糕的应用通常无法为企业带来期望的收益。这些应用纯粹是耗费时间和资金,无法获得客户的认可,因此并不能有效转化为企业资产。如果一个应用/软件无法保证高性能、高可用地提供预期服务,那么无论是什么原因,都会给参与项目的团队成员,包括架构、设计、编码、测试(如果有的话)带来负面影响。

对比在业界发展相当成熟且广为人知的功能测试或者运行验收测试(Operational Acceptance Testing,OAT),性能测试未能引起足够的重视。时至今日,很多公司依然忽视性能测试的重要性,常常发布一些性能状况尚不明朗的应用,而这些应用通常上线不久就会因为性能或者扩展性问题给公司带来困扰。尽管很多性能咨询专家(包括我在内)一直致力于性能测试的推广,也有不少业界高曝光度的系统因为性能问题而饱受诟病,但大家对于性能测试的观念却依然没有明显改观。

1.1 从终端用户角度看性能
什么样的应用可以认为是运行性能很好呢?根据我和客户、性能团队多年共事的经验,性能其实是一种感受。当一个终端用户使用一个性能很好的应用时,他通常感受不到由于延迟带来的不畅或困扰。性能说到底是一个很主观的东西,是一种因人而异的感受。一个性能很好的应用不会让用户在完成一些操作时分散注意力,就好比当你登录某个网站时,一个性能很好的网站不会出现一个空白页让你等很久。

这听起来好像很简单,或许你对于什么叫好的性能也有自己的见解。但是无论你如何定义它,很多应用甚至连最基本的性能期望都不能满足(比如当系统处在负载高峰的时候)。当然,当我谈到应用性能状况的时候,其实是在指向应用各个组件的综合性能。毕竟应用的各个组件共同决定了应用性能。宏观上来看,一个应用的性能可以从客户端、应用软件和承载应用的硬件基础这几个方面来定义。硬件基础又包括运行软件的服务器和用于应用组件之间相互通信的网络基础设施。现在,随着分布式应用架构的广泛使用,应用所依赖的第三方服务也制约着应用的整体性能。说到底,上面提到的任何一个方面出了问题,应用的整体性能都会受到影响。也许你会认为,我们只要通过观察应用各个组件在负载或者压力模式下的表现,发现问题就解决问题,兵来将挡、水来土掩就一定能保证应用的整体性能。而事实却表明使用这种方式往往是“杯水车薪,悔之晚矣”,你所做的只不过是在头痛医头、脚痛医脚,对于造成性能问题的根本原因已经很难定位。

1.1.1 性能度量
性能应该如何度量呢?在前面,我们讨论了终端用户感受,但是要精确地进行性能度量,就必须引入一些关键性能指标(Key Performance Indicator,KPI)。这些指标属于非功能需求的一部分,关于非功能需求我们会在第3章详细讨论。我们暂时将指标分为两类:面向服务的和面向效率的。

面向服务的指标包括可用性和响应时间,这两个指标用来衡量一个应用是否能够很好地为终端用户提供服务。面向效率的指标包括吞吐率和资源利用率,它们用来衡量一个应用是否能够有效地利用系统资源。我们可以进一步为这些指标做以下定义。

可用性
通常采用应用对于终端用户的可用时长来衡量。高可用至关重要,因为很多应用如果发生不可用的情形,哪怕是很短的时间都会给业务带来不可估量的损失。换成性能术语可以这样描述:当一个应用无法响应或者可以响应但是响应时间已经增长到用户无法接受的程度,以至于终端用户完全不能正常使用该应用时,我们就认为这个应用此时不可用。

响应时间
应用响应一个用户请求所消耗的时间。在性能测试里,响应时间一般都指系统响应时间,即从用户发起请求到应用响应完全到达用户客户端所消耗的时间。响应可以是同步的(阻塞式)也可以是异步的,一个异步响应不会在返回结果前阻塞用户与应用的交互。关于这一点,我们会在后面的几个章节做更多讨论。

吞吐率
某种面向应用的事件的发生速率。比如在单位时间内一个网页的点击次数。

资源利用率
对某种资源理论容量的使用百分比。比如一个应用消耗了多少的网络带宽,又比如当有1000个并发用户的时候,一个Web服务器集群所消耗的内存。

把上述这些指标结合起来,我们就可以对应用的性能及其对资源的消耗有一个比较准确的认识。

1.1.2 性能标准
千万别以为我会在这一节给出一个普适的行业性能标准,这世上并不存在一个权威指南告诉我们什么是好的性能、什么是差的性能。总有一些人试图为性能制定一些量化的标准,特别是针对基于浏览器的应用。你也许听说过一个叫“最小页面刷新时间”的东西。我记得最初有人将他定义在20秒,没过多久就变成了8秒,而现在这个时间是2秒或者更快。当然,对于用户(业务)来说,最好是“瞬间响应”(就像老鹰乐队唱的那样:“生活就像快车道,所有一切刹那至”),然而这种一致性能的想法很有可能会一直是一个幻想。

20世纪80年代后期,马丁等人试图绘制终端用户生产效率和响应时间之间的关系图表。这些初始研究大多是基于古老的绿屏文字类应用(比如Turbo C)做的,但是研究的结论时至今日还是非常有参考意义的。

超过15秒
这么长的响应时间排除了会话式交互的可能性。也许针对某些类型的应用,有些终端用户愿意等上15秒才看到一个简单查询的反馈。但对于类似呼叫中心的接线员,或者那些期货交易员来说,15秒的响应时间是完全无法接受的。如果应用的交互中会出现这么长时间的延迟,我们应该考虑将系统设计成异步的,允许用户提交查询后可以切换到其他界面操作,稍后再来查看之前查询的返回结果。

超过4秒
超过4秒的延迟对于会话式的交互而言会显得太长,用户不得不将之前获得的信息暂存在短期记忆里(用户的大脑,而非电脑!)。这样的延迟通常会不利于用户解决问题,也会让数据录入变得让人苦恼。然而,在用户提交一个较为复杂的事务时,4~15秒的延迟时间还是可以接受的。

2~4秒
超过2秒的延迟不利于进行需要注意力高度集中的连续性操作。当用户全神贯注地在完成手头的一个任务时,2~4秒的延迟时间对他而言就显得相当漫长了。当然,在完成一些阶段性的简单操作的时候,这类延时还是可以接受的。比如对消费者来说,在他们输入地址和信用卡以后等上2~4秒钟或许是可以接受的,但绝不是在开始比较商品属性的早期行为中。

小于2秒
如果用户需要在多个响应中记住若干的信息,那么响应时间必须足够短。用户要记的信息越详细,我们越需要把响应时间控制在2秒以下。因此,对于一些复杂的操作,比如浏览不同维度的多个商品,2秒是一个非常关键的响应时间上限。

小于1秒
一些思维密集型的工作(比如写作),会要求应用具备非常短的响应时间,特别是如果这个应用有着非常丰富图形化的界面,那么这个要求会更高。因为只有这样才能让用户长时间地集中注意力。设想一个艺术家在界面上拖动一幅图像到另一个位置,他需要得到立即响应才不至于打断他的创造性思路。

小于0.1秒
当我们敲击键盘(看到字母在屏幕上显示)或者用光标点击屏幕上的一个物体时,我们期望的响应是实时的:动作发生后0.1秒内响应。很多电脑游戏都要求极速的交互响应。

回顾上面这几个响应时间,最关键的一个界限似乎是2秒。超过2秒的响应时间一定会对用户的生产效率产生影响,所以如今8秒的网页刷新时间标准就显得非常不理想了。

1.1.3 万维网与电子商务
如今大家对应用程序高速运行的要求越来越高(最好都能装上“曲速引擎”),万维网(World Wide Web)的爆炸性发展在这个过程中扮演的角色不容忽视。很多(也许应该说所有?)电子商务公司现如今都在互联网这个能够想到的最激烈的竞争环境下争夺自己的利益地盘。如果你的网站性能没让用户满意,他的下一次点击就会是“你的竞争对手.com”了。

电子商务应用面对需求骤升的高峰时,往往力不从心。这一点,很多大型网上零售商店深有体会。

时间: 2024-09-20 08:15:07

《应用程序性能测试的艺术(第2版)》—第1章 1.1节从终端用户角度看性能的相关文章

《全栈性能测试修炼宝典 JMeter实战》—第1章 1.5节从招聘要求看岗位价值

1.5 从招聘要求看岗位价值 下面我们看一下性能测试及性能架构师/专家的招聘要求就可以知道职位对技术的要求范围与层次. 1.金融行业 案例一 上海 某金融平台性能安全工程师 任职资格: 熟悉数据库编程,能熟练操作至少一种数据库,如Oracle或MySQL: 精通LoadRunner.Jmeter等主流性能测试工具之一,熟练编写相应测试脚本,测试过复杂应用者尤佳: 深入了解HTTP.TCP/IP等网络协议,熟悉J2EE Web系统,熟练掌握多种中间件(Tomcat.Apache.Nginx.MQ等

《应用程序性能测试的艺术(第2版)》目录—导读

作者简介应用程序性能测试的艺术(第2版)Ian Molyneaux,EMEA地区的性能领域专家,是Intechnica公司总裁.Intechnica公司是一家总部位于英国曼切斯特的软件咨询公司.他精通企业级应用性能保证,在管理,流程和工具方面都颇有建树.本书特色本书作者具有15年的性能测试经验.本书详尽阐述了不完善的性能测试策略会带来哪些问题.本书也提供了一种健壮的,结构化的方法用以保证你的应用能够性能表现优异,特别是在需求增长的时候也能够做到可扩展. 图书评论应用程序性能测试的艺术(第2版)时

《应用程序性能测试的艺术(第2版)》—第2章 2.1节性能测试工具架构

第2章 选择合适的性能测试工具应用程序性能测试的艺术(第2版)生活中,人们只需要两种工具:让设备运转起来的WD-40(一种润滑剂)和使其停滞的冷缠胶. --G. Weilacher用于性能测试的自动化工具在过去20年的大部分时间里都以某种形式存在.在这期间,应用技术发生了巨大的改变,从胖客户端到Web架构,到如今越来越多的应用以无线的方式来提供服务.相应的,自动化工具所需提供的功能也越来越面向Web和无线开发,而不再是支持传统的二层应用架构中常用的技术.应用技术的集中化对于性能测试人员来说是一件

《应用程序性能测试的艺术(第2版)》—第1章 1.3节小结

1.3 小结在这一章,我们探讨了什么是应用性能,什么是好的性能.差的性能.我们还探讨了缺乏有效性能测试会导致应用性能糟糕的一些常见原因.这些原因归根结底可以概括成一句话: 在软件生命周期中的设计.测试阶段,没有给予性能应有的重视. 在下一章我们会讨论为什么自动化对于有效性能测试如此重要以及如何根据需求来选择最为合适的性能测试工具. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《精通软件性能测试与LoadRunner最佳实战》—第1章1.4节软件测试的分类

1.4 软件测试的分类 精通软件性能测试与LoadRunner最佳实战 软件测试按照测试阶段.是否运行程序.是否查看源代码以及其他方式,可以用图1-1所示来描述软件测试的各种分类. 黑盒测试.白盒测试与灰盒测试 1.黑盒测试 黑盒测试(Black-box Testing)是软件测试的主要方法之一,也可以称为功能测试.数据驱动测试或基于规格说明的测试.测试者不了解程序的内部情况,只知道程序的输入.输出和系统的功能,这是从用户的角度对程序进行的测试.软件的黑盒测试意味着测试要在软件的接口处进行.这种

《全栈性能测试修炼宝典 JMeter实战》—第2章 2.4节不同角色看性能

2.4 不同角色看性能 图2-5是当前典型的系统性能涉及的方面,需要多个工种(有架构师.开发.系统管理员.DBA.测试等)一起协调才能完成工作,每个环节都可能是瓶颈,造成阻塞.相对于目前国内的IT软件部门环境,因为需要协调多部门,所以性能测试工作人员必须是一个复合型人才,对于各工作的知识有所了解也要求有一定的项目协调能力,来引导大家同心协力地完成此项复合任务,靠单人是不太可能完成如此具有挑战的工作. 技术部门一般有以下几种常见的角色,开发.测试.架构师.运维人员-(系统管理员.DBA)等.下面我

《全栈性能测试修炼宝典 JMeter实战》—第2章 2.1节性能测试初体验

第2章 性能测试初体验 全栈性能测试修炼宝典 JMeter实战 从本章你可以学到: 性能测试的价值 性能测试流程 性能测试成功与失败要素 不同角色看性能 性能测试工具选择 性能测试相关术语 性能测试通过标准 性能测试趋势 性能测试是一项综合性的工作,致力于暴露性能问题,评估系统性能趋势.性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况,找出潜在的性能问题,分析并解决:找出系统性能变化趋势,为后续的扩展提供参考.测试显然不是录制脚本那么简单的事情(而且现在很多系统还无法录

《应用程序性能测试的艺术(第2版)》—第2章 2.3节性能测试工具集:概念验证

2.3 性能测试工具集:概念验证对于候选的性能测试工具,你需要对它们一一试用以验证工具的可行性,只有这样才能确保你最终选择的工具集能够满足你的需求.在验证过程中至少选择录制两个测试用例:一个只读用例(比如一个返回一条或者多条记录的搜索操作)和一个涉及插入和更新你的应用数据库的写用例.这样你就能验证录制下来的测试用例是否能够正确回放.如果你的应用是只读的,你也要检查脚本回放日志来确保回放过程中没有任何错误. 概念验证完成以下目标. 为验证性能测试工具是否适合目标应用提供了一次技术评估的机会技术兼容

《应用程序性能测试的艺术(第2版)》—第1章 1.2节为什么性能问题如此常见

1.2 为什么性能问题如此常见上文为什么是好的性能.什么是差的性能做了一个基本的定义.应用的性能孰优孰劣,似乎也很好判断,那为什么还有那么多的应用无法满足高性能这样一个关键需求呢?下文给出了一些常见的原因. 1.2.1 IT商业价值曲线性能问题之所以让人头疼,有一个很重要的原因就是它通常在应用生命周期的后期才会凸显出来,越晚发现问题,就要花费越多的精力去解决问题.图1-1所示的IT商业价值曲线很好地描述了这个观点. 图1-1所示中,实线(预期)表示在经过一段时间的IT投入(应用开发过程)后,应用