作者：符强
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
深入浅出性能测试与LoadRunner实战试读：
前言
转眼间一年过去了，2014年，应用性能管理团队决定把性能测试相关项目实践经验写成一本书，几经波折，最近终于定稿。
关于性能测试的能力，我通常将其分成三个层次：能测—会分析—懂调优。这也是进阶的三个层次。
我的第一本关于性能测试的书是与好友郭伯雅合著的《性能测试诊断分析与优化》，书中以迫切希望能面面俱到的心态尝试覆盖三个层次的内容，现在看来还是有点急躁。
能测，这个层次很多人都能达到，掌握一两个性能测试的工具，按照一定的流程规范即可开展性能测试工作。
会分析，需要掌握的技能则要广泛很多，从网络到Web服务器、中间件、数据库的性能监控，性能指标数据的解读，业务指标与资源指标的关联分析，能精通此道的人就少了很多。
懂调优，原则上不是测试人员的事情，但是懂调优的测试人员会更有价值。如果Web服务器、中间件、数据库的调优都能加以尝试和排查，剩下的就是代码优化，岂不是能倒逼程序员，让其毫无借口，必须优化代码？
优化是最高境界，但是能测、会分析是基础！
应用性能管理团队在电信、航空、电力、金融、政府等领域的性能测试项目中摸爬滚打了多年后，大部分人都能达到能测的境界，并且有所超越，甚至一些性能测试脚本的疑难杂症也能顺利攻克。但是，始终只有少部分人在性能数据的分析上能摸到一些门道，能调优的就更少，这种状况直到公司APM产品问世才得到很好的解决。
这里先简单介绍一下我们的APM能力：通过分析应用程序在Web层、中间件层、数据库层的调用情况，组合成完整的调用链，从而形成清晰的业务视图。正是这种能力大大提升了团队性能分析的准确性和效率，降低了对人的要求，在某些项目中还能定位到代码的性能瓶颈，推动开发进行优化。
借此次编写书籍的机会，应用性能管理团队重新梳理了性能测试领域的知识体系，分成“初识庐山”、“云览群山”、“华山论剑”三篇，在总结项目实践经验的同时，再一次巩固了自身对性能测试知识的掌握，达到更深入的理解。●“ 初识庐山”篇的编写目的是教会他人性能测试的基本功，使得
新员工入职也能迅速掌握基本的性能测试工作技能，继而投入到
项目中去。●“ 云览群山”篇的编写目的是希望走在前面的性能测试工程师能
把多年的经验传承下来，让初级的测试工程师也能顺着阶梯往上
爬。●“ 华山论剑”篇的编写目的是归纳总结不同行业、不同类型的性
能测试项目特点及实战经验，让测试的同行可以参考借鉴。
在我看来，这几大目的都在一定程度上达到了。参与编写本书的几位同事也收获了很多，这些收获有工作经验上的积累，有性能测试技能上的提高，也有同甘共苦、共同奋战在一线的成长与快乐。
本书得以最终成稿并出版，有赖应用性能管理团队几位小伙伴（丁锦良、蒋娟、冼志超、邱艳玲）的帮助。他们在辛苦工作之余，牺牲个人时间，帮忙收集相关材料和提出宝贵建议。
由于篇幅有限，我们遗漏了不少在项目中实践的技术和案例，例如，APM工具在性能测试中的应用、性能基线测试的管理、性能测试自动化调度执行框架的设计、业务拨测与性能数据分析等。我们期待有机会在下一本书中呈现，或者以其他形式与读者交流碰撞。
通过此次书籍的编写，让我本人也收获良多，尤其是有了更多新的关于软件性能的视角，以及关于性能测试发展方向的思考。例如，APM这类工具在典型的系统架构中所发挥的性能诊断分析的作用；从日志分析的角度利用类似Splunk这样的工具进行性能诊断分析。我希望有机会能在一些项目中验证这些想法。
人生总在一次次的经历中成长，有所经历不代表着一定会有经验，但是经验一定是建立在经历的基础之上的。很高兴我们的应用性能管理团队能一起经历各种项目，面对各种类型的客户，更难得的是我们能把这些经历转化为经验传递给团队中的其他人，以及通过出版书籍的方式传递给广大的测试同行。
最近一两年来，通过与客户的交流、与同行的交流，我收获了很多。例如，通过给客户培训性能测试一遍又一遍地梳理性能测试的知识体系；与华为的朋友交流性能建模；与DynaTrace厂商的朋友交流APM及大规模分布式性能压测；与招商银行的客户碰撞关于通过抓取网络流量包进行大数据性能分析，等等。这些都让我脑洞大开，原来性能领域还有这么新奇的东西。
书是一种与人交流的形式，我们期待通过著书立说的途径与更多人交流。希望我们的书能给大家带来一些启发的同时，抛砖引玉，期待广大读者的反馈，共同努力推进软件性能领域的发展。
最后，再次感谢应用性能管理团队的小伙伴们的努力，在符强和潘绍强的“双强”带领下，取得了骄人的成绩。感谢新炬的领导程总，营造了一个技术导向、技术为王、技术创新的工作团队氛围，让我们能在工作的同时取得技术上的一次次突破。还要感谢出版社编辑的辛勤工作，你们的耐心与细心指导是本书得以顺利出版的必备条件。
他山之石，可以攻玉。
路漫漫其修远兮，吾将上下而求索。
与广大测试同行共勉！新炬网络 应用性能技术总监、质量优化顾问、APM架构师DBA+社群联合发起人 陈能技第1篇 初识庐山
有人曾这样形容软件测试：它让一场本该在用户面前发生的灾难提前在自己面前发生了，这会让它们生出一种救世主的感觉，拯救了用户，也拯救了这个软件，避免了它们被卸载的命运。目前软件测试人才的缺口在30万人以上，性能测试人员更是稀缺人群。很多读者之所以会步入性能测试领域，也是因为职业发展到了一个瓶颈期，希望摆脱日复一日的黑盒功能测试。如何让菜鸟迅速成长为高手？接下来我们将拨开性能测试的层层迷雾，探寻真相之源。第1章性能测试概论
随着互联网技术的迅速发展、软件系统的日益复杂，性能已经成为软件质量重要的衡量标准之一。中国银联业务也曾经因性能问题中断6小时，数百万笔跨行交易无法进行，损失超过10亿元。由性能所导致的问题影响越来越广泛，因此企业对于软件产品的性能要求越来越高，也越来越关注。一个好的建筑师首先需要清楚了解各建筑材料的特性，同样，一个好的性能测试工程师也需要对性能的基础知识有全面的了解。下面就让我们一起来学习性能测试的基础知识。1.1 什么是性能测试
1. 性能（Performance）
计算机系统或子系统实现其功能的能力。
对计算机系统或子系统执行其功能的能力的度量。例如，响应时间、吞吐能力、事务处理数。
2. 用户角度
用户关注的性能，主要为主观用户体验。一方面是用户查询、提交等业务操作的响应速度，从用户发起请求到服务器返回结果的时间。另一方面是页面展示、页面解析、渲染的速度，包含了用户计算机和网站服务器的通信时间、网站服务器的处理时间、用户计算机浏览器构造请求解析响应数据的时间。
3. 开发人员角度
从架构层面看，关注应用层、服务层、数据层的性能。
从系统功能层面看，关注各个模块、模块之间、接口之间的性能。
在浏览器端：浏览器缓存、页面压缩（计算机的能力）、合理布局页面、减少Cookie传输、使用CDN在网络供应商处缓存。
在应用服务器端：服务器本地缓存、分布式缓存、异步消息队列、集群（应用服务器集群、缓存服务器集群、数据服务器缓存）。
在数据库服务器端：索引、缓存、SQL优化、NoSQL。
在代码层面：多线程、改善内存管理。
具体体现：包括响应延迟、系统吞吐量、并发处理能力、资源消耗、系统稳定性。
4. 性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。它的覆盖面非常广泛，对于一个软件系统而言包括了执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。性能测试用来保证产品发布后，系统的性能满足用户的需求。性能测试在软件质量保证过程中起到重要的作用。
通俗地讲，通过模拟生产运行的业务压力和使用场景组合，测试系统的性能是否满足生成性能要求。即在特定的运行条件下验证系统的能力状况。1.2 性能测试的现状
在软件业较发达的国家，性能测试早已成为软件开发的一个重要组成部分。而在我国，软件行业起步晚，所以在很多方面没有做到标准化和规范化。此外，对于性能测试的重要性、测试方法和流程等还存在很多错误的认识和问题。（1）国内的很多软件公司对性能测试的重视程度不够，很多领导或项目经理仅关注功能质量，把测试的资源都放在功能测试上。（2）一些中小型的软件公司没有成立专门的性能测试组，大多数时候由功能测试人员兼顾开展性能测试，没有保证性能测试的专业性和预期效果。（3）认为性能不会存在太大问题；或者项目进度紧张，等时间充足时再做性能测试。（4）缺乏实际的性能需求分析，性能测试仅仅让软件项目长时间运行，保证资源消耗正常或者系统不出现崩溃即可。（5）场景设计不合理，无法模拟真实的业务行为和性能场景。（6）测试环境与生产环境差别太大，测试无法真实反映生产系统压力状况。（7）缺乏专业的性能测试结果分析，无法真正定位系统性能瓶颈，达不到调优效果。1.3 性能测试的必要性
随着社会的发展、科技的进步、信息技术的飞速发展、计算机的普及，软件产品已经应用到社会的各个行业领域，加上网络的发展、信息的共享性等，人们对计算机及网络的依赖性越来越大。软件产品的使用者对高质量、高效率的工作方式的要求越来越高，因此对于工作和生活中息息相关的IT系统服务，他们也要求提供更快、更高效的服务品质。
网络的发展，让人们对网络的依赖性越来越大，成千上万的用户在庞大的网络系统中游转。网络时代的到来，也给提供服务的系统带来严重的负荷，这就是系统网络发展中最明显的特征：“高并发”、“数据集中”。数据越来越集中于后台系统服务器中，众多系统同时为成千上万的网络用户提供服务，如银行、电信、社交网站等公司的软件系统随处可见，影响着我们生活的方方面面。随着各个企业的业务发展、用户访问量的增加，其服务系统承载的负荷也会随着增加，系统性能的好坏将严重影响企业的利益，因此对于IT服务系统的性能测试与优化也越来越受到业界的重视。
2008年Aberdeen Group的研究报告表明，Web网站1s的页面加载延迟相当于减少了11%的PV，相当于降低了16%的顾客满意度。如果从金钱的角度计算，就意味着：如果一个网站每天挣10万元，那么一年下来，由于页面加载速度比竞争对手慢1s，可能导致总共损失25万元的销售额。Compuware公司分析了超过150个网站和150万个浏览页面，发现页面响应时间从2s增长到10s，会导致38%的页面浏览放弃率。Radware也曾发布一份题为“行业现状：2013年春季电商页面速度与Web性能”的调查报告。报告指出，仅一年时间内，美国前2000家领先的在线零售商网站的加载时间较去年同期减慢了22%，网站性能急剧下降，用户体验质量大幅下降。对网站回访率、跳出率、客户满意度及在线收入等多个关键业务指标的影响越来越大，对在线零售商而言，网站加载速度已经成为制约其发展的重要因素，提升Web性能已经刻不容缓。
2014年中国电子商务研究中心发布对电商网站的调查报告，报告中指出用户对网站响应时间的要求很严苛，期望立刻作出响应的占90%，期望5min内作出响应的占10%。我国的12306订票系统因几度濒临瘫痪而受到业内的广泛质疑，既影响了铁道部的信誉，带来了损失，又影响了全国人民的出行计划。
从上面的研究分析可以看出，性能测试非常重要也非常必要，因为性能问题不仅会损害公司的形象，造成资金方面的损失，也会给用户带来各方面的困扰。1.4 性能测试类型
对于性能测试的分类，业界有很多标准，而对每个类型的诠释也有一些差别。
从狭义来看，性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。
从广义来看，性能测试则是压力测试、负载测试、强度测试、容量测试、大数据量测试、基准测试等和性能相关的测试的统称，性能测试类型如图1-1所示。图1.1 性能测试类型
1.4.1 压力测试
压力测试（Stress Testing）是指通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
压力测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能是由于争用共享资源（如数据库锁或网络带宽）而造成的。压力测试还可用于确定测试对象能够处理的最大工作量。
压力测试并不是简单地为了一种破坏的快感而去破坏系统，实际上它可以让测试工程师观察系统在出现故障时的反应。系统是不是保存了它出现故障时的状态？是不是它突然间崩溃掉了？它是否只是挂在那儿什么也不做了？它失效的时候是不是有一些反应？在重启之后，它是否有能力恢复到前一个正常运行的状态？它是否会给用户显示出一些有用的错误信息，还是只显示一些很难理解的十六进制代码？系统的安全性是否会因为一些不可预料的故障而会有所降低？
1.4.2 负载测试
负载测试（Load Testing）是指在给定的测试环境下，通过逐步增加系统负载，直到性能指标超过预定指标或某种资源使用已经达到饱和状态，从而确定系统在各种工作负载下的性能容量和处理能力，以及持续正常运行的能力，确定系统所能够承受的最大负载量。负载测试的主要用途是发现系统性能的拐点，寻找系统能够支持的最大用户、业务等处理能力的约束，为系统调优提供数据。
当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而确定能够接受的性能的过程。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
1.4.3 强度测试
强度测试检查程序对异常的处理能力。压力测试注重的是外界不断施压，而强度测试注重的是系统的极限或者系统异常情况下的测试。
强度测试总是迫使系统在异常的资源配置下运行：● 当中断的正常频率为每秒1~2个时，运行每秒产生10个中断的测
试用例。● 定量地增长数据输入率，检查输入子功能的反应能力。● 运行需要最大存储空间（或其他资源）的测试用例。● 运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例
等。
强度测试是一种特别重要的测试，对系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定及性能是否容易扩展。
1.4.4 容量测试
容量测试是负载测试的补充，用来确定程序的最终临界点。容量测试用于测试系统能够处理的最大会话能力，确定系统可处理同时在线的最大用户数。即使系统处理会话超过了临界点，系统仍需要稳定运行。
容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或仍能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。软件容量测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
1.4.5 大数据量测试
大数据量测试可以分为三种类型：● 针对某些系统存储、传输、统计、查询等业务进行大数据量的独
立数据量测试。● 与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数
据量测试方案。● 单独的数据库或文件系统性能测试。
通常来说，我们采用第二种测试方案，即把多种测试类型结合在一起，以节省测试时间。如果怀疑或者已经发现大数据量情况下存在问题，那么需要采用方案一、三进行深入测试。
1.4.6 基准测试
基准测试（Benchmark Testing）是指在一定的软件、硬件及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测的过程中，通过运行相同的业务场景比较测试结果，确定调优的结果是否达到预期效果，或者为系统的选择提供决策数据。基准测试一般基于配置测试，通过配置测试得到数据，并将这个数据作为基准来比较每次调优后的性能是否有所改善。
通过对被测系统的软硬件环境进行调整，了解不同环境对性能影响的程度，从而找到系统各项资源的最优分配原则。
基准测试的主要意义：主要用于性能调优。在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。1.5 软件性能的基本指标
性能测试指标一般可以划分为业务指标和系统资源指标两大部分。对于一般用户而言，对于系统性能的要求主要是业务指标，而系统资源指标是系统性能的一个反应，它可以帮助分析系统性能瓶颈、优化系统或者发现一些隐性问题。
对于业务指标的要求主要是请求响应时间、最大并发量等。
对于系统资源的指标，例如，资源使用率，是指在系统负载运行期间，数据库服务器、应用服务器、Web服务器的CPU、内存、硬盘、外置存储、网络带宽的使用率。低于20%的使用率为资源空闲，20%~60%的使用率为资源使用稳定，60%~80%的使用率表示资源使用饱和，超过80%的资源使用率必须尽快进行资源调整和优化。
1.5.1 业务指标
业务指标是对软件系统业务处理能力及响应速度的衡量值，是软件系统性能表现的最直观体现。以下列出了性能测试中常见的业务指标。
1. 点击率
点击率（Hit per Second）主要指每秒客户端向Web服务器提交的HTTP请求数。客户端每发送一个请求，服务器就处理一次，所以点击数是Web应用处理交易的最小单位。点击率越大，对服务器的压力相对也越大。
这里需要区别的是，点击不是指日常使用鼠标的“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发起了多个HTTP请求。
点击率除受程序处理速度的影响，还受带宽的限制，即每个请求的大小情况。请求越小，每秒完成的请求数越多。在排除带宽影响的情况下，具有缓存机制的系统比没有缓存机制的系统点击率要高很多。在网络传输到达一定程度后，点击率就不会随并发量的增长而增大。一般可以在限定的带宽情况下对最大点击率进行估算，公式如下：
最大点击率=带宽/（估算平均每个×请求大小×8）
一般来说，日访问量是在点击率基础上计算出来的，公式如下：
日访问量=点击率×3600×日访问小时数（可按8小时算）
2. 响应时间
要理解响应时间，首先需引入“事务”的概念。事务是指用户在客户端做一种或多种业务所需要的操作集。响应时间就是对事务操作时间的测量。事务响应时间是记录客户端请求开始到服务器返回内容至客户端的时间来计算用户操作响应时间的，此响应时间不包含客户端GUI时间（例如浏览器解释页面所消耗的时间）。
对于软件系统来说，通过事务得到的系统响应时间也是由很多部分组成的。一般来说，响应时间由网络时间、服务器处理时间、网络延迟三大部分组成。首先来看从客户端发出请求到服务器返回需要经历哪些过程，如图1.2所示。图1.2 请求与响应流程
1）网络时间
客户端发出请求首先通过网络来到Web Server上（消耗时间为N1）；Web Server将处理后的请求发送给App Server（消耗时间为N2）；App Server将操作数据指令发送给Database（消耗时间为N3）；Database将查询结果数据发送回App Server（消耗时间为N4）；App Server将处理后的页面发送给Web Server（消耗时间为N5）；最后Web Server将HTML转发到客户端（消耗时间为N6）。这里的Nx都是网络传输上的时间开销，没有计算业务处理所需要花费的时间。
2）服务器处理时间
另外还要考虑各个服务器处理所需要的时间WT、AT、DT。
3）网络延迟
除了上面两种时间开销，还要考虑网络延迟的问题。
所以最终的响应时间组成为：
响应时间 = 网络延迟时间 + WT+AT+DT +（N1+N2+N3）+（N4+N5+N6）+ WT+AT+DT
3. 吞吐量
吞吐量为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。对于交互式应用系统来说，吞吐量反映的是服务器承受的压力；在容量规划的测试中，吞吐量是一个重要指标，它不但反映在中间件、数据库上，更加体现在硬件上。
从业务角度看，吞吐量可用请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量；从网络角度看，吞吐量可以用字节/秒来衡量。
对于交互式应用来说，吞吐量反映的是服务器承受的压力，它能够说明系统的负载能力。
以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节/秒的方式，可以表示要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；以请求数/秒的方式，表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
4. 并发用户数
首先来理解一下并发的概念。
1）并发的两种情况
一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。例如，所有用户同一时刻做并发登录，同一时刻做表单提交。
另一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。例如，在同一时刻有用户在登录，有用户在提交表单。
2）从服务器的角度来看并发
前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。
如果考虑整个系统运行过程中服务器所承受的压力，则并发是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上都有一个“同时向服务器端发送请求的客户数”，这就是所谓的服务器所承受的最大并发访问数。
3）并发用户数与系统用户数、在线用户数的区别
例如一个邮件系统，有100个注册用户，那么系统用户数就是100个；其中一段时间内有80个用户登录使用，在这段时间内在线用户数就是80。但其中有10个用户在阅读邮件内容，20个用户在写邮件，这30个用户在此阶段对服务器并没有产生压力。只有产生了请求、提交等业务操作的用户才会对服务器构成压力。所以并发用户数是指在系统运行期间同一时刻进行业务操作的用户数量。一般应用系统并发用户数为在线用户数的10%~20%，但还是要取决于具体的业务逻辑、业务场景。
5. 最大并发用户数
最大并发用户数是指应用系统在正式环境下所能承受的最大并发用户数量。在运行中，如果出现了频繁业务操作失败、响应时间远远超出用户所能承受的最大值或出现了服务器宕机等情况，则说明系统承载量已经超出了最大并发用户数的范围。
6. TPS
TPS即Transaction per Second，是指每秒事务处理量。
TPS=脚本运行期间所有事务总数/脚本运行时长
TPS反映了系统在同一时间内能够处理业务的最大能力。TPS会受到负载的影响，也会随着负载的增加而逐渐增加。当系统进入繁忙期后，TPS会有所下降，而在几分钟后开始出现少量的失败事务。
点击率与TPS最大的区别是：TPS体现的是服务器对客户端请求的处理能力；而点击率体现的是客户端对服务器的压力。
1.5.2 资源指标
资源指标与硬件资源消耗直接相关。测试的目的不同，需要统计的系统资源指标也不同，主要包括服务器操作系统资源使用情况、资源消耗情况等。
1. 内存
1）Paging Rate：内存页交换速率
如果该值偶尔走高，则表明当时有线程竞争内存。如果该值持续很高，则内存可能是瓶颈，也可能是内存访问命中率低。
2）Memory/Available Bytes
Memory/Available Bytes计数器的值持续降低，同时Process/Private Bytes计数器和Process/Working Set计数器的值在长时间内持续升高，则很可能存在内存泄漏。需要更详细的内存监控工具来定位是否有内存泄漏和存在内存泄漏的代码。
内存资源成为系统性能瓶颈的征兆：● 很高的换页率（high pageout rate）。● 进程进入不活动状态。● 交换区所有磁盘的活动次数很高。● 很高的全局系统CPU利用率。● 内存不够出错（out of memory）。
2. 处理器
1）CPU占用率（CPU Utilization）
如果该值持续超过95%，则表明瓶颈是CPU。可以考虑增加一个处理器或更换一个更快的处理器。一般可接受的最大上限是80%~85%，合理使用的范围在60%~70%以下。
2）System/Processor Queue Length
如果System/Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能瓶颈的征兆：● 很慢的响应时间（slow response time）。● CPU空闲时间为零（zero percent idle CPU）。● 过高的用户占用CPU时间（high percent user CPU）。● 过高的系统占用CPU时间（high percent system CPU）。● 长时间的有很长的运行进程队列（large run queue size
sustained over time）。
3. 磁盘I/O
1）Disk Rate：磁盘交换率
如果该参数值一直很高，则表明I/O有问题。可考虑更换更快的硬盘系统。
2）Disk Time和Avg.Disk Queue Length
当这两个值很高，而Page Reads/sec（页面读取操作速率）很低时，则可能存在磁盘瓶颈。
I/O资源成为系统性能瓶颈的征兆：● 过高的磁盘利用率（high disk utilization）。● 太长的磁盘等待队列（large disk queue length）。● 等待磁盘I/O的时间所占的百分率太高（large percentage of time
waiting for disk I/O）。● 太长的运行进程队列，但CPU却空闲（large run queue with idle
CPU）。● 太高的物理I/O速率[large physical I/O rate（not sufficient in
itself）]。● 过低的缓存命中率[low buffer cache hit ratio（not sufficient in
itself）]。
4. 带宽
一般使用计数器Bytes Total/sec来度量。Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽进行比较。
判断网络带宽是否是系统运行性能瓶颈的首要条件是，网络带宽是否会影响系统交易执行性能。例如，减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。
在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。1.6 软件性能测试方法论
性能测试方法主要包括SEI负载测试计划过程和RBI方法。
1.6.1 SEI负载测试计划过程
SEI负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生“清晰、易理解、可验证的负载测试计划”。SEI负载测试计划过程包括6个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。
SEI负载测试计划过程将以上述6个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容。（1）生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确地反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。（2）用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。（3）用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程。对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。
从SEI负载测试计划过程的描述中可以看到，SEI负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。
SEI负载测试计划过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。
1.6.2 RBI方法
RBI（Rapid Bottleneck Identify）方法是一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：（1）发现的80%系统的性能瓶颈都由吞吐量制约。（2）并发用户数和吞吐量瓶颈之间存在一定的关联。（3）采用吞吐量测试可以更快速地定位问题。
RBI方法首先访问服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。
在确定具体的性能瓶颈时，RBI将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4个环节确定系统性能具体的瓶颈。
RBI方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。1.7 软件性能测试的目标
软件性能测试的目标是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最终起到优化系统的目的。
软件性能测试包括以下几个方面的内容。（1）评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。（2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。（3）系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。（4）检测软件中的问题：长时间的测试执行可能导致程序发生由于内存泄漏引起的失败，揭示程序中隐含的问题或冲突。（5）验证稳定性（Resilience）、可靠性（Reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。1.8 本章小结
通过本章对性能测试基本概念的介绍和说明，初学者可以深入地理解性能测试的重要性及基本术语。虽然第1章为基础知识，但对于全面地学习性能测试知识尤为重要。如果不能很好地理解和掌握这些基本概念，后续的学习会变得混乱，难于理解。对于初学者来说切记脚踏实地，不要浮躁！
了解以上基础知识后，我们将学习性能测试工具如何使用。接下来我们将对主流的性能测试工具LoadRunner进行介绍。第2章软件性能测试工具介绍
经过第1章的讲解，我们对性能测试有了深入了解。日行千里需有千里马，要想做好性能测试也需要一款好的工具来支持。软件性能测试工具分为三类：商业收费工具、开源免费工具、自主开发工具。商业收费工具有QA Load、SilkPerformer、LoadRunner、WebRunner、IBM Rational Performance Tester等。开源免费工具有Apache JMeter、AutoBench、ApacheBench、Pylot等。自主开发工具成本高，稳定性与可靠性也容易存在问题。
LoadRunner引入国内以来迅速为测试工程师接受，成为性能测试的主流工具，下面我们将对LoadRunner工具的使用展开详细讲解。2.1 LoadRunner工具介绍
LoadRunner是一款预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间、优化性能和加速应用系统的发布周期。LoadRunner是一款适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。
LoadRunner能够完成以下工作：（1）轻松创建虚拟用户。（2）创建真实的负载。（3）定位性能问题。（4）分析结果以精确定位问题所在。（5）重复测试保证系统发布的高性能。
2.1.1 LoadRunner实现性能测试需求
LoadRunner性能测试是利用产品、人员和流程来降低应用程序、升级程序或补丁程序部署风险的一种手段。性能测试的核心是向预部署系统施加工作负载，同时评估系统和最终用户体验。一次组织合理的性能测试可以让用户清楚以下几点：● 应用程序对目标用户的响应是否足够迅速？● 应用程序是否能够游刃有余地处理预期用户负载？● 应用程序是否能够处理业务所需的事务数？● 在预期和非预期用户负载下应用程序是否稳定？● 是否能够确保用户在使用此应用程序时感到满意？
通过回答这些问题，自动化性能测试可以量化业务状况的更改所带来的影响。这反过来也可以让用户清楚部署此应用程序的风险。有效的自动化性能测试可帮助开发人员作出更加明智的发行决定，防止发行的应用程序带来系统停机和可用性问题。
2.1.2 LoadRunner包含的组件
LoadRunner包含以下组件。● Virtual User Generator：录制最终用户业务流程并创建自动化性
能测试脚本，即Vuser脚本。● Controller：组织、驱动、管理并监控负载测试。● Load Generator：通过运行Vuser产生负载。● Analysis：用于查看、剖析和比较性能结果。● Launcher：使用户可以从单个访问点访问所有LoadRunner组
件。
2.1.3 LoadRunner术语
在LoadRunner中，以下术语是一定会用到的，在使用之前应先了解各个模块的作用，如表2.1所示。表2.1 LoadRunner基本术语
在LoadRunner使用过程中，还需要了解以下常用的术语，如表2.2所示。表2.2 LoadRunner常用术语
2.1.4 LoadRunner负载测试流程
负载测试一般包括5个阶段：规划负载测试、创建Vuser脚本、定义场景、运行场景和分析结果，如图2.1所示。图2.1 负载测试各阶段
各个阶段介绍如下。● 规划负载测试：定义性能测试要求，例如并发用户数量、典型业
务流程和要求的响应时间。● 创建Vuser脚本：在自动化脚本中录制最终用户活动。● 定义场景：使用LoadRunner Controller设置负载测试环境。● 运行场景：使用LoadRunner Controller驱动、管理并监控负载测
试。● 分析结果：使用LoadRunner Analysis创建图和报告并评估性能。
2.1.5 LoadRunner核心组件VuGen简介
在测试环境中，LoadRunner在物理计算机上使用Vuser代替实际用户。Vuser以一种可重复、可预测的方式模拟典型用户的操作，对系统施加负载。
LoadRunner Virtual User Generator（VuGen）以“录制-回放”的方式工作。当用户在应用程序中执行业务流程步骤时，VuGen会将用户的操作录制到自动化脚本中，并将其作为负载测试的基础。
VuGen不仅可以录制Vuser脚本，还可以运行和调试Vuser脚本。在录制Vuser脚本时，VuGen会生成多个函数，它将这些函数插入VuGen编辑器以创建基本Vuser脚本，同时仍然可以在VuGen中丰富、完善脚本，如加入事务、集合点、参数化数据等。当然，如果需要，可以自行编写一些代码等。
在录制过程中，VuGen会录制客户端和服务器之间的相关交互活动，它将自动生成相关的模拟实际情况的API函数。由于Vuser脚本不依赖于客户端软件，因此即使客户端软件的用户界面尚未完全开发好也可以使用它来检验系统性能，这为产品前期框架选择等提供了便利。
VuGen提供了多种协议，方便用户模拟系统的Vuser技术。每种技术都适合于特定的体系结构并产生特定类型的Vuser脚本。例如，可以使用Web Vuser脚本模拟用户操作Web浏览器的相应行为，使用FTP Vuser模拟FTP会话及其处理过程。各种Vuser既可以单独使用（单协议），又可以一起使用（多协议），以创建有效的负载测试。在录制单个协议时，VuGen仅录制指定的协议。以多协议模式进行录制时，VuGen将录制多个协议中的操作。对于以下协议，支持多协议脚本：COM/DCOM、File Transfer Protocol（FTP）、Internet Messaging（IMAP）、Oracle NCA、Post Office Protocol（POP3）、Real、Windows Sockets、Simple Mail Protocol（SMTP）和Web（HTTP/HTML），如表2.3所示。表2.3 LoadRunner支持的协议
很多初学者认为LoadRunner仅支持对B/S结构的应用程序进行性能测试，而不能对C/S等其他结构的应用程序进行性能测试，其实这个理解是不对的。LoadRunner支持多种协议，选择了正确的协议后，通常都能够进行脚本的录制和编写工作，前提是LoadRunner有相应的许可协议，才能够进行这个类型脚本的负载。除了录制会话，VuGen还可以创建自定义Vuser脚本。可以使用Vuser API函数，也可以使用标准的C、Java、Visual Basic、VBScript或JavaScript代码。通过VuGen可以在脚本中编写自己的函数，而不用录制实际会话。可以使用VuserAPI或标准的编程函数。使用Vuser API函数可以收集有关Vuser的信息。例如，可以使用Vuser函数来度量服务器性能、控制服务器负载、添加调试代码，或者检索关于参与测试或监控的Vuser的运行时信息。
2.1.6 LoadRunner核心组件Controller简介
当虚拟用户脚本开发完成后，使用Controller将这个执行脚本的用户从单个人转化为众人，从而模拟大量用户操作，进而形成负载。我们需要对负载模拟的方式和特征进行配置从而形成场景。场景（Scenario）是一种用来模拟大量用户操作的技术手段，通过配置和执行场景向服务器产生负载，验证各系统各项性能指标是否达到用户要求，而Controller可以帮助我们对场景的设计、执行及监控进行管理。
Controller是提供所有用于创建和运行测试的工具，帮助用户准确模拟工作环境。
使用Controller管理场景主要分为场景设计和场景监控。最后通过运行场景来完成性能测试的执行。
在设计视图中，场景有两种类型：手工场景和面向目标场景，其中手工场景还有百分比模式。
1. 手工场景（Manual Scenario）
创建虚拟用户组，设置虚拟用户数目及其他n-time信息。
手工场景是常用的设计模式，负载测试就常用它。手工场景符合性能测试常规思路：
第一步，设置虚拟用户的数目、脚本及它们运行的方式。
第二步，运行，得出服务器的响应时间等指标。
手工场景还有一个百分比模式，在该模式中，只需设定总用户数，Controller将总用户数以百分比的方式分派去执行不同的脚本。
2. 面向目标场景（Goal-Oriented Scenario）
如果说手工场景是一板一眼的因果关系，而面向目标场景就是一个稍微复杂一些的闭环回馈关系了。在面向目标场景中，先定义测试要达到的目标，然后LoadRunner自动基于这些目标创建场景。在运行过程中，LoadRunner会不断地把结果和目标相比较，以决定下一步怎么走。
目标场景共有5种目标类型。● Virtual Users：该参数表示虚拟用户数，是指被测系统所需要支
持的用户数。● Hits per Second：该参数表示每秒点击数，是指一秒能做到的点
击请求数目，即客户端产生的每秒请求数（正常情况下等于服务
器请求响应数）。● Transactions per Second：该参数表示每秒事务数，一个事务代
表一个操作，反映系统的处理能力。● Transactions Response Time：该参数表示事务的响应时间，反
映系统的处理速度及一个操作花费的时间。● Pages per Minute：该参数表示每分钟页面的刷新次数，反映系
统每分钟提供的页面处理能力，代表了系统的整体处理能力。
2.1.7 LoadRunner核心组件Analysis简介
Analysis会话的目的是查找系统的性能问题，然后找出这些问题的根源。
1. 创建Analysis会话
在运行负载测试场景时，数据存储在扩展名为.lrr的结果文件中。Analysis是一种实用程序，可处理收集的结果信息并生成图和报告。在使用Analysis实用程序时，用户是在会话中工作的。Analysis会话至少包含一组场景结果（.lrr文件）。Analysis将活动图的显示信息和布局设置存储在扩展名为.lra的文件中。
2. 启动Analysis
Analysis可以作为独立的应用程序打开，也可以直接从Controller打开。要将Analysis作为独立的应用程序打开，请选择以下某种方法：● 开始→程序→LoadRunner→应用程序→Analysis。● 开始→程序→LoadRunner→Applications→Analysis，选择File→
Open命令，选择要打开的结果文件。
3. Analysis负载测试
要直接从Controller打开Analysis，请选择“结果”→“Analyze结果”。此选项仅在运行负载测试场景后才可用。Analysis会从当前场景中提取最新的结果文件，并用这些结果文件打开新会话。也可以通过选择“结果”→“自动加载Analysis”，指示Controller在完成场景执行后自动打开Analysis。在创建新会话时，Analysis会提示指定要包含在会话中的场景结果文件（扩展名为.lrr）。要打开现有的Analysis会话，请指定Analysis会话文件（扩展名为.lra）。
4. 整理执行结果
在运行负载测试场景时，默认情况下所有Vuser信息将存储在每台本地Vuser主机上。场景执行后，会自动整理或合并结果——来自所有主机的结果将传输到结果目录。通过在Controller窗口中选择“结果”→“自动整理结果”，并取消选择此复选框，可以禁用自动整理。要手动整理结果，可选择“结果”→“整理结果”。如果未事先整理结果，则Analysis会在生成分析数据前自动整理结果。
5. 查看概要数据
在结果大小超过100 MB的大型负载测试场景中，Analysis处理数据将需要较长时间。在LoadRunner处理完整数据时，可以查看这些数据的概要。要查看概要数据，请选择“工具”→“选项”，然后选择“结果集合”选项卡。要在查看概要数据的同时处理完整数据图，请选择在生成完整数据的同时显示概要数据；如果不需要LoadRunner处理所有Analysis数据，则选择仅生成概要数据。
2.1.8 LoadRunner工作原理
根据LoadRunner的总体架构图，包括各个组件VuGen、Controller和Analysis之间的关系，从而分析得到LoadRunner的工具作原理为：代理（Proxy）是客户端和服务器端之间的中间介质，LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流的。（1）虚拟用户脚本生成器通过代理方式接收客户端发送的数据包，记录并将其转发给服务器端；接收到从服务器端返回的数据流，记录并返回给客户端。这样服务器端和客户端都模拟在一个真实运行环境中，虚拟脚本生成器能通过这种方式截获数据流；虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理，最终用脚本函数将数据流交互过程转化为容易看懂的脚本语言。（2）压力生成器则是根据脚本内容，产生实际的负载，扮演产生负载的角色。（3）用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或是线程协作，接受调度系统的命令，调度产生负载压力的进程或线程。（4）压力调度是根据用户的场景要求，设置各种不同脚本的虚拟用户数量，设置同步点等。（5）监控系统则可以对数据库、应用服务器、服务器的主要性能计数器进行监控。（6）压力结果分析工具用于辅助测试结果分析。
根据上面的描述，大致绘制LoadRunner的总体架构图和工作原理图，如图2.2和图2.3所示。图2.2 LoadRunner的总体架构图2.3 LoadRunner的工作原理2.2 LoadRunner基本运用
本节主要介绍怎样使用VuGen录制脚本，设计压力测试场景，运行场景，分析压力测试结果。
2.2.1 使用VuGen录制脚本
本节中先介绍使用VuGen录制脚本。录制脚本是进行压力测试的第一步，也是最重要的一步。
1. 录制脚本
创建负载测试的第一步是使用VuGen录制典型最终用户的业务流程。VuGen采用录制并回放机制。当用户在应用程序中按照业务流程操作时，VuGen将这些操作录制到自动脚本中，以便作为负载测试的基础。
要开始录制用户操作，请打开VuGen并创建一个空白脚本，然后通过录制操作和手动添加增强功能来填充这个空白脚本。
在这一节，将打开VuGen并创建一个空白Web脚本。（1）启动LoadRunner。
选择“开始”→“程序”→HP LoadRunner→LoadRunner命令，这时将打开HP LoadRunner 11.00窗口，如图2.4所示。图2.4 启动界面（2）打开VuGen。
在欢迎使用Virtual User Generator区域中，单击Create/Edit Scripts按钮，这时出现Welcome to the Virtual User Generator界面。（3）创建一个空白Web脚本。
在VuGen的开始页中的File选项卡中，单击New按钮，将打开New Virtual User对话框，并显示New Single Protocol Script屏幕，如图2.5所示。图2.5 新建脚本界面
协议是客户端用来与系统后端进行通信的语言。Tours是基于Web的应用程序，因此用户将创建一个Web虚拟用户脚本。
确保Category类型为All Protocols，VuGen将显示所有可用于单协议脚本的协议列表。向下滚动查看该列表，选择Web （HTTP/HTML），并单击Create按钮创建一个空白Web脚本。
空白脚本以VuGen的向导模式打开，同时左侧显示Tasks窗格。如果没有显示Tasks窗格，请单击工具栏上的Tasks按钮，然后单击Introduction按钮，如图2.6所示。图2.6 界面功能展示
VuGen的向导将指导用户逐步完成脚本创建并使其适应测试环境。Tasks窗格列出脚本创建过程中的各个步骤或任务。在执行各个步骤的过程中，VuGen将在窗口的主要区域显示详细说明和指示信息。
可以自定义VuGen窗口来显示或隐藏各个工具栏。要显示或隐藏工具栏，请选择View→Status Bar并选中/不选中目标工具栏旁边的复选框。通过打开Tasks窗格并单击其中一个任务步骤，可以随时返回到VuGen向导。
试读结束[说明：试读内容隐藏了图片]