作者：51Testing软件测试网
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
性能测试进阶指南——LoadRunner 11实战试读：
内容简介
本书是一本基于HP LoadRunner 11工具的指导用书，从性能测试原理到工具使用再到项目实施，全面介绍了性能测试的各个方面，其内容基本主线说明如下。
第一步（了解理论）：磨刀不误砍柴工，打下基础；第二步（掌握工具）：深入介绍LoadRunner 11工具三大部分（Virtual User Generator、Controller、Analysis）如何实现用户行为的模拟、性能指标的监控、负载的生成及后期的数据分析；第三步（项目实施）：理论联系实际，介绍性能测试项目实施的流程和性能测试部门的组织管理；第四步（进阶提升）：对一些当下流行的或比较特殊的协议和开发技巧通过真实案例进行介绍。
本书结合了很多工作中的实际案例，图文并茂，既适合渴望了解性能测试的新人，也适合对性能测试有一定认识和经验的中、高级测试工程师。同时，本书也可以作为高校开展性能测试课程的参考教材，让在校学生能对性能测试的本质和价值有一定的认识。未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。版权所有，侵权必究。图书在版编目（CIP）数据性能测试进阶指南：LoadRunner 11实战/陈霁编著;51Testing软件测试网组编.北京：电子工业出版社，2012.5（测试实践丛书）ISBN 978-7-121-16739-3Ⅰ.①性… Ⅱ.①陈… ②5… Ⅲ.①性能试验－软件工具，LoadRunner Ⅳ.①TP311.56中国版本图书馆CIP数据核字（2012）第065650号策划编辑：李 冰责任编辑：葛 娜文字编辑：赵树刚印 刷：北京东光印刷厂装 订：三河市皇庄路通装订厂出版发行：电子工业出版社 北京市海淀区万寿路173信箱 邮编100036开 本：787×1092 1/16 印张：40.5 字数：1037千字印 次：2012年5月第1次印刷印 数：3500册 定价：79.00元
凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888。
质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。
服务热线：（010）88258888。
《51Testing软件测试网作品系列》编辑委员会名单
编 委：
王 威（具有多年软件开发经验和软件测试工作经验，对产品测试的方法和管理流程有深刻的认识，51Testing软件测试培训高级讲师）
王 琰（具有丰富的通信终端产品的测试以及管理工作经验，51Testing软件测试培训高级讲师）
朴春龙（Mercury认证CPC，自动化测试专家，51Testing软件测试培训高级讲师）
邓 强（具有丰富的软件系统测试工作经验，对功能性测试、自动化测试、性能测试及测试框架均有深入的研究，51Testing软件测试培训高级讲师）
周 峰（信息产业部认证系统分析员，51Testing软件测试培训高级讲师）
周春江（具有多年通信协议和通信终端设备的测试工作经验，51Testing软件测试培训高级讲师）
徐林林（熟悉大型应用软件的开发和测试流程；熟悉性能测试流程、方法和工具（如LoadRunner等），51Testing软件测试培训高级讲师）
商 莉（多年从事软件开发、软件测试及质量保证方面的管理工作，51Testing软件测试培训高级讲师）
宋 锋（具有多年软件开发和软件测试工作经验，以及丰富的项目实战经验，51Testing软件测试培训高级讲师）
宋光照（具有深厚的开源软件测试实践经验，擅长嵌入式测试，51Testing软件测试培训高级讲师）
刘德宝（具有多年软件测试及培训经验，参与门户网站、移动BOSS等多个大型软件测试项目，在自动化测试技术方面具有丰富项目经验，51Testing软件测试培训高级讲师）
编辑部成员：张晓晓 张燕青序
2012年1月8日至2月10日，全球最大规模的“迁徙活动”浩浩荡荡地展开，www.12306.cn成了全球最炙手可热的网站，每天高达数十亿次的点击量，平均刷新500次才能买到一张票。“一票难求”成了大量期盼回家过年的人最头疼的大事。
虽然铁道部一再想尽办法动足脑筋，可是网络购票难的问题始终没有解决。能从网上购买到一张回家的车票，真的是一件难如登天的事情。
为什么车票如此难买，网站如此难登？我觉得从本质上而言是设计者在最初乐观地估计了网站的访问流量，致使网站的性能指标完全无法应对真实的用户需求。简而言之一句话：性能测试没有达标。
这次春运网上购票暴露出来的问题再次向我们敲响了警钟，如何有效地开展性能测试，如何有效地将性能测试融入到百姓的生活中去，是众多企业、众多测试从业者毕生追求的目标。
作为一名测试工程师，性能测试也是我所关注和关心的问题。如何发掘系统潜在的性能瓶颈，如何准确地定位瓶颈的所在位置，如何进一步提高系统的性能指标，也是我在不断学习和提高的。
在学习的过程中，一本好的教材往往可以起到融会贯通、醍醐灌顶的作用。虽然古语有云“师傅领进门，修行靠个人”。可是领进门这个工作，真的不容小觑，少走冤枉路，往往可以起到事半功倍的作用。一些好的方法，一些有用的经验总结，一些具体的工程实践，可以帮助我们更好地深入理解性能测试的内涵，从而不断地完善自己。
本书就是这样一把“利器”，由浅入深，从理论联系到实际，一步步深入地向我们剖析了性能测试的内涵。工具的使用只是一个开始，真正地了解系统的结构、协议、数据库等各方面的内容，才能让我们更好地完成身为一名性能测试工程师应尽的职责，从而成长为一名优秀的性能测试工程师。“序”话不多，马上展开我们精彩的性能测试之旅吧。永远支持你的老婆沈蕾鸣2012年1月28日前 言
性能测试并不是一个很新的名词，但自从LoadRunner进入国内并流行起来，带动了性能测试的潮流，一时间测试人员的口边已经离不开这个HP的性能测试神器。如果你不会使用它进行性能测试，出门都不好意思和同行打招呼，似乎掌握了该工具就成为了测试的资深专家。可以说性能测试的流行从某些角度也反映了国内软件测试技术的进步，从过去的手工化功能测试逐步开始涉及通过编程的方式对系统进行功能测试，从而进一步地开展性能测试。为什么写这本书
在游戏中身为一个DPS总是不断地在天赋、装备属性、输出手法、站位、技能优先级等问题上反复琢磨调优，力争成为该职业的高手。在不同的论坛会参考别人的推荐来选择BIS（最优配置装备）、合适的天赋、最佳的重铸属性，熟悉和计算各种技能的优先级，在战斗的过程中动态监控各种BUFF和DEBUFF来让自己的核心技能能够在最合理的时间爆发并且获得最大利益。当每次实战时都能看到自己的DPS牢牢地处于榜首，那种感觉是妙不可言的。与职业玩家的互相交流，探讨心得可以更好地选择不同技能应对不同的战斗，性能测试及调优就这样在游戏中淋漓尽致地闪耀着光芒。当去指导朋友如何玩好这复杂的职业时，需要使用很多策略来让他了解游戏的逻辑本质，掌握技能的意义及优先级排列，并在战斗中合理应用。
而另一方面对于软件来说，性能测试、调优又是如此雷同而又复杂。看过很多性能测试方面的书，也在论坛上不断地解决各种问题，但总会发现新手问题反复发，高手问题无人解的问题，而企业中的各种问题也大同小异，仔细一看其实在很多书中都有介绍。在上一本《性能测试进阶指南——LoadRunner 9.1实战》中介绍了LoadRunner 9.1，后两年中并没有看到市面上有关LoadRunner 11的图书，而这两年中自己也有很多新的理解和对于部分章节描述的补充，在老婆的鼓励和支持下这本书就诞生了。限于作者的经验和水平，书中的不足和纰漏之处在所难免，恳请广大读者批评指正。
疑问和建议可以访问笔者的BLOG：http://www.51testing.com/?104本书面向的读者
本书并不是完全为初学者设计的，因为性能测试本来就不是一个新人能够涉及的内容，想要掌握性能测试需要多年的测试基础及广泛的知识面。这里需要读者具备一定的动态页面开发基础及Linux系统和数据库基本操作能力。
对于一个刚刚涉及性能测试的朋友来说，这本书可以解答你遇到的所有问题，虽然刚开始看会稍显吃力，但随着逐步的深入会越发轻松。对于已入门的朋友，在简单地了解性能测试基础及LoadRunner的实现原理后，本书的深度会让你进一步看透一些朦胧的东西。而对于高手来说，项目的实施策略、扩展工具的辅助及特殊的脚本开发可以帮助你进一步扩展思路。
相对于上一本《性能测试进阶指南》来说本书做了大量篇幅的修改，强化了很多细节的知识，将部分基础知识进行了精简。对于基础较差的入门级读者，建议先阅读笔者的上一本《性能测试进阶指南——LoadRunner 9.1实战》以熟悉基础知识，从而降低阅读中的困难。本书作者
陈霁，51Testing论坛中ID为云层，集上海人和四川人的优缺点于一身，常常被朋友指责为典型处女座。自认公司内皮肤最白，经常被学员笑称“云版”或“棉花糖”老师，现任51Testing高级讲师，主攻性能测试。
2001年至2004年在多家软件公司任职测试工程师，在底层摸爬滚打多年，对各种类型的软件测试都有所涉及。
2004年至2007年在Gameloft上海部曾任测试经理、SQA及SCM。
2007年中加入51Testing任职高级讲师，负责软件测试培训、咨询、企业应用解决方案等工作。本书结构
本书分为8章、5个，其内容如下表所示。从本书能收获什么
对于读者来说，通过本书的学习可以完全掌握LoadRunner 11的各种功能，并了解性能测试的实施过程，做到理论联系实际。本书中所有的例子都可以在本地或者权威网站进行实践，包括项目实践的所有内容也可在本地完成，从而真正实现自学成材。虽然本书是介绍如何使用LoadRunner这一性能测试工具来进行性能测试的，但是书中还穿插了大量的辅助工具，从而弥补了LoadRunner自身工具的不足；在实战阶段提供了详尽的性能需求分析方法、测试数据构造方式、性能测试分析方法及性能测试团队构建方式，让菜鸟迅速成长为高手。致谢
测试做久了总习惯挑别人毛病或者具备一点完美主义精神，看了很多论坛上的提问和市面上的书籍后，我自信地认为能写本“比别人好点的书”。当开始执笔时，一本“完美”的书一直压迫得我喘不过气来，经过多次辗转，最终这个相对“完美”的版本没有胎死腹中，这里不得不感谢那些在这些年中和我互相学习分享知识的朋友。
对我来说最幸福的事情是在进入高中时拥有了一台小小的学习机，当第一次接触到键盘，第一次编写BASIC小程序时仿佛失了魂，按照现在的说法也就是“宅”了。这里要感谢我的父母，他们并没有阻止我沉迷于计算机之中，从而让我找到了自己的兴趣，并进一步将兴趣转化为了职业。
第一次接触软件测试是在2001年，作为一名刚毕业、自我感觉良好的大学生，我只身来到了上海。四处碰壁后“委身”于一家软件公司任职测试工程师，就这样误打误撞地进入软件测试行业，多亏当时面试我的原IBM测试经理田芳女士给了我这样的机会。“师傅领进门，修行靠个人”，待我明白这个道理并奋发努力后，在Wang Sheng和Steven Ye的栽培下我逐渐成为了独当一面的测试经理。
加入51Testing对我来说是个不小的转变，作为原Etang的SQA和Gameloft的测试经理，游戏测试及管理和软件测试还有一条不小的鸿沟，而性能测试以前并不是我的主攻方向，期间受到Sincky、海龙、老朴、徐林林的细心指点，使我对性能测试的理解逐步加深，也逐渐接过了性能测试培训的教鞭。
在本书的编写过程中，宋锋、徐林林、田威峰、刘德宝、邓强等老师都在各个方面给予了我很多支持。为了给我更多的闭关写书的时间，小师妹和师弟不得不帮忙顶了很多课程，在此表示感谢。网上的很多朋友给了我很多知识点和参考案例，这里需要感谢一下QQ群中的Fin、Mike、土匪、千里、友船、一个人、Yettie等几大版主和热心网友帮助我完成了Beta版本的测试工作，并在校稿中做了很多的工作，包括内容的收集、评审和整理，在此表示感谢。
最后还是要感谢一下亲爱的老婆，写书这段时间让你多费心了，这是一本为你而写的书。陈 霁基础篇第1章 性能测试基础
软件测试逐步成为软件开发过程中一个必不可少的环节，随着功能测试的必要性被认可，自动化测试和性能测试也逐步崭露头角。
我们经常会抱怨浏览网页慢、下载文件慢，其实这都是属于性能问题。用户在得益于功能方面的质量提升后，开始对性能有了新的认识和要求，而性能测试并不像功能测试那样可以“低门槛”进行。性能测试的本质是通过编写一个程序去测试另外一个程序，而正是有了这个相对的“高门槛”，性能测试便成了一个“高薪”、“高技术含量”的工作，新人在看到高手指点江山（性能测试）时，充满了羡慕的眼神，摩拳擦掌准备进入这个行业。
在开始从事性能测试工作之前，我们先来看看这个职位的考核标准和面临的挑战。1.1 性能测试工程师的标准及挑战
在你掌握了性能测试的基本技能之后，接着就需要找到一家合适的企业，通过劳动换取经济上的回报，那么通常公司如何去招聘一个性能测试工程师，并如何进行绩效考评，即性能测试工程师应该达到的工作目标到底是什么呢？1.1.1 性能测试工程师的考评指标
在介绍性能测试之前，我们回想一下功能测试的考评和工作内容。如果你是一名功能测试经理，该如何考评你的员工呢？
当软件测试刚刚进入中国时，我们对测试的理解是通过模拟用户执行，发现用户可能遇到的问题，而缺陷的数目成了考评的唯一指标。
例如，PM（Project Manager）规定，每个测试人员每天都要发现10个以上的缺陷，否则说明他在工作态度和工作能力上有一定的缺陷。
综上，作为一名功能测试工程师，其考评要求可以归结为一条，那就是测试通过的软件不会被用户发现严重的缺陷。
而现在，软件测试逐渐正名，我们对测试的理解从证明软件没有错误变为证明软件具备一定的质量，而功能测试工程师的考评标准也随之发生了变化。
功能测试工程师的考评指标主要有以下几点：
1）缺陷数目
缺陷的数目虽然不能作为主要的考评指标，但是从某一个角度也说明了测试工程师发现问题的能力。在成熟的软件开发公司中，我们能够通过历史数据生成的缺陷质量模型准确预估缺陷数量。如果你发现的缺陷数量明显低于预估，则说明你的工作可能存在一定问题。
2）缺陷质量
有量没有质是不行的，由于计件制的压迫，测试人员往往为了达到数目上的指标而凑缺陷，数目是够了，但是所提的缺陷都是鸡毛蒜皮的事情，缺陷的危害等级和优先级都比较低，那么对软件质量的提升效果会相对较差。
在缺陷的质量中包含两个概念：
缺陷的严重等级和优先级。
对缺陷的描述。
3）工作态度
测试工作是一个很容易“偷懒”的工作，是需要个人积极主动、追求完美的工作，对于测试工程师，只有具备善于交流、积极主动、“视公为私”的态度才能对被测对象负责。
4）工作效率
在较短的时间内是否能够高质量完成上级布置任务的能力。
5）文档编写
过去所谓的软件测试工程师只是软件测试执行工程师，现在被称为Tester。现在测试工程师还需要进行测试计划、测试方案及用例等文档的编写工作。
6）团队协作能力
7）其他相关技能
性能测试在国内刚刚开始流行。一个公司招聘性能测试工程师的主要目的是通过对产品进行专业的性能测试，获得一份性能测试评估报告，从而向用户证明本产品能够满足预期的性能需求。
随着性能测试职位的逐渐成熟，对这个职位的要求也越来越严格，性能测试的目的不仅仅是为了获得当前系统的性能评估，而是希望进一步通过性能测试发现系统性能瓶颈并修复性能问题，提升系统处理能力，甚至对系统的扩展能力提供一定的数据参考。而性能问题的修复成本一般相对较高，如何使用最低的成本换取最高的性能，从而在性价比上找到黄金分割点，将是性能调优的重点。
性能测试工程师的考评指标会包括以下内容：
1）是否能够独立开发脚本
能否使用一种或多种性能测试工具完成用户行为的模拟脚本开发工作。
2）能否对需求进行性能分析并获得性能需求
任何测试都是基于需求的。作为一名性能测试工程师，需要具备一定的性能需求分析能力，从而根据用户的需求进行性能测试，得到被测系统与用户需求之间的差距，从而生成性能报告并提供性能调优方案。
3）能否设计场景及监控负载系统完成对性能测试的实施和监控工作
对性能测试进行实施，设计负载规则并监控负载下各个系统的状态。
4）能否通过性能测试发现比较具体的性能瓶颈
具备一定的性能结果分析及瓶颈定位能力。
5）文档编写与环境搭建的能力
独立编写性能测试文档和搭建测试环境的能力。
6）团队协作能力
7）其他相关技能1.1.2 性能测试工程师的挑战
作为工作了几年的功能测试工程师来说，大家觉得在功能测试工作中的挑战是什么呢？
公司不重视测试。
就我一个人做测试。
找不到缺陷。
开发工程师不能及时修改测试中发现的缺陷。
不熟悉业务。
不了解功能测试的方法及流程。
总结来说就是工作内容略感重复、缺乏技术含量，并且在有限的时间和资源下难以达到理想化的目标。
在实际工作中，要确保软件没有缺陷是比较困难的，这是因为：
软件不可能不存在缺陷。
测试无法发现所有缺陷。
测试在大多数情况下都没有足够的资源和时间（在成本和质量上寻求平衡）。
所以无法完全保证整个软件在交付时不存在缺陷。虽然可以通过各种方法发现并修复严重级别或者优先级别较高的问题，但由于个人能力或客观原因还是会遗留某些缺陷的。
那么作为一个性能测试工程师所面临的挑战又有哪些呢？
对性能测试的理论和技术不熟悉。
公司不重视性能测试。
就我一个人做性能测试。
测试出来的结果不知道怎么分析。
不熟悉业务。
定位出的性能问题无法修正。
总结来说，就是如何在有限的时间和资源下，保证提交给用户的软件系统可以达到指定的性能需求指标。
从某种角度来说，现在性能测试的功效被过度放大了。以功能测试为例，最初软件是无须测试的，因为软件功能单一，而软件质量是依赖于有经验的开发人员自己进行维护，随着开发规模的逐渐扩大，软件越来越复杂，随之质量逐渐下降，这时功能测试的低成本效果就出现了。各大公司开始大规模地成立测试部门，随着功能测试部门的规模逐渐扩大，其效率开始不断下降，依赖于功能测试提高质量的性价比逐渐降低，而现在大家都认识到功能测试并不是万能的，其主要作用是保证软件达到一定的质量，通过自动化可以降低功能测试的执行成本。性能测试也处在这样一个过程中，由于客户日趋成熟，逐渐意识到性能是继功能后另一个重要的质量指标，而我们常常错误地认为性能测试就是满足用户性能需求的灵丹妙药，掌握了性能测试仿佛就走在了软件测试技术的最高端，却忽略了去思考性能测试到底能做些什么。
性能问题并不像功能问题那么棘手，因为几乎常见的性能问题都可以通过硬件解决，也就是花点儿钱买个功能更加强大的硬件来提高软件的效率，其次通过性能测试后发现了性能瓶颈（一般性能瓶颈都是较为底层的问题），修复的成本和风险也是需要考虑的问题。好比功能测试在最后的BETA测试中发现了一个异常严重的功能问题，而该问题是由于引擎所导致的，改还是不改呢？功能是必须要进行修改的，如果不修改用户无法正常使用，但是从性能角度来说，系统处理速度慢一点往往还是能够接受的。往往出现花了很多钱进行性能测试，并且发现了性能问题，但是修复该性能缺陷的成本或风险太高，最终不得不放弃。
性能测试无非就是以相对较低的成本模拟一个真实环境来了解系统上线后的性能情况，至于定位、分析及调优，这需要一个团队的支持才能完成，所以软件的性能问题不是简简单单靠最后进行几次性能测试就能定位解决的。1.2 性能测试基础1.2.1 性能定义
1．性能的定义
在新华字典中可以查询到这样的解释：性能指器物所具有的性质与效用。
这个定义中包括了以下两层含义：
1）性质
性质是指该器物具有什么特性，能够做什么。
2）效用
效用是指该器物能够干得怎么样。
在我们身边的性能有哪些呢？
1）F1赛事
从竞技比赛的角度来说，在比赛中获胜的一方性能较好，那么是不是性能只包括速度呢？不是！F1比赛并不是直道跑1000米，而是有很多转弯，而且赛程也较长。车速并不是获得冠军的唯一指标，而车胎的类型、进出站的次数、驾车选手的发挥等条件组合在一起才是一个冠军诞生的基础。
2）个人计算机
个人计算机的性能指什么呢？用起来比较快？看起来比较漂亮？我们通常说电脑的性能是指运行常用软件的反应迅速，但是仅仅拥有一颗高级的芯，计算机一定能够性能出众吗？不一定，这还取决于存储器、显卡等相关设备。
针对CPU来说，主频也并不是说明CPU性能的唯一指标，并不是说CPU的频率越高，其计算速度越快。例如：现在有两块CPU，一块是奔腾Ⅴ3.0C主频3GHz，另外一块是酷睿2 T7200主频2GHz，显然T7200的性能远远优于奔腾Ⅴ。
3）软件
单位时间内能处理的业务、处理一个运算所需要花费的时间、打开该软件需要的时间，都能作为衡量软件性能的指标。例如在相同的计算机配置下分别安装Windows XP和Windows Vista操作系统。在这两个操作系统中复制大量文件至移动硬盘时，就会发现在Vista下进行相同的操作会比XP慢很多，这个时候就会说在该硬件配置下Vista的磁盘读/写性能相对XP较差。
2．失败案例
为什么突然开始如此重视性能测试呢？那是因为经历了太多惨痛的经历，让我们不得不重视这个以前被忽视的问题。
接着来回顾一下发生在2007年的一件由于性能测试不足而导致的惨痛案例——奥运会订票系统瘫痪。2008年8月，对于全国人民来说，没有什么比奥运会更大的事情了。买到一张称心如意的门票，也成了很多人的一个梦想。网上购票、先到先得、人人参与的策略，让大家觉得进入鸟巢观看开幕式，见证这历史性的一刻成为可能。然而当大家在奥运官方售票网上抢购门票时，这个梦想却被网上购票系统的瘫痪击成碎片。
我们来思考一个问题，作为一个奥运订票系统应该会有多少人去买票呢？看一下当时的新闻报道：
境内公众启动第二阶段奥运会门票预售。然而，为了让更多的公众实现奥运梦想的“先到先得，售完为止”的销售政策适得其反，公众纷纷抢在第一时间订票，致使票务官网压力激增，承受了超过自身设计容量8倍的流量，导致系统瘫痪。
超出8倍系统容量？那么接着来看看真正的系统容量是多少呢？
昨天上午9点，预售一开始，公众提交申请空前踊跃。北京奥运会官方票务网站的浏览量在第一个小时内达到800万次，每秒从网上提交的门票申请超过20万张；票务呼叫中心热线的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请。
1小时访问量达到800万次，通过计算可以得到平均每分钟的访问量约是13万次，而每秒约是2200次。对比自身设计的每小时100万次，每秒的访问量预估为280次左右，你是不是发现系统估计的访问量少得可怜？作为一个门户网站，新浪、搜狐每秒的访问量是多少？需求是不是出了问题？
作为百年一遇的奥运会盛典，每个炎黄子孙都会希望亲身在鸟巢感受奥运开幕式的盛况，而一张奥运会门票成了炙手可热的香饽饽，由于采取的是先到先得的策略，为了保证自己能够成为第一个进入系统购票的用户，我们需要确保自己以最快的速度进行订单的操作（提前准备用户注册、表单填写、业务熟悉、网络调整、个人反应速度调整、期待好运降临）。当到达北京时间9点整，马上单击订票按钮。有少数人由于最先进入系统，所以他们顺利地订票成功，而更多用户由于网络的延时或者某些别的原因，被堵在了系统的外面。在这种情况下就会产生大量用户并发订票的操作。
北京奥运会官方票务网站的浏览量在第一个小时达到800万次，每秒从网上提交的门票申请超过20万张。
从这句话可以看出，浏览量和门票申请的数量完全不是一个数量级，对应每秒不超过2000多次的浏览量，系统却承受了20万张每秒的申请量。这是因为绝大多数购票者都非常有经验，知道不能到9点钟再来填写订票表单，而是应该不断地单击提交按钮将事先输入的订票信息提交给服务器。
接着来分析一下如果想要订到奥运会的门票需要做哪些工作：
1）用户注册
当然要先注册订票网站会员，并顺便把银行卡也准备好，确保支付顺利。
2）表单的填写
在订票开始前，先到奥运会订票系统上去，将要购买的开闭幕式、足球决赛等关键场次的表单都准备好。
3）熟悉业务
整理并熟悉整个购票的流程。
4）网络调整
对于整个开幕式来说，全国可能有几千万的用户在尝试购票，而开幕式的门票一共也就3万多张，对于如此多的需求（接近800万的访问量）只是杯水车薪，所以如果想要在这种供需严重不平衡的情况下获得一张开幕式的门票，网速是一个非常重要的因素。
每秒20万的订票申请，也就是平均每毫秒200张。如果一个上海的网友和一个北京的网友同时在9点整购票，那么上海的兄弟就订不到这张票了，因为上海电信到北京网通的平均延时都在200ms，按照刚才的平均值来计算，已经卖掉4万张票了。所以如果想要购买到门票，最好在北京机房进行订票，使用光纤连接，确保订票信息到达服务器的延时在1ms之内，那么成功的概率就会大大提升。
5）个人反应时间
其实提交订票信息也是有讲究的，不同的人的反应有快慢之分，一般人在接受了信息到反应为动作可能需要0.4～0.6秒的时间，而通过训练可以提升到0.1～0.2秒，算算这是200毫秒的差距啊，又是4万张票没了，所以练练手速是很重要的一点，懂一些技术的朋友可能会使用按键精灵、QTP这类自动化工具来实现，将时间更加精准地进行控制，甚至可以考虑做一点抢跑的操作。
好，现在万事俱备，时间一到9点，如果你是那个能在最短时间就将请求发送到服务器的人，作为第一个冲入系统的用户，就能顺利地获得想要预订的门票。而如果你很不幸在9点钟打了一个喷嚏，再去提交门票预订申请，那么很抱歉，1秒钟过去了，有20万人在你前面了。
虽然整个系统在上线前进行过性能测试，但由于错误的需求导致当出现远远超出系统所能负载的访问量时，系统来不及响应就瘫痪了。错误的需求是整个售票网站瘫痪的最大原因。那么是不是需求做错了，系统瘫痪就是理所当然的呢？我们再来看看当时的新闻解释：
从昨天上午8点左右开始，就有不少网民登录票务官网排队等待申购门票。据了解，从上午9点正式开始售票到中午12点的3小时内，票务网站的浏览次数达到2000万次。这与此次所提供的100万次/小时的流量相差甚远。
不停地刷新网页，也是造成网络拥堵的原因之一。杨力说，“不少网民在无法正常登录后便不断刷新，这就相当于一名申购者变成了若干名申购者，无形中增大网站流量。从技术角度上讲，网站的流量几乎呈几何倍数增长，导致其他申购者无法登录。”
当大量的用户进行访问时，整个系统由于网络瓶颈或处理瓶颈导致了拥堵，用户无法访问。既然没有有效的网络流量处理能力，如果进行流量控制，问题就会被限制在一个可控的范围内。这好比一个银行有大量人来取款，总不能听之任之，而应该有专人进行协调管理，确保秩序，并告知排在后面的顾客可以考虑改天再来。
导致奥运会售票网站瘫痪的原因是综合的。如果当时进行了流量控制，那么可以保证登录到服务器上的用户可以比较正常地访问，而超出服务器处理能力的用户将无法进入系统，从而确保系统不会由于负载过大而停止响应。进一步来说如果剩下的用户需要通过排队的方式来登录服务器进行购票，那么当时尴尬的情况就不会出现。按照系统默认的处理能力，相信在两小时内肯定能够把所有的票都销售完毕。
当然，也需要以平常心来看待这个事情，作为任意一家公司来说，开发和维护一个奥运会门票系统都是有一定困难的，但是问题的出现告诉我们，性能测试不是简单做做就可以的，想要真正地解决性能问题需要注意以下几个问题。
1）确定需求
整个系统到底有多少人会访问？并发量会是多少？访问集中在哪些业务上？根据这些需求进行性能测试，即可保证系统在指定的指标下能够正常工作。如何获得奥运会订票的真实需求呢？其实并不是很难。
首先，在奥运会第一次抽签售票的过程中就能了解有多少人有意向购票，由于中签率非常低，那么没有中签的人一定会参加在线购票，所以可以得到一个比较不错的订票访问量预估。
其次，可以参考一下往届奥运会售票的经验和数据。
最后，可以做一次模拟售票的测试，给予一定的奖励号召大家都来尝试一下（例如，前200名注册的用户可以免费获赠一张门票，或者订票尾号为多少的用户获赠门票），确保在正常上线的情况下不出问题。
奥运会开幕式前就在鸟巢进行了带妆彩排，通过这次性能测试了解了开幕式的真实情况，从而制定了推荐观众在开幕式前及早进入场地且开幕式结束后先等待运动员离场后观众再分批离场的策略，确保不会出现拥堵的情况，这就是通过性能测试发现问题并进行修改的案例。
2）确保系统的健壮性
系统应该能够在极端负载的情况下正常运行。这就好比我们，不能因为生活压力大就不工作了，可以工作效率低，但是不能不工作。
3）制定意外的处理方式
在运行过程中有全面的监控，并且针对各种意外制定详细的应急方案，才能确保系统有能力处理各种意外情况。对于可能出现的访问高峰，相信很多网络维护的朋友做过这样的事情，将公司多余的服务器或者不常用的服务器腾出来，加入核心服务器的群集中，并且设置流量阈值，确保整个系统能够正常工作。当出现网络流量过大的情况时，可以通过队列等技术手段进行解决。
还记得我在Etang做SQA的时候，每次进行CET查分的时候，公司都会将所有的服务器停下来，全部支持CET查分的业务。
所以说，并不是奥运会在线购票的用户请求远远超出了我们的技术能力范围才导致网站瘫痪。一些门户网站在直播神七出仓时，其页面的并发请求会远远高于奥运订票网站的并发请求，但是并没有出现无法访问或者响应时间较长的情况。
3．性能测试
上面谈了什么是性能，忽视了性能会带来怎样的结果，那么什么是性能测试呢？
1）性能测试的概念
性能测试是系统测试的一种。作为一个优秀的系统测试工程师，需要通过“系统”的视角来分析被测试系统，分析包含以下两点。
功能测试：某个功能点。
性能测试：整个系统，包括软件和硬件。
在软件质量模型中，性能测试是属于效率这一类的。我们先来了解这句话涉及的两个概念。
质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。
软件效率（efficiency）：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。其中资源可能包括其他软件产品、系统的软件和硬件配置，以及物质材料（如打印纸、磁盘等）。
衡量一个软件的性能，需要从软件效率的以下3点考虑：
①时间特性。在规定条件下，软件产品执行其功能时提供适当的响应和处理时间以及吞吐率的能力。
②资源利用性。在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
③效率依从性。软件产品遵循与效率相关的标准或约定的能力。
也就是说我们需要确保软件在一定的资源配置条件下达到一定的性能，并且遵守相关的标准或协议。例如我们从来不会奢望一台80386的计算机能够在1分钟内启动完成Windows 7操作系统，因为我们知道其硬件不符合产品的标准。但是如果一台高级的主流配置计算机在1分钟内无法完成Windows 7操作系统的启动，你就会开始怀疑是不是自己的硬件存在某些问题，如果不是硬件问题，那么就会觉得这个操作系统很慢，性能很差。
所以一个性能测试工程师的主要工作目标就是确保系统能够在一定的硬件、软件环境下达到一定的性能指标。
而性能测试（Performance Testing）的定义为：在一定的负载情况下，系统的响应时间等特性是否满足特定的性能需求。从某些角度来说，性能其实是功能的一种。
什么是负载？
对于单机软件来说，我们的负载一般都是指操作的对象复杂度。例如使用Word打开一个100MB大小的doc格式文档，这就是一种负载。在另一种负载中可能存在并发的情况，例如使用格式转换软件的同时转换2个电影文件。
而对于基于网络架构（如C/S架构或者B/S架构）的系统，当众多终端用户对系统进行访问时，用户越多，那么服务器需要处理的客户请求也就越多，从而形成负载，而在这里负载的概念包含以下3点。
①系统实际用户。可能会有很多人使用同一个系统，但并不是所有的用户都会同时使用该系统，所以系统的实际用户是一个容量的问题，而不是负载的问题。
②系统在线用户。当系统用户对系统进行操作时，我们认为该用户为在线用户，这些用户对系统形成了负载，在线用户和实际用户的比例是根据系统特性决定的。
例如：
对于电子邮件系统，每天上班后几乎所有的实际用户都会进行收取邮件的操作，这个时候在线用户几乎等于实际用户，而在线用户又几乎等于并发用户。
而对于某网络游戏来说，工作时间的在线用户甚至不足所有用户的20%，而在线用户在进行交易行为的又是凤毛麟角。
③并发操作。用户在线后会对系统产生负载，但是用户和用户之间的操作却不是并发的，这是因为首先用户的操作需要延时等待，其次每个用户的操作并不是完全相同。并发操作会对系统产生很大的负载，当多个用户同时对某个功能进行操作时，服务器必须对这些请求进行队列管理，依次处理。
2）性能测试的分类
性能测试的方法很多，名词也很多，从使用方便的角度来说，这里将性能测试分为6种。
①负载测试（Load Testing）。负载测试是指在一定的软件、硬件及网络环境下，运行一种或多种业务，在不同虚拟用户数量的情况下，测试服务器的性能指标是否在用户的要求范围内，以此确定系统所能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。
负载测试强调的是在一定的环境下系统能够达到的峰值指标，大多数的性能测试都是负载测试。
例如，在各大网站上看到的各种显卡测试，都是通过运行3DMark或者某种游戏得到的最终数据，通过这个数据来说明显卡的峰值处理能力，这就是负载测试的一种方式。
通过运行EVEREST的性能测试功能对当前硬件平台下CPU Queen进行负载测试，负载结果如图1.1所示，最终得分为8392分。
②压力测试（Stress Testing）。压力测试是指在一定的软件、硬件及网络环境下，模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下并长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作。与负载测试获得峰值性能数据不同，压力测试强调在极端情况下系统的稳定性，这个时候处理能力已经不重要了。
例如，在CPU超频后经常需要对系统的稳定性进行测试，那么可以通过Prime95工具来进行稳定性测试，如图1.2所示，该软件可以让系统的所有资源长时间处于消耗殆尽的状态。通过这样一段时间的“烤机”后，如果没有出现死机等情况，可以认为系统通过了压力测试，即可以在各种情况下稳定地运行。图1.1 EVEREST CPU Queen测试结果图1.2 压力测试工具Prime95
③容量测试（Volume Testing）。容量测试是指在一定的软件、硬件及网络环境下，在数据库中构造不同数量级别的数据记录，运行一种或多种业务在一定虚拟用户数量的情况下，获取不同数量级别的服务器性能指标，以确定数据库的最佳容量和最大容量。容量测试不仅可以对数据库进行，还可以对硬件处理能力、各种服务器的连接能力等进行，以此来测试系统在不同容量级别下是否能达到指定的性能。
容量测试和负载测试的区别在于，容量测试主要关心how much，而负载测试则同时强调how much和how fast。
例如，测试一个Word 2003文档中最多可以存放多少个汉字。
容量测试中也包含了可伸缩性测试的概念，可伸缩性可以从硬件和软件两个方面来理解。
硬件的可伸缩性
是否可以通过硬件设备的增加来支持更多的用户，比如通过增加CPU个数或者存储器空间大小等。
软件的可伸缩性
是否可以通过运行更多的实例或者采用分布式处理来支持更多的用户。
再具体一点就是一个可伸缩系统必须具有随负荷增加响应时间也线性增加的特点。这样就可以通过线性增加硬件设备、实例个数或者分布式处理点来处理更多的数据量，也就能更好地在不增加响应时间的前提下支持更多的用户。
可伸缩性测试具体的测试过程为：进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。如线性增加，则说明系统具有可伸缩性；否则说明系统可伸缩性较差或者没有可伸缩性。
在CPU的发展中我们逐渐意识到提高主频和单核心处理能力越来越困难，而我们使用的系统却越来越多任务化，与其困难地提高主频何不增加核心通过多颗CPU核心并行处理来解决问题？当我们添加了一颗核心后，我们会发现处理能力会有大幅提升，这就是一种具备硬件可伸缩性的情况。但是并不是无限增加CPU核心就可以有效地解决问题，软件无法合理地使用多个核心会导致高负载时某几颗CPU核心满负载，而别的核心无事可做的情况。
④配置测试（Configuration Testing）。配置测试是指在不同的软件、硬件以及网络环境配置下，运行一种或多种业务，在一定的虚拟用户数量情况下，获得不同配置的性能指标，用于选择最佳的设备及参数配置。通过产生不同的配置，来得到系统性能的变化状况。
在购买计算机前，我们通常会参考各种硬件评测，通过这些评测可以得知如何花最少的钱获得最高的性能回报，而这些测试都是通过在相同的平台下切换CPU或者显卡等硬件来获得对应的性能指标。例如可以使用EVEREST Ultimate、Iometer、Sisoft Sandra这类工具来获得当前系统整体或者某个硬件的性能数据。
通过配置测试可以将性能缺陷放大，方便定位性能瓶颈。
通过EVEREST测试内存读/写速度，得出当前系统的内存写入速度为3029MB/s，如图1.3所示。图1.3 EVEREST 内存写入测试结果
⑤基准测试（Benchmark Testing）。基准测试是指在一定的软件、硬件及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测的过程中，通过运行相同的业务场景比较测试结果，确定调优的结果是否达到预期效果或者为系统的选择提供决策数据。基准测试一般基于配置测试，通过配置测试得到数据，并将这个数据作为基准来比较每次调优后的性能是否有所改善。
例如，前面通过EVEREST Ultimate工具获得了当前的内存读写速度数据，然后对系统进行调优（修改内存时序），再做一次相同的测试，如果内存读/写速度上升了，就说明前面的调优是正确有效的，反之则说明调优无效。
⑥并发测试（Concurrency Testing）。并发测试是指通过模拟多个用户并发访问同一个应用、存储过程或数据记录及其他并发操作，测试是否存在死锁、数据错误等故障。为了避免数据库或函数方法在并发下的错误，需要专门针对每个模块进行并发测试。
例如，软件系统中有以下类似的存储过程：
当大量用户并发运行该存储过程时就会出现注册成功的会员数目大于5000的情况，因为有多个会员能够同时得到系统当前的用户数，而产生多个用户同时插入会员信息的情况，导致功能的最终错误。对于这种情况需要在查询用户数的时候添加查询锁来避免查询功能的并发操作。
对于数据库上的SQL或者存储过程可以使用Quest BenchmarkFactory来帮助我们进行并发及容量测试，完成对数据库的基准评估。
3）性能测试进行的时间
好比几年前功能测试刚刚起步，其实就是一次出厂验货，却美其名曰QA。现在我们知道了功能测试包括单元测试、集成测试、系统测试，知道了需要尽可能早地介入测试，甚至应该对需求进行测试，从而有效地、全方位地保证软件质量。《扁鹊见蔡桓公》是一篇小学的课文，相对于看病来说，软件测试也是一种类似的工作，应该及早对病情进行诊断及预防。现在的性能测试往往都是在项目后期才开始进行的，通过性能测试发现系统性能已经完全无法达到预期的需求，但在多数情况下已经于事无补。
一个有效的缺陷就是能够被修复的缺陷！
一个软件的缺陷，特别是性能上的缺陷不是简单地改改代码就行。当一栋高楼已经建到第40层，才发现地基打得不够深，没办法继续往下修建了，而主梁的强度也不够，这时除了推倒重建也没什么其他有效的方法了。软件也是如此，当后期才发现存在严重的性能问题时，再想修正它的成本和难度相对功能问题来说要大很多。
接着来看看理想情况下性能测试应该在哪些阶段介入，如图1.4所示。图1.4 性能测试的进行时间
1）编码阶段（压力/并发）
在编码阶段，当每个函数、方法、存储过程被开发出来并通过单元测试后，都应该进行压力和并发测试，确认接口和被测对象能否健壮地处理极端情况，并且能否正确处理并发请求。
在大多数情况下，这个阶段的性能测试都是开发人员自行负责。而作为一个架构设计师，在设计软件时即应该考虑整个系统的性能，并进行建模测试，确保设计的正确。随后程序员对架构进行实现时就需要对自己编写的代码进行并发测试和压力测试。
2）编码-测试之间（容量测试）
在系统编码完成时，应该及时进行容量测试，确认系统能否满足在指定容量下的性能需求，并具备足够的软硬件伸缩性。例如，导入5年的历史数据量，检查在这种容量下系统的性能是否可以接受，进一步再构造未来5年的数据量，检查系统是否正常工作。
3）测试阶段（负载/配置/基准）
在进入测试阶段之后，在确保功能正确实现后需要进行负载测试，得到系统在当前硬件及软件环境下的性能指标（响应时间、吞吐量、资源利用率），进一步形成性能数据基准，然后通过配置测试进行性能瓶颈的定位和优化。
在负载测试后可以得到系统的性能，如果该结果满足用户需求，则可以考虑结束性能测试，也可以考虑进一步进行配置和基准测试，定位系统中的性能瓶颈，并进行进一步的优化。1.2.2 性能指标
前面了解了什么是性能，忽视性能会带来什么结果，以及什么是性能测试，那么性能测试到底要测什么呢？
在讨论软件的性能指标之前，请思考一下汽车和家用计算机的性能指标是通过什么数据来说明的。
对于一个应用系统来说，我们所需要监控的性能指标主要有以下3点。
1．响应时间
响应时间反映完成某个业务所需要的时间。
例如，从单击登录按钮到登录完成返回登录成功页面需要消耗1秒钟，那么就说这个操作的响应时间是1秒。
在性能测试中是通过事务函数来完成对响应时间的统计，事务是指做某件事情的操作，事务函数会记录开始做这件事情和该事情做完之间的时间差，使用Transaction Response Time这个词来说明，也称为事务响应时间。
2．吞吐量
吞吐量反映单位时间内能够处理的事务数目。
例如，对于系统来说一个用户登录需要1秒钟，如果系统同时支持10个用户登录，且响应时间是1秒钟，那么系统的吞吐量就是10个/秒。
在性能测试工具中，吞吐量也被称为TPS（Transaction Per Second，每秒事务数）也就是说在单位时间内能完成的事务数目。TPS的计算一般是通过的事务数除以时间。
3．服务器资源占用
服务器资源占用反映在负载下系统的资源利用率。资源的占用率越低，说明系统越优秀。资源并不仅仅指运行系统的硬件，而是支持整个系统运行程序的一切软硬件平台。在性能测试中，我们需要监控系统在负载下的硬件或者软件上各种资源的占用情况，例如，CPU的占用率、内存使用率、查询Cache命中率等。
对于一个终端用户来说，最关心的指标只有响应时间，如果响应时间长了，那么用户就会觉得系统慢。用户并不关心有多少人使用这个系统以及系统的资源是不是足够，所以从某个角度来说，性能测试必须保证在任意情况下终端用户使用的操作响应时间不大于5秒。
有调查统计，对于一个用户来说，如果访问某系统的响应时间小于2秒，那么用户会感觉系统很快，比较满意；如果访问某系统的响应时间在2～5秒，那么用户可以接受，但是对速度有些不满；如果某系统的响应时间超过10秒，用户将无法接受。
所以对于一个系统来说，需要尽可能保证每一个操作的响应时间在5秒以内，当然某些特殊的操作可能会大大超出这个响应时间，可以通过Loading Bar的方式来提前告诉用户。1.2.3 单机与网络性能测试
在性能测试初期，测试对象都是单机软件，测试目的是确认一个应用在一定的配置下能够以多快的速度完成一个任务，甚至同时完成几个任务。例如，测试Windows下的计算器计算999999的999999次方需要消耗的时间。如果需要对单机软件进行性能测试，关注的目标一般为
业务处理的时间。
是否存在内存泄漏？有没有申请一些没必要的资源？资源的释放是否完全？
最低或者建议的配置如何，给出推荐值。
提示：单机软件的性能不能使用诸如LoadRunner、JMeter等工具进行测试，如果需要可以考虑使用QTP、Rational Purify等工具。
随着网络的发展，系统逐渐网络化，现在需要进行性能测试的绝大多数都是网络架构软件，因为随着客户端用户的增加，系统的负载越来越大，对性能的要求也越来越高。而针对网络架构的软件，我们需要关注的目标如下。
系统的最大处理能力。
系统在各个负载情况下的处理能力。
系统能否进一步调优。
由于网络架构的复杂性（C/S或B/S），需要进行的性能测试也相对复杂，并不能简单地通过一个工具进行分析。
对于C/S架构来说，由于其有独立的客户端，拥有独立的客户端业务处理及自定义的连接协议，所以在编写性能测试脚本时一般会比较复杂，但脚本一般偏短。而访问用户受客户端限制一般访问量能够控制，需求把握准确，由于客户端可以独立处理大量的基础业务，所以性能问题较少。
而对于B/S架构来说，一般来说都是用标准的HTML技术，脚本开发简单，但由于客户端几乎无法完成业务处理，所以代码一般偏长。由于访问用户的不可控，B/S架构的性能需求十分难于确定，而客户端又无法完成业务处理，所有的业务都需要服务器完成，所以性能问题会比较明显的暴露。当使用了Flex或者Silverlight富客户端技术时，也会出现和C/S架构类似的问题。1.2.4 性能测试的流程
在具体介绍性能测试前先简单介绍一下整个性能测试的流程。性能测试相对于功能测试来说复杂很多，但其流程还是类似的，如图1.5所示。图1.5 性能测试的流程首先在进行性能测试前我们需要明确测什么？也就是性能测试的目标，通过需求分析得到性能测试需求。
例如，系统需要满足在500个用户在线、20个用户并发操作发帖的情况下，发帖响应时间不超过2.5秒，系统资源使用率不超过30%。选择性能测试工具。注意性能测试并不是LoadRunner，LoadRunner只是性能测试工具的一种，它并不是在任何情况下都适用，在进行性能测试前，需要对性能测试工具进行可行性分析。确定工具后，即可开始性能测试的准备工作，主要是设计性能测试，其中包括了性能测试脚本的开发、负载的生成规则及监控方式、测试环境的搭建等。准备工作完成，接着开始进行负载，而在负载过程中和负载后需要对相关数据进行分析，这个分析需要众多专家共同协作，找出数据背后的问题，确定性能瓶颈。在确定瓶颈后，进行软硬件方面的调优工作，调优完成后，重新进行前面的、、步骤确认调优的效果是否达到了预期的目标。
具体的实现方法在本书的相关章节中会进行详细的说明。1.2.5 性能测试招聘要求
那么做一个性能测试工程师，需要具备什么样的技术水平呢？
1．熟悉软件测试基本理论
如果没有任何软件测试的基础理论，是无法支持任何测试工作的，而性能测试又属于软件测试，所以掌握基本的测试理论和方法是必需的，可以简单认为如果无法有效地完成功能测试，那么想要做好性能测试也是比较困难的。
2．掌握软件测试常用方法
性能测试是系统测试的一种，对于系统测试来说，需要了解需求分析、测试用例设计、方案计划编写、测试执行及缺陷报告提交等。而性能测试也需要进行相同的步骤，掌握软件测试的常见方法，才能更好地指导我们进行性能测试。
3．熟悉一门编程语言（如Java、C#、PHP）
在性能调优的时候需要对开发语言有一定的了解，并且性能测试也是通过代码来进行的，所以很多时候需要自己编写代码来进行性能测试。
对于编程语言的学习来说，了解被测软件的编程语言是最好的，同时常见的一些脚本语言也会在某些时候提供很大的帮助，例如，Python、Perl、Ruby。
4．熟悉一种数据库管理系统（如Oracle、SQL Server、MySQL）
数据库作为现代软件不可或缺的一部分，从过去数据存储的功能，逐渐发展成为数据库管理系统，除了以前存储的功能以外，还可以通过存储过程触发器等完成业务处理，如果不了解数据库就无法有效地进行容量测试及数据库级别的瓶颈定位及调优。
这里对数据库系统的掌握侧重在系统配置和硬件环境搭建上，随后可以进一步深入了解数据库设计及DML语句调优。
5．熟悉Web服务器（如IIS、Apache、Nginx）
现在所需要进行性能测试的系统大多数都是B/S架构，作为B/S三层架构的第一层，了解常见Web服务器的安装和配置有助于环境搭建和进行性能分析调优。
6．熟悉常见网络协议（如HTTP、TCP）
由于性能测试的特殊性，几乎所有的性能测试工具都是基于协议，所以掌握和了解协议的原理和特征可以更好地理解性能测试的原理。在掌握了协议后，更需要进一步了解该协议下的常见数据包格式和工作原理，便于理解脚本录制及回放原理。例如，对于B/S架构的性能测试还需要了解HTML、XML、CSS、Cookie、Session、AJAX等常见网页技术。
7．掌握性能测试理论
在了解功能测试的理论后，还需要进一步了解性能测试的理论，例如，前面提到的性能测试的概念、常见性能测试的方法等，以此来指导性能测试的实施。
8．熟练使用一种性能测试工具
性能测试是一个综合性的测试，而且不同性能测试工具的针对性也不尽相同，掌握多种性能测试工具可以更好地对症下药。
例如，常见的应用性能测试工具有LoadRunner、Jmeter、OpenSTA。
9．实际工作中需要的其他技能
可以看出想要做好性能测试需要全方面的知识基础，这也是为何在很多职业发展的介绍中都推荐有3～4年测试经验基础后再进入性能测试的原因。1.2.6 性能测试学习阶段
对于大多数进入性能测试行业的朋友，在学习性能测试的过程中都会经历下面几个阶段。
1．工具入门
对于性能测试的初学者来说瓶颈往往是性能测试工具，如何掌握一个工具完成协议的录制、回放、负载是初学者需要经历的一个阶段，而随后能够独立完成简单的场景负载得到对应的负载数据。
完成标准：能够熟练使用工具，了解常见功能的作用及原理。
2．系统业务
终于会用工具了，但是落实到不同的项目中时，由于开发架构、语言、平台的不同会导致脚本回放往往都不会成功。理解协议原理、熟悉系统业务架构成为了第二个门槛。
完成标准：十分熟悉被测系统的数据包格式及实现技术原理，能够合理使用工具完成系统脚本开发，从而进一步进行负载得到最终的负载数据报告。
3．性能需求
在得到了负载数据后，如何编写性能测试报告成为了大问题，到底系统的负载结果能说明什么，这个依赖于对系统性能需求的分析挖掘，最终帮助确认系统是否满足客户需求及调优目标。
完成标准：能够在每次性能测试前明确测试目标，完成性能测试方案及性能测试用例的设计，在性能测试报告中能够清晰地给出测试结论。
4．监控
当能够看懂性能测试报告时，会发现最终数据并不能有效地帮助我们分析、定位性能问题，而一个有效的监控工具和监控结果的分析成为了一座大山。
完成标准：熟悉与系统有关的计数器原理及概念，掌握多种监控工具，完成对系统各个层次或结构的监控，提供清晰有效的监控数据。
5．调优
有了好的监控，再加上常见系统的计数器原理，这下终于知道问题在哪里了，但是这个问题怎么调优呢？开始学习操作系统原理、数据库原理等各种系统架构策略和常见调优技巧吧。
完成标准：了解常见的性能问题，对硬件、操作系统、数据库、应用层等有一定的性能评估及调优能力。
6．脚本开发
当把如何调优这个问题想明白后，会发现最困难的东西回到了原点，怎么使用工具开发出各种脚本，甚至需要自行编写一个客户端来完成对系统的负载。只要能够成功地模拟用户行为对系统产生负载，那么后面的分析、定位、调优就易如反掌了。
完成标准：强大的编程功底，能够重写客户端从而实现各个层次的独立调用，从而实现对任意对象的性能负载，帮助分析、隔离、评
试读结束[说明：试读内容隐藏了图片]