详情
本书介绍性能测试的完整生命周期，配合最佳实践，帮助读者了解应用程序性能测试的方法、目标以及如何进行。本书配有真实的示例和实用的建议，帮助读者认识不完整的测试策略的陷阱所在，并且给出一个健壮的、结构完备的方案，帮助读者很好地测试应用性能。
书名：应用程序性能测试的艺术（第2版）
ISBN：978-7-115-41454-0
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [新西兰] Ian Molyneaux
译 樊 非
责任编辑 陈冀康
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2015 by O’Reilly Media, Inc.
Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Posts & Telecom Press, 2016. Authorized translation of the English edition, 2015 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书中文简体版由O’Reilly Media, Inc.授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
性能测试通过自动化的测试工具模拟多种条件来对系统的各项性能指标进行测试，在软件的质量保证中起着重要的作用。
本书基于作者十多年的项目经验编写而成，全书共10章，分别介绍了为什么要做性能测试、如何选择合适的性能测试工具、有效性能测试的基础、性能测试流程、性能测试结果解读、性能测试与无线客户端、终端用户体验监控与性能、在性能测试中集成外部监控、应用技术及其对性能测试的影响以及作者对未来性能测试的思考。
作者结合丰富的实践经验，介绍了有关性能测试的相关知识，适合软件测试人员及想要学习性能测试的读者阅读参考。
当我在2009年1月出版本书第1版的时候，我无论如何也没有想到它会在性能测试社区受到如此欢迎。我收到了来自世界各地的读者来信，感谢我写了这本书，对此我深感意外但同时也倍受鼓舞。这本书的主要目标读者是那些希望成为性能测试专家的技术人员。同时这本书也适合那些从事和性能测试相关工作的IT专业人员，他们可能是或大或小的互联网公司成员，如果他们对工作中的系统性能负有直接的责任，那么这本书对他们而言就再合适不过了。
我认为就算到现在，2009年出版的本书第1版中的大多数原理和概念依然有效。但同时IT行业从2009年以来也发生了很多变化，软件应用的部署模式和测试方法都随之发生变化。以云计算为例，2009年的时候，它还是一朵“浮云”，业界尚没有很成熟的云计算服务商。但是到了2014年，云似乎成了Web部署的标配模式。无论是开发环境、测试环境还是生产环境，云计算都能支持实时的启动和停止。在第2版中的各个章节我都根据需要加入了云计算相关的内容。
如今无线设备百花齐放，至2014年年底，无线设备带来的网络流量将会成为所有互联网流量中占比最大的一部分。我在本书第1版简单提到了无线，现在在第2版中我单独开辟了1章来介绍无线设备的性能测试。终端用户监控（End-User Monitoring，EUM）在过去的5年时间里也成熟起来。它和性能测试在某些方面有着交集，因此我在第2版中新添了两章来专门讨论终端用户监控。终端用户监控所提供的数据对于我们理解真实世界的软件应用性能非常重要。
在第2版中，我对几乎所有的原有章节和附录部分都做了修订和扩充。新加入了那些我认为会对性能测试人员有帮助的最新材料，不管你是测试新手还是领域专家都会有所帮助。现如今，业务的兴起还是消亡还是会受到关键软件／应用性能的影响。但还是有很多应用在发布之前没有经过足够的扩展性测试和性能测试，这真让人遗憾。需要再次强调，有效的性能测试能够帮助我们尽早地发现和定位性能瓶颈，从而可以快速解决这些瓶颈，只有这样我们才能放心地发布应用。本书第2版中使用了很多相关的参考资料来强调性能测试在市场中的持续需求。但是这依然不是一本能够教你如何对某某技术进行调优的著作。除非技术本身对于性能测试的方法有很大影响，我尽量避免了深入特定的技术细节。这本书的目的在于结合我15年多的性能测试项目管理经验，提供一份常识性的关于如何进行性能测试计划、执行和结果解读的指南。
同样，我也不会介绍业界一些特定的性能测试方法论（说实话我认为它并不存在）。应用性能测试有其独有的原则并且还没有形成一套自己的行业标准。我希望本书依然能够成为正规性能测试流程的标杆。
我个人的工作在2009年发生了变化，虽然我仍然在一家对应用性能有激情的公司工作，但是这本书依然是独立于工具和具体的工具供应商的。在本书中描述的流程和策略对于使用任何专业的性能解决方案都是适用的。
希望你会喜欢这本书。
——Ian Molyneaux，2014
这本书是针对那些希望学习和拓展自己在应用性能测试方面知识的技术人员的基础读物，无论是软件测试人员还是完全的新人都可以阅读。
我认为性能测试和其他软件原则一样，更像一门艺术。在没有一致的性能测试方法和合适的自动化工具的情况下很难开展。一个人需要很多年的经验才能成为一位专业的性能测试工程师，但是有一些基本技能是可以通过恰当的教导和合适的指南在短时间内学会的。
这本书假设读者具备一些软件测试知识，但不一定要和性能测试相关。有效的性能测试需要的一个前提条件就是使用自动化技术。因此，为了能从本书中获取更多的有用信息，读者最好能够对一些自动化性能测试工具有所了解。
下面这些参考资料可以帮助你更好地学习。
基于我工作中的一些笔记（始终没有成为完善的白皮书）和十多年的项目经验，本书强调了为何在发布应用之前的性能测试至关重要。本书将引导你学习有效性能测试策略的若干步骤。
下面是对本书各个章节和附录的一些简单介绍。
第1章：为什么要做性能测试，讨论了应用性能测试背后的逻辑并且从历史角度来探讨性能测试在IT领域的发展。
第2章：选择合适的性能测试工具，介绍了自动化的重要性和如何选择合适的性能测试工具。
第3章：有效性能测试的基础，介绍了有效性能测试的基础概念并且阐述了其重要性。
第4章：性能测试流程，推荐了一种最佳实践方法。流程是基于第3章的理论概念而来的，它将需求和应用性能测试的模型映射起来。这一章还使用了一些案例来更好地阐述最佳实践方法。
第5章：性能测试结果解读，介绍了有效的根源分析方法。这一章介绍了典型的性能测试产出以及如何解读性能测试结果。
第6章：性能测试与无线客户端，介绍了无线设备的性能知识以及无线客户端对性能测试造成的独特挑战。
第7章：终端用户体验监控与性能，介绍了终端用户体验监控和性能测试之间的互补关系。
第8章：在性能测试中集成外部监控，介绍了如何将终端用户体验监控和性能测试进行集成。
第9章：应用技术及其对性能测试的影响，介绍了特定的软件技术栈对于性能测试的影响。虽然本书中的测试方法是通用的，但一些特定的技术对于如何实际开展性能测试会有一定影响。
第10章：总结，这在本书第1版中是没有的。我认为用我对未来性能测试和终端用户体验监控发展趋势的思考，作为全书的结束是个不错的主意。
附录A，用例定义样例，展示了如何在性能测试中准备测试用例。
附录B，概念验证和性能测试快速指南，重复了本书中的性能测试实践方法。
附录C，性能测试工具供应商，列举了性能测试和性能分析中需要使用到的自动化技术供应商。虽然我在写书的时候列举了当时尽可能多的工具选择，但这个列表并不意味着我对某个工具有偏好或者推荐。
附录D，监控模板样例：硬件关键性能指标，提供了在进行性能测试的时候需要对服务器或者网络进行监控的时候可以使用的指标模板。
附录E，项目计划样例，提供了一份微软Project格式的典型性能测试计划。
本书中使用到了以下术语。
应用性能管理（Application Performance Monitoring），提供深入应用层面的性能分析工具。
APM即服务（APM as a Service）（云计算）。
部署软件应用所需要的服务器网络基础设施的一种通用描述方法。
亚马逊Web服务（Amazon Web Services）。
内容发布网络（Content Delivery Network），根据用户地理位置就近提供静态或者可缓存动态内容的远程内容缓存服务。
持续集成（Continuous Integration），在软件工程领域，是指在同一天内将开发人员的代码进行合并的操作。这最初是在极限编程（Extreme Programming，XP）里提出的。主要的目的在于减少集成问题，在XP中也称为集成地狱（引自Wikipedia）。
一种软件开发模式，强调软件开发人员和IT运维人员之间的沟通、协作和集成。DevOps是应对软件开发和IT运维直接的相互依赖而产生的，目的在于帮助企业迅速发布软件产品和服务。
终端用户监控（End-user Monitoring），是一种对终端用户响应时间和行为进行离散监控的通用说法。
设施即服务，Infrastructure as a Service（云计算）。
独立计算架构（Independent Computing Architecture）是一种Citrix私有协议。
IT基础架构库（Information Technology Infrastructure Library）。
IT资产管理（Information Technology Portfolio Management）。
IT服务管理（Information Technology Service Management）。
Java消息服务（Java Message Service），前身是Java Message Queue。
自动化性能测试方案中用来模拟真实终端用户操作的PC或者服务器。
IBM的面向消息的中间件。
性能测试中用以控制脚本执行速度的延迟。
平台即服务（Platform as a Service）（云计算）。
概念验证（Proof of concept），产品售前周期中的一个验证性项目。它可以帮助客户将建议的软件方案和自身的应用条件进行对比，提供后续参考。通常也叫做Proof of value。
真实用户监控（Real-user monitoring）是一种被动模式的终端用户体验监控。
软件即服务（Software as a Service）（云计算）。
面向服务架构（Service-oriented architecture）。
被测系统（System under test）。
思考时间，和Pacing类似，指的是在脚本中模拟真实用户和软件之间的交互延迟。更多地被用来提供更真实的请求排队模型而不是用来控制吞吐率。
计时单位，通常是交易流程中的一个组件，是用户关心的一个独立的用户操作，比如登录或者添加到购物车。
事务，有着明确开始和结束的应用功能区块。比如，登录或者搜索。它经常和用例这个概念混用。
用户体验监控（User experience monitoring）是对终端用户体验监控的一个通用说法，经常是指在生产环境的监控。
用以表示典型应用操作的一组终端用户事务。典型的事务可能是登录、打开搜索对话框、输入查询条件、单击搜索按钮、退出。事务是自动化性能测试的基础元素。
Windows操作系统实例（Windows Operating System Instance）是机器或者工作站上运行的Windows操作系统。
感谢O’Reilly公司的每一个人，没有你们的帮助我这样一个外行作者是不可能完成这本书的。感谢我的编辑，Andy Oram；助理编辑，Isabel Kunkle；编辑主任，Marlowe Shaeffer；还有帮助我制作图表和美工的Robert Romano；感谢Jacquelynn McIlvaine和Karen Tripp帮助我开创博客，并且提供了最初的编写材料；感谢Karen Tripp和Keith Fahlgren帮我建立DocBook库并且回答我的各种问题。
对于更新的第2版，我要感谢我的助理编辑Allyson MacDonald，以及开发编辑Brian Anderson，他们给了我很多无价的反馈和指导。
同时我也要感谢我的前任职公司以及现在的伙伴，Compuware公司，感谢他们允许我使用他们公司的一些性能方案的截图来更好地阐述本书中的观点。我也感谢下面这些专家，他们给了我很多建议和帮助：Peter Cole，前Greenhat公司的总裁和CTO，他帮我更好地理解和扩展了SOA的性能测试模型；Quotium公司的Adam Brown；Scott Barber，软件测试协会的创始人和主席；前SUN公司的David Collier-Brown；Matt St. Onge；Gerrad咨询公司的Paul Gerrard；前Compuware专家服务部门的Francois MacDonald；以及前Compuware法国公司、现在AppDynamics公司的Alexandre Mechain。
我还要特别感谢我最尊敬的同事Larry Haig，他对本书中关于终端用户监控的章节，以及对性能测试和终端用户监控的集成章节提供了无价的帮助和指引。
最后我还要感谢过去十几年中和我共事过的软件测试人员和顾问。因为你们的帮助和建议，才会有这本书的诞生！
快过极速子弹！
——动作漫画，超人
欢迎开启性能测试之旅！在开始探索性能测试的基础知识之前，我想在第1章里花点时间探讨一下什么是我们认为的好性能、什么是差性能以及为什么性能测试是整个软件生命周期（Software Development Lifecycle，SDLC）当中至关重要的一个环节。性能糟糕的应用通常无法为企业带来期望的收益。这些应用纯粹是耗费时间和资金，无法获得客户的认可，因此并不能有效转化为企业资产。如果一个应用/软件无法保证高性能、高可用地提供预期服务，那么无论是什么原因，都会给参与项目的团队成员，包括架构、设计、编码、测试（如果有的话）带来负面影响。
对比在业界发展相当成熟且广为人知的功能测试或者运行验收测试（Operational Acceptance Testing，OAT），性能测试未能引起足够的重视。时至今日，很多公司依然忽视性能测试的重要性，常常发布一些性能状况尚不明朗的应用，而这些应用通常上线不久就会因为性能或者扩展性问题给公司带来困扰。尽管很多性能咨询专家（包括我在内）一直致力于性能测试的推广，也有不少业界高曝光度的系统因为性能问题而饱受诟病，但大家对于性能测试的观念却依然没有明显改观。
什么样的应用可以认为是运行性能很好呢？根据我和客户、性能团队多年共事的经验，性能其实是一种感受。当一个终端用户使用一个性能很好的应用时，他通常感受不到由于延迟带来的不畅或困扰。性能说到底是一个很主观的东西，是一种因人而异的感受。一个性能很好的应用不会让用户在完成一些操作时分散注意力，就好比当你登录某个网站时，一个性能很好的网站不会出现一个空白页让你等很久。
这听起来好像很简单，或许你对于什么叫好的性能也有自己的见解。但是无论你如何定义它，很多应用甚至连最基本的性能期望都不能满足（比如当系统处在负载高峰的时候）。当然，当我谈到应用性能状况的时候，其实是在指向应用各个组件的综合性能。毕竟应用的各个组件共同决定了应用性能。宏观上来看，一个应用的性能可以从客户端、应用软件和承载应用的硬件基础这几个方面来定义。硬件基础又包括运行软件的服务器和用于应用组件之间相互通信的网络基础设施。现在，随着分布式应用架构的广泛使用，应用所依赖的第三方服务也制约着应用的整体性能。说到底，上面提到的任何一个方面出了问题，应用的整体性能都会受到影响。也许你会认为，我们只要通过观察应用各个组件在负载或者压力模式下的表现，发现问题就解决问题，兵来将挡、水来土掩就一定能保证应用的整体性能。而事实却表明使用这种方式往往是“杯水车薪，悔之晚矣”，你所做的只不过是在头痛医头、脚痛医脚，对于造成性能问题的根本原因已经很难定位。
性能应该如何度量呢？在前面，我们讨论了终端用户感受，但是要精确地进行性能度量，就必须引入一些关键性能指标（Key Performance Indicator，KPI）。这些指标属于非功能需求的一部分，关于非功能需求我们会在第3章详细讨论。我们暂时将指标分为两类：面向服务的和面向效率的。
面向服务的指标包括可用性和响应时间，这两个指标用来衡量一个应用是否能够很好地为终端用户提供服务。面向效率的指标包括吞吐率和资源利用率，它们用来衡量一个应用是否能够有效地利用系统资源。我们可以进一步为这些指标做以下定义。
通常采用应用对于终端用户的可用时长来衡量。高可用至关重要，因为很多应用如果发生不可用的情形，哪怕是很短的时间都会给业务带来不可估量的损失。换成性能术语可以这样描述：当一个应用无法响应或者可以响应但是响应时间已经增长到用户无法接受的程度，以至于终端用户完全不能正常使用该应用时，我们就认为这个应用此时不可用。
应用响应一个用户请求所消耗的时间。在性能测试里，响应时间一般都指系统响应时间，即从用户发起请求到应用响应完全到达用户客户端所消耗的时间。响应可以是同步的（阻塞式）也可以是异步的，一个异步响应不会在返回结果前阻塞用户与应用的交互。关于这一点，我们会在后面的几个章节做更多讨论。
某种面向应用的事件的发生速率。比如在单位时间内一个网页的点击次数。
对某种资源理论容量的使用百分比。比如一个应用消耗了多少的网络带宽，又比如当有1000个并发用户的时候，一个Web服务器集群所消耗的内存。
把上述这些指标结合起来，我们就可以对应用的性能及其对资源的消耗有一个比较准确的认识。
千万别以为我会在这一节给出一个普适的行业性能标准，这世上并不存在一个权威指南告诉我们什么是好的性能、什么是差的性能。总有一些人试图为性能制定一些量化的标准，特别是针对基于浏览器的应用。你也许听说过一个叫“最小页面刷新时间”的东西。我记得最初有人将他定义在20秒，没过多久就变成了8秒，而现在这个时间是2秒或者更快。当然，对于用户（业务）来说，最好是“瞬间响应”（就像老鹰乐队唱的那样：“生活就像快车道，所有一切刹那至”），然而这种一致性能的想法很有可能会一直是一个幻想。
20世纪80年代后期，马丁等人试图绘制终端用户生产效率和响应时间之间的关系图表。这些初始研究大多是基于古老的绿屏文字类应用（比如Turbo C）做的，但是研究的结论时至今日还是非常有参考意义的。
这么长的响应时间排除了会话式交互的可能性。也许针对某些类型的应用，有些终端用户愿意等上15秒才看到一个简单查询的反馈。但对于类似呼叫中心的接线员，或者那些期货交易员来说，15秒的响应时间是完全无法接受的。如果应用的交互中会出现这么长时间的延迟，我们应该考虑将系统设计成异步的，允许用户提交查询后可以切换到其他界面操作，稍后再来查看之前查询的返回结果。
超过4秒的延迟对于会话式的交互而言会显得太长，用户不得不将之前获得的信息暂存在短期记忆里（用户的大脑，而非电脑！）。这样的延迟通常会不利于用户解决问题，也会让数据录入变得让人苦恼。然而，在用户提交一个较为复杂的事务时，4～15秒的延迟时间还是可以接受的。
超过2秒的延迟不利于进行需要注意力高度集中的连续性操作。当用户全神贯注地在完成手头的一个任务时，2～4秒的延迟时间对他而言就显得相当漫长了。当然，在完成一些阶段性的简单操作的时候，这类延时还是可以接受的。比如对消费者来说，在他们输入地址和信用卡以后等上2～4秒钟或许是可以接受的，但绝不是在开始比较商品属性的早期行为中。
如果用户需要在多个响应中记住若干的信息，那么响应时间必须足够短。用户要记的信息越详细，我们越需要把响应时间控制在2秒以下。因此，对于一些复杂的操作，比如浏览不同维度的多个商品，2秒是一个非常关键的响应时间上限。
一些思维密集型的工作（比如写作），会要求应用具备非常短的响应时间，特别是如果这个应用有着非常丰富图形化的界面，那么这个要求会更高。因为只有这样才能让用户长时间地集中注意力。设想一个艺术家在界面上拖动一幅图像到另一个位置，他需要得到立即响应才不至于打断他的创造性思路。
当我们敲击键盘（看到字母在屏幕上显示）或者用光标点击屏幕上的一个物体时，我们期望的响应是实时的：动作发生后0.1秒内响应。很多电脑游戏都要求极速的交互响应。
回顾上面这几个响应时间，最关键的一个界限似乎是2秒。超过2秒的响应时间一定会对用户的生产效率产生影响，所以如今8秒的网页刷新时间标准就显得非常不理想了。
如今大家对应用程序高速运行的要求越来越高（最好都能装上“曲速引擎”），万维网（World Wide Web）的爆炸性发展在这个过程中扮演的角色不容忽视。很多（也许应该说所有？）电子商务公司现如今都在互联网这个能够想到的最激烈的竞争环境下争夺自己的利益地盘。如果你的网站性能没让用户满意，他的下一次点击就会是“你的竞争对手.com”了。
电子商务应用面对需求骤升的高峰时，往往力不从心。这一点，很多大型网上零售商店深有体会。
上文为什么是好的性能、什么是差的性能做了一个基本的定义。应用的性能孰优孰劣，似乎也很好判断，那为什么还有那么多的应用无法满足高性能这样一个关键需求呢？下文给出了一些常见的原因。
性能问题之所以让人头疼，有一个很重要的原因就是它通常在应用生命周期的后期才会凸显出来，越晚发现问题，就要花费越多的精力去解决问题。图1-1所示的IT商业价值曲线很好地描述了这个观点。
图1-1 IT商业价值曲线
图1-1所示中，实线（预期）表示在经过一段时间的IT投入（应用开发过程）后，应用按期发布成功，上线之后运行良好，几乎没有任何性能问题，并立即开始带来营收（黑色方块）。
图1-1所示中，虚线（实际）描绘了在现实世界经常发生的真实情况：开发延迟、发布延期（虚线方块）。应用发布上线之后，为了应对层出不穷的线上性能问题，大量的时间和金钱被消耗。最终开发出来的应用不能为企业带来预期的收益，这对谁都不是一个好消息。
类似这样的问题，在公司董事执行层得到越来越多的重视。很多公司都引入了IT服务管理（Information Technology Service Management，ITSM）和IT资产管理（Information Technology Portfolio Management，ITPM），希望由此走上拥抱IT基础架构库（Information Technology Infrastructure Library，ITIL）这个行业标准的道路。在当今很多公司里，IT部门再也不是一个“独立王国”，可以享受不受限制的资金和资源投入。它也成为公司众多部门当中的一个（重要的）业务单元，同样需要在一定的预算控制下运作。
图1-2所示是弗雷斯特研究公司在2006年针对一次应用部署的产品中性能缺陷的修复率监控得到的数据。在本次再版中，我本想用一些更新的数据来代替这张图，但是很遗憾，这些数据从2009年以来似乎并没有发生太大变化。
图1-2 弗雷斯特研究公司关于性能缺陷的研究
图1-2中描述了3个性能测试成熟度等级。第一级称为“救火式”，也就是说在应用正式发布之前几乎没有任何性能测试，因此基本上所有的性能问题都需要在线上发现并解决。这是最低效的一种方式，但让人诧异的是，这种做法在业界还相当普遍。采用救火式对待应用性能的公司面临着巨大的风险。
第二级称为“性能验证（或者叫检验）”。采用这种模式的公司在对待应用性能时，会做一些性能测试，但是这通常只会发生在应用生命周期的靠后阶段；因此，仍然会有相当一部分性能缺陷会遗漏到线上（30%）。这是目前大多数公司采用的方式。
最后一级称为“性能驱动”。这意味着在应用生命周期的每一个阶段，性能都会被纳入考虑。采用这种方式的公司，通常只会有很小一部分性能缺陷遗漏到线上（5%）。这才是所有公司应该努力采用的一种性能测试模式。
回到关于导致性能问题的常见原因的讨论上来：如果在应用设计阶段没有充分考虑性能，麻烦会接踵而至。“性能驱动设计”本身对于应用性能就是一个很好的保证，或者至少在出现意料之外的性能问题时，提供了一种便捷修复的可能性。由于设计导致的性能问题如果在应用生命周期的早期阶段没有发现，那么到后期很难彻底消除，而且这种性能纠正如果不耗费巨大返工几乎是不可能的。
上文提到，有很多公司在研发过程中采用了“性能验证/检验”模式。使用这种模式，性能测试往往是在应用即将发布之前才开始的，他们几乎没有考虑性能测试本身所需要的时间，也没有考虑如果发现问题所需要的修复时间。虽然这种方式比性能“救火”要好，但这种方式的缺点也显而易见：一些非常严重的性能缺陷仍有可能被遗漏到线上；另一种情况是虽然发现了问题，但是却没有足够的时间在应用发布以前修复这些问题。
性能测试被延迟到最后一刻带来的常见场景就是为了修复临近发布才发现的性能问题，应用发布不得不一拖再拖。一个带着性能问题上线的应用在发布之后仍需要不断的投入来修复问题，最坏的情况是应用彻底下线直到问题解决。
所有这些问题都会对业务以及等着使用应用的客户信心造成极大的负面影响。所以性能测试必须尽早开始，而不是等到应用即将发布的最后一刻。
对应用容量需求或者应用的可扩展性评估不足也是导致性能问题常见的一个原因。应用的设计和预期的发布模式很容易忽视潜在的用户社区体量和地理分布。许多应用在开发和测试过程中都容易忽略下面一些问题。
如果忽视上面提到的这些问题，我们就无法真实评估应用到底需要支持多少线上并发用户。同样，应用终端用户的网络情况，比如低带宽、高延迟的广域网连接，也是容易被忽视的一个考量因素。本书第2章将会讨论关于连接性问题的更多细节。
很多公司会低估他们网站的受欢迎程度，这听起来有点奇怪，但是事实确实如此。公司在发布网站时容易忽视“追新效应”。每当有什么新奇的东西出现，人们都会对此非常好奇，然后蜂拥而至。有的时候为了发布效果，公司也会通过媒体来做一些推广，这就更加重了这种群集效应：本来预期网站在发布之后第一天会有10000的点击量，结果等着你的却是1000000的点击量，这样预期之外的压力足以将你的系统彻底击溃。
换句话说，当我们考虑性能时，我们需要考虑的是峰值流量而不是平峰流量。
重大故障：一个真实案例
几年前，英国政府决定在互联网上公开1901年的人口普查数据。这项工程浩大，需要将大量的纸质文档电子化，然后开发一个应用供用户来访问。
我本人也非常期待这个项目的实施，因为我当时正在追溯自己的家族历史，而政府即将公开的这部分数据应该可以提供很多有用的信息。当这个网站上线之后，我便马上登录使用。虽然我发现网站有点慢，但我还是能够用它进行一些简单的搜索。然后仅仅过了一天，当我再来使用这个网站时，呈现在我面前的已经是一则道歉信息，表明网站暂时不可用。这个网站在最终修复重新发布之前连续好几个星期不可用。
这是一个低估应用受欢迎程度的典型案例。大家对这个网站的关注程度远远超出了预期，因此网站的性能支撑不了如此大体量的访问点击。这并不意味着这个网站在推出之前没有做过性能测试。但这个案例至少说明，对于这样一个网站，评估的性能和容量需求太保守了。
一个好的应用必须能够支撑那些突发的需求高峰。
正如上文提到的那样，性能测试计划和实施通常还是非常不正式的。其中的原因很难考究，因为功能测试在很多年前就已经成为一门非常正式的学科。关于功能测试，行业内有许多沉淀和专家意见，甚至还有很多咨询公司专门提供测试类的咨询服务。
回到2009年看性能测试，情况却和功能测试恰恰相反，至少从参考资料的层面上说是这样。当时测试行业内几乎没有任何关于性能测试的系统性文档，所以我决定为性能测试写些东西。我们一直不缺关于如何进行应用性能调优的书籍和文档，但是阐述如何有效地进行性能测试的书籍实在是太少了。
到了2014年，我很高兴地看到情况有所改观。当我们在谷歌上搜索“性能测试”的时候，我们能够搜到大量公司，他们提供性能测试服务、工具和一些培训，当然这些公司更多的出发点还是性能测试工具。
如果不使用自动化工具，就没有办法有效开展性能测试。人肉战术（周末叫上100个心怀怨恨的员工，掐着秒表测试性能）显然不是一个好主意。首先，这种人肉测试没法复用，然后为了测试稳定性，让员工连续24小时使用/测试系统，这恐怕已经侵犯员工权利了。
还有，你如何对来自100个不同员工的响应时间数据进行关联分析呢？更别提还有那么多监控指标（网络、服务器）需要关注。如果你的应用的目标用户数小于5个，这种人肉性能测试方法或许还可行，但是如果真是这样，恐怕你现在也不需要阅读这本书了。
业界有不少非常棒的性能测试工具，而且这样的工具还会越来越多。需要进行多大规模的性能测试，很大程度上决定了你使用工具的成本。好消息是，性能测试工具市场是一个充满竞争的市场，最大的不一定是最好的。因此在选择工具之前，最好多做点功课，帮助公司IT预算负责人更好地决策。附录C的列表包含了当今业内领先的性能测试工具供应商。第2章会详细讲述如何根据需求，选择最合适的性能测试工具。
应用开发中使用到的一些技术，可能无法使用第一代，甚至第二代自动化工具来进行压测。这样的借口已经越来越勉强了，因为如今绝大多数的应用都在一定程度上Web化了。而如今大部分自动化测试方案都能够很好地支持Web技术。
Web软件开发过程中的技术栈都慢慢开始标准化了，形成了一些核心的技术。大多数自动化工具供应商都会跟随这个节奏，推出对应支持功能。在本书第9章，我会探讨一下现在（以及老旧）的应用技术如何影响了性能测试的发展。
在这一章，我们探讨了什么是应用性能，什么是好的性能、差的性能。我们还探讨了缺乏有效性能测试会导致应用性能糟糕的一些常见原因。这些原因归根结底可以概括成一句话：
在软件生命周期中的设计、测试阶段，没有给予性能应有的重视。
在下一章我们会讨论为什么自动化对于有效性能测试如此重要以及如何根据需求来选择最为合适的性能测试工具。
生活中，人们只需要两种工具：让设备运转起来的WD-40（一种润滑剂）和使其停滞的冷缠胶。
——G. Weilacher
用于性能测试的自动化工具在过去20年的大部分时间里都以某种形式存在。在这期间，应用技术发生了巨大的改变，从胖客户端到Web架构，到如今越来越多的应用以无线的方式来提供服务。相应的，自动化工具所需提供的功能也越来越面向Web和无线开发，而不再是支持传统的二层应用架构中常用的技术。应用技术的集中化对于性能测试人员来说是一件好事，因为市场上有很多自动化工具供应商都能很好地支持Web和无线技术，测试人员可以根据需要选择物美价廉的工具。同时，开源社区中也不乏一些优秀的性能测试工具。
听起来不错，但用户还是得当心：如果你的一些性能测试涉及非Web场景，那么可选的工具会迅速变少。尽管经过这么多年，自动化工具的技术魔咒依然存在。通常开源工具对于非Web场景的性能测试支持都比较弱，这就意味着性能测试的工具开销不可避免。对于非Web场景，性能测试的执行和分析并没有多大不同，关键的难点在于应用操作的录制，以及针对录制脚本的后期编辑。有些技术比如“加密”、“压缩”会给性能测试工具带来更大的麻烦，甚至我们有可能根本无法录制，只能通过手工编码或者针对性地开发一些测试组件才能满足性能测试的需要。Web应用的性能测试有时候也会遇到挑战，比如流媒体的压测、使用了客户端证书的安全机制等，针对这些场景，不是所有的性能测试工具都能满足你的需求。在最终决定使用哪个工具之前，你应该充分考虑工具的实际能力和你的压测需求，我强烈建议在购买工具之前先做一个概念验证（Proof of Concept，POC）。尽管有着诸多挑战，但是压测工具还是我们的必需选择——如果不使用工具，我们无法开展有效的性能测试。在第1章我也提到了这个观点，它也是为什么许多应用在上线之前没有进行有效性能测试的原因之一。如果要开展可靠的、可重复的性能测试，我们必须使用自动化技术。
自动化的性能测试工具可以帮助我们简化测试流程。工具通常允许用户对终端用户的操作进行录制，进而产生对应的脚本。这些脚本会被用来创建性能测试会话或者场景，这些会话/场景模拟了一批典型用户的操作行为。这才是真正意义上的性能测试，它们可以非常方便地反复执行，这是人工测试所不具备的一个重要优势。同时，性能测试自动化工具会自动存储测试结果，并且可以方便地对多次测试结果进行比较，因此可以显著提升性能结果分析过程的效率。
性能测试自动化工具通常由以下模块组成。
支持对终端用户操作行为的录制，有些工具会支持多种中间件协议的录制。允许用户对录制下来的脚本进行编辑，关联脚本内部和外部的数据，对响应时间度量的粒度进行控制。“中间件”在这里是指应用用于客户端和服务端通信的主要协议（对于Web应用来说，主要是指HTTP或者HTTPS）。
支持性能测试会话或者场景的创建和执行，使用会话和场景来模拟不同用户的操作行为。这些会话/场景使用指定的性能测试脚本和一个或者多个施压引擎（取决于需要多大的负载）来产生期望的负载。
产生负载——通常使用多台工作站或者服务器，需要使用多少台取决于期望达到的负载。通过部署在相对少量的物理机或者虚拟机上的施压引擎来产生大量虚拟用户（Virtual User，VU）来模拟大量的终端用户操作行为。用户客户端本身对于内存和CPU资源的消耗很大程度上决定了一个施压引擎能够产生多少虚拟用户，进而决定我们需要部署多少施压引擎。
提供对每次测试执行所产生的数据进行分析的能力。数据通常包括各种自动产生的报表、可配置的图表和数据表格。有些分析模块还提供专家功能，帮助用户对结果进行深度分析，提炼重要关注点。
通常作为上述模块的补充用来对测试环境中的服务器和网络进行性能监控，或者用来集成其他类型工具帮助分析。图2-1展示了一个典型的性能测试工具部署结构。应用的终端用户被一批工作站或者服务器取代，这些机器通过创建虚拟用户来给目标应用施加负载/压力。
图2-1 性能工具典型部署图
由于对工具本身的技术评估不够，很多性能测试项目在脚本编写阶段就陷入问题的泥潭。很多测试服务供应商都支持来自各种工具供应商的解决方案，他们通常根据特定的客户性能测试需求来选择合适的性能测试工具。
Web技术如日中天，几乎每个性能测试供应商都提供HTTP/S的支持。然而，在Web技术里面还有很多特别的设计，尤其是客户端。如果你在应用中使用了大量的JavaScript、JSON或者微软的Silverlight，你就得充分考虑所选工具的功能以及技术限制。下面是一些关于如何选择工具的建议。
选择性能测试工具最重要的一点就是确保你所选的工具能够支持你的应用协议栈，也就是说你的应用客户端如何同服务端进行通信。比如，在绝大多数情况下，一个典型的浏览器会使用HTTP或者HTTPS作为它的通信协议。
在工具满足应用协议栈需求的前提下，还要看工具的授权模式。大多数性能测试供应商通过下列模块进行收费。
允许执行的最大规模负载测试（用虚拟用户数来衡量）
这个计价方式通常会采用区间收费，比如以100个虚拟用户作为入门价，虚拟用户数越多，收费越贵。也有一些供应商会以一个较高的固定价格来提供无上限的虚拟用户数。有一些供应商会提供一种短期授权，允许用户临时提高工具允许的最大虚拟用户数，来获得更大的负载。
工具支持的额外协议种类
当用户购买工具的时候，也许只选择了HTTP协议。但是后来由于项目需要，需要测试其他协议，比如Citrix，这样就需要支付额外的协议费用。新购买的额外协议是否适用已经购买的虚拟用户数，不同供应商会有不同的做法。
额外的集成和监控插件
工具供应商通常会有一些可选插件，用户可以在购买基础软件授权后按需购买可选插件。插件通常包括一些特定技术栈的监控工具，比如Oracle、MS SQL Server和IIS等；同时测试工具还可以和应用性能管理工具（Application Performance Monitor，APM）或者持续集成（Continuous Integration，CI）工具进行集成。这些集成通常会收取一定费用。当考虑购买这些插件时，你需要清楚这些功能通常需要在目标服务器上安装相应的代理软件，并且允许它们访问网络；你必须确保这些需求在被测环境（System Under Test，SUT）是可接受的。
在确定采购工具的候选名单时，确保你对各种工具的授权模式是非常清楚的。
很多性能测试工具提供商声称他们工具产生的脚本基本或者完全不需要手工编辑。对于一些简单的页面浏览，或许可以做到完全不需要手工编辑脚本。但事实是你总会遇到需要手工编辑脚本的场景（或许是插入一些JavaScript或者一些代码模块来处理复杂的客户端逻辑）。
你也许会发现你不得不对录制的测试用例进行手工编辑以让它能够正确回放。一个工具可能需要你在每个脚本上耗费几个小时的时间来让它正确运行，而另一个工具基本可以自动化你刚才的操作，因此在选择工具的时候你就必须充分考虑这部分额外工作对你的性能测试项目和测试团队带来的影响。
测试团队的技术能力也是一个需要考量的因素。如果队员有着很强的开发背景，那么让他们在测试脚本中进行一些手工编码应该不成问题。但如果你的队员不熟悉编码，尽管前期投入比较大，你还是更应该考虑一款提供具有向导功能的性能测试工具来帮助测试人员更容易地创建脚本。
有些供应商只提供性能测试工具，有些供应商提供整套的性能测试解决方案。解决方案通常要比单纯的性能测试工具贵，但是它可以提供更完善的分析。除了性能测试，解决方案供应商通常提供：自动化需求管理、自动化数据构造和管理、性能测试前的应用性能调优、响应时间预测和容量评估、细到类和方法级别的APM应用性能分析、应用发布后的终端用户体验（EUE，End User Experience）监控以及测试结果/测试资产的可视化的数据看板。
如果你的资源有限或者项目周期非常紧张，那还是考虑将性能测试项目外包给一个供应商会更加合适。一些工具供应商会提供一整套服务，从带有实施支持的工具采购到全方位的性能测试服务。这些公司在测试领域非常专业，能够使用合适的性能工具集来提供专业的性能测试服务。使用外包模式的优势在于用户不用为自己的应用专门购买一个性能测试工具，节省了时间和资源成本。但如果用户的场景需要进行多次性能测试，使用外包模式来完成性能测试会比自己购买或者研发性能测试工具贵得多。
如果你的应用是基于Web的，而且它也是面向消费者的，你也许有一个更好的选择——软件即服务（Software as a Service，SaaS）的性能测试服务。现在有很多供应商通过Web提供性能测试服务，他们帮你实现整个测试流程：编写关键测试用例，然后通过分布在各地的施压引擎来对你的应用施加压力。采用这种方式，用户不需要自己提供足够数量的施压机器，性能测试服务供应商的施压节点通常部署在主干网络，能够真实地模拟大量终端用户。对于低频的大规模性能测试，SaaS化的解决方案非常有吸引力，而且性能测试服务供应商通常还提供终端用户体验监控。
采用SaaS化性能测试服务的一个不足之处在于你需要为每次测试付钱，对被测服务器和网络的监控也需要用户自己来负责。当测试过程出现问题，用户需要通过重复测试来排查时，整体开销就相当可观了。
总而言之，SaaS化的性能测试服务还是非常值得调研的。附录C列举了一些提供这类服务的供应商。
对于候选的性能测试工具，你需要对它们一一试用以验证工具的可行性，只有这样才能确保你最终选择的工具集能够满足你的需求。在验证过程中至少选择录制两个测试用例：一个只读用例（比如一个返回一条或者多条记录的搜索操作）和一个涉及插入和更新你的应用数据库的写用例。这样你就能验证录制下来的测试用例是否能够正确回放。如果你的应用是只读的，你也要检查脚本回放日志来确保回放过程中没有任何错误。
概念验证完成以下目标。
技术兼容性显然是一个关键目标，否则你将会在测试用例的脚本实现阶段举步维艰（或者根本是不可能完成的任务）！你必须在真实的应用环境来试用性能测试工具，只有这样才能在确定是否在项目中应用该工具之前充分暴露和解决问题。
典型的概念验证会构建一些简单的测试用例，这些用例是整个性能测试项目的基础。这是在正式开始编写性能测试脚本之前非常好的一次排演机会，在这个过程中你会发现为了正确执行用例所需要的外部数据和运行时数据。概念验证只会创建两三个测试用例，随着正式用例的增多，你会发现更多的数据需求。但是概念验证经常能够帮你快速定位到一些常用的输入数据需求，比如登录的用户名密码和一些保持用户会话有效的状态数据。
概念验证还可以帮你评估编写一个典型的测试用例脚本需要耗费多少时间以及评估修改脚本所带来的额外时间。
相比简单的样例沙箱，针对实际应用的工具测试要靠谱很多。
下面列举的检查点为有效地开展概念验证提供了一些指引。就时间而言，每个概念验证都有它的独特性，但是在应用环境可用的前提下，一般不会超过几天的时间。
下面这些需求应当在项目中尽早准备以便在需要的时候能够快速搭建POC环境。
下面这个列表可以帮助你确保POC项目为后续的正式性能测试打下坚实的基础。
注意
Windiff.exe是一款用于定位两个文件中不同内容的Windows工具程序；这是一款免费工具并且已经伴随Windows发布有好长时间。如果你需要更加强大的对比功能，可以尝试下面的工具：
prestoSoft的ExamDiff Pro
WinMerge
下面列表中的内容是POC的交付物，它们是后续有效开展正式性能测试项目的基础。
这一章展示了自动化对于性能测试的重要性，我们也讨论了一些性能测试工具的可选项。下面是几点需要重点关注的。
下一章我们将继续讨论有效开展应用性能测试的几个核心模块。它们通常被称作（非）功能需求。
