作者：赵强
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
LoadRunner性能测试巧匠训练营试读：
前言
国内软件测试行业人才缺口已突破20万，并随着需求的不断攀升而挺向30万大关。据悉，国外成熟软件企业，一个软件开发工程师对应1~2个软件测试工程师，而国内软件企业，平均8个软件开发工程师才对应1个软件测试工程师，比例严重失衡。国内测试行业在这一点上与国外的差距比较大。实际上，为了保证软件质量，从项目开始测试人员就要介入，要了解客户需求，参与项目评审，把握测试要点。如果测试人员数量少，软件质量是得不到保证的。测试行业的确需要大量人才，尤其是在性能测试方面有丰富测试经验的人才更加稀缺。
另一方面，软件产业是国家鼓励发展的朝阳产业，软件产业要发展，提高软件质量势在必行，这样就产生了对软件测试工程师的大量需求。
由此可见，测试行业需求量大，前景好，但也面临激烈的竞争。所以不断提升自身技能，并明确职业发展方向对所有人来说就显得非常重要了，这样才能抓住一切机会。为什么要写这本书
经常有软件测试的同行和学员向我们咨询：自己读了不少性能测试的书籍和资料，但是仍然无法把性能测试完全灵活地运用于项目中。经过深入的交流后发现，大部分都是“纸上谈兵”式的学习所造成的。对于求职者而言，花费大量精力学习的知识没法运用到项目中，十分苦恼；同样，对于公司而言，高薪招来的人员无法快速切入项目，培养成本大大增加。一本以真实的项目为核心，融技术讲解于项目实战的性能测试书籍是十分必要的。
同时我们也发现，很多书籍描述性能测试知识简单、死板，会使大部分读者感到枯燥、乏味。其实性能测试的学习是一个很快乐的过程，其中充满了挑战、惊险、失望与希望，可以说是痛并快乐着。为了最大限度地提高阅读趣味性，强化出具体的实战测试内容（包括如何发现并解决性能问题等），更好地理解学习性能测试，本书描述了一个刚步入性能测试领域的小兵“小白”在性能测试工作中的学习、成长历程，让读者在充实而惬意、严谨又不失快慰的氛围中掌握性能测试的全部流程以及性能调优方法与技巧！（小兵成长经历纯属虚构，如有雷同，纯属巧合。）
很多读者之所以会步入性能测试领域，也是因为职业发展到了一个瓶颈期，或者是对职业发展进入了一个迷茫的状态，而市面上缺少这种类型的指导书籍。本书最后以真实的人物经历以及职业发展两个方面来帮助读者解答疑问，在黑暗中点亮一盏灯。
最后总结一下，本书并不是单纯地讲解LoadRunner工具，它只是书中的一部分而已。另外，写书不是为了说明自己有多牛，而是知识经验的总结、梳理与分享。不论之前大家是否了解性能，请耐心读完全书，你一定会有非常大的收获，不仅仅是技术上的。我们也相信只有更多的分享、交流才能创造更大的价值，才能为测试界的进步尽一点绵薄之力。本书特色
从技术层面来讲，性能测试的复杂性是不言而喻的，目前性能测试一直处于一个只能发现问题而无法定位并给出解决方案的状态，本书正是为了改变现状而诞生的。
从内容层面来讲，目前很少有此类以全程项目实战和调优为主的性能测试类书籍，实战类型书籍向来是比较受欢迎的书籍，加之内容又以现实的故事为穿插，真实而不枯燥，可读性极强。
从读者层面来讲，很多读者以及大部分学员都没法把知识、方法和技巧应用到实际项目中，存在严重的“纸上谈兵”现象，本书将有望解决此难题。
从测试职业发展层面来讲，技术必然是重要的，但是职业的发展规划也不容忽视，能避免少走弯路，很多读者都对测试的发展有疑问，本书中主人公小白的螺旋上升式发展和众多从业者实录会对读者有所启迪。
读者对象
不论你是否有性能测试基础，也不论你是否了解性能测试，抑或是你已经是性能测试老手，本书都会对你有所帮助。包括但不限于以下读者：
·测试工程师
·开发工程师
·运维工程师
·测试经理
·技术主管
·对性能测试感兴趣的读者如何阅读本书
本书分为四大部分：
第一篇（第1~7章）为“初入职场”篇，全面、细致地讲解了刚刚步入性能测试领域的小白是怎么一步步学习性能测试的，并以实战方式讲解所有知识点。
第1章 本章用实际例子深入浅出地来讲解性能测试的基本知识与模型，带领读者快速入门，摆脱枯燥。
第2章 本章对LoadRunner的脚本开发进行详细实战讲解，并对重要知识点进行深入分析总结。
第3章 本章以LoadRunner的Controller为引子，深入讲解实战中的场景设计、资源监控等重点知识。
第4章 本章以真实案例为蓝本，通过LoadRunner的Analysis进行深入分析，并得出性能测试报告。
第5章 介绍了开源性能测试工具JMeter的基本使用，并结合HTTP、JDBC、SAOP的实际例子演示了JMeter参数化、关联、检查点的基本使用方法。
第6章 本章简单介绍了开源性能测试工具Apache ab的基本使用方法，方便大家开阔视野。
第7章 本章主要对常用的脚本协议开发进行了全面、深入的实战讲解，以具体的例子演示实际应用。
第二篇（第8章）为“新硎初试”篇，重点以实战方式讲解在.NET项目中如何进行性能测试以及性能调优，并把所有知识点融合到项目中，使读者更好地理解并应用，摆脱无趣的理论。
第8章 本章以.NET项目的案例为基础，全面讲解了完整的性能测试项目是如何进行的，把以往的知识点再次融入到实战中。
第三篇（第9章、第10章）为“再露锋芒”篇，重点以实战方式讲解Java项目的性能测试，通过真实的、完整的项目使读者身临其境地体会性能测试、性能调优、安全测试以及最佳流程实践等。
第9章 本章用一个实际的项目完整地介绍了真正的前沿互联网公司项目实战是怎么做的，用真实例子带领大家了解真正前沿的性能测试思想。
第10章 本章全面讲解了安全测试的原理，并结合常用的安全测试工具进行了实战演示。
第四篇（第11章、第12章）为“反躬自省”篇，以真实的在职人物的学习历程、心得以及方法做交流实录，再次以事实指导读者，并针对现状来分析测试人员的职业发展，指导读者的选择与提升路线。
第11章 本章讲述了真实人物在面对转型、提升过程中的奋斗历程，以最淳朴的思想感动你我。
第12章 本章从职业发展角度全面剖析测试行业的点点滴滴，为所有测试人员解惑并给出指导建议。
其中第二、三篇以实战项目来讲解性能测试的应用，如果你是一名有一定基础的性能测试工程师，那么你可以直接阅读这部分内容。但是如果你是一名初学者，请一定从第一部分开始学习。如果你目前对自己的工作有迷茫之处或想得到职业发展上的指导，可看第四篇。本书为读者提供了完整的流程以及细致的解决方案，也能看到小白的成长与不足，这也许正是你的真实写照。
附录总结了LoadRunner常见的问题以及解决方法，让你不必再四处求助。同时也为对编写报告文档感到很头疼的读者提供了各类参考模板。勘误和支持
由于笔者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。你可以将书中的错误发布在BestTest网站（http://www.besttest.cn），同时如果你遇到任何问题，也可以加入我们的QQ群：249854093，我们将尽量在线上为读者提供最满意的解答。如果你有更多的宝贵意见，也欢迎发送邮件至besttest@foxmail.com，期待能够得到你们的真挚反馈。致谢
本书由赵强、邹伟伟、任健勇撰写，其中，赵强写了第1、2、3、4、7、8、11、12章；邹伟伟写了第5、6、9章；任健勇写了第10章。
感谢广大读者对三个老男人的支持，你们的支持与热情才是我们写这本书的最大动力。
感谢机械工业出版社华章公司的杨福川和高婧雅，在这段时间中始终支持我们的写作，你们的鼓励和帮助使得我们能顺利完成全部书稿。
特别感谢BestTest的所有学员给我们提供了不少宝贵的建议与意见，使得本书更加通俗易懂且有趣味性。
最后，谨以此书献给支持我们的小伙伴们以及广大测试同仁，谢谢你们的一路支持与伴随！赵强 邹伟伟 任健勇第一篇 初入职场
小白多年一直勤勤恳恳地奋斗在测试行业，但始终每天重复着黑盒功能测试，虽然自学过一些其他测试技能，但总感觉不系统，自己也深感职业发展到了瓶颈期，希望能有所突破，于是他开始查阅资料，无意间发现了BestTest这样一个网站，里面有不少好资料，经过一段时间的考虑，决定向性能测试的方向发起突击，希望早日突破自己的瓶颈！
说来也巧，这时候收到经理的一封邮件，内容如下。
亲爱的小白：
随着公司与产品的发展，我们的测试技术与手段也要与时俱进，所以准备在后续项目中增加性能测试，而这方面我们没有技术储备，希望你能承担起这个任务，抓紧时间学习性能测试，争取早日应用到我们的项目里。不知你是否愿意接受这个挑战？
这么好的机会小白怎能放过，于是小白毅然决然地接受任务并信心满满地开始了性能测试学习之旅。第1章与性能测试的亲密触碰
性能测试的挑战性和趣味性小白早有耳闻，也会经常听到各个公司因为系统性能而引发的一系列严重问题，所以性能测试会越来越受到重视，只是时间的问题。下面就让我们和小白先来了解下性能测试的趣事，再一同学习性能测试的基本知识。1.1 性能测试的作用以及重要性
随着社会的发展，用户对产品的要求也越来越高，以前可能看重功能方面，现在正在逐步转变为性能方面，同时各大公司也加强了产品的性能测试，因为从这几年发生的事件来看，性能带来的严重问题以及损失不容忽视，而性能测试的重要性也不言而喻。1.1.1 由性能引发的严重问题
小白印象中由性能引发的严重问题历历在目，大部分都是由于没有做性能测试、性能测试做得不充足或者对并发以及流量的预估不正确导致。【案例1】2008年的奥运会票务系统，由于庞大的订票人数超出预期，奥运票务系统“开工”后不久便陷入“瘫痪”状态，当时对外公布的是奥运票务系统每小时能处理15万张门票的销售，以及承担每小时100万次以上的网上浏览量，但10月30日系统死机前每小时的网上浏览量达到800万，1小时售出的票也达到了20万张。由于预估工作的缺陷，导致很多人无法通过网络订到自己想要的票，影响了很多人的热情，也损害了国家形象。【案例2】作为电商的代表，2009年11月22日，eBay网站出现死机，导致卖家至少损失了当日销售额的80%，原因是那年圣诞临近时，eBay网站上有超过2亿件待售商品，这个数字比上一年同期多出33%，正是这激增的33%的待售商品导致eBay网站不堪重负而死机，80%的销售额对于eBay来说不可谓不严重。【案例3】魔兽世界在中国的代理商由九城变更为网易，与九城服务器经常死机不无关系，但是换作网易后，服务器也经常死机。2010年10月11日，魔兽世界服务器故障时，官网论坛上的游戏玩家纷纷发“贺词”表示不满，从这可以看出网易公司对魔兽世界的性能预估存在不足。也正是因为对性能严重忽视间接导致了九城在失去魔兽世界之后，从一家土豪公司成了一家几乎被人遗忘的公司。【案例4】视频网站优酷网也在2010年发生死机事件，超过3小时无法访问。优酷对外宣称的原因是：此次死机事件起源于“地球一小时”活动，优酷网为响应这次活动，全站采用关灯模式，意在借此提醒网民注重环保与节约。但此举令网友一时无法适应，大量网友频繁刷新页面导致优酷网服务器崩溃。【案例5】2010年，中国最大的微博平台新浪微博死机4小时，新浪官方解释说：之所以掉线几小时，是因为用户增长超出预期，服务器备感压力。自上午10点起，用户无法登录，新浪的报错页面几次更改，最初的“微博正在升级，将于11:30恢复”，然后改为“12:00恢复”，过了一段时间，干脆改为“稍后恢复”，然而，估计是看不到恢复希望，提示信息又改为“微博系统压力过大正在抢修，我们深表歉意”。悲剧的是“歉意”竟然写成了“谦意”，这件事遭到网友的大量恶搞，小白也是参与者之一。1.1.2 性能测试的重要性以及必要性
根据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%。
从上面的研究分析再结合小白印象中列举的例子可以看出，性能测试非常重要也非常必要，因为性能问题不仅仅会损害公司的形象，也会造成公司资金方面的损失。1.1.3 什么系统需要做性能测试
小白刚接触到“什么系统需要做性能测试”这个问题的时候，心里在想应该是大型的系统、软件才需要做性能测试，如果只是几个人用就没有必要了。可仔细想想，小白觉得应该是所有系统、软件都应该做性能测试，关键是要思考应该做到什么程度，而不是做不做的问题。因为就算是一个人在使用某个系统，但该系统的查询性能极差，一次查询需要50多秒钟，这绝对是任何人都难以接受的。
接着小白对现有的系统进行了分类，大致分为单机系统、C/S、B/S。这3类系统都应该进行性能测试，只是每个分类有各自特点，在实际测试中应该有不同策略进行应对。
一般C/S架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求等。例如，内存、用户连接数、数据库死锁、数据库cache命中率、运行的最低配置等。
而对于B/S架构的应用程序，会关注Web服务器的相关指标，如每秒点击数、吞吐量、尝试连接数、事务成功率等。
如下几个案例分别针对典型的系统进行了说明。【案例1】假设使用Word来编辑一个1000多页的文档，该文档包含了丰富的图表、图片，需要等待系统花多少秒的时间进行处理。这时需要关注性能响应。【案例2】某业务系统属于二次开发，之前没有做过性能测试，当并发100个用户时就会造成数据库服务器崩溃。这是很明显的性能问题。【案例3】某企业内部信息系统，使用人比较少，但并发时会出现重复的相同记录。这种场景很难在功能测试时出现，所以有时候性能测试并不是只能发现性能问题。【案例4】面向广大互联网人群的网站，每天都需要接受大量的访问请求，服务器压力大，对这样的系统进行性能测试是十分必要的。
其中B/S架构的系统会比较复杂，小白接到的正好是B/S的项目，看来这下需要学习一番了。1.1.4 性能测试的目的
很多第一次接触性能测试的人都会把功能测试的思想带入，造成思维的局限。其实性能测试还是与功能测试有所不同的。性能测试更加关注系统的性能表现，也就是How fast和How much。而做性能测试就是排除系统瓶颈，使得它表现得更好、更霸气。可以从以下几个方面来理解。
1）评估当前系统。系统未做过任何性能测试，对系统的当前性能情况不了解，就好像没有体检过就不知道自己的身体状况一样。而此前说到的一系列性能引发的严重问题也正是由于缺少了必要的性能评估而导致。
2）寻找瓶颈，优化性能。常见的现象为，某业务操作响应时间很长、某系统上线一段时间后运行越来越慢，这些都需要逐步分析定位并调优。
3）预测未来性能。当用户数和业务量增加时能否及时应对？如何调整？是增加应用服务器，还是数据库服务器？还是要优化代码逻辑？这一系列问题都值得我们深思，这也是性能测试的目的所在。回想1.1.1节中的eBay不就是最好的例子吗。1.2 生活中的性能测试
小白对性能测试有所了解后，不自觉地联想到了实际生活中的现象，他突然发现原来性能无处不在。每天上下班的高峰，不论是地铁，还是公交车都反映了交通的性能状况。就拿地铁来说，上下班高峰期进站就是出现了严重的性能问题，表现为缓慢、堵塞、拥挤甚至打架！对于性能测试来说不也是这样的吗？小白继续思考着，缓解地铁压力的方式无非就是限流，增加通道、发车频率、列车长度和进站路径复杂度等，这似乎又能和性能测试挂上钩了。
再想想让我们又爱又恨的12306。这简直就是一个活生生的例子，网站页面响应很慢，查火车票更慢，下单还经常失败，服务死机更是家常便饭，小白越想越气，起早贪黑地抢票，每次都空手而归。小白想如果对产品设计、开发、测试、运维部署中的每个点都进行优化，也许就会比现在的情况好很多。比如，页面设计简洁，去掉那些花哨的元素；对后端的业务进行拆分；把火车票的数据分区，并放在各个省市等。理想很丰满，但现实很骨感。不过小白也明白了一点：学习性能测试多与实际生活中的现象进行类比更容易理解。1.3 性能术语与指标详解
小白理解了性能测试后就开始了性能测试基本概念的学习，首要任务就是深入理解重要的术语和指标，因为对这些术语和指标的理解是否深入、透彻，将直接影响后续的学习效果。1.并发数
在理解并发数之前，先提出3个常见的概念，分别是系统用户数、在线用户数和并发用户数。小白发现很多人都会把这3个概念混淆，其实是不一样的。以BestTest的论坛作为例子，对应的解释分别如下。
·系统用户数：简单地说就是该系统的注册用户数。例如，BestTest论坛里存在6666个注册用户，他们可以是活跃的，也可以是僵尸的。
·在线用户数：即登录系统的用户。例如，其中有666个用户的状态为在线，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。
·并发用户数：是对服务器产生压力的用户。例如，可能在线的666个用户中，只有20%的用户对服务器产生了压力，这20%的用户数就是并发用户数。
那为什么要关注并发用户数而不是其他用户数呢？上面已经提到过，最直接的原因就是只有并发用户数才对系统产生真正的压力。就好像一个人提1斤的东西不觉得重，但是提150斤的东西，那可就难以提动了。
在实际应用中，并发数可以通过分析服务器日志得以确定，这种方式更加准确。一般常用的日志分析工具有AWStats、Webalizer、Analog、Deep Log Analyzer等。也可以通过业界的一些计算模型得到，后续章节中会学习。
这里再延伸一下并发的概念。一般有两种理解方式：一种为所有用户在同一时刻做同一种操作，主要是为了验证程序或数据库对并发的处理能力；另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同的操作，类似于混合场景的概念。
2.响应时间
小白通过查找资料发现，大部分资料都是说“响应时间=网络响应时间+应用程序响应时间”诸如此类的解释。小白一时间有点摸不着头脑。于是，静下心来开始认真分析、研究。
我们可以换个角度去看待这个概念。首先从大的方向上可以把一个系统分为前端与后端，而响应时间也可以按照这个划分来理解。让我们先看图1-1再来理解。图1-1 请求与响应
通过图1-1可以清楚地看出在没有缓存的情况下，一个请求发出去后，需要经过网络传输、DNS解析等步骤才能到达服务器，服务器处理完后，经由网络传输返回给客户端，而客户端接收到以后，要进行解析渲染展示给用户。这里需要注意，网络时间包括请求传输的时间和响应传输的时间，而服务器也可能是多层处理。
这下逻辑就非常清楚了，可以总结为：响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间+页面前端解析渲染时间。小白终于明白响应时间背后的来龙去脉了。
在实际应用过程中，需要明白响应时间的长短取决于用户的实际需求，而不是盲目设定该指标。毕竟在BestTest论坛查找一个帖子和在数据统计系统中查找一个月的数据汇总与明细统计是完全不同的，它们的业务有各自独有的特点，不能简单地一概而论。
注意 前端页面的解析展示时间一般在做非前端性能测试中不太会关注，因为每个浏览器解析页面的方式不一样，时间也会不一样。
3.每秒通过事务数
TPS是指每秒通过事务数，是直接反映系统性能的指标，该值大时，系统性能会比较好，当然每个系统都有它的上限，不可能无限大。将它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。
例如，当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的多少而改变。就好像传说中的北京五道口地铁检票机一样，只有两台进站检票的机器，一次一台机器只能通过一个人，不论是来10个人，还是100个人。
4.每秒点击数
每秒点击数代表用户每秒向Web服务器提交的HTTP请求数。但这里需要注意的是提交一个登录请求，对于用户来说感觉是一个请求，但对于后端服务器来说也许是多个请求，所以点击一次不代表就是一个请求。例如，点击一个链接，该操作返回的页面上有6张图片，因为下载每张图片都需要一个HTTP请求，所以这个页面下载完成之后的点击数应该是7。
每秒点击数从侧面可以反映客户端的状况，每秒点击数不正常，一般可能是网络问题或者脚本问题导致，需要进一步具体分析。
5.吞吐量
经常在网上看到“吞吐量”与“吞吐率”的概念，也有不少人把两者混淆。吞吐量是指单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。而吞吐率一般指用户在给定的一秒内从服务器获得的数据量，简而言之就是服务器返回的数据量。
例如，一个食品厂的生产效率很高，一天能生产很多食品，但是工厂只有两辆三轮车在运输，不难想象会出现什么样的可怕场景。这个时候工厂运输食品的能力就成为了瓶颈，也就是它的吞吐量/吞吐率出现了瓶颈。
6.思考时间
思考时间可以从两个宏观的角度来理解。
1）思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。因为在实际使用中不太可能会出现不断地发送请求，一般都是一个请求后，等待一段时间，然后发送下一个请求，恶意攻击除外。
2）小白发现在BestTest论坛连续发帖时会提示“两次发帖时间间隔不能小于15秒钟”，这时如果要满足业务的特定需求就需要加上思考时间15s了。这下小白对思考时间有了进一步的认识，很是高兴。
另外，小白经常在网上看到关于0思考时间的讨论，自己也有点疑惑，于是请教了经理。经理告诉他，如果想了解系统的最大承受能力或者极端情况下系统的性能表现，则可以设置为0思考时间。但如果是预估系统的性能，就应该最大可能地模拟真实思考时间。一般都会加上思考时间，只是在分析时要去掉思考时间。
7.资源利用率
小白通过查找资料发现，关于资源利用率的资料太多也太杂，根本无法梳理，而且会越看越乱，无奈之下向经理求助，经理告诉他虽然指标很多，但很多时候每个指标间都是有关联的，而且重点的就是那么几个，只要把这几个理解透彻就行了。小白按照经理的指导开始学习、理解重点的几个指标。
·CPU：它就像是人的大脑，主要是进行判断和处理，能反映出系统的繁忙程度，一般分为系统CPU与用户CPU，其中系统CPU是处理系统本身所占用的资源，用户CPU则是处理程序所占用的资源，对象不同。
·Load Average：指一段时间内CPU正在处理和等待CPU处理的任务，也就是CPU使用队列的长度的统计信息。这里的Load Average值就好像地铁里等待进站上车的乘客，越多则Load Average值也越大。
·Memory：它就像是人大脑的记忆区域，将各种信息收集起来存放。数据从内存中读取要比从磁盘上读取速度快，而内存经常发生内存泄露或内存溢出的现象，是需要重点留意的。不过这里需要注意，短时间的可用内存越来越少，不代表一定有内存泄露或溢出。
·队列：可以理解成地铁进站的排队现象，队列长，说明处理能力可能达到了极限或者遇到了阻塞。
·IO：与磁盘的交互，重点关注交换频率和磁盘队列长度。
·网络：重点关注网络的流量，看是否存在网络带宽的瓶颈。
虽然小白把这些指标的含义都弄清楚了，但是具体用法以及如何判断是否会出现问题还是不太懂，不过小白心里也清楚，这事得一步步来。先把基本概念和重点指标理解清楚了才是最重要的，只有这样，以后分析起来才能有头绪、有突破口，否则会很被动。想到这里小白会心一笑，心里暗想加油吧！1.4 性能测试分类详解
小白在学习过程中发现性能测试的种类繁多，但是实际执行起来又很难严格区分，所以小白觉得理解各种分类的特点和概念即可，没必要咬文嚼字。
1.基准测试
基准最简单的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化。一般情况下，基准测试有以下几种应用场景。
1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。例如，数据库的基准性能测试。
2）系统进行基准测试可以在较早的阶段发现性能问题。例如，如果对BestTest网站进行10个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。
3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。这是基准测试常见的一种场景，也是大部分没有做过性能测试的公司最需要的。
虽然基准测试不难理解，但实践起来常常被误解。以对某个系统的数据搜索进行性能基准测试为例，这个系统的数据量会随着时间的增长而增长，所以必须频繁地进行基准测试，这样才能准确地把握数据量的增长对系统性能的影响。但因为进行的基准测试又恰恰是在应用程序级别的，并不能客观地反映全局性的性能。所以，比较好的做法是每次只修改一个地方，这样就能准确地判断出哪个地方会对性能产生影响。
2.并发测试
并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题。例如，内存泄露、线程锁、资源争用等，几乎所有的性能测试都会涉及并发测试。并发测试的主要目的是找出并发引起的问题。
那并发数又如何确定呢？小白通过查找资料得知，一般可以通过以下几种方法推算需要的并发数。
1）并发数=PV/PV Time×页面连接次数×HTTP响应时间×因数/Web服务器数量。
其中，PV Time是PV的统计时间，换算成秒，一天是86400s。页面连接次数包括外部的JS、CSS、图片等，一般为10。HTTP响应时间一般可为1s或更少。因数一般为5。
假设，BestTest官网每天有6万PV，其余参数保持默认，那么推算出来的并发数大致为35。
提示 PV（page view）即页面浏览量。一个用户有可能创造十几个甚至更多的PV。它是目前判断网站访问流量最常用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。
2）著名的经典理论80-20原则。
3）参考段念老师在《软件性能测试过程详解与案例剖析》一书中提到的估算方法。
当然，上面的方法仅供参考，需要根据实际的系统特点、业务特点来衡量。
3.负载测试
负载测试可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每秒通过事务数和其他相关指标。
从另一个角度理解，负载测试可以看作是性能测试的一部分，但它们两者的目的是不同的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。因为在性能测试过程中，也可以不调整负载，而是在同样负载情况下通过改变系统的结构、算法、硬件配置等来得到性能指标。
4.压力测试
压力测试可以理解为没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。仍然以生活中的例子来说明，压力测试就好比跑马拉松，看你到底能跑多久，什么时候就坚持不住了。
压力测试也可以看作是负载测试的一种，即高负载下的负载测试。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能可以正常使用或者出错的概率比较低，但在压力测试下可能很快就会出现，帮助我们提早发现性能问题。
小白想起，公司之前有个网站，在用户少的时候没有什么问题，但在用户多时就暴露出了一些问题，经常会有异常报错产生。看来公司的网站真的需要进行性能测试来评估了，小白心里暗想。
注意 负载测试与压力测试的概念并非完全独立，读者大可不必纠结于文字概念。在实际应用中一般二者都是相互结合、相互补充的。
5.稳定性测试
稳定性测试顾名思义重点在于“稳定”二字，要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩溃等现象。一般都会进行所谓的7×24小时的稳定性测试。
但稳定性测试也有和其他分类不一样的地方，这里需要强调以下两点。
1）一般稳定性测试需要在系统成型后进行，并且没有严重的Bug存在。
2）场景的设计以模拟真实用户的实际操作为佳。
6.失效恢复测试
失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。怎么理解呢？很简单，以跑马拉松为例，为了预防出现跑不动的情况，预先准备了一瓶红牛（应该给我广告费），当选手累得躺下后，拿出这瓶红牛一口气喝了，然后你有力量了，恢复了原来的状态，站起来继续跑。这下理解了吧。
不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。
在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快速响应。
小白学到这里也明白了原来性能测试中需要关注许多点，既要有对某个点的思考，也要有扩展点的思考，否则容易遗漏或得出片面的结论，而不能从根本上来预防解决问题。
7.现网性能测试
所谓现网性能测试，就是在实际网络、实际环境中进行测试，完全和真实用户一样。当然这样的测试有一定的风险，需要注意以下几点。
1）时间段的选择。现网性能测试可能会影响正常用户，所以这样的时间段要尽量避开高峰期，选择半夜或者凌晨来进行。
2）垃圾数据处理。如果现网性能测试涉及了写数据的操作，那么肯定会带来不少的垃圾数据，这些数据后期一定要清理，为了清理方便，前期数据的设计要有规律可循。
3）网络限制。和在内网测试不同，现网的测试如果突然间产生大的数据量，可能会被网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。所以如果在现网进行性能测试，那么压力机需要和被测服务器部署在同一个网段机房内，这样可以避免网络限制，最后远程收集数据即可。
如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进行，一定要事先充分评估风险以及应对的解决方案，这样出了问题可以快速响应，把影响控制到最小。1.5 性能测试模型分析
经过上面的学习，小白对基本的性能测试概念等有了深刻理解，为了能把这些概念应用到实际项目中，小白开始对典型的性能测试模型进行学习，逐步把概念、指标运用起来，并培养自己的观察分析能力。1.5.1 曲线拐点模型分析
对于初学者来说，培养观察与分析思想是很重要的，首先来看一张典型的曲线拐点模型图，如图1-2所示。图1-2 曲线拐点模型
分析图1-2最好是先看一个个指标，然后再综合分析，这样的步骤更容易理解，思路也更加清晰明了。接下来就和小白一起来分析吧，分析思路如下。
1）X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
2）然后一个个分析，根据前面学习的性能术语与指标进行理解，随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。
分析到这里，小白终于找到点成就感了，同时也庆幸自己没有忽略基础，看来基础对于日后的学习有着重要意义！1.5.2 地铁模型分析
和绝大部分人一样，小白每天都要乘坐地铁上下班，那么就拿地铁来分析，再次深刻理解下性能。早上乘坐地铁上班，最典型的就是北京地铁1、5、10、13号线等，人多得简直没法形容！为了方便理解分析，先做如下假设。
·某地铁站进站只有3个刷卡机。
·人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。
·乘客耐心有限，如果等待超过30min，就会暴躁、唠叨，甚至选择放弃。
按照上述的假设，最初会出现如下的场景。
场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。
场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。
场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
想到这里，小白越来越觉得有意思了，原来技术与生活这么息息相关，真的可以快乐学习哦。随着上班高峰的到来，乘客也越来越多，新的场景也慢慢出现了。
场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队，等A、B、C三名乘客进站完成后才行。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。
通过上面这个场景可以发现，每秒能使3名乘客进站，第1s是A、B、C，第2s是D、E、F，但是对于乘客D、E、F来说，“响应时间”延长了。
场景五：假设这次进站一次来了9名乘客，根据上面的场景，不难推断出，这9名乘客中有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。
场景六：假设这次进站一次来了10名乘客，根据上面的推算，必然存在1名乘客的“响应时间”为4s，如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。
场景七：如果地铁正好在火车站，例如，著名的北京西站、北京站。每名乘客都拿着大小不同的包，有的乘客拿的包太大导致卡在刷卡机那（堵塞），这样每名乘客的进站时间就会又不一样。
小白突然想到，貌似很多地铁进站的刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽），这样就能避免场景七中的现象。
场景八：进站的乘客越来越多，3台刷卡机已经无法满足需求，于是为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。
场景九：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。
分析到这里，小白可以熟练地把性能指标与场景结合运用起来了，初步学习成果还是不错的。1.6 本章小结
通过本阶段的学习，小白深入理解了性能测试的作用、重要性以及意义，同时掌握了重要的术语、概念、指标，并把这些知识应用到实际生活场景中，经过深刻学习产出了两个经典模型。
虽然第1章为基础知识，但对于学习整体的性能测试知识尤为重要，如果不能很好地理解和掌握这些基础，后续的学习将会变得凌乱不堪，这也是很多读者最容易犯的错误，切忌不要浮躁！
接下来小白将学习现在十分流行的商业性能测试工具LoadRunner，他又会遇到什么问题呢？让我们继续往下看吧。第2章LoadRunner VuGen实战
经过上面的学习，小白已深入理解了性能测试，接下来小白需要通过一个性能测试工具来引导他动手实践，毕竟实践才是王道。
经过查找资料，小白发现性能测试工具貌似比较多，但LoadRunner是目前比较流行的，所以小白决定先学习最流行的性能测试工具。下面就和小白一起来见识下LoadRunner 11的强大功能吧！2.1 LoadRunner快速安装
在Windows下安装软件一般都是4个步骤：下载、安装、配置、验证。小白到HP的官网找到了LoadRunner 11，因为据说这个版本比较好用、稳定，所以小白决定就用它了。
1）下载后双击安装包中的setup.exe，然后按照提示一步步安装即可。提示
安装LoadRunner时需要先确认如下几点。
·LoadRunner 11不支持Windows 8系统。
·软件安装到非中文目录下。
·如果是Windows 7系统，请右击鼠标后选择管理员权限进行所有安装操作。
·安装之前请关闭360、腾讯管家、杀毒软件等类似的管理软件。
2）完成安装后将会在“开始”菜单看到LoadRunner，如图2-1所示。
3）单击图2-1中的LoadRunner，即可出现如图2-2所示主界面。
至此，LoadRunner的安装就算完成了。图2-1 LoadRunner菜单图2-2 主界面
注意 建议使用LoadRunner的英文版，比较稳定，中文版会出现一些莫名其妙的问题。
LoadRunner的性能测试过程一般为计划测试、创建脚本、设计场景、运行场景、分析结果。小白也将按照此过程进行学习。2.2 LoadRunner组成与示例程序
完成LoadRunner的安装后，小白迫不及待地想试试这个软件的威力如何。下面就跟随小白继续学习吧。
1.LoadRunner的三大组件
LoadRunner由三大基本组件构成，分别是VuGen、Controller、Analysis。那这三个组件的作用如下。
·VuGen：是录制与编写脚本的地方，就是通过录制或编写脚本来模拟用户的行为，可以理解为用户行为模拟器，同时会打印出日志信息，方便调试脚本。VuGen也是一个集成开发调试环境，在这里完成脚本开发并调试通过后就可以放到Controller中来创建场景了。
·Controller：是性能测试场景设计以及监控的地方，让脚本按照预定的规则运行并产生压力，同时监控重要指标等都在此处完成。
·Aanlysis：是收集测试数据后生成图表报告的地方，能帮我们分析数据并产生图表，方便进行后续的分析。
2.WebTours示例程序
LoadRunner还提供了一个示例程序WebTours供我们练习。启动菜单为“开始”→HP LoadRunner→Samples→Web，如图2-3所示。
出于好奇，小白直接单击了HP Web Tours Application的链接，结果出现了如图2-4所示的报错页面。图2-3 示例程序图2-4 报错页面
根据自己的猜测应该是某个服务没有启动导致的。所以小白下意识地单击Start Web Server，然后再次访问该地址，终于见到WebTours的真面貌了，如图2-5所示。
于是他单击图2-5中的Sign Up Now链接并注册了一个名为besttest的用户，登录成功后出现如图2-6所示的页面。图2-5 WebTours图2-6 登录成功页面
提示 推荐使用IE 6或IE 9，并设IE为默认浏览器，同时选中“浏览器”，之后选择“工具”→“Internet选项”，在弹出的“Internet属性”对话框中选择“高级”选项卡，在其中选中“启用第三方浏览器扩展”。2.3 深入理解协议选择
上述操作完成后，小白立刻打开VuGen，想看看传说中的LoadRunner到底如何。就在他刚刚兴奋起来时却看到如图2-7所示的界面，原来还要熟悉协议才行，因为协议对于LoadRunner来说是很重要的。图2-7 协议
那么接下来，就按部就班地来学习协议的相关知识吧。
首先需要明白协议是什么？可以把协议理解为数据包在交换、通信时要按照统一的约定，这样双方才能识别，否则一个用A格式，一个用B格式，那不就对不上号了吗？当然也就无法识别了。所以，协议的选择至关重要。
其次，LoadRunner与协议又有什么联系呢？LoadRunner录制时不关心对象是什么，LoadRunner有一个Agent进程来专门监控客户端和服务器之间的通信。所以，LoadRunner录制时关心的是通信，是客户端和服务器之间的数据包，也就是协议。
小白在BestTest论坛上看到有许多人会问为什么有时LoadRunner不能录制或录制出来的脚本为空。也许就是这个原因，因为LoadRunner不认识用户的协议，所以LoadRunner截获的数据包不能解析。
也有很多人认为只要是B/S结构的，都选择HTTP，如果不是B/S的，就选择Socket，这种说法是比较片面的。因为一般Socket是万能协议，任何对象都可以通过它来传输。所以要真正理解这个问题，必须清楚所测系统的数据流采用什么协议包装。最好能向开发人员多了解，多学习。
到这里小白还有一个疑问：这么多协议一般该怎么选择呢？带着这个疑问，小白查阅资料后做出如下总结。
·Web类型网站：协议选用HTTP/HTML。
·FTP服务器：协议选用FTP。
·邮件服务器：协议选用IMAP（同步邮件电子邮件）、POP3（接收电子邮件）、SMTP（发送电子邮件）。
·以ADO、OLEDB方式连接后台数据库的C/S客户端：协议选用MS SQL Server、Oracle、Sybase、DB2。
·以ODBC方式连接后台数据库的C/S客户端：协议选用ODBC。
·没有后台数据库的C/S客户端：协议选用Socket。
虽然总结不是十分全面，但是对于我们已经足够用了。为了方便，小白选择使用WebTours程序来进行后续的练习。2.4 脚本编写实战
知识的学习都是从易到难的，所以小白选择了最简单的场景。以提前注册好的用户名besttest，密码123123完成登录、退出的业务。别小看这么简单的场景，也许你也和小白一样遇到了不少问题呢。
通过“开始”菜单下的HP LoadRunner→Application→Virtual User Generator打开并新建一个空白的Web（HTTP/HTML）协议的脚本，首次会出现Task视图界面，如图2-8所示。图2-8 Task视图界面
初学者可按照图2-8中的步骤学习。因为这里不使用此视图，所以切换到Script视图界面。
提示 LoadRunner的VuGen支持C语言开发、Java语言开发以及.NET语言开发，几乎支持目前主流的开发平台，十分强大。这里以C语言为主。2.4.1 脚本录制
在开始录制之前有必要了解LoadRunner的录制原理。当使用VuGen进行录制时，会使用代理来访问服务器，这样就把客户端和服务器之间的通信数据包捕捉了下来，然后LoadRunner通过对应协议的API进行脚本封装，最终以良好的形式展现在VuGen中。
了解录制原理之后，就开始录制脚本。打开LoadRunner的VuGen组件，新建一个Web（HTTP/HTML）协议的脚本，弹出Start Recording（开始录制）对话框，如图2-9所示。图2-9 “开始录制”对话框
下面对图2-9中的主要选项进行学习。
·Application type：一般默认为Internet Applications，即B/S应用。这里的WebTours使用该默认选项。Win32 Applications则是用来支持标准的Win32客户端。
·Program to record：指定录制时使用的浏览器，默认为IE。提示
如果调用浏览器时出现异常，可以手工在此指定IE的完整绝对路径，如“C:\Program Files\Internet Explorer\iexplore.exe”。对于Windows 7 64位操作系统的用户需要注意的是，IE可以指定为“C:\Program Files（x86）\Internet Explorer\iexplore.exe”。
另外，建议浏览器保持干净，不要安装多余的插件，否则会出现一些莫名其妙的问题，浪费我们的宝贵时间。
·URL Address：填写要录制的程序地址URL。
·Working directory：脚本存放的工作目录。
·Record into Action：包含vuser_init、Action和vuser_end。它们的区别是vuser_init和vuser_end中的脚本代码只执行一次，而Action中可以执行设定的次数。同时集合点也只能在Action中设置。至于集合点是什么，我们后面再学习。这里默认选择Action即可。
单击图2-9中的OK按钮后，LoadRunner调用IE打开WebTours网站并录制。开始录制后，在屏幕上出现如图2-10所示的浮动工具条，通过该浮动工具条可以完成暂停录制、停止录制、Action切换以及其他动作。图2-10 录制结束导航
录制完成后，生成的完整代码如下。
代码清单2-1 登录、退出完整代码Action（）{ //打开Web Tours首页web_url（“WebTours”， “URL=http：//127.0.0.1：1080/WebTours/”， “TargetFrame=”， “Resource=0”， “RecContentType=text/html”， “Referer=”， “Snapshot=t5.inf”， “Mode=HTML”， EXTRARES， “Url=http：//conf.xmp.xunlei.com/vus/vipjs/vus_utility.js”， ENDITEM， “Url=http：//conf.xmp.xunlei.com/vus/vipjs/vus_config.js”， ENDITEM， “Url=http：//conf.xmp.xunlei.com/vus/vipjs/vus_finder.js”， ENDITEM， LAST）；web_url（“videourlsnifferconfig.xml”， “URL=http：//conf.xmp.xunlei.com/videourlsnifferconfig.xml”， “TargetFrame=”， “Resource=0”， “RecContentType=text/xml”， “Referer=”， “Snapshot=t6.inf”， “Mode=HTML”， EXTRARES， “Url=http：//conf.xmp.kankan.com/vus/vipjs/vus_main.js”， “Referer=”， ENDITEM， LAST）；web_url（“config.xml”， “URL=http：//plugin.xl7.xunlei.com/coop/thunderbho/2.5.x.xxxx/config.xml”， “TargetFrame=”， “Resource=0”， “RecContentType=text/xml”， “Referer=”， “Snapshot=t7.inf”， “Mode=HTML”， LAST）；lr_think_time（56）；web_url（“IE9CompatViewList.xml”， “URL=http：//ie9cvlist.ie.microsoft.com/IE9CompatViewList.xml”， “TargetFrame=”， “Resource=0”， “RecContentType=text/xml”， “Referer=”， “Snapshot=t8.inf”， “Mode=HTML”， LAST）；lr_think_time（32）； //提交登录信息web_submit_data（“login.pl”， “Action=http：//127.0.0.1：1080/WebTours/login.pl”， “Method=POST”， “TargetFrame=”， “RecContentType=text/html”， “Referer=http：//127.0.0.1：1080/WebTours/nav.pl？in=home”， “Snapshot=t9.inf”， “Mode=HTML”， ITEMDATA， “Name=username”， “Value=besttest”， ENDITEM， “Name=password”， “Value=123123”， ENDITEM， “Name=login.x”， “Value=53”， ENDITEM， “Name=login.y”， “Value=9”， ENDITEM， LAST）；lr_think_time（9）； //退出Web Toursweb_url（“SignOff Button”， “URL=http：//127.0.0.1：1080/WebTours/welcome.pl？signOff=1”， “TargetFrame=body”， “Resource=0”， “RecContentType=text/html”， “Referer=http：//127.0.0.1：1080/WebTours/nav.pl？page=menu&in=home”， “Snapshot=t10.inf”， “Mode=HTML”， LAST）；return 0；}
小白看到产生的脚本有点晕了，这脚本应该怎么看呢？于是他向经理求助。经理告诉他，学习LoadRunner最好的小伙伴就是F1的函数帮助手册，它可以说是绝佳“利器”。
注意 在LoadRunner的录制过程中，请勿使用浏览器中的“后退”按钮。LoadRunner对该功能的支持不好。2.4.2 “利器”——函数手册
于是小白就用经理告诉他的“利器”函数手册来学习。首先来看下web_url函数。这个函数对应的业务操作是打开WebTours首页。具体函数信息可双击选中web_url后，按F1键查看，出现说明，如图2-11所示。
试读结束[说明：试读内容隐藏了图片]