这次测试的业务流程很简单，是向tomcat下的一个自制应用加压并观测其性能数据。需求也并不复杂尽量多地对服务器加压，多并发多点击。使用的加压机是3台1U服务器，内存分别为32g，32g，16g。测试机是1台1U服务器，内存硬盘cpu都和加压机相仿。不设置集合点，和思考时间，只自定义一个事务。
需求对于并发用户数的理想为1000以上，每秒点击在10000以上。开始测试后发现，并发数在100以上后，就开始不断报错，错误主要是以下两种

Action.c(10): Error -27796: Failed to connect to server "192.168.12.252:81": [10060] Connection timed out
Action.c(10): Error -27791: Server "192.168.12.252" has shut down the connection prematurely

网上查到的解释是，加压机性能过好，导致端口开的过多并且来不及释放造成的，因此修改了加压机的maxport数和tcptimewaitdelay值。重启后测试，问题明显好转但仍然存在。只要并发用户数超过1000，该报错便源源不断，同时随着报错数的不断增加每秒点击数响应降低。初步判断是服务器端来不及响应部分请求导致很多连接超时。调试了很久找到了解决办法，第一步修改runtime setting下，internet protocol-preferences-options中几个timeout值，强制使lr发起的http请求的超时变长，要修改的值有http-request connect timeout，http-request receive timeout，step download timeout都设置为800秒，顺便提一下，keep-alive http connections应该是http长短连接的设置，由于本次测试的应用均为短连接，所以该值设为no。修改执行加压，报错和点击数仍然形同水火，一个增加另外一个必然减少。反复查看lr的设置后尝试将tools-options-timeout的各个超时也响应增加。加压后，报错再次得到了显著减少。在1000用户数的情况下点击数可以到达每秒20000次并且报错在万分之1的比例。本以为大功告成，谁知场景运行10分钟后，每秒点击数骤然下降，5分钟之后下降到10000，并且仍有下降趋势。抓耳挠腮一阵后，分析出问题也许出在加大报错timeout后，很多非正常连接尚未断开，在800s后渐渐超时，连接数的减少导致请求数减少。尝试勾选runtime setting下general-miscellaneous中error handing的设置continue on error。犹如一弯神器，立竿见影。最终测试结果达到了预期。
顺便提一下，analysis下对于响应时间的分析比较具体，不仅可以看到每次迭代的时间，每个事务的时间，还可以具体到请求和返回的网络消耗时间，服务器响应时间等等，具体可以在average transaction response time图的web page diagnostics中查看，但必须待生成完整日志以后。

LR在录制程序运行的过程中，VuGen（脚本生成器） 自动生成了包含录制过程中实际用到的数值的脚本，如果你企图在录制的脚本中使用不同的数值执行脚本的活动（如查询、提交等等），那么你必须用参数值取代录制的数值，这个过程叫做参数化。

以下为参数化过程：

　　第一步：录制测试脚本，录制二遍

　　第二步：使用WinDiff工具找出两次脚本的不同，判断是否需要进行关联

　　第三步：确定插入关联的位置

　　第四步：在VIEW TREE中使用web_reg_save_param函数手动建立关联

　　第五步：将脚本中有用到关联的数据，用参数代替

　　第六步：验证关联的正确性

　　下面详细介绍：

　　第一步：录制测试脚本，录制二遍

　　这一步就不用多说了，相同的操作，录制两份，分别保存

　　第二步：使用WinDiff工具协助找出需要关联的数据

　　1. 在第二份脚本中，点选VuGen的【Tools】>【Compare with Vuser…】，并选择第一份脚本。

　　2. 接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。（假如没看到红色字体，请点选【Options】>【View】>【Show Inline Differences】）。

　　查看二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。

　　注意：lr_thik_time部分的差异可以忽略

　　找到不同的部分后，复制，然后打开Recording Log或是Generation Log，按Ctrl+F，在查找窗口中粘贴差异部分的内容，点击查找找到后，查看该部分的信息，确认是客户端的请求信息还是服务器回应的信息

　　如果出现在$$$$$$ Request Header For Transaction With Id 3 Ended $$$$$$这个部分，那证明是客户端发出的请求，这里是不需要做关联的

　　一般做的关联都是出现在****** Response Header For Transaction With Id 7 ******和****** Response Body For Transaction With Id 7 ******中的部分。

　　在找到这个信息后，需要记录如下信息：

　　a、记录这个不同数据之前的内容和之后的内容

　　b、记录这个不同数据出现的位置，是Header还是Body

如：

<tr bgcolor=#66cccc><th>Flight<th>Departure time<th>Cost

<tr bgcolor=#66CCff><td align=center><input type = radio name=outboundFlight value=230;378;11/20/2003 checked >Blue Sky Air 230<td align=center>8am<td align=center>$ 378

　第三步：确认插入关联的位置

　　我们在日志中找到了两次脚本的不同点的位置，根据这个位置，我们再确定是在哪个请求之后产生的，也就是说要定位发生不同点的response是由哪个request产生的，找到了这个请求的函数位置，我们就知道要往哪里做关联了。

　　一般情况下关联函数写到发出请求的函数之前就可以了。

　　第四步：插入关联函数

　　在插入关联函数前，我们先介绍关联函数web_reg_save_param

　　一个web_reg_save_param函数的例子：

　由此可以看出，作边界LB与右边界RB直接的值为要关联的值。

在此例，即“230;378;11/20/2003”

在这里我们只介绍几个常用参数的含义

　　语法：int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);

　　参数说明:

　　ParamName: 存放得到的动态内容的参数名称

　　list of Attributes: 其它属性，包括：Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, SaveLen。属性值不分大小写

　　LB( Left Boundary ) : 返回信息的左边界字串。该属性必须有，并且区分大小写。

　　RB( Right Boundary ): 返回信息的右边界字串。该属性必须有，并且区分大小写。

　　Search : 返回信息的查找范围。可以是Headers，Body，Noresource，All(缺省)。该属性质可有可无。

　　那么如何插入该关联函数呢？

　　1.将vugun切换到 view tree 模式下

　　2.在左边的列表中，找到在上一步发出请求的函数，点击“右键”

　　选择“insert before”

　　3.在弹出的“add step”对话框的“find function”中输入“web_reg_save_param”，点击“ok”

　　在“parameter name”中输入,关联函数的名称，这里最好有含义，“sessionid”

　　在“left boundary”中输入，刚才记录下的不同点字符串的左面的几个字符，定义左边界

　　在“right boundary”中输入，刚才记录下的不同点字符串的右面的几个字符，定义右边界，;

　　在“search in ”中，选择“body”

　　点击“ok”

　　4.回到脚本编辑模式下，查看该函数插入是否正确

　　在发出请求的函数前应该看到：

　　第五步：将脚本中有用到关联的数据，用参数代替

　　如发出请求的参数如下，那么将原来服务器返回的动态值使用{ outFlightVal} 来替换：

　　第六步：验证关联的正确性

　　回放脚本，验证关联的正确性。

　　OK！！！

　　大功告成。

　LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1- 1所示。性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的，正如 所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU使用率、内存使用率分别不超过75%、70%，那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。

图1- 1性能测试结果分析流程图

• 结果摘要

　　　LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1- 2所示。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。

图1- 2性能测试结果摘要图

场景执行情况

该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 3所示。从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。

图1- 3场景执行情况描述图

Statistics Summary（统计信息摘要）

该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 4所示。从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

图1- 4统计信息摘要图

Transaction Summary（事务摘要）

该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图1- 5所示。从该图我们得到每个Action的平均响应时间与业务成功率。

注意：

图1- 5事务摘要图

HTTP Responses Summary（HTTP响应摘要）

该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5- 6所示。从图中可以看到，在本次测试过程中LoadRunner共模拟发出了211974次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”则有2163，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分失败了，但未影响测试结果，“HTTP 200”表示请求被正确响应，而“HTTP 404”表示文件或者目录未能找到。有朋友可能会问，这里出现了404的错误，为什么结果还都通过了。出现这样问题的原因是脚本有些页面的请求内容并非关键点，比如可能请求先前的cookie信息，如果没有就重新获取，所以不会影响最终的测试结果。

图1- 6 HTTP响应摘要

常用的HTTP状态代码如下：

• 并发数分析

　　　“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。图1- 7显示了在OA系统考勤业务性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。在脚本中我们加入了这样一段代码：

上述代码的意思是说，如果登录失败了，就退出脚本的迭代，那么什么原因可能会导致登录失败呢？就是我们前面参数化的设置，一旦Vuser分配不到正确的登录账号，就可能导致登录失败，从而引起Vuser停止运行。所以，从图5- 7的表现，可以认为参数化是没有问题的。

图1- 7运行的并发数图

测试脚本中我们还使用了集合点，那么这里还可以看看集合点在场景执行过程中的表现，点击左边的“New Graph”，出现图5- 8，展开“Vusers”前的加号，双击“Rendezvous”，出现集合点的图形后，点击【Close】，关闭添加新图界面。

图1- 8添加集合点统计图

集合点的图形如图1- 9所示，从图中可以看到，所有用户到达集合点后，立刻就释放了。与之前设定的集合点策略设置“所有运行用户到达后释放“是一致的。假设这样的一种情况，Running的Vusers有10个，集合点策略设置是“所有运行用户到达后释放”，而集合点图形显示的最大释放Vusers是7个，那么就表示有些Vuser超时了，引起超时的原因可能是Vuser得到的响应超时了，可以结合平均事务响应时间再详细分析原因。

图1- 9集合点状态图

我们本次测试Running Vusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。

• 响应时间

在性能测试要求中我们知道，有一项指标是要求登录、考勤业务操作的页面响应时间不超过3秒，那么本次测试是否达到了这个要求呢？我们先来看“Average Transaction Response Time（平均事务响应时间图）”（图1- 10），这张图是平均事务响应时间与结果摘要中的“Transaction Summary”合成的。

图1- 10平均事务响应时间图

从图形下部我们可以看到，登录部分对应的Action是“submit_login”，考勤业务提交对应的Action是“submit_sign”，他们的“Average Time（平均响应时间为）”分别是4.425秒与0.848秒，从这两个数值来看，考勤业务的事务响应时间0.848秒小于预期的3秒，达到了要求，而登录是4.425秒，大于预期的3秒，不符合要求。这样的结果是不正确的，因为在统计的登录业务的时候，我们没有去除思考时间，所以，登录功能的实际事务时间应该是4.425秒-3秒=1.425秒，小于预期的3秒，故登录业务的事务响应时间也达到了我们的要求。在平时的性能测试活动中，统计结果的时候需要去掉思考时间，加上思考时间是为了真实的模拟用户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，两者并不矛盾。

看完了“Average Time”，我们再看“90 Percent Time”，这个时间从某种程度来说，更准确衡量了测试过程中各个事务的真实情况，表示90%的事务，服务器的响应都维持在某个值附近，“Average Time”值对于平均事务响应时间变动趋势很大的情况统计就不准确了，比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些。

从图5- 10可以看出，所有Action平均事务响应时间的趋势都非常平滑，所以使用“Average Time”与“90 Percent Time”差别不是很大，用哪个都可以。这里是使用最常用的统计方法“90 Percent Time”。登录业务的“90 Percent Time”是5.298秒-3秒（思考时间）=2.298秒，考勤业务的“90 Percent Time”是1.469秒，没有思考时间，那么就是实打实的啦。根据上面的计算，本次测试结果记录如表1所示。

表1测试结果对照表一

• 每秒点击数

　　“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。图1- 11显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。具体问题具体分析，这里仅给出一些建议。

图1- 11每秒点击数与每秒吞吐量复合图

对于本次测试来说，“Hits per Second”与“Average Throughput (bytes/second)”都是正常的，而且整体表现还是不错的。

一般情况下，这两种指标用于性能调优，比如给定了几个条件，去检测另外一个条件，用这两个指标衡量，往往起到很好的效果。比如要比较某两种硬件平台的优劣，就可以使用相同的配置方法部署软件系统，然后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。

• 业务成功率

　　“业务成功率”这个指标在很多系统中都提及到，比如电信的、金融的、企业资源管理的等等。举个例子，我们楼下的建行，假如每天的业务类别是这样的：20个开户，5个销户，300个存款，500取款，100个汇款等，那么在做他们的营业系统测试时就需要考虑业务成功率了，一般不得低于98%。具体的业务成功率是什么意思呢？排除那些复杂的业务，比如异步处理的业务（移动的套卡开通就是异步的），业务成功率就是事务成功率，用户一般把一个Aciton当做一笔业务，在LoadRunner场景执行中一笔交易称为一个事务。所以，说业务成功率其实就是事务成功率、通过率的意思。在“Transaction Summary”中我们可以很明确的看到每个事务的执行状态，如图1- 12所示。

图1- 12事务状态统计图

从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次更新测试结果记录表如表2所示。

表2测试结果对照表二

• 系统资源

　　　系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图1- 13所示。

图1- 13测试服务器系统资源监控结果图

从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了错误！未找到引用源。的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。

获得上述数据后，最新的测试结果记录表如表3所示。

表3测试结果对照表三

从上表数据来看，本次测试总体上已经达到了预期的性能指标，但从其他的数据，比如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。

• 网页细分图

　　　网页细分图可以评估页面内容是否影响事务响应时间。使用网页细分图，可以分析网站上有问题的元素（例如下载很慢的图像或打不开的链接）。

我们这里查看一下网页细分图中的“Page Download Time Breakdown”，点击错误！未找到引用源。左边的“New Graph”，出现图1- 14，展开“Web Page Diagnostics”前的加号，双击“Page Download Time Breakdown”，待出现“Page Download Time Breakdown”监控图后，点击【Close】按钮关闭添加监控图界面。

图1- 14添加网页细分图

在监控图列表中，我们看到图1- 15，从图中我们看到，在所有的页面中，登录后的用个人面页面“http://192.168.0.52:8080/oa/oa.jsp”的下载时间最长。

图1- 15网页下载时间细分图

图1- 16详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表4所示。该表由LoadRunner使用手册提供。通过这些指标的数据，我们可以轻易的判断是哪个页面、哪个请求导致了响应时间变长，甚至响应失败。

图1- 16 oa.jsp页面下载时间分布图

表4网页下载时间细分指标说明

对于本次测试，从网页细分图来看，基本上每个页面的加载时间都是预期范围内，oa.jsp页面因为集成了用户的个人工作平台，需要检索很多的数据，并合成了很多图片，所以相应的加载时间较长，这是正确的。

• Web服务器资源

　　　上述所有的监控图形LoadRunner都可以提供，但对于某些测试监控图来说，LoadRunner就没有提供了，期望其新版支持这些功能，当然想监控Tomcat、Jboss或者其他的Web服务器可以SiteScope工具，这个工具配置较为复杂，根据个人需要吧。我这里监控Tomcat使用的是ManageEngine Applications Manager 8的试用版，测试结束后得出Tomcat的JVM使用率如图1- 17所示。

图1- 17 Tomcat JVM使用率监视图

从图中我们可以明显看出，Tomcat的JVM使用率不断上升，配置Tomcat时共分配了100M左右的物理内存给其，测试初期使用的JVM相对来说较少，我们的测试场景是从15:58:40开始，到16:29:42结束，共历时31分2秒。从图中看到，从16:00到16:30这个时间内，也就是测试场景执行期间，JVM的使用率不断上升，并没有在请求达到均衡状态后也呈现一种平衡状态，所以，从这点可以推断，如果测试场景继续执行，或者加大并发数，最终必将导致Tomcat内存不够用而报出“Out Of Memory”内存溢出的错误。在正常情况下，内存的使用应该与“Hit per Second”、“Average Throughput (bytes/second)”等监控图的图形走势是一致的。

从上述过程可以得出一个结论，出现图1- 17中的问题，可能有两个原因：

1、 Tomcat的内存分配不足；

2、 程序代码有错误，可能导致内存泄露。

解决方法：

1、 为Tomcat分配更多的内存，如果是使用的catalina.sh或Catalina.bat启动的Tomcat，则可在这两个文件中添加“SET CATALINA_OPTS= -Xms300m–Xmx300m”，如果使用的winnt服务方式启动的Tomcat，则可在“运行”中输入“regedit”进入注册表，然后在“HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters”修改两个属性，一个是JvmMs，另外一个是JvmMx，如图1- 18所示。

2、 检查程序代码，使用一些内存泄露检查工具进行清查。

图1- 18修改Tocat的JVM数据

• 数据库服务器资源

数据库服务器资源监控相对来说就复杂的多了，现在常用的数据有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供对后面几种数据库的监控方法，但对Mysql没有提供对应的监控方法。他不提供，咱们就自己找监控工具，我这里使用的是Spotlight，该工具监控数据库的好处是配置连接简单，不仅能监控数据库，还能监控操作系统的资源，监控结果直观明了。错误！未找到引用源。显示了Mysql数据库在场景执行过程中SQL语句的执行情况，从图中可以看到，“Selects（查询）”与“Inserts（插入）”两种语句执行的趋势在场景执行过程中是比较平滑，并且测试中没有错误发现，也就说明在处理相关业务时Mysql的处理是正常的。假如这两种SQL语句任何一个出现波动很大的情况，就可以推出在场景执行过程中存在页面错误，因为这些语句不执行，就表明某些页面未被加载或者某些功能未被使用。在本次测试中，OA系统的“oa.jsp”页面有大量的“Selects（查询）”语句，而考勤操作则是“Inserts（插入）”，所以，只要有一方出问题，必然表示测试过程中存在页面打不开或者考勤不成功的错误。

通过前面的分析，在查看错误！未找到引用源。中的SQL语句执行状态，本次测试在页面访问、功能执行方面是没有问题的。

2011-03-21 15:37:38| 分类： 性能测试 | 标签： |字号大中小 订阅

　　如果选择以线程方式来运行虚拟用户：

　　在场景设置时，“是单行脚本，还是多行脚本”会决定系统启动的进程数的多少：假设并发用户设置为30，如果是单行30个用户，系统只需启动一个进程；假设并发用户设置为30，如果是多行，30行，每行一个用户，系统就需要启动30个进程；

　　如果选择以进程方式来运行虚拟用户：

　　那么无论脚本在场景组中怎么设置，是单行多用户还是多行少用户方式，系统需要启动的进程数是一定的，就是并发用户的总数；

　　进程方式和线程方式的优缺点：

　 　如果选择按照进程方式运行，每个用户都将启动一个mmdrv进程，多个mmdrv进程会占用大量内存及其他系统资源，这就限制了可以在任一负载生成器上 运行的并发用户数的数量，因为负载机的资源（内存及其他系统资源）是有限的。如果选择按照线程方式运行，在默认情况下，controller为每50个用 户仅启动一个mmdrv进程，而每个用户都按线程方式来运行，这些线程用户将共享父进程的内存段，这就节省了大量内存空间，从而可以在一个负载生成器上运 行更多的用户。（如果选择线程方式来运行用户，每个进程中会多出几个线程，例如是53个，多出来的进程可能是用于维护进程之间的运行的）选择线程方式虽然 可以减少启动的mmdrv进程数，减少了内存的占用，但是也容易出现一个问题，例如，同一个测试场景，用线程并发就会出现超时失败或报错，而用进程并发就没错。为什么呢？因为线程的资源是从进程资源中分配出来的，因此同一个进程中的多个线程会有共享的内存空间，假设a线程要用资源就必须等待b线程释放，而b线程也在等待其他资源释放才能继续，这样就会出现这个问题。

　　系统需要启动的mmdrv进程数与哪些因素有关：

　 　与在controller 的运行时设置中选择的是进程方式or线程方式来运行虚拟用户有关进程方式：无论是单行or多行脚本，需要启动的进程数就是并发用户数；线程方式：假设是单 行脚本，每50个用户才启动一个进程；多行脚本，有几行（每行<50人）就启动几个进程，而不是每个用户启动一个进程。如果选择了线程方式，需启动 的进程数，进一步还与脚本是单行还是多行有关单行脚本，多用户，假设少于50，只需启动一个进程，100个用户，只需启动2个进程，依此类推；多行脚本， 即使每行一个用户，也需要启动一个进程，多一行就需要多启动一个进程；不是每个用户启动一个进程，有几行（每行<50人）就需要启动几个进程。在启 动了IP欺骗功能后，所需启动的进程数，还与选择的是按进程还是按线程来分配IP地址有关按进程分IP：每个ip（负载生成器）就需要多启动一个进程； 按线程分IP：每个ip（负载生成器）不需要多启动一个进程。

Warning   Set up the Controller before setting up any agents.

Note   Load controllers cannot be installed on domain controllers.

1. Start setup.exe located in the vs\controller folder.

The Welcome to Setup page appears.

2. Click Next.

The End-User License Agreement and Product Key page appears.

3. Review the End-User License Agreement (EULA) and select I accept the terms of the license agreement, if appropriate.

4. Enter the product key information and then click Next.

The Destination Folder page appears.

5. Click Browse to select a different destination folder, or click Next to use the default folder.

The Service Account page appears.

6. Enter the account name and password for the controller service account and then click Next.

The Ready to Install page appears.

7. Review the installation information and then click Install to continue.

The Installing Components page appears.

8. Upon successful installation, the Setup Completed Successfully page appears. Click Finish to complete the Setup program.

During Setup, you are prompted for the controller service account. The controller service account collects performance counters on other computers during a load test. Use a domain account that can easily be granted access to many computers. Grant the controller user rights to monitor performance on all the systems under test for the built-in performance monitoring capabilities to work.

Setup creates three local groups:

· TeamTestControllerAdmins

· TeamTestControllerUsers

· TeamTestAgentService

Add users who run tests to TeamTestControllerUsers. Add users who administer the test rig to TeamTestControllerAdmins. Agent setup automatically adds the users who Agent Services run as to TeamTestAgentService.

Note The user running the controller setup must be a member of local Administrators group.

The controller runs as a Windows Service on the computers on which it is installed. To view the properties of the service use Control Panel. In Control Panel, choose Administrative Tools and then choose Services. The name of the controller service is the Visual Studio Team Test Controller. The controller services can be started and stopped like other services in Windows.

The controller and agents can be configured and monitored by using the Administer Test Controller dialog box, available on the Test menu. For more information, see “How to: Administer the Rig” in the product documentation.

By default, the controller uses SQL Express to store load test results. SQL Express is license limited to store 4GB of data, which is approximately 10 hours of load test data. If you choose to use another SQL database to store the results, you can set up the Load Test Results Store after you have installed the controller. For more information, see “How to: Configure a Results Store using SQL” in the product documentation.

After you have configured your Load Test Results Store, you must indicate to the controller where the results are to be stored. For more information, see “How to: Select a Load Test Results Store” in the product documentation.

Load Controller Firewall Exceptions

If you are running Windows Firewall, the controller setup adds the following exceptions to your firewall:

If you are running on Windows XP in a work group, you must turn off Simple File Sharing. See this KB for info on how to do that: http://support.microsoft.com/kb/307874

Accessing the Controller

After the controller is installed, access to the controller is limited to members of the TeamTestControllerUsers and TeamTestControllerAdmins groups that were created during Setup, and to the Administrators group.
Add appropriate users and/or groups to these groups to allow them to access the controller.
Members of the TeamTestControllerAdmins group or the Administrators group can administer the controller by clicking the Test menu, and then choosing Administer Test Controller in Visual Studio.
Members of the TeamTestControllerAdmins group must also be power users or administrators on the controller computer.

Team Test Load Agent Installation

Warning    Set up the Controller before setting up any agents.

1. Start setup.exe located in the vs\agent folder.

The Welcome to Setup page appears.

2. Click Next.

The End-User License Agreement and Product Key page appears.

3. Review the End-User License Agreement (EULA) and accept the terms of the license agreement, if appropriate.

4. Enter the product key information and then click Next.

The Destination Folder page appears.

5. Click Browse to select a different destination folder, or click Next to use the default folder.

Note   If you are installing the Agent on the same computer as the Controller, the option to choose a new location is disabled.

The Specify Controller page appears.

6. Enter the computer name of the Team Test Load Controller computer and click Next.

Note   You can locate the name of the controller computer by clicking My Computer, right-clicking, choosing Properties and viewing the Computer Name tab.

The Ready to Install page appears.

7. Review the installation information and then click Install to continue.

The Installing Components page appears.

8. Upon successful installation, the Setup Completed Successfully page appears. Click Finish to complete the setup.

Following this, you will be prompted to restart your computer to complete the installation.

Note The user running the agent setup must be a member of local Administrators group and a member of the controller’s Administrators group.

During setup, you are prompted for the name of the controller computer that this agent will be associated with. Agent setup communicates with the controller to add the agent to the controller.

During setup, you are prompted for the Agent user. This user is automatically added to TeamTestAgentService group on the controller. Only Agent Service Users who are a member of this group are allowed to communicate with the controller.

The Agent service is named Visual Studio Team Test Agent. To view the properties of the service use Control Panel. In Control Panel, choose Administrative Tools and then choose Services. The agent services can be started and stopped like other services in Windows. Also the agents can be administered using the Administer Test Controller dialog box, available on the Test menu. For more information, see “How to: Administer the Rig” in the product documentation.

Note   AgentConfigUtil.exe is a command line utility that can be used to assign an Agent to a different Controller, or to add an Agent to a Controller if Agent setup fails to do so.

Load Agent Firewall Exceptions

If you are running Windows Firewall, Agent setup added the following exceptions to your firewall:

If you are running on Windows XP in a work group, you will also need to turn off Simple File Sharing.

Troubleshooting

Note   To verify the installation, run Visual Studio and launch the Administer Test Controller dialog box (available from the Test menu), connect to the controller, and check the status of the agents.
Agents should be in the Ready state.
If an agent is not in the list of agents, reinstall the agent or run AgentConfigUtil.exe after verifying that the controller is installed correctly.
If the agent is in the Disconnected state, check that the agent service user account has been added to the TeamTestAgentService user group on the controller. Also check the <installdir>\Microsoft Visual Studio 2005 Team Test Load Agent\LoadTest\agentConfigUtilSetup*.log file for errors.

“Rig failed to restart for controller <controller computer name>. The following error was reported Cannot open VSTTController service on computer <controller computer name>.”

This error occurs when a user tries to restart the rig from the Administer Test Controller dialog box, but while this user has been added to the TeamTestControllerAdmins group, they have not also been added to the Power User or Administrator group.

　　一个访问量达到百万级别的门户网站及奥运会订票系统等这中用户数较多的系统，进行性能测试是必须的。要不就和产品演示会上出现的笑话一样，风险投资商提出的问题是这个网站能支持多少用户同时上线，项目经理居然说没有进行这方面的测试。全场哗然。。。。

　　对于性能测试的第一步是怎么去根据业务的实际模型分析出具体的测试场景及性能测试的指标。

　　一、 性能测试业务逻辑理解的一些基本概念

　　1、负载测试和压力测试的区别：负载测试在于确定最终满足系统指标的前提下，系统所能承受的最大负载测试，压力测试的目标则在确定什么条件下系统性能处于失效状态。

　　2、吞吐量（Throughput）：指单位时间内处理的客户段请求数量，直接体现软件系统的性能承载能力。

　　3、并发（Concurrency）：多个同时发生的业务操作。例如100个用户同时点登录21CN邮箱和同时在线人数不一样。比如说21CN通行证用户登录的有1万个可能只有20%的人在看博客，10%的人在看相册，30%的人在查看邮件，10%的人在查看播客，10%的人在看视频点播，10%的人在逛论坛等等

　　但是同时在线人数就是1万，并发用户就是针对每个系统的具体人数。

　　二、几种常见的业务模型设计

　　1、e家广告系统：

　　（1）具体的业务参数要求：

　　系统要达到4000万日均PV，则需要平台可以处理4000并发/秒。根据选中的服务器的性能，处理能力约为2000个HTTP并发/秒或1000个流媒体并发/秒。假设这4000万PV中有图片的PV占3000万，流媒体的PV占1000万，则需要WEB服务器及流媒体服务器各两台。

　　（2）具体的测试设计方法：

　　（a）平台的处理能力与要达到的日均PV的能力的计算关系为：

　　参数说明：

　　X：表示整个系统的日均PV值，单位为：万PV/天

　　m：平台最大有效并发数（即用来服务于广告物料显示的并发数），单位为：并发/秒，每小时是3600秒，即每个小时处理的并发数为3600m并发，即0.36m万并发/小时。

　　y：非高峰时期的平均并发数与平台最大并发数的比例，0<y<1

　　Y：高峰期（平台达到最大并发数的70%，平台负载超过70%以后，将变得不稳定）小时数,0<Y<24,即高峰期并发数为70%*0.36m

　　那么：

　　日均PV＝高峰期并发数＊高峰期小时数＋非高峰期平均并发数＊（24－高峰期小时数）

　　即：

　　X=0.7*0.36mY+y*0.36m*(24-Y)

　　即最后结论：

　　X=(0.252Y+8.64y-0.36yY)*m

　　根据经验值，Y＝3，y=30%时，m/X=0.33。而m是平台最大有效并发数，即用来服务于广告物料显示的并发数，而对于每次广告物料的显示，客户端还有访问其它资源如JS代码等，假设每一次广告物料的访问会有伴随另外2个资源的访问。

　　那么平台支撑的总的并发数与需要达到的日均PV的比大约为0.33*3=1。

　　（b）实际测试模型设计中结果：

　　对广告链接页面的并发用户数只需要达到N1=0.33*40000000*0.7/24*0.3*3600=356个

　　对于流媒体服务器并发用户数：N2=10000000*0.7/24*0.3*3600/2=135个

　　对于图片服务器并发用户数：N3=30000000*0.7/24*0.3*3600/2=405个

　　2、集团邮箱：

　　（1）具体的业务参数要求：集团邮箱支持支持2000万用户，对性能有要求的操作有邮箱登录，读信，翻页，发邮件（分别是8秒内，2秒内，2秒内，5秒内）。所有的操作均返回HTTP200的状态代码。其中服务器资源分别是登录5台机器（连接PASSPORT），收发邮件5台（不包括POP收发信），其它邮件处理服务器5台，pop/smtp服务器5台。 

　　（2）具体的测试设计方法：具体的设计2000万个用户登录时间大概在会在8点到下午18点前操作，而该类业务模型满足80~20原则，比如80%的业务会在20%的时间内处理。则登录的并发用户数设计成多少好呢？ VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此类推。 

　　（3）当然如果业务在要求吞吐量的时候，就要更根据吞吐量来设计性能瓶颈所需要的并发用户数这在我们21CN网站和电子商务网站中经常出现。这里引进一个公式VU=F /R*T(VU并发虚拟用户数,F吞吐量,T性能测试时间,R每个VU的请求数量)举例说明（某网站的吞吐量为90亿KB，每个用户每秒50万kb，运行时间30分钟设计出来的每秒用户数VU=9000000000/(500000*30*30)）

　　（4）如办公系统（业务比较频繁的系统）：每天内的一些典型用户固定可以考虑采用一种更准确的计算并发用户数的的方法。公式引进：C=N*L/T,C1=C+ (C是平均并发用户数，N是login session的数量，L是login session的时长，T是考察的时间长度，C1是最高峰值)（*这里的用户是指明确每天都要使用的系统的大概数量来自需求，而这里的用户都是当做一个典型的用户来分析就是登录后会进行正常的流程操作）如21CNEIP每天有320个典型用户访问，系统平均时间为4小时，在一天内用户使用该系统的时间都在8小时内。得出C=320*4/8,C1=C+3 (5)针对这几种模式做一些归纳无论那种模型都是来源于需求根据需求的实际模型是最真实的也是最有效的性能测试模型，在没有典型用户的前提下选择2-8原则（在测试环境中要考虑到等价这个概念就是测试环境服务器数量没有实际环境哪么多的时候要折算过来），有典型用户的情况下选择最大并发数的计算方法，在要求有吞吐量的情况下用吞吐量的计算方法（但是吞吐量的数据要采用上一次测试或者经验值中没有突破系统瓶颈的部分数据要不结果不准确，其中每秒事物数取的是平均值）

　　三、其它值得注意部分

　　1、设置测试场景中并发用户为每隔一段时间增加X个虚拟用户（预热，RAMP UP设置），与同时加载所有的并发用户的测试结果不同，实际的测试中要根据具体业务情况设计。另外实际的数据库记录数和网络环境等都会影响到测试结果。

　　2、建议在实际的测试过程中能多次测试取平均值。

　　3、性能测试的”拐点论”:产生拐点的情况是性能测试产生某种瓶颈，主要原因是某种资源达到了极限。此时表现为随着压力的增大，系统性能出现急剧下降。

　　4、性能测试的系统能力验证: （a）是系统稳定性的一个基本要求，通常表现为系统在要求的平均并发用户下服务器的CPU平均使用率不高于75%，内存的使用率不高于75%。（b）系统在要求的并发用户数达到峰值情况下服务器的CPU平均使用率不高于95%，内存的使用率不高于90%。（c）系统能在高于实际系统运行压力1倍的情况下，稳定的运行72小时。

　　5、为分清各个不同事物的响应时间请务必在多事物的脚本中添加事物以便区分，请在要用到多个帐户或者多个用户的迭代或者循环操作的时候请务必进行参数化（很多系统都限制了同一帐户在多长时间的操作，或者防止数据冲突）。

邮箱：sideny2009@gmail.com

MSN：kxming2010@hotmail.com

2、泄漏的例子
举几个例子   
  void   fun0()   
  {   
      char   *p=new   char[100];   
  }   
  执行完上面的函数就发生了泄露   
  指针p是局部变量，函数执行完后，指针p被销毁，造成   new   char[100]的内存没有指针指向它   
  ，也就无法再使用，造成内存泄漏。  
  void   fun1()   
  {   
      char   *p=new   char[100];   
      p=new   char[100];   
  }   
  这也泄露了   
   
  void   fun2()   
  {   
      new   char[100];   
  }   
  这东西肯定泄露完了   
   
  void   fun3(char   *a)   
  {   
      char   *p=new   char[100];   
      char   *b=p;   
      p=a;   
      a=b;   
  }   
  可能有泄露，赶紧去加内存条。

3、泄漏的分类
以发生的方式来分类，内存泄漏可以分为4类：
（1）常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
（2）偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
（3）一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
（4）隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

4、内存泄漏的表现
内存泄漏或者是说，资源耗尽后，系统会表现出什么现象哪？
cpu资源耗尽：估计是机器没有反应了，键盘，鼠标，以及网络等等。这个在windows上经常看见，特别是中了毒。
进程id耗尽：没法创建新的进程了，串口或者telnet都没法创建了。
硬盘耗尽： 机器要死了，交换内存没法用，日志也没法用了，死是很正常的。
内存泄漏或者内存耗尽：新的连接无法创建，free的内存比较少。发生内存泄漏的程序很多，但是要想产生一定的后果，就需要这个进程是无限循环的，是个服务进程。当然，内核也是无限循环的，所以，如果内核发生了内存泄漏，情况就更加不妙。内存泄漏是一种很难定位和跟踪的错误，目前还没看到有什么好用的工具（当然，用户空间有一些工具，有静态分析的，也会动态分析的，但是找内核的内存泄漏，没有好的开源工具）
内存泄漏和对象的引用计数有很大的关系，再加上c/c++都没有自动的垃圾回收机制，如果没有手动释放内存，问题就会出现。如果要避免这个问题，还是要从代码上入手，良好的编码习惯和规范，是避免错误的不二法门。

5.内存泄漏的检测
另外网上还有很多针对java和c＋＋等的内存泄漏的文章
Java内存泄漏：http://www.blogjava.net/galaxyp/archive/2006/04/28/43724.html
VC6.0内存泄漏检测：http://leoman95.spaces.live.com/... e8fa434b1!131.entry
LR中：如果Process\Private Bytes计数器和Process\Working Set计数器的值持续升高，同时Memory\Available bytes计数器的值却持续降低的话，说明很有可能是存在内存泄漏

   在LoadRunner中没有提供直接监控MySQL的方法，但是在实际工作中需要我们对mysql数据库服务器进行监控，我们可以利用sitescope监控然后在lr中显示SiteScope监控的结果，达到间接监控mysql的目的。

   备注：MercyrySiteScope介绍：它是一款无代理监测解决方案，可确保分布式IT基础架构——如服务器、操作系统、网络设备、网络服务、应用和应用组件的可用性和性能。这款主动的、基于Web界面的基础架构监测解决方案是非常简洁的，而且完全根据客户度身定制，无需在您的上线系统中增加额外的代理。
SiteScope为上线系统提供24×7的监控服务，为维护工程师及时发现问题提供帮助，确保系统架构内一切组建的正常运作。SiteScope在大量增加检测周期的同时也降低了维护人员的工作成本 。
SiteScope能够监控UNIX服务器资源、windows服务器资源、weblogic应用服务器、IIS应用服务器、Oracle数据库、SQLServer数据库、F5、URL地址、Ping、内存、CPU、磁盘空间、服务等等系统架构内各种组建的运行状况；监控器按照指定频率对目标进行检测，一旦发现异常会及时向管理员发送意外事件的报警，警报可以通过声音提醒、email、短信等方式发送；另外，SiteScope还可以生成监测活动的汇总报告，该对象从日志文件中读取历史信息，接着总结、筛选信息，并生成图表格式的报告。

   SiteScope利用Database Query monitor监控指定的数据库，通过SiteScope监控器的SHOW STATUS命令，获得相应数据，命令如下:

  show status where variable_name like ’innodb_buffer_pool_pages_total’

 为了确保监控请确认LoadRunner and SiteScope之间的端口, SiteScope和MySQL必须打开TCP 8888和TCP 3306 . 还有SiteScope要监控必须要确保有JDBC的安装。 

转自SiteScope帮助：

Keep in mind that when we mention rendering time, it means the time taken for the display of the web components, Javascript or applet to load in the browser (or anything that is considered client-activity, loading in the browser) that is being activated after the HTML page is being received.

When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.

In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time). However, in the context of LoadRunner, UI is not part of this entire request and response cycle.

Keep in mind that the transmission of the data is still pure text (or binary) and that needs to be rendered by the browser to be displayed properly. That’s considering the Javascript and any applets that needs to be loaded which is greatly dependent on the browser (eg. IE, Modzilla)and your machine specifications.

Even for Web Page Diagnostics, rendering time is not included as part of the transaction response time. It only allows the drill-down of time taken to download web components and not the time taken to render the component for display. In summary, it’s still at the network level.

If you are looking for an end-to-end response time testing that includes the rendering of the UI, you should consider using the GUI vuser protocol. The protocol utilizes another (famous) HP testing product, Quick Test Professional (QTP) as the recording mechanism, and replays the QTP scripts in the Load Generators as GUI vusers. For official information on the GUI vuser protocol, you can refer to the HP LoadRunner (v9.0) Controller User Guide, Chapter 14, “Using Functional Testing Scripts in LoadRunner”.

首先，从工具的角度来说，厂商推荐使用Web_submit_form函数，因为这个函数看起来更易用，需要关注的东西较少。但是，从个人的角度来说，我推荐使用Web_submit_data函数。因为这个函数提供更多技术细节。在测试的过程中可控性更高。下面我就详细解释一下两个函数的工作机制：

首先看一下下面这段HTML代码

<Form Action=login.asp Method=“POST”>

<input name=user value=“”>

<input name=password value=“”>

<input type=hidden name=sessionID value=15379>

</Form>

在录制的过程中，当打开这个页面的时候，这个页面会放在LR的Cache中，之后当我们输入了用户名、口令之后，点了一下提交。Browser会向LR Record Proxy发送一个提交请求，提交内容应该是这样的：

POST login.asp HTTP/1.1

user=steve password=buba

sessionID=15379

这时候，LR会自动比较提交的内容和Cache的内容，首先它会比较提交的数据项和Cache中的数据项是否一致。页面中有三个输入域user、password、sessionID，而提交的内容也有这三项数据，所以它认为提交数据使用了Cache中的页面，之后它会继续比较具体数据的值。它会发现sessionID的值和Cache中的值是一样的。但是user和password的值不一样。

这时候，Web_submit_form和Web_submit_data的区别就出现了：

web_submit_form(”start",

ITEMDATA,

"name=user", "value=steve", ENDITEM,

"name=password", "value=bean", ENDITEM,

LAST);

web_submit_data(”start",

“Action=login.asp”,

“Method=POST”

ITEMDATA,

"name=user", "value=steve", ENDITEM,

"name=password", "value=bean", ENDITEM,

"name=sessionID", "value=15379", ENDITEM,

LAST);

可以看到，Web_submit_form只提供了和Cache中有差别的数据，其余的数据会自动从Cache中取。而Web_submit_data则提供了所有的数据，不管Cache存在不存在Web_submit_data都是可以工作的。

所以厂商会推荐使用Web_submit_form，因为它看起来更易用，甚至关联都不需要作，就能直接回放。但是这种情况只能对于简单系统适用。对于一些银行或者移动的复杂系统来说，有时侯会对Cache作特殊操作，Web_submit_form有时侯就会报一些莫名其妙的错出来。而Web_submit_data则跟Cache内容无关。稳定性和可控性都要比Web_submit_form要高很多。所以个人推荐尽量使用Web_submit_data函数。

在Loadrunner的使用中，对于Run-time Settings下的browser emulation设置是比较容易让人产生困惑的地方。下面我们结合sniffer来具体看看每个选项的用途，以及对测试的影响。

                                               Browser Emulation 图

二：案例和工具

1. 测试案例：

打开网站首页两次，对比不同Browser Emulation设置下loadrunner的行为，脚本如下。

Action()
{
    web_url("www.primeton.com", 
        "URL=http://www.primeton.com/", 
        "Resource=0", 
        "RecContentType=text/html", 
        "Referer=", 
        "Snapshot=t2.inf", 
        "Mode=HTML", 
        LAST);

    web_url("www.primeton.com", 
        "URL=http://www.primeton.com/", 
        "Resource=0", 
        "RecContentType=text/html", 
        "Referer=", 
        "Snapshot=t2.inf", 
        "Mode=HTML", 
        LAST);

    return 0;
}

2. sniffer工具

开源工具：Wireshark(前身是ethereal)（www.wireshark.org）

三：测试过程

为了方便描述，我们约定用：

A代表Simulate browser cache

B代表Cache URLs requiring content(HTMLs)

C代表Check for newer versions of stored pages every visit to the page

D代表Download non-HTML resources

E代表Simulate a new user on each iteratioin

F代表Clear cache on each iteration

首先设置Run Logic中的iteration为2。让Action运行两次，看看循环运行脚本两次，数据包和连接数的变化。

1. 去掉所有选项

结果：共获取数据包95个，建立连接1个（红色标识），断开连接1个（蓝色标识）

No.     Time        Source            Destination       Protocol Info
      1 0.000000    192.168.1.61      203.81.29.137     TCP      13835 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      2 0.036053    203.81.29.137     192.168.1.61      TCP      http > 13835 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
     92 1.415887    192.168.1.61      203.81.29.137     TCP      13835 > http [FIN, ACK] Seq=817 Ack=71762 Win=257760 Len=0
     94 1.449960    203.81.29.137     192.168.1.61      TCP      http > 13835 [FIN, ACK] Seq=71762 Ack=818 Win=16464 Len=0

在这种情况下，数据包非常少（没有选择下载资源文件入css,js,gif等），而且你可以看到，打开4次首页，只建立了一个tcp连接。

这时，你即使选择A，发现数据包的数量量页没有变化，因为cache主要还是针对资源文件

2. 选择E(F)

结果：共获取数据包102个，建立连接2个（红色标识），断开连接2个（蓝色标识）

No.     Time        Source            Destination       Protocol Info
      1 0.000000    192.168.1.61      203.81.29.137     TCP      13886 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      2 0.037013    203.81.29.137     192.168.1.61      TCP      http > 13886 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
     48 0.618117    192.168.1.61      203.81.29.137     TCP      13886 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
     49 0.644106    192.168.1.61      203.81.29.137     TCP      13887 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
     51 0.651919    203.81.29.137     192.168.1.61      TCP      http > 13886 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
     53 0.676377    203.81.29.137     192.168.1.61      TCP      http > 13887 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
     99 1.310379    192.168.1.61      203.81.29.137     TCP      13887 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
101 1.347949    203.81.29.137     192.168.1.61      TCP      http > 13887 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0

在这种情况下，数据包非常少（没有选择下载资源文件入css,js,gif等），对比第一种情况，你会发现它建立了两个连接，这就是E的作用，它对于每次迭代都当成一个新的用户，需要重新建立连接。

3. 选择DE(F)

结果：共获取数据包1782个，建立连接6个（红色标识），断开连接6个（蓝色标识）

No.     Time        Source            Destination       Protocol Info
      1 0.000000    192.168.1.61      203.81.29.137     TCP      14016 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      2 0.037911    203.81.29.137     192.168.1.61      TCP      http > 14016 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
      6 0.107432    192.168.1.61      203.81.29.137     TCP      14017 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      9 0.141816    203.81.29.137     192.168.1.61      TCP      http > 14017 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    426 3.334889    192.168.1.61      203.81.29.137     TCP      14017 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
    428 3.372253    203.81.29.137     192.168.1.61      TCP      http > 14017 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
    448 4.395488    192.168.1.61      203.81.29.137     TCP      14020 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    457 4.439604    203.81.29.137     192.168.1.61      TCP      http > 14020 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    859 7.593610    192.168.1.61      203.81.29.137     TCP      14016 > http [FIN, ACK] Seq=2849 Ack=377404 Win=257484 Len=0
    870 7.659680    203.81.29.137     192.168.1.61      TCP      http > 14016 [FIN, ACK] Seq=377404 Ack=2850 Win=15935 Len=0
    888 8.511308    192.168.1.61      203.81.29.137     TCP      14020 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0
    890 8.549451    203.81.29.137     192.168.1.61      TCP      http > 14020 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0
    892 8.566246    192.168.1.61      203.81.29.137     TCP      14022 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    893 8.601893    203.81.29.137     192.168.1.61      TCP      http > 14022 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    899 8.702628    192.168.1.61      203.81.29.137     TCP      14023 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    904 8.741807    203.81.29.137     192.168.1.61      TCP      http > 14023 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
   1298 11.809456   192.168.1.61      203.81.29.137     TCP      14022 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0
   1310 11.878665   203.81.29.137     192.168.1.61      TCP      http > 14022 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0
   1341 12.771707   192.168.1.61      203.81.29.137     TCP      14026 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
   1348 12.813950   203.81.29.137     192.168.1.61      TCP      http > 14026 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
   1759 16.032952   192.168.1.61      203.81.29.137     TCP      14023 > http [FIN, ACK] Seq=3151 Ack=367918 Win=257484 Len=0
   1761 16.068296   203.81.29.137     192.168.1.61      TCP      http > 14023 [FIN, ACK] Seq=367918 Ack=3152 Win=17280 Len=0
   1779 16.983042   192.168.1.61      203.81.29.137     TCP      14026 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0
   1781 17.016836   203.81.29.137     192.168.1.61      TCP      http > 14026 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0

在这种情况下，数据包的数量非常大，连接也很多，由于没有cache功能，每次打开页面都需要重新下载所有的资源文件。

4. 选择ADE

结果：共获取数据包525个，建立连接3个，断开连接3个(不再标识了，syn即为连接请求，fin即为断开请求）

No.     Time        Source            Destination       Protocol Info
      1 0.000000    192.168.1.61      203.81.29.137     TCP      14189 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      2 0.033657    203.81.29.137     192.168.1.61      TCP      http > 14189 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
      6 0.100636    192.168.1.61      203.81.29.137     TCP      14190 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      9 0.133703    203.81.29.137     192.168.1.61      TCP      http > 14190 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    429 3.383748    192.168.1.61      203.81.29.137     TCP      14190 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
    431 3.418556    203.81.29.137     192.168.1.61      TCP      http > 14190 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
    471 4.352071    192.168.1.61      203.81.29.137     TCP      14189 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0
    472 4.380312    192.168.1.61      203.81.29.137     TCP      14192 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    474 4.389778    203.81.29.137     192.168.1.61      TCP      http > 14189 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0
    476 4.413220    203.81.29.137     192.168.1.61      TCP      http > 14192 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    522 5.078068    192.168.1.61      203.81.29.137     TCP      14192 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
524 5.115099    203.81.29.137     192.168.1.61      TCP      http > 14192 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0

在这种情况下，cache发挥作用，数据包对比第三种情况大大减少，几乎等于打开一次首页的数据量（449个数据包），只有第一次打开页面需要完整下载页面（包括资源文件），后面的三次打开页面都只要下载HTML页面（不包括资源文件）。

5. 选择ADEF

选择F之后我们看看结果：共获取数据包942个，建立连接4个，断开连接4个

No.     Time        Source            Destination       Protocol Info
      1 0.000000    192.168.1.61      203.81.29.137     TCP      14292 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      2 0.034524    203.81.29.137     192.168.1.61      TCP      http > 14292 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
      6 0.102314    192.168.1.61      203.81.29.137     TCP      14294 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
      9 0.139752    203.81.29.137     192.168.1.61      TCP      http > 14294 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    426 3.791111    192.168.1.61      203.81.29.137     TCP      14294 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
    428 3.824970    203.81.29.137     192.168.1.61      TCP      http > 14294 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
    468 6.213276    192.168.1.61      203.81.29.137     TCP      14292 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0
    469 6.244052    192.168.1.61      203.81.29.137     TCP      14297 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    471 6.249564    203.81.29.137     192.168.1.61      TCP      http > 14292 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0
    473 6.279647    203.81.29.137     192.168.1.61      TCP      http > 14297 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    479 6.374967    192.168.1.61      203.81.29.137     TCP      14298 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
    484 6.419597    203.81.29.137     192.168.1.61      TCP      http > 14298 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
    897 9.858493    192.168.1.61      203.81.29.137     TCP      14297 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0
    899 9.895188    203.81.29.137     192.168.1.61      TCP      http > 14297 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0
    939 12.840029   192.168.1.61      203.81.29.137     TCP      14298 > http [FIN, ACK] Seq=1806 Ack=226090 Win=257760 Len=0
    941 12.876120   203.81.29.137     192.168.1.61      TCP      http > 14298 [FIN, ACK] Seq=226090 Ack=1807 Win=17076 Len=0

在这种情况下，由于选择了F，在迭代的时候清除了cache，所以每次迭代都需要重新下载资源文件。数据包差不多等于第三种情况的一半，约等于打开两次首页的数据量（449×2个数据包）。

6. 关于BC选项

C的解释（Check for newer versions of stored pages every visit to the page）

C比较容易理解，类似IE设置中的每次检查，如果不设置C，LR对于已经cache的文件就不会重新向服务器请求，如果选择C，你就可以在数据包中发现很多304信息。

B的解释（Cache URLs requiring content(HTMLs)）

LR对于资源文件的cache并不会真正cache在内存中或者在磁盘上，这个选项表示：对于一些需要用到的关联，校验，页面解析内容真正cache在内存中，减少客户端的重复工作。

当然如果你想把GIF也cache到内存中，你可以在Advanced中设置，选择Specify URL requiring content in addition to HTML pages，加入条目image/gif，并勾选。当Vuser运行的时候，你可以对比一下mmdrv.exe进程的内存消耗（内存占用会更多）。

四： 结论

通过上面的测试分析，我们大概知道了每个选项的真正含义，你需要根据你的测试目的来选择合适的设置：

1、 对于一个具体的应用测试，对于前端Web Server不可忽略，缺省设置非常合适，不需要调整（有时候需要考虑把C选上）

注意：很多人在录制脚本的时候，习惯把登入操作放到vuser_init中，这时候缺省设置可能会抛错，建议把这类的操作都放入到action中

2、 如果你更关注后端应用服务器的性能或者说做一些架构的验证分析，那你缺省设置对于你来说就不合适了，你需要选择取消所有的设置项。

当然你也可以根据自己的具体情况做不同调整，但是一定要真正理解这些选项的具体含义才能做到不犯错误

Web Page Diagnostics （以下简称WPD），这是LR Analysis中非常重要的一块，搞清楚这部分的内容会让你少走很多弯路，很多环境问题都可以通过它来定位，比如客户端，网络。通过它可以你可以比较好 的来定位是环境的问题还是应用本身的问题，当然更重要的是Web页面本身的问题。

WPD包括下面几个图表：

Web Page Diagnostics     这是张总图，包括下面几张Over Time图的内容

Page Component Breakdown     页面中每个元素的平均响应时间占整个页面响应时间的百分比

Page Component Breakdown(Over Time)     在整个测试过程中，任意一秒内页面中每个元素的响应时间（例如在runtime中设置了browser cache，页面中的资源文件就只会在第一次下载，后面的页面响应时间也就不包括这些元素的时间，这在Page Component Breakdown中是看不出来的，因为Page Component Breakdown是整个测试期间内的平均时间。当然，是否启用了cache，通过over time图就能看出来）

Page Download Time Breakdown    页面中每个元素的响应时间分割图，响应时间被分割为以下几个部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error

Page Download Time Breakdown(Over Time)      在整个测试过程中，任意一秒内页面中每个元素的响应时间分割图

Time to First Buffer Breakdown      First Buffer Time时间分割为Network Time和Server Time，客户端http请求发送到接收到服务器端的应答包（ACK）为Network Time，从接收到ACK到完成First Buffer接受为Server Time

Time to First Buffer Breakdown(Over Time)      基本同上，任意一秒内的

Downloaded Component Size(KB)      页面中每个元素的大小（KB）

介绍了这么多，具体如何分析呢？

首先打开Web Page Diagnostics图，来看看下面一个例子Download Time图：

上图存在两个问题：

1、receive时间很长

这个一般是网络问题，当然如果你确认网络不存在问题，那么你就要看看是不是客户端的问题（客户端也可能会造成Receive过长，这个千万要注意）

2、页面问题

页面上包括了非常多的图片，而且图片似乎都没有优化，最大的竟然有163K，记下来，这可是罪证哦 ；）

很多时候，你可以根据DNS,Connection,Receive来看出是否存在网络问题，根据Client来判断是否存在客户端问题。

看看，挺简单的吧！ ^_^

换个图看看，Page Component Breakdown(Over Time)

很清楚吧，页面元素都被cache了，说明场景启用了browser cache，页面的响应时间只包括红线和蓝线。

        下面就讨论一下在性能测试实战中，为什么要设置考虑时间。

        先说一个概念：吞吐量，这指的是服务器系统（包括软件和硬件）单位时间内处理业务的数量。我们现在做一个小试验，写一个小程序，执行一个简单的业务，并且 在程序中进行计时，计算每分钟能执行多少次。然后当我们运行1路这个程序的时候，每分钟能完成约6万次。好，现在问一个问题，如果我们起2路，是不是每一 路都能达到 6万/分钟 的吞吐量？

        试验发现，当运行2路的时候，两个程序的数值都降了下来，但是它们的总和仍然是6万次。而且不管我们起多少路，这些程序的性能总和都接近于6万。

        这就好像一个人1分钟最快能吃1个馒头，你让他一个一个吃，他两分钟能吃2个，如果你让他一手拿一个，同时吃，他两分钟吃不了4个，还是只能吃两个。

        我们不是在说“考虑时间”么，哈哈，别急，因为上面的问题必须要先说清楚。

        如果我们需要进行性能测试的业务是一个单纯的业务，就好像上面举的那个例子一样，那么测试脚本中就不需要设置“考虑时间”，因为不管你用什么方法测试，一个服务系统处理单一业务的吞吐量总是一个定值。

        但是在实际环境里面，往往一个系统都是要处理多种业务，并且这些业务之间是有逻辑关系的。举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开 帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。

        好，如果我们不设置考虑时间，起2路A的脚本，1路B的脚本进行性能测试，我们会得到什么结果呢？我们会得到这两个业务的吞吐量，并且能算出每个小时系统完成A、B业务的总数，吞吐量 × 时间 ＝ 总数。

        这时我们发现，同样时间，AB业务的处理总数却不是2:1的关系，这是为什么呢？原因是这样的，我们在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器 的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，测试结果就是最好的证据。A查看帖子由于响应时间短，因此跑 的次数更多，最后的比例可能是4:1。

        那么这样的结果有什么问题呢。总结为一句话：测试环境的业务和真实环境不符，这样测出的数据没有价值。即使测试通过，也不能证明真实环境是ok的；或者即使测试不通过，也不能说明真实环境不ok，呵呵。

        比如上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。

        说到这里，大家应该明白了，我们设置考虑时间，是为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。

% Processor Time(Processor_Total)
指处理器用来执行非闲置线程时间 的百分比。计算方法是:度量处理器用来执行空闲线程的时间，然后用100%减去该值。(每个处理器有一个空闲线程，该线程在没有其他线程可以运行时消耗周 期)。此计数器是处理器活动的主要指示器，显示在采样间隔期间所观察的繁忙时间平均百分比。应注意，对处理器是否空闲的计算是在系统时钟的内部采样间隔期 间(10ms)执行的。考虑到现在的处理器速度非常快，因此，在处理器可能会用大量时间为系统时钟采样间隔之间的线程提供服务时，% Processor Time 会低估处理器利用率。当恰好进行采样后即向计时器发出信号时，更可能对应用程序做出不准确地度量，基于工作负荷的计时器应用程序是一个这样的示例。

%Processor Time (Process _Total)
D0是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。

多处理器系统中，对任何处理器或线程，系统监视器报告的Processor\% Processor Time值不会超出100%。另一方面，进程对象(也就是Process)Processor Time%值能超出100%；如果超出就意味着该进程的线程累计使用超出了一个处理器的100%。要得到更详尽的信息，使用线程对象计数器去分析在该进程 中每个线程的Processor Time%值。调查在这部分描述的其它数据，如延迟过程调用(DPC)活动或上下文切换，可能会帮助你去解释高Processor Time%值。

“\Process(…)\% Processor Time” can go up to N*100 (where N is the number of CPUs) because it adds up the CPU usage of the requested process across all the CPUs.
l,T8G&X9D$L$M$N!D2K02.“\Process(_Total)\% Processor Time” should always be around N*100 (where N is the number CPUs) because it adds up the CPU usage of each process, including the idle process.
3.“\Processor(…)\% Processor Time” can go up to 100 because it’s the CPU usage of the requested CPU.
“\Processor(_Total)\% Processor Time” can go up to 100 because it’s the average CPU usage across all CPUs.
Processor(_Total)\% Processor Time

This counter gives the total processor utilization figure for the server as a whole. For example, on a dual processor system with one processor pegged out at 100% utilization and the other processor standing idle, a figure of about 50% would be recorded.

This server metric is useful for gauging overall how busy a server is or, put in another way, how much spare capacity there is available (by subtracting from 100%).

If per-processor information is required to be monitored by Resource Manager, then additional server metrics may be configured for monitoring:

Processor(0)\% Processor Time

Processor(1)\% Processor Time

... etc.

(See the Resource Manager Administrator’s Guide and the help within the Presentation Server Console for information on Customizing Server Metrics).

Process Processor Utilization

In addition to monitoring server metrics Resource Manager also monitors process activity; one aspect of process activity monitored is the degree to which the processor(s) is being used.

Processor usage of each process on the server is sampled at regular intervals using a standard operating system call - note that the operating system call used returns the sum of processor time used by all threads within the process. Resource Manager expresses the processor time used during the sampled interval as a percentage by dividing this time by the elapsed time since the previous sample.

On a multi-processor system it is quite possible for the percentage reported to exceed 100% in the case of a multi-threaded process. For example, on a dual-processor system, a multi-threaded process in which two threads are performing lengthy processor intensive calculations would cause a value of about 200% to be recorded.

This process-specific processor utilization is useful for gauging the state (and possibly health) of the process; if a process which normally uses little processor time is seen to be consuming a figure approaching 100%, a likely explanation is that it has encountered a bug which has caused it to enter an uncontrolled looping state.

网站最基本的东西是什么？
——内容？SEO（搜索引擎优化）？UE（用户体验）？都不对！是速度！
内容再丰富的网站，如果慢到无法访问也是毫无意义的； SEO做的再好的网站，如果搜索蜘蛛抓不到也是白搭； UE设计的再人性化的网站，如果用户连看都看不到也是空谈。
所以网页的效率绝对是最值得关注的方面。如何才能提高一个网页的效率呢？Steve Souders(Steve Souders的资料http://www.oreillynet.com/pub/au/2951)提出的提高网页效率的14条准则，而这些准则也将是我们下篇中介绍到的YSlow工具的理论基础：

• Make Fewer HTTP Requests
• Use a Content Delivery Network
• Add an Expires Header
• Gzip Components
• Put CSS at the Top
• Move Scripts to the Bottom
• Avoid CSS Expressions
• Make JavaScript and CSS External
• Reduce DNS Lookups
• Minify JavaScript
• Avoid Redirects
• Remove Duplicate Scripts
• Configure ETags
• Make Ajax Cacheable

第一条：Make Fewer HTTP Requests 尽可能的减少HTTP的Request请求数。

80%的用户响应时间都是浪费在前端。而这些时间主要又是因为下载图片、样式表、JavaScript脚本、flash等文件造成的。减少这些资源文件的Request请求数将是提高网页显示效率的重点。
这里好像有个矛盾，就是如果我减少了很多的图片，样式，脚本或者flash，那么网页岂不是光秃秃的，那多难看呢？其实这是一个误解。我们只是说尽量的减少，并没有说完全不能使用。减少这些文件的Request请求数，当然也有一些技巧和建议的：

1：用一个大图片代替多个小图片。

一个大小为40528bytes的337*191px的大图片的分析结果（点击图片可以查看完整大图片）

一个大小为13883bytes的280*90px的小图片的分析结果（点击图片可以查看完整大图片）

大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。

• 大文件和小文件下载所需时间的确是不同的，差异的绝对值不大。而且下载所需时间占总耗费时间比例很小。
• 大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。无论文件大小，这个时间的花费大致是相同的。而且所占总耗费时间的比例是极大的。
• 一个100k的大图片总耗费时间绝对大于4个25k的小图片的总耗费时间。而且主要差别就是4个小图片的Blocked时间绝对大于1个大图片的Blocked时间。

2：合并你的css文件。

图:合并与融合

3：合并你的javascript文件。

第二条：Use a Content Delivery Network 使用CDN

这个看上去好像很深奥的样子，但是只要结合中国的网络特色，这个便不难理解了。“北方服务器”、“南方服务器”、“电信服务器”、“网通服务器 ”……这些词听起来是那么熟悉和压抑。如果，一个北京的电信用户试图从广东的网通服务器上打开一个类似《壁纸合集》帖子的网页时，你就能很深刻的理解。
鉴于这个不是我们开发人员力所能及的准则，所以这里也就不多言了。

图:这个图也算有点中国特色了

第三条：Add an Expires Header 添加周期头

这个也并非开发人员来控制，而是网站服务器管理员的职责。所以，如果作为开发人员的你不了解和明白也没有关系。还是把这个准则告诉公司的网站服务器管理员。

第四条：Gzip Components 启用Gzip压缩

这个大家应该比较熟悉。Gzip的思想就是把文件先在服务器端进行压缩，然后再传输。这对于体积较大的纯文字型的文件有特效。鉴于这也并非开发人员，而是网站服务器管理员的工作范畴，这里就不详细讲解了。如果你对此感兴趣，可以资讯贵公司的网站服务器管理人员。

第五条：Put CSS at the Top 把CSS样式放在页面的上方。

无论是HTML还是XHTML还是CSS都是解释型的语言，而非编译型的。所以CSS到上方的话，那么浏览器解析结构的时候，就已经可以对页面进行 渲染。这样就不会出现，页面结构光秃秃的先出来，然后CSS渲染，页面又突然华丽起来，这样太具有“戏剧性”的页面浏览体验了。

第六条：Move Scripts to the Bottom 将脚本放在底部

原因同第五条一样。只是脚本一般是用来于用户交互的。所以如果页面还没有出来，用户连页面都不知道什么样子，那谈交互简直就是扯谈。所以，脚本和CSS正好相反，脚本应该放在页面的底部。

第七条：Avoid CSS Expressions 避免使用CSS中的Expressions

图:CSS中的Expressions其实也是一种if判断

第八条：Make JavaScript and CSS External 将javascript和css独立成外部文件

这一条好像和第一条有点矛盾。的确，如果从HTTP的request请求数来讲的话，这样做的确是降低了效率。但是之所以这么做，是因为另外一个重 要的考虑因素——缓存。因为外部的引用文件会被浏览器缓存，所以如果javascript和css体积较大的时候，我们将它们独立成外部文件。这样当用户 只要浏览一次以后，这些体积较大的js和css文件就能被缓存起来，从而极高地提高用户再次访问时的效率。

第九条：Reduce DNS Lookups  减少DNS查询

DNS域名解析系统。大家都知道我们之所以能记住那么多的网址，是因为我们记住的都是单词，而非http://202.153.125.45这样的 东西，而帮我们把那些单词和202.153.125.45这样的ip地址联系起来的就是DNS。那这一条对我们到底有什么真正意义上的指导意义呢？其实有 两条：
1：如果不是必须，请不要把网站放到两台服务器上。
2：网页中的图片、css文件、js文件、flash文件等等，不要太多的分散在不同的网络空间中。这就是为什么那种只发一个网站中的壁纸图片的帖子，要比壁纸图片来源于不同网站的帖子显示要快得多的原因。

第十条：Minify JavaScript and CSS  减少JavaScript和CSS文件的体积

这点很好理解。在你的最终发布版本中把没有必要的空行、空格和注释全部去掉。显然手工去处理效率太低，好在网上到处都是用于压缩这些东西的工具。压缩JavaScript代码体积的工具随处可见，我便不再列举了，这里我只提供一个用于压缩css代码体积的在线工具网站——http://www.cssdrive.com/index.php/main/csscompressor
它提供了多种压缩方式，可以适应多种要求。

第十一条：Avoid Redirects 避免跳转

我只从网页开发人员的角度来解读此条。那么我们可以解读到什么东西呢？2点——
1：“此域名已过期，5秒钟以后，页面将跳转到http://www.xxxxxx.com/index.html页面”，这句话看起来的确很熟悉。但是，我就奇怪了，为什么不直接链接到那个页面呢？
2：一些链接地址请更明确的写出来。例如:将http://justinyoung.cnblogs.com/ 写成http://justinyoung.cnblogs.com （注意最后面一个“/”符号）。的确，这两个网址都能访问到我的博客，但是，事实上，它们是有区别的。http://justinyoung.cnblogs.com 的结果是个301响应，它会被重新指向http://justinyoung.cnblogs.com/ 。但是显然，中间多浪费了一些时间。

第十二条 Remove Duplicate Scripts 移除重复的脚本

图:对重复说“不！”

这个准则的道理很浅显，但是真正在工作中，很多人却因为“项目时间紧”、“太累了”、“初期没有规划好”……这样的理由搪塞过去了。你，的确可以找很多的理由不去处理这些多余重复的脚本代码，如果你的网站不需要更高的效率和后期维护的话。
也正是这点，我提醒大家一些，一些javascript框架、javascript包一定要慎用。至少要问一下：用了这个js kit 到底给我们多少方便，提高了多少工作效率。然后，再与它因为多余的、重复的代码带来的负面效果比较一下。

第十三条：Configure ETags 配置你的实体标签

首先来讲讲什么是Etag吧。Etag（Entity tags ）实体标签。这个tag和你在网上经常看到的标签云那种tag有点区别。这个Etag不是给用户用的，而是给浏览器缓存用的。Etag是服务器告诉浏览器 缓存，缓存中的内容是否已经发生变化的一种机制。通过Etag，浏览器就可以知道现在的缓存中的内容是不是最新的，需不需要重新从服务器上重新下载。这和 “Last-Modified”的概念有点类似。很遗憾作为网页开发人员对此无能为力。他依然是网站服务器人员的工作范畴。如果，你对此有兴趣，可以咨询 贵公司的网站服务器管理员。

第十四条：Make Ajax Cacheable 上面的准则也适用Ajax

图:Ajax的使用要恰当

现在的Ajax好像有点被神话了，好像网页只要Ajax了，那么就不存在效率问题了。其实这是一种误解。拙劣的使用Ajax不会让你的网页效率更高，反而会降低你的网页效率。Ajax的确是个好东西，但是请不要过分的神话它。使用Ajax的时候也要考虑上面的那些准则。

后记：

当然，上面的这些也只是供你参考的理论上的准则。具体的情况还是要具体的去对待。理论和准则只是用来指导现实工作的，却是万万不可死记硬套。

网站最重要的东西是什么？
——内容？SEO（搜索引擎优化）？UE（用户体验）？都不对！是速度！
内容再丰富的网站，如果慢到无法访问也是毫无意义的； SEO做的再好的网站，如果搜索蜘蛛抓不到也是白搭(页面效率和搜索蜘蛛之间的关系，需要进一步的确认，此为和上篇保持统一)； UE设计的再人性化的网站，如果用户连看都看不到也是空谈。

所以网页的效率绝对是最值得关注的方面。虽然我们在 《如何提高网页的效率（上篇）——提高网页效率的14条准则》提 到了如何提高网页效率的14条准则，但是如何知道我们现在的网页的效率到底如何？到底处于怎样一个级别？又有哪些方面做的不够好，需要改进呢？也许，你会 说，问一下用户不就知道了吗？但是相比感性比例占据太大的用户感受而言，理性的工具和数据更具有说服力。本篇就将向你介绍一款评测网页效率的工具—— YSlow（why slow，这个名字起的太好了）。

yslow

YSlow是由Yahoo开发者团队发布的一款基于Firebug的插件。而Firebug 又是一款基于FireFox的插件。所以说YSlow是一款基于FireFox插件的插件。虽然有点绕，但是最终说明的问题是：

• 很遗憾，微软的IE系列浏览器不能使用YSlow。
• YSlow只能使用在FireFox浏览器上。
• 如果要想使用YSlow，那么你必须先安装FireFox。
• 如果要想使用YSlow，那么你就要安装FireFox上的Firebug插件。

这看上去好像有点令人沮丧，但是事实上它并不像想象中的那么麻烦，只要按照下面的步骤你将能很快的使用YSlow：

1. 到http://www.mozilla.net.cn/firefox/ 下载最新版的FireFox，并安装它。当然如果你已经安装了FireFox可以跳过此步。
2. 到https://addons.mozilla.org/en-US/firefox/addon/1843/ 下载最新版的Firebug，并安装它。当然如果你已经安装了Firebug可以跳过此步。
3. 到https://addons.mozilla.org/en-US/firefox/addon/5369/ 下载最新版的YSlow，并安装它。当然如果你已经安装了YSlow可以跳过此步。

图2：在菜单中先打开Firebug插件

图3：在菜单中先打开Firebug插件(点击小图查看完整大图)

点击【Performace】菜单

YSlow便开始分析此页的效率，并从13个最影响网页效率的方面给出评估（如图4）。

图4：YSlow给出的本页面效率评估

可以看出来，YSlow评估的依据就是我们在 《如何提高网页的效率（上篇）——提高网页效率的14条准则》中提到的前面13条。前面蓝色的字母表示这一条准则的得分。A最高。点击右面的三角形可以得到更多的信息和建议，有些信息里面还有“放大镜” 图标，点击也将展示更为详细的信息和建议。（如图5所示）

图5：YSlow可以给出每条准则的详细评估信息和建议

点击【Stats】菜单

这个视图会告诉你页面的总体统计信息。包括页面大小、css样式表大小、脚本文件大小、总体图片大小、flash文件大小和css中用到的图片文件大小。还会告诉你，哪些东西被缓存了，缓存了多少等等。

图6：【Stats】视图信息

点击【Components】菜单

这个视图是一个页面所有部件的信息列表。从中我们可以得知每个部件的各种详细信息。如：类型、URL、Expires数据、状态、大小、读取时间、ETag信息等等。通过对这个列表的分析，我们就可以知道到底是什么东西最耗费我们的资源，从而有针对性的进行优化。

图7：【Components】视图信息，点击“放大镜”图标我们可以知道更详细的信息（点击小图查看完整大图）

点击【Tools】菜单

【Tools】菜单包含4个子菜单，就是4个实用工具。【JSLine】工具会生成JSLine报表，报表是对本网页中JS脚本的分析报告，包含错 误和建议。【ALL JS】工具，将生成本页面所有脚本代码便于阅读和打印的报表页面。【ALL CSS】工具，将生成本页面 所有CSS样式表代码便于阅读和打印的报表页面。【Printable View】将【Performance】和【Stats】视图中的信息生成一份更适合阅读和打印的报表页面。

图8：【Tools】菜单，包含了4个子菜单

点击【Help】菜单

【Help】主要是些常用的帮助途径的入口。从这里你可以很方面的访问YSlow的官方网络和博客。如果你还对YSlow的使用有什么疑惑的话，那么在这里你将获得满意的解答。

图8：【Help】菜单是些常用的帮助入口

后记

“工欲善其事，必先厉其器！”好的工具的确能很大的提高我们的工作效率。但是“阿斗”就算手里拿着“方天画戟”，估计也没有几个人怕他。好的工具是一方面，但是更重要的还是提高我们自身的知识水平。就如同这款YSlow，如果没有 《如何提高网页的效率（上篇）——提高网页效率的14条准则》中的理论知识，工具提供的信息我们看到的可能只是表面，就算看懂了数据，我们也很难知道对应的手段和措施。壮汉拿厉斧，这样伐木才能又快又轻松。

参数：
　1、StepName：步骤名称，在Tree视图中出现。

2、Attributes and Specifications list：

支持的属性有：

Frame：在多Frame的情况下，定义要查找Frame的范围。

Expect：定义在什么情况下函数检查成功：找到了指定的搜索标准或者没有找到。例如说，可以检查指定的错误信息是否出现在web页面中。合法的值有2个：found和notfound。默认值是“found”。

Matchcase：指定搜索是否区分大小写。

Repeat：指定当第一次发现要查找的字符串时，搜索是否继续。当一个web页面中包含多个被查找的字符串时，此参数是非常有用的。合法的值有2个：yes，no。默认值是“yes”。

Report：指定在什么情况下，VuGen在执行日志中显示此函数的检查结果。合法的值有：success，failure，always。默认值是“always”。

Onfailure：此参数决定在函数检查失败后，Vuser是否中断。参数值是abort。如果指定了Onfailure=abort,当函数检查失败时，不论在运行时设置中的error-handling是什么，脚本都会中断。

如果没有指定Onfailure=abort,那么运行时设置中error-handling将会起作用。

支持的特性有：RightOf, LeftOf （不支持7.x及更高版本）。

RightOf：要查找的字符串右边的内容。

LeftOf：要查找的字符串左边的内容。

3、Searchstring：需要查找的字符串，格式为“What=stringxyz”。此搜索不区分大小写。

4、LAST：属性列表结束符。

返回值
　整型。 成功时返回LR_PASS(0)，失败时返回LR_FAIL (1)。

说明
　此函数的作用是在HTML页面中查找指定的字符串。

此函数只能在基于HTML录制的脚本中使用。当指定的HTML请求全部完成以后，开始执行搜索过程，比web_reg_find要慢。

web_find函数在C语言的脚本中已经被web_reg_find所替代，web_reg_find运行速度比较快，而且在HTML-based和URL-based的录制方式中都可以使用。 在C语言脚本中，web_find是向后兼容的。Java和Visual Basic脚本中不再支持它。

运行在HTTP模式下的WAP用户都和运行在WSP回放模式下的WAP用户都不支持此函数。

web_global_verification

　语法：
　int web_global_verification (<List of Attributes>, LAST )；

参数：
　List of Attributes：

1、Text：此属性是一个非空的，以NULL结尾的字符串，表示要查找的内容。语法是”Text=string”。还可以使用text flags自定义字符串。

2、TextPfx：没有指定Text的情况下使用此属性。要查找的字符串的前缀。语法是” TextPfx =string”。还可以使用text flags自定义字符串。

3、TextSfx：没有指定Text的情况下使用此属性。要查找的字符串的后缀。语法是” TextSfx =string”。还可以使用text flags自定义字符串。

4、Search：可选项，在哪里查找字符串。可选的值是：Headers，Body，NORESOURCE或All。默认值是NORESOURCE。语法是“Search=value”。

5、Fail：当字符串找不到时的处理选项：Found （默认值）或NotFound。Found表示当找到对应的字符串时发生了错误（例如“Error”）。NotFound表示当找不到字符串时发生了错误。语法是“Fail=value“。

6、ID：在日志文件中标识当前函数。

LAST：属性列表结束符。

注：text flags：/IC表示忽略大小写；/BIN表示指定的是二进制数据。

返回值
　整型。 成功时返回LR_PASS(0)，失败时返回LR_FAIL (1)。

说明
　web_global_verification属于注册函数，注册一个在web页面中搜索文本字符串的请求，与web_reg_find只在下一个 Action函数中执行搜索不同的是，它是在之后所有的Action类函数中执行搜索的。可以搜索页面的body，headers，html代码或者是整个页面。

在检测一些应用程序级别（不通过http状态码来表现）的错误时，web_global_verification是非常有用的。如果要定位通过HTTP状态码表现的错误时，使用web_get_int_property。

查找范围：all：这个HTML页面；Headers：页面的头；body：页面的体，包含所有的资源但不包含头；NORESOURCE（默认选项）：仅仅包含页面的体，把包括头和资源。

如果不知道要查找的精确的文本，或者要查找的多个文本不是完全相同的,可以使用前缀和后缀来表示。这时需要用到TextPfx和TextSfx属性。这2个属性必须同时指定，一旦指定了其中一个，就不能指定Text属性了。

注意：web_global_verification在WAP协议下不能运行。

web_image_check

　语法：
　int web_image_check(const char *CheckName, <List of Attributes>, <"Alt=alt"|| "Src=src">, LAST );

参数：
　1、CheckName：名称，在Tree视图中出现。

2、List of Attributes：

支持的属性有：Frame（在多Frame的情况下，定义要查找Frame的范围）。

支持的选项有：expect, matchcase, repeat, report, onfailure。

Tip：选项跟属性的区别，大部分选项都只允许设置预定义的值，其他的值都是无效的。

3、Alt：检查图象的ALT标记。不允许空值。

4、Src：检查图象的SRC标记。不允许空值。

5、LAST：参数列表结束的指示符。

返回值
　整型。

说明
　web_image_check检查指定的图象是否在HTML页面中出现。

Alt或者Src两者必须有一个在参数列表中出现。如果两项都通过，那么检查成功。

此函数仅仅支持基于HTML的脚本。

　web_reg_add_cookie

　语法：
　int web_reg_add_cookie(const char * cookie, const char * searchstring, LAST );

参数：
　1、Cookie：定义需要增加或修改的Cookie。

Cookie的参数格式为：<name>=VALUE; (required)；domain=DOMAIN_NAME;(required)；expires=DATE；path=PATH；(default path is "/")；secure。

此参数中的cookie元素和HTTP响应头中的Set-Cookie是相同的。例如“Session=1234；domain=sanditon.com”，在这里，“Session”是cookie的名称。

2、Searchstring：要查找的文本字符串。字符串不能为空，以null结尾。格式为“Text=string”。

3、LAST：属性列表的结束符。

返回值
　整型。 成功时返回LR_PASS(0)，失败时返回LR_FAIL (1)。

说明
　web_reg_add_cookie是注册类型的函数。它首先注册一个搜索文本字符串的请求。检查动作在后续的Action函数之后进行。如果字符串被找到，就添加到cookie中。

需要注意，尽管web_reg_add_cookie在功能上跟HTTP Set_Cookie头相似，它们还是有个明显的区别。 根据HTTP标准，domain属性在Set-Cookie头中是可选的。如果没有指定，默认的domain的值是产生cookie的服务器的host name。当使用web_reg_add_cookie函数时，服务器的hostname对于压力测试的机器来说是不可用的，所以domain属性是必选项。

此函数在HTML-based 和URL-based的脚本中都可以使用。（参照录制选项的录制标签页）。此函数是在服务器内容到达客户端之前注册搜索请求的，所以当所请求的内容一到就会执行搜索操作，脚本会比较高性。

web_reg_add_cookie是用户手动添加的，无法录制。

web_reg_find

　语法：
　int web_reg_find (const char *attribute_list, LAST);

参数：
　1、attribute_list：

通过Name=Value对来传递参数。例如“Text=string”。Text，TextPfx，TextSfx三个必须有一个出现。其他的属性是可选的。

a) Text：要搜索的字符串，字符串必须非空，以NULL结尾。可以使用text flags自定义搜索字符串。

b) TextPfx：要搜索的字符串的直接前缀。

c) TextSfx：要搜索的字符串的直接后缀。

d) Search：搜索的范围。可选的值是：Headers 、Body（在请求体中搜索）、Noresource (仅仅在HTML请求体中搜索，不包括头和资源)、ALL （在请求体、头和资源中搜索），默认值是“BODY”。

e) SaveCount：匹配的个数。

f) Fail：设置函数检查在什么状态下失败。

g) ID：日志文件中标识此函数的一个字符串。

h) RelFrameId：相关联的FrameId。注意：此参数在GUI级别的脚本中不受支持。

2、LAST：属性列表结束的标记符。

返回值
　整型。 成功时返回LR_PASS(0)，失败时返回LR_FAIL (1)。

说明
　web_reg_find属于注册函数，注册一个在web页面中搜索文本字符串的请求，在接下来的Action（象web_url）类函数中执行搜索。

通过查找期望的字符是否存在来验证是否返回了期望的页面。例如，通过查找“Welcome”来检查主页是否完全打开了。也可以查找“Error”检查浏览器是否发生错误。还可以使用此函数注册一个请求来统计特定字符串出现的次数。

如果检查失败，在接下来的Action类的函数中会报告错误。此函数仅仅注册请求，并不执行。函数的返回值只表明注册是否成功，并不表示检查的结果。

此函数不仅能够查找text，还能查找到围绕着text的strings。不要同时指定text和前缀后缀。

Fail，处理选项，可以是“Found或“NotFound”。默认是“NotFound”。

“Fail=Found” 指示当对应的字符找到时，函数检查失败。例如，查找单词“Error”，如果找到了，说名web请求没有成功，你想把函数检查设置为失败。

“Fail=NotFound”指示当对应的字符找不到时，函数检查失败。如果查找的是web请求成功时出现的字符串时，需要使用NotFound。

SaveCount参数指示保存到参数中的匹配的字符串的个数。使用这个属性，需要指定“SaveCount=param”。检查操作被执行后，param 的值是null结尾的数字类型的值。

如果指定了SaveCount，且没有使用Fail参数，检查不会失败，无论需要查找的字符串是否找到。通过检查SaveCount的值确定字符串是否被找到。 如果param是0，说明没有找到对应的字符串。

如果同时指定了SaveCount和Fail，指定的错误处理选项和SaveCount协同工作。 handling option specified works together with the SaveCount. Thus,如果指定了SaveCount且指定了“Fail=NotFound” ，但是字符串被找到，SaveCount被赋值为字符串出现的次数，检查成功。如果字符串找不到，SaveCount被赋值为0，检查失败（注意，参数的0值只在运行时设置中Continue on error 选中时才有意义）。

此函数在HTML-based和URL-based的脚本中都可以使用。此函数是在所请求内容到达之前注册搜索请求的，所以当所请求内容一到达后就会执行搜索，产生的脚本比较高效。

　　URL是一种低级别的录制模式，这种录制选项不允许浏览器去确定哪些页面资源（比如图片或者Flash内容）是需要下载的。每项资源在录制回话的过程中都被录制到脚本中。这种级别录制模式同时也会录制其他任何隐藏的对象，比如session ID（也就是会话ID）信息，包括发给服务端和从服务端收到的session ID信息。

脚本方面的不同，HTML级别录制模式将生成的是web_submit_form 语句来提交终端用户可以看见或者修改的信息。当基于HTML模式在提交窗体时遇到错误，你可以选择URL模式去录制任何从服务端发送过来的请求和资源。而 URL基本录制模式将生成的是web_submit_data语句，这些语句记录的是所有通过浏览器实际发送给服务端的信息。值得注意的是URL录制模式 会录制那些HTML模式没有能录制到隐藏信息。通常情况下，隐藏信息里面会包含session ID信息。

        每当一个客户端网络浏览器连接到服务器，服务器就会获得一个当时的时标，再计算出校验和返回至客户端。这两个域是用来确认一次即时的会话。换句话说，一组时标 + 校验和就是会话 ID。以下就是这种交互的图解：

        问题在哪里呢？让我们再回放一次录制的脚本。 当执行已录制的脚本时，出现了问题。网络服务器用当前时间检验客户端发来的时标。如果客户端的日期是过期的或错误的，服务器就会返回一个错误的信息：参数“校验和”未找到或显示为无效值。 此次交互的图解：

     客户端不能再次使用旧的（即硬编码）的值作为时标和校验和。而必须使用新的日期。所以，LR 脚本应该运行服务器返回的动态数据，而非硬代码。使用关联就能做到这一点：

    关联的定义：关联就是捕获服务器发送给客户端的动态值。 实现关联的方法：

1、自动

2、手动

自动关联会在后文中讲到。但是至今为止，我敢说自动关联并不是最好的解决方法。因为有些时候自动关联会失效，或者错误关联。 一个真正 LoadRunner 工程师会选择使用手动关联。所以说这是“必备”的学问！好吧，让我们来开始探究手动关联。 手动关联的使用法则如下： 找到一个需要捕获的动态值。

1) 找到服务器包含该动态值的响应。

2) 捕获动态值。使用特定参数取代该动态值。

3) 将脚本中所有出现的动态值都替换为参数。

4) 检查变化。

录制脚本

获得时标 & 校验和

时标 = TSnew，校验和 = CSnew

网络 服务器

开始新一轮会话：TSnew & CSnew

OK 会话开始

客户端

解析服务器端响应，并捕获 TSnew & CSnew

现在，我要开始就每一步进行解释：

1) 找到一个需要捕获的动态值

     我建议先录制并保存两段相同的虚拟脚本。再打开主菜单项中的“Tools / Compare with Scripts...”，用 WDiff 比较这两段录制的脚本：

    黄色标出的地方即不同处。意味着每次脚本运行至该处，代码（参数值）就会发生变化。所以，多数情况下，这些值是需要关联的。

        提示：有时通过比较可能找不到动态值。那您需要再次确认是否已录制了该段脚本：

       "Name=SessionID", "Value=A38E9002A41", ENDITEM, "Name=CurrentMonthID", "Value=4", ENDITEM,

       显而易见，那个会话 ID 应该被关联。那 CurrentMonthID 呢？第二次录制的脚本也包含“Value=4”。也有可能您的脚本在四月份是工作正常的（4th month 即四月），而到 5月1日开始就会报错！所以亲爱的读者们要特别小心！ 提示：通篇察看您录制的脚本源码。时标、检验和、会话 ID 以及那些不同的 ID 都可能需要被关联。 提示：仔细检查回放（执行）日志，错误可能就在里面。往往脚本错误最普遍的原因就是缺少关联。

      提示：在可用的运行视图（菜单“Tools / General Options../ Display”）中执行脚本。当出现错误（“Page not found”，“Session timeout”等）就是在暗示可能存在关联。

     提示：在可用的运行视图（菜单“Tools / General Options../ Display”）中执行脚本。当出现错误（“Page not found”，“Session timeout”等）就是在暗示可能存在关联。

2) 找到服务器包含该动态值的响应

   在执行脚本前，请设置扩展日志为可用（“Vuser / Run-Time Settings...”）：

  然后执行脚本。

   打开回放（执行）日志并找到服务器的响应（包含时标、检验和的动态值）：

  好！我们已经找到服务器发送动态值的地方了。而且我们也找到了返回该值的步骤——第 13 行 Action.c (13)。双击该行，连同时标以及检验和的值，打开第 13 行代码：

    web_submit_data("generateChecksum.jsp",

  "Action=http://eprumossd0010:8400/RMS/jsp/generateChecksum.jsp",

  "Method=POST", "RecContentType=text/html",

    这就表示服务器响应页面，generateChecksum.jsp 内包含应被关联的动态值。

3) 捕获动态值

  我将演示两种方法来捕获动态值：

    A. 从树视图中自动捕获

    B. 从脚本视图中手动捕获

这两种方法很相似，也使用相同的函数 — web_reg_save_param。 开始：

    A.从树视图中自动捕获

打开树视图（菜单“View / Tree view”）：

然后：

? 点击“View recording snapshot only”按钮 (2)；

? 从树视图中选择 generateChecksum.jsp 页面 (3)；

? 选择“Body”查看服务器响应的整体内容 (4)；

? 从中您将看到已录制的时标以及检验和的值 (5)。

现在让我们选择第一个动态值（检验和），右击并选择“Create parameter”，以创建参数：

 您可以开始为动态值创建参数。 如果您需要替换所有脚本中出现的动态值，请按“Yes”按钮。如果不要替换所有的，请按“No”按钮。 提示：我不建议替换所有的动态值，因为很有可能导致错误。相反，通过“Search and Replace”对话框逐个替换的效果更好。 OK，我按了“No”按钮。

返回脚本视图（“View / Script View”）查看变化。可以发现generateChecksum.jsp 页面前会出现新行：

    //[WCSPARAM WCSParam_Text1 40 715E19300D670ED77773BBF066DAAAE2866484B8] Parameter {WCSParam_Text1} created by Correlation Studio web_reg_save_param("WCSParam_Text1", "LB=window.parent.setChecksum(\"", "RB=\"", "Ord=1", "RelFrameId=1", "Search=Body", "IgnoreRedirections=Yes", LAST);

 web_reg_save_param 函数将从下一个服务器响应中查找并储存一个字符串。换句话说，它会捕获一个动态值。 在这个例子里，web_reg_save_param 函数将会把捕获的值保存在参数 WCSParam_Text1 中，并会发现左边界（window.parent.setChecksum("）和右边界（"）。从左右边界之内找到的字符串将保存到参数 WCSParam_Text1 中。Ord 属性注明了被捕获值的顺序位置。本例中（Ord=1），即我们捕获的值处于左边界和左边第一个值之间。 容易想到的是，“Search=Body”意思是在服务器响应的实体内搜索。我建议通过 Help 进一步学习 web_reg_save_param 函数。 注意：捕获时标参数的方法是类似的。其生成的代码如下：

    // [WCSPARAM WCSParam_Text2 13 1192177661211] Parameter {WCSParam_Text2} created by Correlation Studio web_reg_save_param("WCSParam_Text2", "LB=, ", "RB=)", "Ord=1", "RelFrameId=1", "Search=Body", "IgnoreRedirections=Yes", LAST);

    ? 从脚本视图中手动捕获。

    事实上，这个方法与手动编辑 web_reg_save_param 函数相结合。它要求对这个函数及其参数非常熟悉。web_reg_save_param 函数有许多属性，在此我不再重复说明，请大家参考 Help。 提示：我建议重命名默认参数（WCSParam_Text1， 2， 3， etc），方便记忆。例如在此例中，我喜欢将参数 prmCheckSum 和 prmTimeStamp 重命名为 WCSParam_Text1 和 WCSParam_Text2。

4) 将脚本中所有出现的动态值都替换为参数

    将脚本中所有出现的动态值都替换为参数。 打开“Search and Replace”对话框（“Edit/Replace...”），并逐个将硬编码替换为参数。 其重要性何在？

    试想，您有以下源码：

    web_submit_data("somepage", ...

    "Name=OrderNumber", "Value=125", ENDITEM,

    "Name=UserID", "Value=125",

     如果您为 UserID 创建参数，并替换其所有的值（“125”），那么其就会生成代码：

    web_submit_data("somepage", ...

    "Name=OrderNumber", "Value={WCSParam_Text1}", ENDITEM,

    "Name=UserID", "Value={WCSParam_Text1}",

    就会产生这样的错误：当 UserID 变化，OrderNumber 可能就会变为固定值 125。 现在我能确保您已经成功替换所有需要替换的硬编码。让我们开始执行最后一步：

    5) 检查变化

    经过以上操作，我们的代码将变为：  

“{WCSParam_Text1}”表示“获取 WCSParam_Text1 参数的值”。

    所以，现在的规则是：

? 当服务器返回不同的检验和、时标值时

? web_submit_data 会捕获并将其置于变量 WCSParam_Text1 和 WCSParam_Text2 中

? 然后，我们使用 {WCSParam_Text1} 和 {WCSParam_Text2} 获得变量的当前值，并将其用到脚本中去。

运行修改后的脚本，并观察捕获的服务器响应的结果：

   图10

您可以看到动态值被保存至变量。很好！我们刚完成了脚本关联！

提示：使用以下语句获得并调试变量捕获的值：

  lr_output_message("Value of WCSParam_Text1:%s", lr_eval_string("{WCSParam_Text1}"));

   lr_output_message("Value of WCSParam_Text2:%s", lr_eval_string("{WCSParam_Text2}"));

再次执行，结果是：

 结束语： 我以尽可能简单易懂的语言解释了 LoadRunner 中的关联功能。亲爱的读者，非常欢迎您也能分享自己的意见和想法。 参考文献：

? Using parameters in Loadrunner VuGen script

? LoadRunner Correlation - How to capture an array of dynamic data with web_reg_save_param function

? What are LoadRunner parameter and parameterization?

? Boundaries for web_reg_save_param LoadRunner function

? How to perform basic operations on LoadRunner parameters?

关联是为了获取每次运行脚本的唯一数据值和通过嵌套查询生成的数据。关联提供了避免产生重复数据错误的数值以及优化代码（以避免嵌套查询）。关联是正常回放含有动态数据如Session IDs，Database Primary Keys 和差不多所有的HTTP安全机制脚本的根本。关联的目的就是吧脚本中某些hard-coded数据转变成从服务器传过来的动态的，每次执行都不一样的数据。

2.参数（化）和关联的区别

参数（化）相当于代码编写中的变量。是某个变量向服务器输入不同的值，用来模拟真 实的用户。运行脚本时，不同的数据集被发送给服务器。只能对某个具体的变量值进行参数化。参数化的对象在回放过程中即时没有被参数化也不会报错，只是像服 务器输入了相同的值。但是关联的对象在回放过程中如果没有做关联，回放过程中就会报错。关联是对系统的动态数据（每次运行脚本都会变化的值，是从服务器传过来的）进行。简单的说，每一次执行时都会变动的值，就有可能需要做关联。

3.动态关联和手工关联的区别

动态关联是我们为关联设置规则，可以是具体的应用程序服务，这里的数据由所创建的 规则替代。在手工关联中，我们想要关联的数值被扫描并且编写关联函数完成关联。VuGen内建自动关联引擎（auto-correlation engine）,可以自动找出需要关联的值，并可以利用关联函数自动建立关联。

手动关联需要自行查找关联的对象，然后自行插入关联函数。

4.如何发现哪里需要关联？

两种方式：首先回放扫描不同的值然后看哪些值需要关联。其次，我们可以录制2个脚 本然后作比较。我们可以查看不同的文件决定需要关联的数据。在我实践的某个项目中，为每个用户提供一个唯一的ID，一个不确定的数字，是自动生成的，有序 且值唯一。我需要关联这个ID值以防止在运行脚本是出现错误。我用的是扫描的方式关联。

5.在哪里设置自动关联选项？

网页自动关联可以在recording options -->correlation tab栏设置。这里可以为全部脚本设置关联并选择是在线问题信息还是离线actions，我们也可为这些关联定义规则。数据库的自动关联可以用输出窗口、关联扫描、找关联查询项并选择要关联的查询值。如果知道需要关联的具体值，只需要为这些值创建关联并指定这些值是如何创建的。

7.HTML页面中的动态数据可能存在于：

        每次获取相关网页都变化的URL

        在form提交过程中录制的字段（有时是隐藏的）

        JavaScritpt cookies

当录制脚本时，VuGen会拦截客户端（浏览器）与服务器端（网站服务器）之间的会话，并且记录下来，产生脚本。在VuGen的Recording Log中，可以找到浏览器与服务器之间所有的对话，包含通信内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了客户端要对服务器端所说的话，而Recording Log则是完整记录二者的对话。

当执行脚本时，可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初浏览器确实说过的话，再对网站服务器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。

所以VuGen记录在脚本中的要跟服务器所说的话，完全与当初录制脚本时所说的一样，是写死的（hard-coded）。这样的做法在遇到有些比较聪明的服务器时，还是会失效。这时就需要通过关联来让VuGen再次成功地骗过服务器。

3.3.1  关联的意义

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

一般情况下，比较聪明的服务器在每个浏览器第一次跟它要数据时， 都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器，一般称这个辨识码为Session ID。对于每个新的请求，服务器都会产生新的Session ID给浏览器。这也就是执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器发现这个Session ID是失效的或者它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。

下面的例子说明了这样的情形：

当录制脚本时，浏览器发出对网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再发出对网页B的请求时，这时就要用到ID=456的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。

在执行脚本时会发生什么状况呢？浏览器再发出对网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，因此整个脚本的执行就会失败。

要对付这种服务器，必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代脚本中有用到Session ID的部分，这样就可以成功骗过服务器，正确地完成整个交易了。

1．什么地方需要关联

凡是脚本每次执行时都必须获得唯一标识的地方都需要关联。假如脚 本需要关联，如果不做关联是不会执行通过的，也就是说会有错误消息发生。不过很遗憾，并没有任何特定的错误消息是和关联有关系的。会出现什么错误消息，与 系统实际的错误处理机制有关。错误消息有可能会提醒用户要重新登录，但是也有可能直接就显示HTTP 404的错误消息。

2．如何做关联

关联会用到下列的函数：

Ÿ    web_reg_save_param；

Ÿ   web_create_html_param；

Ÿ   web_create_html_param_ex；

其中，web_reg_save_param的语法为：

web_reg_save_param ( "Parameter Name" , < list of Attributes >, LAST );

web_create_html_param和web_create_html_param_ex这两个函数主要是保留以兼容以前旧版本。建议使用web_reg_save_param函数。

那么，如何找出要关联数据呢？简单地说，每一次执行时都会变动的值，就有可能需要做关联。VuGen提供两种方式帮助用户找出需要做关联的值：自动关联和手动关联。

3.3.2  自动关联方法

VuGen内建自动关联引擎（Auto-correlation Engine），提供Rules Correlation和Correlation Studio两种机制，可以自动找出需要关联的值，并且自动使用关联函数建立关联。

1．“Rules Correlation”：在录制过程中VuGen会根据使用者事先制订的规则，实时自动找出要关联的值。规则的来源有内建（Built-in Correlation）和使用者自定（User-defined Rules Correlation）关联规则两种。

Ÿ   内建（Built-in Correlation）：VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、 InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建了 一些关联规则。这些应用系统可能会有一种以上的关联规则。

可以在“Recording Options”>“Internet Protocol”>“Correlation”中启用关联规则，启用关联后，当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。也可以在“Recording Options”>“Internet Protocol”>“Correlation”检视每个关联规则的定义。

Ÿ   除了内建的关联规则之外，使用者也可以自定关联规则。可以在“Recording Options”>“Internet Protocol”>“Correlation”建立新的关联规则。

请依照以下步骤使用“Rule Correlation”：

单击VuGen的“Tools”>“Recording Options”，开启“Recording Options”对话窗口，选取“Internet Protocol”>“Correlation”，勾选“Enable correlation during recording”，以启用自动关联。

假如录制的应用系统属于内建关联规则的系统，如 AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、 PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。或者也可针对录制的应用系统加入新的关联规则，此即为使用 者自定的关联规则。

自动关联时VuGen会侦测到符合关联规则的数据，以下为处理方式：

首先会跳出一个“Correlation warning”消息对话窗口，选择“Issue a pop-up message and let me decide online”：询问用户是否要建立关联，每遇到一次询问一次，以了解每个关联数据的内容和位置。如果每次询问很麻烦，可以选择“Perform correlation in script”（直接自动建立关联）。

2．“Correlation Studio”：有别于“Rules Correlation”，“Correlation Studio”是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次时“Correlation Studio”才会起作用。“Correlation Studio”会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

当录制的应用系统不属于VuGen预设支持的应用系统时，“Rule Correlation”可能无法发挥作用，这时可以利用“Correlation Studio”来进行关联。

使用“Correlation Studio”的步骤如下：

（1）录制脚本并执行。

（2）执行完毕后，VuGen会跳出“Scan Action for Correlation”窗口，询问用户是否要扫描脚本并建立关联，单击“Yes”按钮，扫描脚本。

（3）扫描完后，可以在脚本下方的“Correlation Results”中看到扫描的结果。

（4）检查一下扫描的结果，选择要做关联的数据，然后单击“Correlate”按钮，逐次关联，或是单击“Correlate All”让VuGen一次就对所有的数据建立关联。

由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议用户直接用“Correlate All”。

重复步骤（1）~（4），直到所有需要做关联的数据都找出来为止。

有时关联的地方有多处，前面的关联如果没有执行通过，执行将停止验证脚本的正确性，后面需要做关联的部分无法被扫描出来。

3.3.3  手动关联方法

在对脚本进行关联的时候，有的脚本利用上面介绍的方法自动关联就可以了，但是也有可能某些需要做关联的动态数据，连“Correlation Studio”都无法侦测出来，这时就需要进行手动关联。

虽然手动关联比自动关联方法麻烦一些，操作复杂，对于没有代码编程经验的测试初学者来说，甚至有时连需要关联的位置都无法找到，但是经过多次实践后，会发现很多关联的方法与技巧。毕竟手动关联出来的脚本拥有更大的灵活性，可以随意改动来满足用户不同的需求。

手动关联的执行过程大致如下：

Ÿ   使用相同的业务流程与数据，录制两份脚本。

Ÿ   使用WinDiff工具协助找出需要关联的数据。

Ÿ   使用web_reg_save_param函数手动建立关联。

Ÿ   将脚本中有用到关联的数据，以参数取代。

具体的执行过程如下：

1．使用相同的业务流程与数据，录制两份脚本。

先录制一份脚本并存档，再依照相同的操作步骤与数据录制第二份脚本并保存。

所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。在录制第二份脚本时有时候无法使用相同的输入数据，但也要记住第一份脚本所使用的输入数据，到时对两个脚本进行比较时才能判断出这是所要输入的数据，还是变动的数据。

2．使用WinDiff工具协助找出需要关联的数据。

（1）在第二份脚本中，单击VuGen的“Tools”>“Compare with Vuser…”，并选择第一份脚本。

（2）接着 WinDiff会开启，同时显示两份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字（假 如没看到红色字体，请单击“Options”>“View”>“Show Inline Differences”）。

（3）逐一检视两份脚本中差异的部分，每一处差异都可能是需要做关联的地方。选取差异的脚本，然后复制。在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。

请忽略lr_thik_time的差异部分，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间的。

（4）接着要在 Recording Log（单一协议）或是Generation Log（多重协议）中找这个值。将鼠标光标放到Recording Log的第一行开头，按下“Ctrl+F”组合键，开启“Find”窗口，贴上刚刚复制的脚本，找出其在Recording Log第一次出现的位置。

如果在Recording Log中找不到要找的数据，这时请先确认是否找对了脚本，毕竟现在开启了两个几乎一样的脚本，很容易弄错。

如果在 Recording Log中找到了要找的数据，这时要确认数据是否为从服务器端传送过来的。首先可以检查数据的标头，从标头的Receiving response可以知道数据是否是从服务器端传送到客户端的。假如此数据第一次出现是在Sending request中，则表示此数据是由客户端产生，不需要做关联，但是有可能需要做参数化（Parameterized）。

现在已经找到录制两次不一致而且是由服务器所产生的动态数据，此数据极有可能需要做关联。

3．使用web_reg_save_param函数手动建立关联。

在找到由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param函数，将这个动态数据撷取到某个参数中。

（1）web_reg_save_param函数

对于关联来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，通过设定的边界字符串，找出特定的数据并将其存储在一个参数中，以供后续脚本使用。

web_reg_save_param是一个服务端函数（Service function，主要用来完成一些特殊的工作，如关联、设定proxy、提供认证信息等），当其作用时，不会对网页的内容做任何的修改。

web_reg_save_param 同时也是一个注册类型的函数（Registration Type Function，只要函数名称中包含_reg_的字眼，表示其为注册类型的函数）。注册类型的函数意味着其真正作用的时机是在下一个动作函数 （Action Function）完成时。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将 web_reg_save_param放在此web_url之前，web_reg_save_param会在web_url执行完毕后，也就是网页内容都 下载完后，再执行web_reg_save_param，寻找要做关联的动态数据并建立参数。

要记住一点，当使用注册类型的函数时，要注意其放置的位置必须在要作用的动作函数之前。

（2）web_reg_save_param的语法

int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);

参数说明：

Ÿ   ParamName：存放动态数据的参数名称。

Ÿ   list of Attributes：其他属性，包含 “Notfound”、“LB”、“RB”、“RelFrameID”、“Search”、“ORD”、“SaveOffset”、“Convert”以及“SaveLen”。下面将详细说明每个属性值的意义。

Ø  Notfound：指定当找不到要找的动态数据时该怎么处理。

当指定Notfound=error时，表示着找不到动态数据时，就发出一个错误消息。此为该属性的默认值。

当指定Notfound=warning时，表示当找不到动态数据时，不发出错误消息，只发出警告，脚本也会继续执行下去不会中断。在对脚本出错时，可以如此设置。

Ø  LB：动态数据的左边界字符串。此属性是必须要有的，而且区分大小写。

Ø  RB：动态数据的右边界字符串。此属性是必须要有的，而且区分大小写。

Ø  RelFrameID：相对于URL而言，欲搜寻的网页的Frame。此属性可以是All或是数字，而且可有可无。

Ø  Search：搜寻的范围，其值可以是Headers（只搜寻headers）、Body（只搜寻body部分，不搜寻header）、 Noresource（只搜寻body部分，不搜寻header与resource）或是All（搜寻全部范围，此为默认值），此属性可有可无。

Ø  ORD：指明从第几次出现的左边界开始才是要撷取的数据，默认值是1。假如该属性值为All，则所有找到符合的数据会存储在数组中。此属性可有可无。

Ø  SaveOffset：当找到符合的动态数据时，从第几个字符开始才开始存储到参数中。此属性值不可为负数，其默认值为0。

Ø  Convert：转换数据格式。当指定该属性值为HTML_TO_URL时，意味着将HTML-encoded数据转成URL-encoded数据格式。如果是HTML_TO_TEXT，表示将HTML-encoded数据转成纯文字数据格式。

Ø  SaveLen：当找到匹配项后，偏移量之后的几个字元存储到参数中。此参数可有可无，默认值是-1，表示一直到结尾的整个字符串都存入参数中。

（3）确定使用web_reg_save_param函数的位置

之前的步骤已经在 Execution Log中找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字，然后复制，利用这段文字，找出要关联的动态数据。不过在这之前，需要先找出使用web_reg_save_param函数 的正确位置，所以要再重新执行一遍脚本，而且这次会开启所有的Log。

在VuGen中单击 “Vuser”>“Run-Time Settings”。单击“General”>“Log”，勾选“Enable logging”、“Always sends messages”、“Extended log”以及“Extended log”下的所有选项。然后，单击“OK”按钮就可以执行脚本了。

执行完脚本之后，在Execution Log中搜寻刚刚复制的字符串。找到字符串后，在字符串前面会有A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是说要插入到脚本的第7行。

在脚本的第7行前插入一行空白行，然后输入：

web_reg_save_param("UserSession",

这个“UserSession”就是到时要使用的参数名称，建议取一个有意义的名字。

到目前为止，整个web_reg_save_param函数还没完成。

（4）确定web_reg_save_param中的边界。

web_reg_save_param函数主要是通过动态数据前后的固定字符串，来辨识要撷取的动态数据的，所以还需要找出动态数据的边界字符串。

1）确定左边界字符串

再回到Execution Log中，选取动态数据前的字符串并且复制它。这时会有个问题，到底要选取多少字符串才足以唯一识别要找的动态数据呢？建议是越多越好，但是尽量不要包含特殊字符。

选取“input type=hidden name=userSession value=”字符串，之后再确认一次这段字符串真的是可以唯一识别的，所以在Execution Log中通过“Ctrl+F”搜寻，查看这段字符串是不是要找的动态数据。假如找不到，web_reg_save_param函数还有个ORD参数可以使用，ORD参数可以设定出现在第几次的字符串才是要找的字符串。

将这个边界字符串加到未完成的web_reg_save_param函数中：

web_reg_save_param(UserSession", "LB= input type=hidden name= userSession value=",

2）确定右边界字符串

接下来要找出动态数据的右边界字符串，这个字符串就比较好找了，从动态数据的最后一个字符开始，通常就是要找的右边界字符串。

以这个例子来看，就是“>”，所以再把右边界字符串加入web_reg_save_param函数中，最后再加上“LAST);”就完成整个web_reg_save_param函数：

web_reg_save_param("UserSession", "LB= input type=hidden name= userSession value=", "RB=>", LAST);

当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。即将

"Name=userSession","Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf", ENDITEM,

替换为：

"Name=userSession", "Value={UserSession}", ENDITEM,

至此，已经完成了一个关联了，接下来就是执行脚本，验证其是否能成功运行。假如还是有问题，就要检查看看是否还需要再做另一个关联。

4．将脚本中有用到关联的数据，以参数取代。

利用前面所介绍的方法找到需要关联的地方，把需要变更的常量用参数进行取代，具体参数化步骤参看第3章3.2.1节的内容，在此不再赘述。

参数化的过程执行如下操作：

（1）用参数替换脚本中的常量。

（2）为参数设置属性和数据源。

参数化的过程要注意以下事项：

（1）在参数化的过程中，只有函数中的参数能被参数化，而且也不是所有函数中的参数都能参数化。例如，Lrd_stmt只能参数化mpcText。

（2）参数化CORBA或General_java Vsuer这两个地方保证完整性，必须参数化整个字符串。

（3）参数的格式要与所录制的脚本相一致，否则脚本可能不能正常运行。

3.3.4  关联中的常见问题

设置语句关联时，如果经验不足，经常会出现一些问题。本节将提供一些关联过程中常见的问题的解决方法，其他出现的问题需要在实际应用中具体分析和处理。

1．在脚本的data目录下找不到录制时的快照（snapshot）。

问题可能的原因如下：

（1）脚本是由VuGen 6.02或更早的版本所录制的；

（2）汇入的Action不会包含快照（snapshot）的档案；

（3）脚本存储在只读的目录下，造成VuGen无法存储执行时撷取的快照；

（4）某些步骤并不会产生快照，如浏览某个资源；

（5）快照功能被取消。

解决办法：选择“Tools”>“General options”>“Correlation”>“Save correlation information during replay”，开启快照（snapshot）功能。

2．开启WinDiff时出现“File no longer available”的错误信息。

问题的原因如下：WinDiff工具有限制，对于包含空格符的目录或是脚本无法开启。

解决办法：为目录或脚本命名时不要使用空格符，并且尽可能将名称取短一点。

3．录制时突然跳出“Correlation warning”对话窗口。

问题的原因如下：

如果勾选自动关联的“Issue a popup message and let me decide online”选项，当VuGen发现有可能要做关联的数据时，就会跳出“Correlation warning”的窗口，询问要做“关联”（Correlation in script）还是要“忽略”（Ignore），如图3-26所示。

图3-26 关联警告

解决方法：可以勾选“Perform correlation in script”，让VuGen自动作关联，不会再跳出询问窗口；或者勾选“Disable correlation engine”，关闭自动关联的功能。

4．如何打印出参数值

解决方法：利用lr_eval_string与lr_output_message这两个函数来打印出参数值。

例子：

lr_output_message("Value Captured=%s",lr_eval_string("{ParameterName}"));

5．如何手动启动“Scan action for correlation”的功能

解决方法：要启用“Scan Action for Correlation”功能，请单击“Tools”>“General options”>“Correlation tab”，勾选“Show Scan for correlation popup after replay of Vuser”选项。