性能测试实战经典Word格式.docx

1、 Analysis使用基础 335.1.3 一个视频网站例子 397.1 认识Java虚拟用户 527.1.1 Java虚拟用户协议 527.1.2 Java虚拟用户适用范围 547.1.3 脚本开发环境配置 557.2 Java脚本开发基础 587.2.1 Java虚拟用户开发基础 597.3 Java算法测试案例 697.4 本章小结 90前言 在作者的另一作品Web性能测试实战中，曾经提到过“软件亚健康”这个概念。现在，亚健康不但威胁着IT人的生活质量，也威胁很多应用软件的性能。为此，在Web性能测试实战一书中，作者提出了“全面性能测试模型”，期望能够成为解决软件亚健康问题的一剂“良药”

2、。“全面性能测试模型”包含了测试策略制定、测试用例设计、模型使用方法三部分内容，基本覆盖了性能测试规划和设计的相关内容，为开展性能测试提供了一种可行的方案。借助本模型，软件开发和测试人员可以更好的组织与规划性能测试，避免在项目后期遭遇性能问题的被动局面。不过要想做好性能测试，仅有性能测试模型还是远远不够的，因为还缺少像LoadRunner这样令性能测试工作如虎添翼的性能测试利器。本书将和读者一起深入LoadRunner的性能测试世界，探讨在企业的性能测试项目中如何应用它来发现应用系统存在的性能问题。LoadRunner在性能测试中的地位对于很多使用LoadRunner的测试人员而言，性能测试工

3、作中最大的障碍就是测试脚本开发与测试结果分析，这导致很多测试人员忽略了测试规划与设计的重要性，反而认为能开发测试脚本、运行测试场景、分析测试结果就算做好性能测试了。要想做好性能测试，首先应该把重心放在测试的规划与设计上，尤其要注重测试用例的设计，仅仅能写测试程序与运行测试脚本是远远不够的。诸如LoadRunner等测试工具仅仅是性能测试的执行与分析工具，它们应该服从于测试设计人员的意志。测试工具的使用属于测试人员的基本功，应该在开展性能测试工作前修炼好。只有好的测试用例或者测试场景才能发现系统的问题，这才是性能测试的本质所在。性能测试分析同样依赖于前面工作的输出结果，不是随便一个测试结果就能发

4、现问题的。所谓“万丈高楼平地起”，性能分析的准确性同样取决于此前所做的设计与实施等“地基”是否可靠。可以说，性能测试分析仅仅是百米赛跑的最后二十米而已。当然，这并不是说性能测试分析不重要，因为“最后冲刺的二十米没有跑好”，前面工作做的再好也是徒劳的。因此不难理解，性能测试分析工作开展的根基就是前面测试场景执行的结果。要想保证性能测试分析的结论是正确的，则测试结果数据首先就应该是正确的，而这也意味着测试场景以及测试执行过程都应该是正确的。实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣，性能测试工程师应该认真对待各个阶段的工作。如果一味地追求找出系统瓶颈，无疑是舍本逐末

5、的做法。因此，在性能测试工作中首先要做好性能测试的规划与设计工作，然后再借助LoadRunner的强大功能来发现系统存在的问题。如何通过本书学习LoadRunner首先应该弄清楚学习LoadRunner的目的，那就是在项目的性能测试中应用LoadRunner来发现系统的性能问题。因此，仅仅会用LoadRunner还远远不够，这也是为什么很多培训班出来的学员虽然把工具用的非常熟练，但是仍然不能做好性能测试工作。学好LoadRunner的标准是真正能够把LoadRunner应用到实际项目中去，这就要求学习LoadRunner的同时一定要学好性能测试相关知识。本书的第1章即为基本的性能测试知识，读者

6、需要认真体会这些内容，建议在学习后面的内容时，经常翻阅本章的内容。如果要学习更多的性能测试规划与设计的知识以及性能测试案例，建议读者参考本书的姊妹篇Web性能测试实战。本书的第2章是LoadRunner的简介部分，读者需要通过本章了解LoadRunner的工作原理、测试流程、部署与安装等内容，尤其要掌握图2-1所示的LoadRunner工作原理，这是用LoadRunner开展工作的基础。本书的第3章、第4章、第5章分别讲解了LoadRunner的Virtual User Generator、Controller、Analysis。这三大组件分别负责脚本的录制与开发、场景的创建与执行、测试结果分

7、析工作。用LoadRunner来开展性能测试，必须要掌握这三大组件的使用。如果连基本的工具都没有用好，很难正确地执行设计好的测试用例，更不用说根据结果来分析系统的瓶颈了。在第35章中，详细探讨了LoadRunner各个组件的使用细节，但是这还远远不够，尤其对于那些只会录制或者简单修改录制结果的测试人员！学习这三章的内容时，最好的方法是结合LoadRunner的联机帮助文档，这样可以学习到更多的内容。学习完第35章后，可能还有一些读者会问：“我还是不会自己写测试脚本，很多协议仍然不能进行测试怎么办？”碰到这种情况就需要补习自己的开发知识了。开发知识应该分两个方面来学习：一是面向对象基础知识的学习

8、，二是开发语言的学习。很多人可能会认为面向对象基础知识比较通用，相对容易学习；而开发语言种类繁多，不知道如何入手。根据作者的经验，这两个方面应该结合起来进行：面向对象是现在主流开发语言的灵魂，一起学习可以互相促进。具体做法就是选择C+、Java、C#等一种主流语言来学习，只要这门语言是自己所在公司的主流语言即可。当学会面向对象基础和一门语言后，再去学习其它的语言将会非常容易。具有一定的开发能力后，就可以开始本书探索篇第69章的学习。这四章是LoadRunner的探索篇，讲解了在LoadRunner中如何应用C+、Java、C#语言进行开发以及一些特殊的脚本协议。相信通过前面9章的学习，读者已经

9、掌握LoadRunner的精髓了。不过本书不是一本“LoadRunner使用百科大全”，接下来就需要读者自己不断地应用与探索LoadRunner了，逐步完成成为一个LoadRunner高手的蜕变过程。如何学习本书的性能测试案例本书在第10章中，花了很大的篇幅介绍了一个电子商务平台的性能测试案例，目的不是为了介绍如何测试电子商务系统，而是让读者在掌握前面技能的基础上，更加深入地体会在项目中如何通过LoadRunner来实施性能测试。因此，案例的业务并不重要，读者也没有必要深究具体的细节。通过本案例，能清晰地了解了能测试的整个过程就已经达到了目的。本书案例的学习重点在以下几个方面：l 借助案例体会

10、“全面性能测试模型”在GBE项目中的应用； 学习性能测试规划与设计中的需求分析过程，例如测试环境需求、人力资源； 学习性能测试规划与设计中的测试场景分析与设计、测试用例设计； 学习如何做好性能测试实施前的准备工作； 测试执行过程的进度与变更控制； 一些分析性能问题的过程。关于性能测试案例更多的内容，读者可以阅读Web性能测试实战中的案例部分。关于本书本书的主旨在于让读者学会LoadRunner的应用，并能在此基础上自行探索性能测试世界。本书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一部分：入门篇，包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。在第1章中，讲解

11、了性能测试基本概念、全面性能测试模型、性能测试调整等基础的性能测试理论知识；第2章则介绍了LoadRunner的特点与术语、工作原理、测试流程、部署与安装等内容。第二部分：基础篇，包括第3章至第5章，着重讲解LoadRunner三大组件的使用，是LoadRunner的基本使用部分。在第3章中，主要讲解如何在Virtual User Generator中完成代码的录制与开发；第4章讲解如何在Controller中创建与执行场景；第5章中讲解如何结合Analysis来分析性能测试结果。第三部分：探索篇，包括第6章至第9章，着重讲解LoadRunner的高级应用。第6章讲解如何用Visual C+来

12、增强虚拟用户；第7章深入探索了Java虚拟用户；第8章深入探索了.NET虚拟用户；第9章则讲解了Socket虚拟用户的相关知识。第四部分：实战篇，即第10章，结合案例来讲解在具体项目中如何应用LoadRunner来完成性能测试工作。在第10章中，通过真实的性能测试实例，向读者展示了如何在项目中完成性能测试的整体规划与设计、测试的准备与实施、测试结果分析等工作。致谢感谢广大读者对Web性能测试实战一书的支持，读者的支持是作者写作的真正动力。正是一年来因为大家对Web性能测试实战的肯定才促使我完成本书的写作工作；感谢博文视点周筠老师对本书的支持，周老师对我这个新人一直给予很大的鼓励；感谢电子工业出

13、版社博文视点资讯有限公司的陈元玉编辑，她是本书的责任编辑；感谢师兄王玉亭，他再次为本书提供了很多素材；感谢同事关晓培、周雪松、李熠，他们为本书提供了很多素材；感谢电子工业出版社为本书辛勤付出的所有朋友们；特别感谢夫人小姬，她通篇审校了本书并润色了那些难于理解的句子，特别是她对我在公司的日常工作和编写工作的支持，因为本书占据了大量可以陪她的时间；最后要感谢自己的父母和老师，能写出本书是父母和老师多年教育的结果。软件在性能方面的“亚健康”问题一直伴随着国内很多企业的软件产品而存在。早期由于多数软件应用系统在企业中得不到有效的推广应用，因此用户往往会忽略自己在性能方面的需求。而现在软件几乎渗透到人们

14、工作与生活的各个方面，因而软件的性能开始得到越来越多的重视。随着软件工程技术、软件开发方法和软件开发工具的发展，一方面使人们可以快速开发更加复杂的应用，另一方面也使开发出的软件规模越来越庞大，架构越来越复杂。随之而来的是软件性能问题也越来越多，最终导致很多软件系统由于性能方面存在问题而停止使用，给软件公司以及客户都带来了一定的损失。因此，解决软件性能问题是十分必要的一项工作中，对于企业自身以及客户都具有重要的现实意义。在绍英的上一本著作Web性能测试实战中，为接近软件性能问题提出了“全面性能测试模型”，以期成为解决软件亚健康问题的一剂良药。“全面性能测试模型”包含了性能测试策略制定、测试用例设

15、计、模型使用方法三部分内容，覆盖了性能测试规划和设计的相关内容，为开展性能测试工作提供了一种可行的方案。但是仅有理论是不够的，对于性能测试工作而言，不但需要好的性能测试理论作为工作指导，更需要掌握好的性能测试工具，因此本书的几位作者共同创作了LoadRunner性能测试实战一书。LoadRunner是目前国内性能测试领域应用最广泛的工具之一，它可以通过模拟成千上万的用户，很快地帮助用户确认和查找性能问题。但是国内图书市场上却没有任何相关书籍，LoadRunner性能测试实战填补了这个空白。LoadRunner性能测试实战是非常注重实际应用的作品。书中详细描述了LoadRunner在性能测试领域

16、诸多方面的应用，并结合具体的案例来说明如何应用Web性能测试实战一书中提到的“全面性能测试模型”。强大的性能测试工具加上合理的理论来指导，将为读者打开很多新的思路。本书是由三位作者共同完成的。绍英有流媒体、P2P、电子政务、银行、门户网站等领域应用软件的性能测试经验，在LoadRunner方面更有五年以上的使用经验。他曾到很多公司去推广自己的性能测试模型以及讲解LoadRunner课程，对企业在软件测试方面的需求非常熟悉；建华是在读研究生，因此有充裕的时间来研究LoadRunner的特殊应用；小姬在性能测试方面也有着丰富的经验。相信他们的这些实践经验是很多测试人员急需的。本书对国内软件企业提高

17、性能测试水平是很有价值的。我很高兴能为这本实战性非常强的作品做序，预祝LoadRunner性能测试实战早日出版。也希望国内有更多的人来关注软件性能测试，探讨解决软件亚健康问题的方法！北京大学软件与微电子学院副教授北京市软件促进中心专家顾问 黎怡兰（Melody Le）在一些软件项目中，项目经理或测试经理经常会安排测试工程师进行下面的工作： 用LoadRunner测试系统的最大并发用户数。 用LoadRunner测试系统8小时的最大业务吞吐量。 用LoadRunner测试系统的稳定性与健壮性。 用LoadRunner测试系统在数据达到100万条记录时的性能。 用LoadRunner测试核心事务响

18、应时间是否满足用户的需求。可以说，现在很多IT企业的性能测试工作已经离不开LoadRunner了。不过，尽管使用了LoadRunner这一强大的工具，很多企业软件产品遇到的性能问题仍未能解决因为仅有好的测试工具是不够的。除了比较实用的测试工具外，要想做好性能测试还应该掌握相关的理论知识。只有以坚实的理论作为实际工作的依托，才能让测试工具发挥出应有的功效。本章将介绍一些性能测试的基础知识，主要内容如下：n 性能测试基本概念 全面性能测试模型 性能测试调整基础 如何做好性能测试提示：关于性能测试理论的更多内容，可以参考作者性能测试方面的专著Web性能测试实战，电子工业出版社，2006年5月出版。在

19、软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在和Web相关的系统上。软件几乎无处不在，在给用户带来方便的同时，也对开发人员和测试人员提出了更高的要求。性能测试不但要求测试人员具备很强的技术能力，还要具备综合分析问题的能力。本节从性能测试的概念入手，强化性能测试的基础知识。 什么是性能测试目前很少能见到性能测试的准确定义，但是性能测试又似乎是涉及范围非常广泛的测试。压力测试、负载测试、强度测试、稳定性测试、健壮性测试、大数据量测试都和性能测试有着密切的关系。在本书中，主要从狭义和广义两方面来讨论性能测试。狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产

20、运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。例如，以实际投产环境进行测试，来求出最大的吞吐量与最佳响应时间，以保证上线的平稳、安全等。性能测试是一种“正常”的测试，主要测试正常使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些稍稍超出“正常”范围的测试。广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。下面分别介绍各类测试的主要内容和特点。压力测试对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站

21、点在大量的负荷下，系统的事务响应时间何时会变得不可接受或事务不能正常执行。压力测试的目的是发现在什么条件下系统的性能变得不可接受，并通过对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是通常把负载测试描述成一种特定类型的压力测试例如增加用户数量或延长压力时间以对应用程序进行压力测试。负载测试对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。压力测试侧重压力大小，而负载测试往往强调压力持续的时间。在实际工作中，没有必要严

22、格区分这两个概念，有关内容可以参见后面1.2节的“全面性能测试模型”。强度测试强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如： 当正常的用户点击率为“1000次/秒”时，运行点击率为“2000次/秒”的测试用例； 运行需要最大存储空间（或其他资源）的测试用例； 运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否容易扩展。疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性

23、能表现，例如724小时的压力测试。并发（用户）测试主要指当测试多个用户并同时访问同一个应用程序、同一个模块或数据记录时是否存在死锁或其他性能问题，几乎所有的性能测试都会涉及并发测试。在具体的性能测试工作中，并发用户往往都是借助工具来进行模拟的，LoadRunner中称之为并发虚拟用户。大数据量测试大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。如专项的大数据量测试主要针对前者，后者尽量放在并发测试中。此外，也可以把大数据量测试分为“运行时大数据量测试”与“历史大数据量测试”来进行测试用例设计。配置测试配置

24、测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整Oracle的内存参数来进行测试，使之达到一个较好的性能。可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测试。可靠性测试在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。例如，可以施加让CPU资源保持70%90%使用率的压力，连续对系统加压8个小时，然后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性测试、强度测试、并发（用户）测试、

25、负载测试，等等。因此，当实施性能测试时绝不能割裂它们的内部联系去进行，而应分析它们之间的关系，以一种高效的方式来规划与设计性能测试。为此，本书在1.2节提出了“全面性能测试模型”，以更好的方式来开展性能测试工作。 性能测试应用领域性能测试往往是为了实现下面的一个或几个目标： 判定软件是否满足预期的性能需求； 根据测试结果判定软件的性能表现； 查找系统可能存在的性能问题，如果有，则找出并加以解决； 发现一些应用程序在功能实现方面的缺陷； 对一些存在性能问题的系统，找出瓶颈并加以解决； 为用户部署系统提供性能参考； 通过分析性能测试的种种目标，不难总结出性能测试主要应用在几个领域中，下面分别予以介

26、绍。系统的性能瓶颈定位系统的性能瓶颈定位是性能测试最常见的应用领域。借助LoadRunner等工具，可以在测试场景运行过程中监控系统资源、Web服务器资源等运行数据，与响应时间进行同步分析，可以在一定程度上进行性能瓶颈的分析与定位。系统的参数配置通过性能测试可以测试系统在不同参数配置下的性能表现，进而找出令系统表现更优的系统配置参数，为应用系统投产提供最佳配置建议。实际上，操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重要原因。例如分配给Oracle的内存大小与系统自身的业务特点有极大关系，配置不同的数据库，性能表现就会不同；而即使在内存一定的情况下，SGA的分配也会对性能

27、产生很大的影响。因此，要通过测试，以确定内存的最佳配置。发现一些软件算法方面的缺陷一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，只有通过模拟多用户的并发操作，才能验证其运行是否正常与稳定。例如作者就经历过在一次性能测试过程中，测试人员模拟多个用户并发时发现的一个明显的缺陷：测试对象是一个随机分配任务的模块，只要有用户申请，就会给用户分配任务。这个算法在单用户情况下调试没有任何问题，但是当多个用户同时申请任务时，就发生了把同一任务分配给多个不同用户的现象。经证实，这个缺陷就是“同步算法”发生了问题而引起的。系统的验收测试系统验收测试经常会验证一些预期的性能指标，或者验证系统中一些事

28、务指标是否符合用户期望，这时就需要借助性能测试来完成验证工作。随着用户对性能的重视，现在性能测试几乎是系统验收测试中必不可少的内容之一。用户甚至自己进行专门的性能测试来验证系统上线前的性能，以保证运行时的性能稳定。因此，性能测试在用户验收测试中越来越重要。系统容量规划通过总结系统在不同硬件环境下的性能表现，可以为系统部署时提供非常好的参考。对于一些性能要求较高的系统，性能测试可以为硬件规划提供很好的参考数据，使用户在购买硬件时“有据可依”。例如同一系列机型：两颗CPU系统支持500用户并发、四颗CPU支持800用户并发，这些都是用户根据自身需求来规划硬件的重要依据。产品评估/选型产品评估/选型

29、是性能测试的又一应用领域。通过性能测试，可以对产品的软硬件性能进行更全面的评估，选出更适合自己的产品类型。性能测试的应用领域越来越广，因此在实际工作中，性能测试往往会一次应用在一个或多个领域。对于软件性能测试设计人员，应该根据测试的具体应用领域、测试原则和目标来进行性能测试的规划与设计。 性能测试常见术语本节将介绍一些性能测试中的常见术语，只有掌握这些基础的性能测试知识，才可以进一步开展测试工作。性能测试常见的术语主要有并发、并发用户数量、请求响应时间、事务响应时间、吞吐量、吞吐率、TPS、点击率、资源利用率等，下面分别介绍它们。并发狭义的并发一般分两种情况。一种是严格意义上的并发，即所有的用

30、户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务。例如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特例，即所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操作，但是这些请求或操作可以是相同的，也可以是不同的。对整个系统而言，仍然有很多用户同时对系统进行操作，因此，仍然属于并发的范畴。可以看出，广义的并发是包含狭义的并发的，而且广义的并发更接近用户的实际使用情况，因为对大多数系统而言，只有数量很少的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为只要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。并发用户数量关于并发用户的数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近