性能测试场景分析

录制脚本

录制参数设置

脚本录制

回放和调试脚本

用这按钮进行编译，编译通过后，点击运行按钮即可运行脚本。只有在脚本运行正确后，才能进入Controller中来创建测试场景。

脚本录制的原则

?充分考虑脚本的执行效率

?录制重要的用户业务

?选择你所需要的进行录制

修改脚本

参数化功能

步骤1

步骤2

步骤3

参数类型有多种：

●Date/Time：需要输入日期的地方，可以用Date/Time类型来替代。

●Group Name：使用虚拟用户组的名称来替代参数。

●Load Generator Name：使用虚拟用户所在的LoadGenerator机器名来替代参数。

●Lteration Number：测试脚本当前循环的次数来生成参数。

●Random Number：随机数。

●Unique Number：唯一的数（一般使用递增的数。）

●Vuser ID：使用虚拟用户的ID来替代参数，ID是由Controller来控制的。

●File：在属性中可以指定文件或数据库中提取数据。

●User Definde Function：从用户开发的dll文件中提取数据。

这里的重点是file类型：

在我们工作中最常用的是“Unique（唯一的）”和“Each iteration（下一条数据）”

的组合。比如我们设计一个场景，要求10个虚拟用户都需要进行10次迭代。那编号为1的用户取前10行数据，编号为2的用户取11~20行数据。以此类推，那完成整个场景就需要数据表里至少要有100条数据，否则在Controller运行过程中会返回一个错误。

深入集合点（就是并发点）

使用集合点可以控制各个Vuser，以便在同一时刻执行任务。原理是，当某个Vuser到达该集合点时，Controller会将其保留，直到参与该集合点的Vuser都到达，满足了集合条

件时，Controller将释放Vuser，这样就产生了密集的同一类用户操作或请求。Vuser从集合释放后，将执行脚本中的下一个任务。

需要注意的是：

●集合点一般会创建在用户事务的开始标志前。

●集合点只能加在action部分，而不是init或end部分。

比如我们想在登录时创建一个集合点，我们可以这样安排：

巧用检查点

Loadrunner的检查点有三种：Web_find、Web_reg_find和Web_image_check。至于为什么要用检查点可以用个小例子做个测试，例如一个登陆脚本登陆的账号为123456，密码为123456，可以正确登陆，当把账号或密码改掉再执行，发现脚本并没有报错，也顺利执行下来了。原因是什么呢？Loadrunner以用户角色向服务器发送一个登陆请求，却不会判断请求的返回消息是什么，只要有返回，即使这是个拒绝登陆的返回，Loadrunner也认为登陆成功了。所以在登录或者其他有重要页面跳转的地方，很有必要做检查点。

Web_find和Web_image_check两个函数如果在脚本里面增加，需要在设置中打开“图像和文本检查”功能，该功能默认是不打开的，如果手工在脚本里面添加检查点，系统会有提示：

Action.c(43): Verification checks not enabled. web_find is skipped. See the 'Run-time settings/Preferences/Checks' [MsgId: MMSG-27197]

Web_reg_find是注册类型函数，它本身并不执行，不能通过它的返回值来作为事务的判断条件（因为web_reg_find()的返回值0和1表示web_reg_find()是否注册成功，并不代表查找的内容是否存在，也就是说无论查找的文本内容是否存在，都返回0。它是从返回的缓冲区扫描而不是在接收的页面中查找。这是比web_find更高效的一个函数。

关联

所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）资料，转变成是摘取自服务器所送的、动态的、每次都不一样的资料。

关于检查点和关联的内容，可以参见我们的案例“01 checkproperties”。

另外，我们可以在中配置脚本运行时的设置。

运行逻辑：我们可以设置ACTION的迭代次数。

思考时间：我们一般忽略思考时间，以得到更大的压力。

其他：我们可以选择错误的处理方式，还可以选择线程方式运行脚本以得到更大的压力，最后的选项一般默认就行了。

速度模拟：默认使用最大带宽，我们也可以模拟一些特殊的接入方式。

首选项：需要特别注意的是，如果脚本中使用了文本检查点或图片检查点的时候，

（如果是使用

web_reg_find，则不要求勾选。）

其他的项我们一般都使用默认值即可。

创建测试场景

场景类型

我们在VuGen中完成虚拟用户脚本的调试后，就进入Controller中进行用例场景的设计与执行。

在Controller中，提供了两种类型的测试场景：手动测试场景和面向目标的测试场景。

在场景运行后，Controller会在不同的负载生成器上（根据用户的设定进行分析：手动场景）或（自动分析：面向目标场景），生成一定数量的虚拟用户。通过这些虚拟用户的并发执行以及及时间的运行，来模拟真实情况下服务器承受的压力。在场景运行的过程中，Controller可以提供对服务器资源、虚拟用户执行情况、事务响应时间等方面的监控，帮助测试人员实时的分析系统，并在运行完成后给出结果数据以便进行下一步的分析。

手动场景

在Controller中，新建场景时，我们选择上面的手动场景，也可以再选择使用百分

手动场景是以用户定义虚拟用户数量来进行测试的。

面向目标场景

在面向目标的测试场景中，可以定义希望达到的目标。比如最大虚拟用户数量或每秒事务数等。Controller将根据定义的目标自动构建测试场景，并评估能否达到测试目标。

在这个下拉菜单中，我们可以定义虚拟用户数、每秒点击数、每秒事务数、每分钟页面数和事务响应时间5种类型的目标。

在这个图的下半部分，可以看到有两个标签页面：“场景设置”和“加载行为”。这两个标签页用来设置一些场景的参数，主要用在负载和压力测试的设定。

测试场景设计

配置测试脚本

在虚拟用户脚本加载后的界面上，选中需要配置的脚本后，点击右侧的

可以查看和修改脚本。需要注意的是：修改后就好重新载入，不然会使用修改前的脚本。

虚拟用户数目和每组用户所在的负载生成器可以直接在此界面中输入。

配置Generator（负载生成器）

使用Generator可以使用多台安装了负载生成器的主机产生压力。

点击：==》

点击：==》

配置Schedule（计划生成器）

点击：，可以配置计划生成器

计划是场景配置的重要组成部分，主要用于配置用户的行为方式。这里有两种类型：按场景计划和按用户计划。

●按场景计划（Schedule by Scenario）

按场景计划有三个选项卡：加压、持续时间、减压。

加压中，第一个是同时加载所有用户，第二个是每隔一段时间加载一定的虚拟用户。

持续时间中，第一个是照脚本的设置进行，直到运行完成。这种方式主要用在检测特定功能的实现上，比如在并发时，程序会不会出现一些功能缺陷。第二个是

按照指定的时间运行。如果选择此项，迭代次数的设置会被忽略，每个虚拟用

户都不断的进行迭代，直到指定时间为止。这种方式主要用在指定时间的性能

测试。第三个是一直运行，直到人工干预为止。这种方式主要用来测试系统的

极限。

减压中（必须选中持续时间选项卡中的第二项（按照时间运行），才能操作减压选项卡），指定场景如何结束。这里对于加压，也是两种减压方式。

●按用户计划（Schedule by Group）

按用户计划有四个选项卡，后面三个和场景计划中是一样的。

注意在图左边的窗口中，有用户组的选择，可以对每个组进行独立的开始时间、加压减压和持续时间。特别是一组用户需要使用另一组用户的操作结果时，就必须使用按用户计划方式配置场景了。

我们重点讲解一下开始时间选项卡。

场景开始时运行。

场景开始后一段时间再开始，这里可以指定具体时间。

在某些特定的用户组运行结束后再开始。

需要注意的是：也是一个选项。里面的第二和第三项一般是在运行时间很长，需要放到下班后执行时，我们可以选中它们。

配置集合点

我们之前讲过集合点，这里会具体配置集合点，以现实一定数量的并发，主要用来测试系统某个功能点的并发负载性能。

上面表示在03_checkproperties脚本中包含了一个集合点：maipiao。通过策略按钮我们可以配置它。

这里有三种方式：

●当Vu中全部指定百分比的虚拟用户到达集合点时释放。

●当一定比例处于运行状态的虚拟用户到达集合点时释放。

●当一定数量的虚拟用户到达集合点时释放。

最后一项是超时配置，如果在设定时间内都没有新虚拟用户到达集体点，Controller就会自动释放到达集合点的用户。

配置IP Spoofer

现在一些服务器会对同一IP访问进行限制，这时我们可以通过“IP Spoofer（IP欺骗）”进行配置，以达到我们的测试目的。

我们只需要选择开始菜单中的“IP Wizard”，进入配置界面。

第二步需要选择网卡。

之后再在Controller中的菜单里，启用IP欺骗器就可以了。注意的是：必须在连接到负载生成器之前选择该选项。

再在工具菜单内选中专家模式，进入选项中的常规，就可以根据需要来配置了。

测试果设置

为了更好的管理我们越来越多的测试结果，可以在菜单中的设置结果目录，对其进行管理。

通用参数设置

在菜单的选项中，值得注意的是“超时”选项卡，其他选项一般不用修改。在超时选项卡中，可以对负载生成器的连接、断开以及每个虚拟用户的初始化、运行、暂停和停止操作的超时时间进行设置，一旦超过设定，则会给出一条错误提示。

执行测试场景

启动测试场景

在场景的[运行]界面中有多个窗口，可以观查到场景组、场景状态、多个视图及它们的统计数据。

控制用户与用户组

在场景运行过程中，可以通过来对用户和用户组进行管理，包括添加、删除用户和用户组、控制虚拟用户运行状态等。界面如下：

查看场景与用户状态

通过场景状态区域的数据，我们可以监控场景与用户状态。在测试过程中就可以直接点击链接进行观看。

控制集合点

在场景的运行中，我们也可以像前面配置集合点一样的查看和控制集合点的状态，即可以停止集合点和用户，也可以释放或重置集合点。

查看运行数据图

在Controller中，我们可以添加多种数据图进行查看。在右边的小窗口中，我们可以添加多种数据视图。

监控系统资源

在性能测试中，最重要的一项就是监控系统资源。需要监控这几个方面：操作系统、数据库、中间件服务器等，其中，操作系统的性能表现关系着整个应该系统的性能，属于基础的系统资源数据。需要注意的是：监控系统是一项消耗资源的操作，所以，测试过程一定要考虑具体监控什么，以免影响测试结果的准确性。

在监控系统之前，我们还需要做一些准备工作：

●打上监控主机上的“Network DDE”，“Remote Procedure Call(RPC)”，“Remote

Registry”，“Net Logon”等服务。

●以系统管理员身份从Controller登录待监控主机。

●在监控图中可以添加计算机，输入IP地址后，点击OK就行了。

●在添架计算机的下面，我们再加入需要监控的计数器。

●如果看到数据就是正常，否则检查服务和防火墙有无问题。

Windows监控的主要参数有：CPU占用率、可用内存容量、服务线程占用的CPU

性能测试结果分析

如何分析测试结果

在Controller中的执行的测试场景结束后，首先要判断采集的结果数据是否真实有效。多数场景都需要迭代执行，因此很多测试结果本身就不能反映真实问题，那我们一般按照以下几个步骤进行判断结果的有效性：

1.测试环境是否正常：

如果在测试场景的过程中出现过异常，则结果往往不准确，无须进行分析。如

CPU100%、网络断开……。

2.测试场景设置是否正常、合理：

测试场景的设置不合理会测试出现异常，这时需要对场景设置进行分析修正。如同

时在一台PC上加载全部Vu，太多的Vu可能会造成客户端不能正常初始化，而造

成很多Vu不能初始化而失败，这样的失败和我们要测试的服务器根本没有关系。

这时我们可以改为逐步加压。

3.测试结果是否直接暴露出系统的一些问题：

性能测试的目的是分析出系统在压力下存在的问题，所以我们主要是对出现错误的

结果进行分析。测试结果直接暴露的问题有很多，如：

●一些用户事务响应时间过长

●系统支持最大的并发用户数过低

●服务器CPU利用率过高

●内存不足。

●……

测试人员针对这些结果，用Analysis对其进行深入分析，以发现在一些潜在的性能

问题。

性能分析基础知识

在性能测试中，我们都遵循一个普遍的原则：由外而内，由表及里，层层深入。

性能下降最直接的现象就是系统响应时间变长，所以我们都是以系统响应时间作为性能测试的切入点。而现在的IT系统架构复杂，任何一个环节都可能出现瓶颈，要准确的判断出瓶颈在什么地方，是一个比较头痛的问题。我们分析问题的方法是：任何系统都是由网络和服务器构成的，所以我们先确定问题是出现在网络还是服务器上的。

借助LR的Analysis组件，可以很容易分析。如下图中，我们可以很容易的看出，在整个事务时间中，网络时间和服务器时间所占的多少，也可以很容易确定出问题主要现在在哪

一个环节。

在实际的工作中，我们不能光发现问题，还要定位问题，并给出一个解决方案（或调优方案）。即使有了正确的测试结果，也不一定能对问题进行正确的定位。比如说我们在工作中会经常遇到CPU占用率过高，我们可能还会发现磁盘IO过于频繁，我们一般会认为是服务器内存不足。但也可能是因为程序内部的编写不严密，资源没有释放而造成的，也可能是因为程序内部有内存泄漏。解决工作实际问题不但要靠经验，也需要靠对系统的深入了解，所以说起码的编程能力还是很必要的。

Analysis基本功能

LR在Controller中运行场景，采集了Vu、操作系统、应用服务器等各种运行数据，当场景运行结束后，我们就可以用过LR专用的分析组件Analysis进行分析了。

当我们打开Analysis，通常是下面这样的一个界面：

在右边添加新图处，我们再进行打开新图的界面，这里还有很多的分析图

这里可以看到系统资源这些都是黑色，不是蓝色链接，说时这里没有采集到数据，我们需要在Controller中，场景运行之前开启相应的采集。

这里先简要介绍一下名类分析图的含义及用途。

●虚拟用户（Vusers）图：

虚拟用户图里分为运行的虚拟用户图、虚拟用户概要和集合点3类，主要用来

查看场景与会话的虚拟用户行为。

●错误（Errors）图：

主要有错误统计、每秒错误数量两类，用来查看服务器什么时间发生错误以及

错误的统计信息，可以发现服务器的处理能力。

●事务（Transactions）图：

描述和事务相关的分析图：事务综述图、事务平均响应时间图、每秒通过事务

数图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分析图、

事务响应时间百分比图、事务响应时间分布图等。通过这些分析图，我们可以

分析应用系统事务的执行情况。

●Web资源（Web Resources）图：

描述Web服务器的吞吐率图、点击率图、返回的HTTP状态代码图、每秒HTTP

响应数图、每秒重试次数图、重试概述图、服务器连接数概要图、服务器每秒

建立的连接数量图。借助Web资源图，我们可以深入分析服务器性能。

●网页细节（Web Page Breakdown）图：

网页细分需要在Controller中启动（Controller菜单中诊断中的配置里面，激活

“网页诊断”）。在网页细分图中主要有：页面分解总图、页面组件细分图、页

面组件细分（随时间变化）图、页面下载时间细分图、页面下载时间细分（随

时间变化）图、第一次缓冲时间细分图、第一次缓冲时间细分（随时间变化）

图、已下载组件大小图。借助网页细分图，我们可以分析页面元素是否影响事

务响应时间。