Loadrunner从零开始 - 图文 

例如，您可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异：

配置1：1.2GHz、1GB RAM 配置2：1.2GHz、2GB RAM 配置3：2.4GHz、1GB RAM （3）检查可靠性

确定系统在连续的高工作负载下的稳定性级别。强制系统在短时间内处理大量任务，以模拟系统在数周或数月的时间内通常会遇到的活动类型。 （4）查看硬件或软件升级 执行回归测试，以便对新旧版本的硬件或软件进行比较。您可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。注意：此回归测试的目的不是验证升级版的新功能，而是查看新版本的效率和可靠性是否与旧版本相同。 （5）确定瓶颈

您可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。将LoadRunner与新的网络和计算机监视工具结合使用以生成负载，并度量系统中不同点的性能，最终找出瓶颈所在的位置。 （6）度量系统容量

度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。如图1-7所示，要查看容量，您可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。

我们根据不同的测试目标去选择合适的性能测试设计策略。比如，“度量最终用户响应时间”可以采用负载测试策略，“检查可靠性”就可以用压力测试策略，等等。 1.3.2 Analysis（分析）

本步骤的开始时间：需求分析阶段和性能测试启动阶段 本步骤的输入：性能需求

本步骤的输出：达成一致的性能指标列表，性能测试案例文档 1．分析性能需求

在这里，要定义性能测试的内容，细化性能需求。 客户、需求分析人员和测试工程师一起起草一个性能需求标准，对此标准获得一致认同。此标准将用户的需求细化、量化，并能在测试中作为判断依据。

比如，对于负载测试来说，可以从以下角度来细化需求，逐步找出测试关键点。 测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些？”；“测试中需要模拟哪些部门用户产生的负载压力？”等问题。 系统配置如何，例如“预计有多少用户并发访问？”；“用户客户端的配置如何？”；

“使用什么样的数据库”；“服务器怎样和客户端通信？”。

应用系统的使用模式是什么，例如“使用在什么时间达到高峰期？”；“用户使用该系统是采用B/S运行模式吗？”；“网络设备的吞吐能力如何，每个环节承受多少并发用户？”等问题。

最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。 2．分析系统架构

对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。结合性能测试指标标准，生成性能测试用例。（可参看第10章“进阶LoadRunner高手”的用例设计部分。）

1.3.3 Metrics（度量）

本步骤的开始时间：性能测试设计阶段

本步骤的输入：细化的性能指标和性能测试案例

本步骤的输出：和工具相关的场景度量、交易度量、监控器度量和虚拟用户度量等 度量是非常重要的一步，它把性能测试本身量化。这个量化的过程因测试工具的不同而异。

（1）场景的定义，pass/fail的标准

测试场景包含了性能测试的宏观信息，有测试环境、运行规则和监控数据等。具体可表现为历史数据记录数、虚拟用户数、虚拟用户加载方式、监控指标等。 （2）事务（Transaction）的定义，pass/fail的标准 事务用来度量服务器的处理能力。事务定义应该从性能指标标准而来，是性能指标的具体体现。事务的定义是很重要的，不同的定义会导致不同的TPS结果。

提示：使用性能测试工具执行性能测试之后，我们能看到的是pass/fail的用户数、pass/fail的事务数。而这些pass/fail的标准应该在执行性能测试之前就应该被定义好。比如，LoadRunner默认的pass/fail标准是基于协议层的，而我们要的pass/fail可能是业务级的，需要在业务层上进行判断来决定是pass还是fail。另外，还可能由于案例的关联性引起的pass/fail，如果两个案例之间有关联，A脚本负责向数据库插入数据，B脚本负责查询数据，A要是fail了，导致B也会fail，虽然B本身不一定有错。解决这个问题，一方面可以削弱脚本之间的关联性，另一方面也可以通过增强脚本的健壮性来达到。 （3）虚拟用户pass/fail的标准

虚拟用户是性能测试工具中的一个普遍的概念，虚拟用户负责执行性能测试脚本，在这里应该定义虚拟用户遇到何种情况，选择fail或pass，即退出或通过。 1.3.4 Execution（执行）

本步骤的开始时间：软件测试执行阶段

本步骤的输入：场景、交易、虚拟用户等设置信息 本步骤的输出：测试报告 执行测试包含两个工作： 1．准备测试环境、数据和脚本

测试环境：硬件平台和软件平台。

测试数据：包括初始测试数据和测试用例数据两部分。表现为SQL脚本、Excel文件等。

提示：测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同。需要注意：如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；如果是建立近似的真实环境，要首先达到服务

器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑。实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。有时为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为测试用例数据。

测试脚本：用性能测试工具生成脚本。 2．运行场景和监控性能

运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过。如果未能通过，进入步骤5（Adjust）。 1.3.5 Adjust（调整）

本步骤的开始时间：第一轮性能测试结束后，而且没有通过的条件下 本步骤的输入：测试报告和测试结果数据 本步骤的输出：性能问题解决方案

调整包含两个意思：应用程序修改和中间件调优。 中间件调优可考虑如下因素操作系统调优： 数据库调优； 内存升级； CPU数量； 代码调优； Cache调优。

提示：解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。 系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过度使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过度使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销）。

从以上内容可以看出，目前GAME（A）模型有两个优势：第一，灵活，每个过程都有自己的关注点，可以根据不同的项目特点增加或删除关注点；第二，通用，不依赖于具体的工具。目前GAME（A）关注性能测试技术，比较简单，将来可以进行扩展，同样使用GAME（A）模型关注性能测试的时间、人力等资源问题。

1.4 性能测试工具的评估和选择 我们可以看到，性能测试和一般功能测试不同的是，性能测试的执行是基本功能的重复和并发，因此我们在性能开始之前需要模拟多用户，在性能测试进行时要监控指标参数，同时性能测试的结果不是那么显而易见，需要对数据进行分析。这些特点决定了性能测试更适合通过工具来完成。市场上涌现出越来越多的压力自动化测试工具，古人云“工欲善其事，必先利其器”，一个测试工具能否满足测试需求，能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。

我们这里讨论的主要是一些比较成熟的性能测试软件产品，都已经在市场上占有了一定的份额，得到了用户的认可。

如表1-1所示为主要的性能自动化测试工具。

对于测试人员来说，要么自己开发性能测试工具，要么选择购买市场上已有的性能测试工具。在这里，我们要讨论的只是在选择性能测试工具时，需要考虑哪些因素。这些因素都想清楚了，然后才可以做决定。 1.4.1 测试预算VS工具价格

性能测试的成本与收益比是选择性能测试工具的根本条件。这其实是在考虑“要不要用”的问题。如果购买一套价格几十万的性能测试工具只是为了去做一个几万元预算的性能测试项目，那么无论这个工具再强大，也不会被采用。 1.4.2 协议、开发技术、平台、中间件VS工具的支持

要确定性能测试工具是否支持我们的被测软件系统，这其实是在考虑“能不能用”的问题。考虑因素有被测软件系统使用的协议、采用的技术、基于的平台、调用的中间件。这些都需要性能测试工具有效的支持。

1.4.3 工具可使用的复杂程度VS项目计划的影响 熟悉并使用一个性能测试工具，是需要花费人力和时间等资源的，项目计划中要有相应的资源准备。这其实是在弄清“如何用”的问题。 第8章 欲善其事先利其器——VU脚本开发实战

VU开发脚本是我们使用LoadRunner做性能测试中一个重要的步骤，这里涉及软件系统架构、计算机编程技巧和VU本身的功能特性。在本章，我们将结合邮件系统，介绍如何使用VU生成基于SMTP/IMAP协议的脚本。 我们将按照如下的思路完成脚本。

熟悉SMTP/POP3/IMAP协议规范和原语。 使用VU录制邮件收发操作，分析VU脚本对标准SMTP/IMAP协议的封装与实现机理。 使用VU Java模板用户嵌入Java message接口，实现邮件收发，并以此介绍VU Java模板用户的使用方法，以及Java classpath等相关设置。 8.1 邮件服务SMTP/IMAP协议介绍

电子邮件是我们日常工作中经常使用到的一种交流方式，它是Internet应用最广的一种服务。

8.1.1 电子邮件的工作原理

电子邮件是Internet上最为流行的应用之一。如同邮递员分发投递传统邮件一样，电子邮件也是异步的，也就是说，人们是在方便的时候发送和阅读邮件的，无须预先与别人

协同。与传统邮件不同的是，电子邮件既迅速，又易于分发，而且成本低廉。另外，现代的电子邮件消息可以包含超链接、HTML格式文本、图像、声音甚至视频数据。

电子邮件的工作过程遵循客户-服务器模式。每份电子邮件的发送都要涉及发送方与接收方，发送方构成客户端，而接收方构成服务器，服务器含有众多用户的电子信箱。发送方通过邮件客户程序，将编辑好的电子邮件向邮件服务器（SMTP服务器）发送。邮件服务器识别接收者的地址，并向管理该地址的邮件服务器（IMAP或POP3服务器）发送消息。邮件服务器将消息存放在接收者的电子信箱内，并告知接收者有新邮件到来。接收者通过邮件客户程序连接到服务器后，就会看到服务器的通知，进而打开自己的电子信箱来查收邮件。 8.1.2 SMTP协议介绍

简单邮件传送协议（SMTP）是Internet电子邮件系统首要的应用层协议。它使用由TCP提供的可靠的数据传输服务把邮件消息从发信人的邮件服务器传送到收信人的邮件服务器。SMTP协议服务的默认端口是25。

SMTP协议与人们用于面对面交互的礼仪之间有许多相似之处。首先，运行在发送端邮件服务器主机上的SMTP客户，发起建立一个到运行在接收端邮件服务器主机上的SMTP服务器端口号25之间的TCP连接。如果接收邮件服务器当前不在工作，SMTP客户就等待一段时间后再尝试建立该连接。这个连接建立之后，SMTP客户和服务器先执行一些应用层握手操作。就像人们在转手东西之前往往先自我介绍那样，SMTP客户和服务器也在传送信息之前先自我介绍一下。在这个SMTP握手阶段，SMTP客户向服务器分别指出发信人和收信人的电子邮件地址。彼此自我介绍完毕之后，客户发出邮件消息。SMTP可以指望由TCP提供的可靠数据传输服务把该消息无错地传送到服务器。如果客户还有其他邮件消息需发送到同一个服务器，它就在同一个TCP连接上重复上述过程；否则，它就指示TCP关闭该连接。 让我们看一个客户（C）和服务器（S）交互的例子。前面标以“C:”的文本行是名为Mike的客户端发送的请求，Mike想给Rose发送一封“I love you”的电子邮件情书，前面标以“S:”的是cesoo.com服务器的回应。以下传输内容在TCP连接建立之后马上发生。 S:220 cesoo.com C:HELO

S:250 Hello Mike,pleased to meet you C:MAIL FROM:Mike@cesoo.com

S:250Mike@cesoo.com... Sender OK C:RCPT TO:rose@cesoo.com

S:250rose@cesoo.com...RecipientOK C:DATA

S:354 Enter mail,end with \C: I love you, Rose C: .

S:250 Message accepted for delivery C:QUIT

S:221 cesoo.com closing connection

觉得难以置信么？这不是在写言情小说，而确确实实是客户端和邮件服务器通过SMTP协议在网络上交互的内容，网络协议就这么简单。客户总共发出了5个命令，分别为：HELO、MAIL FROM、RCPT TO、DATA和QUIT。这些命令又叫做原语，可理解为应用协议层上最原始最小的命令颗粒。服务器给每个客户端的命令发回应答，其中每个响应都由返回码和一些英语解释构成。这里需要指出的是，SMTP使用持久连接，也就是说，如果客户端有多个邮件消息需发送到同一个邮件服务器，那么所有这些消息可以在同一个TCP连接中发送。