脚本回放问题解决

　　在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如Web、Web Services协议）录制的脚本进行回放时出现的问题介绍一下解决的方法。

　　需要注意的是，回放脚本时出现的错误有时是程序自身的原因导致的，因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。

　　1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。

　　错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

　　错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

　　解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

　　错误现象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

　　错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。

　　如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

　　解决办法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器，最好对其性能进行优化。

　　如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

　　最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。

　　2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。

　　错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。

　　错误分析：脚本录制可能采用的是URL-based script方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。

　　解决办法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

　　3．LoadRunner HTTP服务器状态代码：在录制Web协议脚本回放脚本的过程中，会出现HTTP服务器状态代码，例如常见的页面-404错误提示、-500错误提示。

　　错误现象1：-404 Not Found服务器没有找到与请求URI相符的资源，但还可以继续运行直到结束。

　　错误分析：此处与请求URI相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模拟实际环境，造成一定的负载压力。

　　解决办法：在出现错误的位置进行脚本关联，在必要时插入相应的函数。

　　错误现象2：-500 Internal Server Error服务器内部错误，脚本运行停止。

　　错误分析：服务器碰到了意外情况，使其无法继续回应请求。

　　解决办法：出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此时需要此程序的开发人员配合来解决，而且产生的原因根据实际情况来定，测试人员无法单独解决问题，而且应该尽快解决，以便于后面的测试。

　　4．LoadRunner请求无法找到：在录制Web协议脚本回放脚本的过程中，会出现请求无法找到的现象，而导致脚本运行停止。

　　错误现象：Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]

　　Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]"

　　这时在tree view中看不到此组件的相关URL。

　　错误分析：所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用“URL-based script”模式进行录制。

　　解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based script”，单击“HTML Advanced”，选择“Script. Type”为“A script. containing explicit”。然后再选择使用“URL-based script”模式来录制脚本。

　　5．LoadRunner不执行检查方法：在录制Web协议脚本中添加了检查方法Web_find，但是在脚本回放的过程中并没有执行。

　　错误现象：在脚本中插入函数Web_find，在脚本中设置文本以及图像的检查点，但是在回放过程中并没有对设置的检查点进行检查，即Web_find失效。

　　错误分析：由于检查功能会消耗一定的资源，因此LoadRunner默认关闭了对文本以及图像的检查，所以在设置检查点后，需要开启检查功能。

　　解决办法：打开运行环境设置对话框进行设置，在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

　　6．LoadRunner回放Web Services协议脚本错误：LoadRunner 8.0版本在录制Web Services协议的脚本时正常，但在回放时会出现错误，提示停止脚本运行。

　　错误现象：利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示，回放脚本时会出现如下错误提示“Error：server returned an incorrectly formatted SOAP response”。

　　错误分析：出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为<?xml version="1.0"encoding="zh_cn" ?>，所以才会有此错误提示。

　　解决办法：下载两个补丁，分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。

 

在LR中运行QTP脚本的注意事项

1、QTP的Tools--Options--Run的"Alow other Mercury products to run tests and components"选项要打勾；
2、在QTP脚本中设置事务，Services.StartTransaction "start"与Services.EndTransaction "start"
把需要在LR运行的脚本放在此事务里面；
3、在LR中运行时选择QTP脚本，文件扩展名为.usr的；
4、在LR中运行QTP脚本时，要把QTP关闭；
5、只能在LR的Controller中运行；不能在Virtual User Generator中打开及回放；
6、LR要使用global的license，单单WEB的license不行，会报错；
7、Controller运行中，只能执行1个虚拟用户，大于1个以上的虚拟用户会提示错误；
如果需要运行多个用户，只能在QTP脚本里设置循环及参数化来解决；

  Controller(wlrun.exe)支持命令行参数，所有你只需要通过命令行给wlrun.exe传入场景文件的路径参数，实现多多个场景顺序执行。

    1.新建并保存所有要执行的场景，注意：每个场景必须设置结果存放路径，菜单"Results - Results Settings",设置结果路径，然后勾选“Automatically create a results directory for each scenario execution”

    2.新建一个bat文件，写入如下内容：

    SET LR_PATH="D:\Mercury\LoadRunner\bin\wlrun.exe"
     %LR_PATH%\wlrun.exe -TestPath "E:\Test\Scenario01.lrs" -Run
     %LR_PATH%\wlrun.exe -TestPath "E:\Test\Scenario02.lrs" -Run
     %LR_PATH%\wlrun.exe -TestPath "E:\Test\Scenario03.lrs" -Run

   
    3.双击bat文件运行。

错误如下：

Exception was raised when calling per-thread-terminate function

网上解决方案:

问题产生原因：
     Unlike the earlier Windows versions, Windows 2000 and Windows XP have the default environment set to C:\Document and Settings\<user-name>\Local Settings\Temp instead of C:\Windows\temp. This long path with a space can cause several problems for LoadRunner. To resolve the issue, change to a directory without empty spaces.
　 解决方法：
     在C盘（或是其它盘均可以）新建TEMP文件夹(为了后续设置临时文件准备)
     右键＂我的电脑＂->高级->环境变量->编辑修改TEMP变量目录，指身上面新建的目录，如我的指向C:\TEMP->保存即可^_^
     

 

在测试项目录入相关数据过程中，lr9.1 协议web(click and script. )不认页面规范词选择问题，在网上查找也没有找到答案，不得，只得继续自己找，终于找到了，并成功录制

步骤：在录制设置模块，找到GUI相关设置，在需要的相关功能中，加个EVENT =ondblclick 搞定

loadrunner 9.1脚本回放时产生的错误：

Action.c(160): Continuing after Error -26161: Frame. not found in browser/dialog   [MsgId: MERR-26161]

脚本如下：

web_image_link("image_link",
  "Snapshot=t14.inf",
  DESCRIPTION,
  "Alt=",
  "ID=",
  "Name=",
  "Ordinal=5",
  "FrameName=browserframe",
  ACTION,
  "ClickCoordinates=7,9",
  LAST);

 web_text_link("经营",
  "Snapshot=t15.inf",
  DESCRIPTION,
  "Text=经营",
  "FrameName=browserframe",
  "BrowserOrdinal=2",
  ACTION,
  "UserAction=Click",
  LAST);

 web_image_link("image_link_2",
  "Snapshot=t16.inf",
  DESCRIPTION,
  "Alt=",
  "ID=",
  "Name=",
  "Ordinal=6",
  "FrameName=browserframe",
  ACTION,
  "ClickCoordinates=5,6",
  LAST);

 web_static_image("tree_expand_2",
  "Snapshot=t17.inf",
  DESCRIPTION,
  "Alt=",
  "ID=tree_expand_2",
  "Name=",
  "FrameName=browserframe",
  "BrowserOrdinal=2",
  ACTION,
  "ClickCoordinates=12,10",
  LAST);

 web_text_link("未经营",
  "Snapshot=t18.inf",
  DESCRIPTION,
  "Text=未经营",
  "FrameName=browserframe",
  "BrowserOrdinal=2",
  ACTION,
  "UserAction=Click",
  LAST);

怎么才能回放成功，谢谢各位

Web(Click and scrīpt)

 

    Web (Click and scrīpt) 协议的录制是基于GUI的、用户实际操作界面过程的脚本，记录的是浏览器和服务器的WEB对话，你选择了该协议后，VuGen记录的是你在WEB界面上的操作的直观过程。例如，当你点击“提交”按钮提交信息时，VuGen会生成web_button函数，当你在编辑框中输入时，VuGen生成web_edit_field函数。

    Web(Click and scrīpt)的Vusers支持非HTML代码，比如客户端的Javascrīpt。VuGen会创建直观的脚本来精确的模拟你在web页面上的操作过程。相反，Web(HTTP/HTML)协议不支持Javascrīpt，VuGen只是把Javascrīpt作为web_url函数的一个资源。

    Web(Click and scrīpt)的Vusers能够自动处理大多数关联（correlations）的问题，大大减少脚本编程的时间。通常情况下，你不需要再去定义关联的规则或者在录制后手动再去做关联。

    例如，当你点击按钮提交数据，VuGen会生成web_button函数。如果该按钮是图片，VuGen生成web_image_submit函数，例如下面的例子中，用户点击了login

    …

    web_image_submit("Login",

    "Snapshot=t4.inf",

    DEscrīptION,

    "Alt=Login",

    "Name=login",

    "FrameName=navbar",

    ACTION,

    "ClickCoordinates=31,6",

    LAST);}

 

    相信使用过QTP(QuickTest Professional)的用户已经明白了，Web(Click and scrīpts)的录制和QTP的过程有点类似，是基于用户操作过程的录制。

    另外需要注意的是，Web(Click and scrīpts)不支持Applets和VBscrīpt。如果被测的WEB站点包含了Applets和VBscrīpt，请使用Web(HTTP/HTML)协议。

 

 

    Web (HTTP/HTML)

 

    Web(HTTP/HTML)协议是基于浏览器请求响应数据的脚本。

    当你选择Web(HTTP/HTML)协议录制时，VuGen记录的是在Internet上传送的“浏览器发出的HTTP请求和服务器的响应”的数据，脚本中包含了你的浏览器请求的数据详细信息，而不是操作过程的信息。

    Web(HTTP/HTML)协议提供了两种录制方式，基于HTML的方式和基于URL的方式。这两种方式让你指定录制哪些信息和脚本使用哪些函数。例如，当你点击按钮（不管是图片，还是按钮）提交信息时，VuGen会生成web_submit_data或者web_submit_form函数。

    web_submit_data("start.swe_2",

    "Action=http://design/callcenter_enu/start.swe",

    "Method=POST",

    "RecContentType=text/html",

    "Referer=http://design/callcenter_enu/start.swe",

    "Snapshot=t2.inf",

    "Mode=HTML",

    ITEMDATA,

    "Name=SWEUserName", "Value=wrun", ENDITEM,

    "Name=SWEPassword", "Value=wrun", ENDITEM,

    "Name=SWERememberUser", "Value=Yes", ENDITEM,

    "Name=SWENeedContext", "Value=false", ENDITEM,

    "Name=SWEFo", "Value=SWEEntryForm", ENDITEM,

    "Name=SWETS", "Value={SiebelTimeStamp}", ENDITEM,

    "Name=SWECmd", "Value=ExecuteLogin", ENDITEM,

    "Name=SWEBID", "Value=-1", ENDITEM,

    "Name=SWEC", "Value=0", ENDITEM,

    LAST);

 

    更详细的信息，可以参考手册或者我的《LoadRunner使用说明》。

 

    不过Web(HTTP/HTML)协议不支持Javascrīpt，它只是把Javascrīpt当作web页面的一个资源。

    对于大部分的应用，包括使用Javascrīpt的应用，使用Web(Click and scrīpt)协议；对于使用applets和vbscrīpt的基于浏览器的应用，或者非浏览器的web应用，使用Web(HTTP/HTML)协议。这两个协议是互斥的，在选择多协议的时候是不能同时选的。

针对WebSphere6.1，使用LR8.1对其进行监控，曾试过LR8.0，最然能够连接到WebSphere,但是不能获得计数器，后改用LR8.1并打了FP4补丁。
　　配置WebSphere

　　1) WebSphere 中的配置 - 设置 PMI 规格级别

　　默认情况下，WebSphere 服务器中的基础架构性能监视（Performance Monitoring Infrastructure，PMI）的规范级别为“None”。 需要将其更改为“Standard”。此外，还需要安装 perfServletApp.ear 文件，该文件使用性能监视接口从WebSphere 应用服务器获取性能信息。

　　注：如果已经完成了这些配置，则可忽略此节。

　　2) 修改 PMI 规范级别的步骤

　　a) 连接到管理控制台 - http://<Host>:<Port>/admin/

　　b) 展开左侧树中的服务器节点。

　　c) 点击应用服务器链接，将显示正在运行的服务器列表。

　　d) 点击需要启用数据收集的服务器。

　　e) 点击基础架构性能监视（PMI）链接。然后启用 PMI 并为当前监视的统计集选择“全部”，应用变更。

　　3) 安装 perfServletApp.ear

　　a) 在管理控制台，点击左侧树中的应用程序节点。

　　b) 点击企业应用程序。右侧的表中将列出已安装的所有应用程序。检查 perfServletApp 是否存在。如果不存在，则点击安装以安装 perfServletApp.ear 文件（默认在WebSphere/AppServer/installableApps目录下）

　　完成上述配置后重启WebSphere使配置和服务生效。

　　在浏览器中输入http://<host>:<port>/wasPerfTool/servlet/perfservlet，若能够看到WebSpere的xml格式瞬时性能指标则配置成功。

　　添加计数器

　　由于WebSphere6.1的访问路径与老版本差异很大，所以在使用LR添加计数器时添加monitor machine 需直接添加http://<host>:<port>/wasPerfTool/servlet/perfservlet，或者修改LR的配置文件

　　dat\monitors子目录下的xmlmonitorshared.ini文件，进行如下修改

　　[WAS4ServletMonitor]

　　DescrīptionFile=WebSphereDesc.xml

　　ServletName=perfservlet/

　　ServletAlias=wasPerfTool/servlet

　　然后添加monitor machine 时只要输入<host>:<port>即可

一、问题引入：当我们在Run中添加一个Block0，并在Block0中添加需要的Action，同时给Block0设置运行逻辑，比如按顺序运行10次(Run Logic为Sequential，Iterations为10)。如果Block0中的Action含有参数，那么该参数应该如何设置？

   其实参数设置最主要的有三个：Select next row、Update value on和When out of values。其中Update value on的值可选的是Each iteration、Each occurrence和Once。而它们的意思分别如下:

(1)Each iteration是指每次迭代时更新值，但这个迭代其实只针对Run-time Settings中，选项Run Logic的Run的Iterations，对Run中的Block是不起作用的。也就是说，当Run迭代了10次，同时Run中的Block0也迭代10次的时候，每Run一次，会更新一个参数值，而Block0迭代10次时都使用这个参数值，不会再去更新参数值了。也可以这样理解，每一个Block其实相当于我们自己在脚本里面写一个for循环，去循环调用Block中的Action，此时Each iteration当然只对Run有效。

(2)Each occurrence是指每次参数出现时就更新值。

(3)Once是指只取值一次。

显然，在这种情况下，Update value on只能选择Each occurrence。另外当我们选择了unique和Each occurrence后，LR要求我们设置Allocate …values for each Vuser，这个值与虚拟用户数和参数化值有关，例如：设置Allocate 5 values for each Vuser，虚拟用户数是10个，那么参数化的值至少需要50个（前提是选择了unique选项）。
二、Each occurrence带来的问题：

1． 问题引入：

当我们在进行某个参数设置时，有时Update value on不得不选择Each occurrence（类似一中所述情况），但是，如果Action中有多个相同的参数时，此时参数会在每次出现就更新值，这不是我们所期望的，应为每次执行Action时，同一个参数的值应该都是一样的，否则实际业务操作将运行失败。

2． 解决方案：

其实解决方法很简单，所有相同的参数以不同名字命名（如，P1,P2,P3…），每个参数指向同一个Dat文件，对参数P1进行相应的设置，接下来其他参数的Select next row选择Same line as P1，这样所有的参数的值的更新机制和P1一样，每次行Action时，同一个参数的值就都是一样了。

三、Dat文件记录读取原理：

Controller在运行时，会首先初始化Vuser脚本，以检查脚本是否有语法错误，以及为各个虚拟用户分配参数值。而分配参数值的时候，本人猜测它是根据需要读取的参数数量循序或者随机读取Dat的记录（一行为一个记录），当记录个数不足时，就会抛出错误提示。因此我们在选择文件源是，就要多加小心，以防止Controller自己“错乱方寸”：

1．不同参数（对应相同的列）对应的Dat文件要不同，若想指向同一文件，则参数设置“Select next row”应选择“Same line as…”

2．不同Vuser脚本不要使用同一个Dat文件。

Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
　 　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌 握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
　　Web Resources（Web资源分析）
　　Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
　　“吞吐率”图和“点击率”图的区别：
　　“吞吐率”图，是每秒服务器处理的HTTP申请数。
　　“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
　　在下列情况将重试服务器连接：
　　A、初始连接未经授权
　　B、要求代理服务器身份验证
　　C、服务器关闭了初始连接
　　D、初始连接无法连接到服务器
　　E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
　　借助此图，可以知道何时需要添加其他连接。
　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
　　Web Page Breakdown（网页元素细分）
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
　　“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

1，             被测系统是由驱动进程mdrv.exe(多线程驱动的进程)和r3vuser.exe来产生压力的，其中r3vuser.exe仿真应用程序的客户端，如IE浏览器。它执行了三个主要的操作：

       Kli> cpp (C 语言pre-processor)

       1）cci （C语言编译器），建立ci文件，然后使用被测系统的协议相关的驱动来执行。

 

通过在Windows批处理脚本中启动Mdrv.exe来默默地启动运行。

Mdrv能自动停止加载Vuser，因为他们与Vuser和Windows负载生成器上的CPU使用监视器之间互相通信。

在Windows机器上，对于每一个基于Java的Vuser都有一个独立的JVM。

2，             虚拟用户通过在负载生成器客户端机器上使用agent（3900 magentproc.exe）作为服务或者进程来按照组（在指定的负载生成器上运行相同脚本的虚拟用户的集合）启动虚拟用户。

3，             每一个拥有代理的机器维护一个在.qtp文件中的执行日志。

4，             当日志被启用后，代理同样会在结果文件中为每一个虚拟用户（由虚拟用户组分开）建立一系列日志文件。

5，             在执行过程中， 这些文件可以通过在Controller机器上的view > Show Output窗口中显示。

6，             在预先设置延时上，Controller上运行的Scheduler指导代理(通过Windows 54345端口,或者Unix上的动态端口)去初始化场景会话.Controller(wlrun.exe)在请求中发送一份场景的拷贝.

7，             代理是由每一个负载生成器上的Remote Agent Dispatcher进程(以前叫Remote Command Launcher(RCL))启动的.

8，             每一个根据场景(.lrs)定义文件中设置的代理来决定哪一个虚拟用户组和脚本需要在主机上运行.

      ## 这就是说Controller可以从DOS的批处理文件(.batch)中启动.

  REM Start Controller:
SET M_ROOT=C:\Program Files\Mercury Interactive\LoadRunner\bin
cd %M_ROOT%
wlrun.exe -TestPath D:\Dev\Dev1.lrs -port 8080 -Run -DontClose

l       包含的-Run 参数与手动的点”开始场景”自动运行是一样的. 这不是一个很好的方法,因为你可能需要决定从以前的运行中收集文件或者想改变输出文件夹.

l       这是假设系统环境变量PATH已经被更新了,包括LoadRunner的安装.

9, Controller通过使用   Windows 操作系统文件夹里的参数值来启动.因为LoadRunner被设计成在一个机器上一次只能运行一个Controller实例,所以需要使用Windows文件夹.

 ## 为了在几个应用之间快速的切换, 在Controller工作之后保存LoadRunner的ini文件, 然后使用记事本来制作一个批处理文件. 在执行wlrun之前拷贝应用程序的指定版本的ini文件. 下面是一个应用程序文件拷贝的例子:

copy %WinDir%/wlrun7-XXX.ini   %WinDir%/wlrun7.ini
copy %WinDir%/wlrun7-XXX.dft   %WinDir%/wlrun7.dft

需要修改一些默认值:

l       在wlrun7.ini文件的output区域, MaxNumberOfOutputMessages= from 10000 to 100000, 这就限制了存储在数据库中的输出信息的数目.

l       MaxOutputUIRowsToShow限制了在Controller的输出窗口中显示的信息/错误行总数.

l       在LoadRunner程序文件的 dat\protocols       文件夹下的QTWeb.lrp文件的[Vugen]部分, 添加一个MaxThreadPerProcess=5来限制由每个负载生成器mdrv.exe进程管理的线程数.

l       存储在wlrun5.ini 和wlrun7.dft文件中的DefaultScenarioDir, DefaultscrīptDir, DefaultResultDir, [Recent File List]几个数据的值会在每次Controller改变的时候更新。

10，             在Vu scrīpts中定义的每个虚拟用户进行的操作是用LoadRunner的VuGen.exe生成的. 当这个程序启动后, 它在windows文件夹下存储了comparamui.INI文件来保存[LastTablesUsed]下面文件的历史,并且保存由Insert > New Parameter > Dates 菜单指定的[ParamDialogDates].

VuGen在Windows文件夹下存储和检索vugen.ini文件.当使用JAVA的时候,需要添加一些其他的调试选项:

[DynaDlg]
JavaLevel=3

当在VuGen 8.1中使用8.0的脚本, 往Vugen.ini中加入信息:

[Editor]
OLDEDITOR = 1

VuGen在LR文件夹template/qtweb default.cfg里和脚本文件里打开.

Vu scrīpts可以使用脚本外部的参数文件来获得的变量值进行编码.

更多关于VuGen的信息请看脚本编写的章节.

11. 运行过程中,执行结果存储到一个结果文件夹中.

    我喜欢在场景执行中把结果设置成自动产生结果.这样,LoadRunner会在每次启动一个场景之后自动产生一个子增的结果名. 例如,结果名称Res1会自动增长到Res12或有时候是R   es11-1.

错误被写到output.mdb微软的Access数据库中。

12. 在每一个结果文件夹中, 程序自动创建Log文件夹来包含每个组的日志文件. 运行之后,在Controller中查看日志文件,点 , .然后在组中点右键,选择 “Show Vuser Log”

13. 场景运行的时候, 监视器在本地维护每个主机的计数器.

14. 运行完成之后, "collate"进程处理.eve和.lrr结果文件, 并且在结果文件夹下创建一个临时的.mdb数据库.

在处理大数据量的结果时, 为了防止错误发生,使用MSDE. ……

15.分析模块(8,320K analysisu.exe)使用mdb数据库中的数据来产生分析图表和报告.

16. 每一次场景运行后的结果文件results_name.lrr,也叫分析文档文件,由分析程序来读取并且显示百分位图表.

Web Page Breakdown(网页元素细分)

　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的

　　元素。

　　1、Web Page Breakdown(页面分解总图)

　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

　　“页面分解”图可以按下面四种方式进行进一步细分：

　　1)、Download Time Breaddown(下载时间细分)

　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。

　　2)、Component Breakdown(Over Time)(组件细分(随时间变化))

　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

　　3)、Download Time Breakdown(Over Time)(下载时间细分(随时间变化))

　　“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分(随时间变化)情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。

　　“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。

　　4)、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间(以秒为单位)。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

　　First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

　　2、Page Component Breakdown(页面组件细分)

　　“页面组件细分”图显示每个网页及其组件的平均下载时间(以秒为单位)。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

　　3、Page Component Breakdown(Over Time)(页面组件分解(随时间变化))

　　“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 (以秒为单位)。

　　4、Page Download Time Breakdown(页面下载时间细分)

　　“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

　　“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

　　5、Page Download Time Breakdown(Over Time)(页面下载时间细分(随时间变化))

　　“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。

　　“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

　　6、Time to First Buffer Breakdown(第一次缓冲时间细分)

　　“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。

　　网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。

　　服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

　　7、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

　　8、Downloader Component Size(KB)(已下载组件大小)

　　“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

录制:web登录邮箱,发送一封带有附件的邮件.

         

但是,每次执行的时候服务器的返回值-附件变量"AttFilles"是不一样的,所以需要将这个变量"AttFilles"做一下关联!

关联的方法大体上可以分为手工关联和自动关联.这两种方法各有所长,手工的比较保险,但是需要自己去找关联函数的位置和需要关联的参数,然后一一替代，

自动关联就比较简单了,找到关联参数的特征,运行的时候自动关联就是了,但是,有时候自动关联不是很完整，可能有的参数找不全!因为我录的脚本是比较简单的,需要关联的参数只有一个,所以,自动关联还是比较可靠的!
我知道的自动关联方式也有两种,我把它们分别定义为:变量名关联和变量值关联!
下面大概说一下录制到关联的过程。
一般情况下都是先录制两份相同的脚本，这里的相同是指录制时执行的业务流程，然后用工具比较两个脚本中变化的变量我个人比较喜欢用ultraedit，loadrunner自身也有一个比较的工具，但是感觉这个用起来比较快！
好了，找到变量就该关联了，下面是我采用的几种关联方法：

变量名关联:前提条件,我已经知道整个脚本中需要关联的变量名是："AttFiles".那么，需要：RecordOption-Correlation,新建一个"aaa"的关联名,
规则为:Action:parameterizeform
filed value;Field name:AttFiles;Parameter
Prefix:AttFiles;

然后重新录制该脚本,录制的过程中,自然会有关联的提示,只需OK就可以了!

变量值关联:前提条件,我已经知道整个脚本中需要关联的变量名是"AttFiles".RecordOption-Correlation,新建一个"bbb"的关联名,

规则为:Action: Search for parameters in all of the body text Left bounday:
还有一点就是，这个左右边界值，一定要是服务器的返回值（response from server)，而不是用户发出的请求值(user request),这个值可以在recording log里找，然后重新录制该脚本,录制的过程中,自然会有关联的提示,只需OK就可以了!

手工关联：在脚本中输入函数：web_reg_save_param("ATT",
"LB="input type="hidden" name="AttFiles" value=",
"RB=>",
LAST,）;
手工关联的关键在于这个函数位置怎么放，之前有看过一个台湾作者的笔记，但是自己实在是笨，怎么也找不到。后来先看了自动关联后的脚本，然后自己分析下， 总结出一个小知识，就是，录完脚本后，再执行一遍，点击：view-scan correlation，loadrunner会自动找一些他觉得需要关联的值参数，并且显示在correlation-result里，我们再选取需要 的参数，点击右边的”correlation“然后这个函数就会自动加到他应该出现的位置，然后我们就可以"借用"它的劳动成果，自己手动添加函数啦！

接着就是在脚本中寻找使用该变量出现的位置，执行替换，value={ATT},这个脚本中共需要两次替换即可！
手工关联后，就不需要再重新录制脚本了！

=========================
还有个小小的经验就是，如果你遇到这样的脚本：web登录邮件，查看其中一封邮件，然后退出。（没有什么实际意义哈）再回放的时候，老是在查看这封邮件的 时候过不去，那么，你可以试试重新录制一份脚本，但是先把：recordingoption-internet protool-recording 勾选url-based scrīpt！具体为啥我也不知道，哈哈。

LR函数：
lr_start_transaction 为性能分析标记事务的开始
lr_end_transaction 为性能分析标记事务的结束
lr_rendezvous 在 Vuser 脚本中设置集合点
lr_think_time 暂停 Vuser 脚本中命令之间的执行
lr_end_sub_transaction 标记子事务的结束以便进行性能分析
lr_end_transaction 标记 LoadRunner 事务的结束
Lr_end_transaction("trans1",Lr_auto);
lr_end_transaction_instance 标记事务实例的结束以便进行性能分析
lr_fail_trans_with_error 将打开事务的状态设置为 LR_FAIL 并发送错误消息
lr_get_trans_instance_duration 获取事务实例的持续时间（由它的句柄指定）
lr_get_trans_instance_wasted_time 获取事务实例浪费的时间（由它的句柄指定）
lr_get_transaction_duration 获取事务的持续时间（按事务的名称）
lr_get_transaction_think_time 获取事务的思考时间（按事务的名称）
lr_get_transaction_wasted_time 获取事务浪费的时间（按事务的名称）
lr_resume_transaction 继续收集事务数据以便进行性能分析
lr_resume_transaction_instance 继续收集事务实例数据以便进行性能分析
lr_set_transaction_instance_status 设置事务实例的状态
lr_set_transaction_status 设置打开事务的状态
lr_set_transaction_status_by_name 设置事务的状态
lr_start_sub_transaction 标记子事务的开始
lr_start_transaction 标记事务的开始
Lr_start_transaction("trans1");
lr_start_transaction_instance 启动嵌套事务（由它的父事务的句柄指定）
lr_stop_transaction 停止事务数据的收集
lr_stop_transaction_instance 停止事务（由它的句柄指定）数据的收集
lr_wasted_time 消除所有打开事务浪费的时间
lr_get_attrib_double 检索脚本命令行中使用的 double 类型变量
lr_get_attrib_long 检索脚本命令行中使用的 long 类型变量
lr_get_attrib_string 检索脚本命令行中使用的字符串
lr_user_data_point 记录用户定义的数据示例
lr_whoami 将有关 Vuser 脚本的信息返回给 Vuser 脚本
lr_get_host_name 返回执行 Vuser 脚本的主机名
lr_get_master_host_name 返回运行 LoadRunner Controller 的计算机名
lr_eval_string 用参数的当前值替换参数
lr_save_string 将以 NULL 结尾的字符串保存到参数中
lr_save_var 将变长字符串保存到参数中
lr_save_datetime 将当前日期和时间保存到参数中
lr _advance_param 前进到下一个可用参数
lr _decrypt 解密已编码的字符串
lr_eval_string_ext 检索指向包含参数数据的缓冲区的指针
lr_eval_string_ext_free 释放由 lr_eval_string_ext 分配的指针
lr_save_searched_string 在缓冲区中搜索字符串实例，并相对于该字符串实例，将该缓冲区的一部分保存到参数中
lr_debug_message 将调试信息发送到输出窗口
lr_error_message 将错误消息发送到输出窗口
lr_get_debug_message 检索当前消息类
lr_log_message 将消息发送到日志文件
lr_output_message 将消息发送到输出窗口
lr_set_debug_message 设置调试消息类
lr_vuser_status_message 生成带格式的输出，并将其写到 ControllerVuser 状态区域
lr_message 将消息发送到 Vuser 日志和输出窗口
lr_load_dll 加载外部 DLL
lr_peek_events 指明可以暂停 Vuser 脚本执行的位置
lr_think_time 暂停脚本的执行，以模拟思考时间（实际用户在操作之间暂停以进行思考的时间）
lr_continue_on_error 指定处理错误的方法

lr_continue_on_error (0）；lr_continue_on_error （1）；
lr_rendezvous 在 Vuser 脚本中设置集合点
TE_wait_cursor 等待光标出现在终端窗口的指定位置
TE_wait_silent 等待客户端应用程序在指定秒数内处于静默状态
TE_wait_sync 等待系统从 X-SYSTEM 或输入禁止模式返回
TE_wait_text 等待字符串出现在指定位置
TE_wait_sync_transaction 记录系统在最近的 X SYSTEM 模式下保持的时间

WEB函数列表：

web_custom_request 允许您使用 HTTP 支持的任何方法来创建自定义 HTTP 请求
web_image 在定义的图像上模拟鼠标单击
web_link 在定义的文本链接上模拟鼠标单击
web_submit_data 执行“无条件”或“无上下文”的表单
web_submit_form 模拟表单的提交
web_url 加载由“URL”属性指定的 URL
web_set_certificate 使 Vuser 使用在 Internet Explorer 注册表中列出的特定证书
web_set_certificate_ex 指定证书和密钥文件的位置和格式信息
web_set_user 指定 Web 服务器的登录字符串和密码，用于 Web 服务器上已验证用户身份的区域
web_cache_cleanup 清除缓存模拟程序的内容
web_find 在 HTML 页内搜索指定的文本字符串
web_global_verification 在所有后面的 HTTP 请求中搜索文本字符串
web_image_check 验证指定的图像是否存在于 HTML页内
web_reg_find 在后面的 HTTP 请求中注册对 HTML源或原始缓冲区中文本字符串的搜索
web_disable_keep_alive 禁用 Keep-Alive HTTP 连接
web_enable_keep_alive 启用 Keep-Alive HTTP 连接
web_set_connections_limit 设置 Vuser 在运行脚本时可以同时打开连接的最大数目
web_concurrent_end 标记并发组的结束
web_concurrent_start 标记并发组的开始
web_add_cookie 添加新的 Cookie 或修改现有的 Cookie
web_cleanup_cookies 删除当前由 Vuser 存储的所有 Cookie
web_remove_cookie 删除指定的 Cookie
web_create_html_param 将 HTML 页上的动态信息保存到参数中。（LR 6.5 及更低版本）
web_create_html_param_ex 基于包含在 HTML 页内的动态信息创建参数（使用嵌入边界）（LR 6.5 及更低版本）。
web_reg_save_param 基于包含在 HTML 页内的动态信息创建参数（不使用嵌入边界）
web_set_max_html_param_len 设置已检索的动态 HTML 信息的最大长度
web_add_filter 设置在下载时包括或排除 URL 的条件
web_add_auto_filter 设置在下载时包括或排除 URL 的条件
web_remove_auto_filter 禁用对下载内容的筛选
web_add_auto_header 向所有后面的 HTTP 请求中添加自定义标头
web_add_header 向下一个 HTTP 请求中添加自定义标头
web_cleanup_auto_headers 停止向后面的 HTTP 请求中添加自定义标头
web_remove_auto_header 停止向后面的 HTTP 请求中添加特定的标头
web_revert_auto_header 停止向后面的 HTTP 请求中添加特定的标头，但是生成隐性标头
web_save_header 将请求和响应标头保存到变量中
web_set_proxy 指定将所有后面的 HTTP 请求定向到指定的代理服务器
web_set_proxy_bypass 指定 Vuser 直接访问（即不通过指定的代理服务器访问）的服务器列表
web_set_proxy_bypass_local 指定 Vuser 对于本地 (Intranet) 地址是否应该避开代理服务器
web_set_secure_proxy 指定将所有后面的 HTTP 请求定向到服务器
web_set_max_retries 设置操作步骤的最大重试次数
web_set_timeout 指定 Vuser 等待执行指定任务的最长时间
web_convert_param 将 HTML 参数转换成 URL 或纯文本
web_get_int_property 返回有关上一个 HTTP 请求的特定信息
web_report_data_point 指定数据点并将其添加到测试结果中
web_set_option 在非 HTML 资源的编码、重定向和下载区域中设置 Web 选项
web_set_sockets_option 设置套接字的选项

Analysis Summary Page

 

分析总结页面划分了三个主要的段，统计总结、事务总结以及HTTP响应总结。统计总结列出了在场景中统计的全部影响。

你可以在运行Vusers的顶点和场景运行的整个期间（这个阶段是17:08:38 – 17:54:35, 有 46分钟），对比吞吐量和统计点击率。

用户的数量和整个运行时间，就是衡量服务器/应用程序可承受吞吐量和点击率的性能了么？你必须对服务器/数据库性能和配置有更多的了解才可以确定。

 

下一个分析总结部分是事务总结，包括了每个单独的事务的统计，他们的回应时间（最小，平均，最大和标准偏差）

图中的“90 Percent”统计指出事务在当前行90%的最大响应时间。在这个统计数值之上，你可以知道90%的“A_MainPage_AFI…”这件事务最大的响应时间是94.845秒

成功和失败事务都列在这个部分里。前缀为“Z_”的事务包含了脚本中使用的所有事务统计的总和

所有的成功事务在“Z_”事务中至多等于最少通过的单独事务，这里不包括Vuser_init/end这两个事务，这是因为“Z_”事务记 录了整个脚本流的统计数字，而不只是一个单独事务。如果脚本中一个用户成功执行所有的步骤，从开始到结束，只有这个时候，“Z_”事务的成功值会上升。无 论如何，如果失败发生在脚本中的某一点，则事务失败的数量在发生失败的地方将会增加，并且“Z_”的失败事务数值也会随之增加。

在这个统计数字的基础上，“Z_”事务中成功事务的总数为776，符合最少成功的单独事务“E_ResultsDisplay…”，而在另一方面，“Z_“的总的失败数是所有事务之和

 

最后部分的分析总结是HTTP响应总结，这包括了在测试过程中所有HTTP响应的总数和每秒统计的记录。最常出现的信号就是HTTP200，表明成功。这个HTTP所有响应的列表和它们的含意可以在术语表中查看附加的文档

Running Vusers

 

运行的用户图表显示了虚拟用户在场景中当前执行脚本的情况。一个虚拟用户按照测试脚本执行一次任务直到全部结束，这个用户已经执行了所需脚本的所有重复（iterations）除非手工停止controller中的用户

虚拟用户会在渐增的场景中被增加，不像上图中所有用户同时被加载，在虚拟用户的数量在压力测试计划中到达一个高度之后，会保持这些用户运行一段时间，再使用户数递减，递减的速度要比递增的快，因为从移除用户对服务器几乎没有任何不利影响。

无论什么时候，在测试中出现问题，你都应该知道当前场景中的用户数量。压力测试的目的是诊断程序在虚拟压力下出现的问题，所以，当虚拟用户 的数量达到某个值时，会看到数据都在减少，这可以说明程序的不稳定。突发的数据向相反方向（正或负）的延伸都意味着运行的虚拟用户在增加中

这张图表遵循着标准的测试时间表，每分钟增加10个用户，到达最大用户数250时运行10分钟，之后每分钟减少25个用户

Hits per Second

 

每秒点击率显示在网站服务器上随着时间推移的点击数量。这个图表可以显示整个场景或者最后60、180、600或3600秒的情况。你可以将它与事务响应时间图表对比来查看点击是如何影响事务的执行的。

每秒点击率的增涨表明服务器负荷的增加，所以将每秒点击率与事务响应时间和吞吐量对比，可以让你对服务器在压力下的执行有更多理解。当一个 网站服务器正在活动中，每秒点击率将会时常镜像成功的HTTP响应信号的总数。在上图中运行的第25分钟左右到达了尖锋。这可以在诸如运行的用户数、吞吐 量和事务响应时间中这些图表中找到答案。

Throughput

 

Throughput(吞吐量)展示了数据的总量,它基于字节，由网页服务器每秒向传送scenario的运行情况. Throughput 是基于字节/秒来传输的，它描述通过网络服务器传输的数据在网络上任意事件发生时的传输量。完美的吞吐量应该是随着每秒点击率的增加而增加，这种增加是建 立在带宽足够处理用户提出的所有请求的基础上的。

在比较吞吐量和每秒的点击率中你可以获得服务器在执行过程中的信息。如果服务器如预期的一样在执行，那么吞吐量会随着它每秒的点击量的 增加而增加。这是期望实现的情况，因为点击增加一次就会需要服务器发送更多的返回信息给用户。无论如何，如果点击的次数增加而吞吐量恒定或减少，就说明服 务器无法执行增加的请求（每秒点击率），结果就是事务反应时间的增加。

这个图表在展示了一个吞吐量在整个测试中普遍下降的情况，在前25分钟，这种减少的数量是少量却明显的，刚好对应了Hits per Sencond的图表的尖锋时刻，比较这些统计的数字，最好的方法就是把这些图表结合起来。

这张图表展示了整个测试过程中吞吐量的一个正常减少，在25分钟前面这里，减少的数量不大却也清晰，与上一张图表Hit per Second正好对应，单纯的这些统计数字还是不如整体对比的看所有图表来得准确详细

Hits per Second - Throughput

 

这张图表是把hits per second和 throughput两图结合起来的结果，我们可以看到在25分钟前后，每秒的点击的爆增和吞吐量的减少是相应的。如果一台服务器的业务量低于最大负载量，则每秒点击率通常

会映射吞吐量。上述图表中的结果最有可能的情况是由于用户负载的增加，因为更多用户将会引起每秒点击率的增长，并且当服务器不再处理大量的请求的时候，吞吐量将会减少。

说到后面的RunningVusers图表，我们知道在前25分钟，加载250个用户会使其到达峰值，由此，预期的每秒点击率的增长和吞吐量的减少说明了服务器的负载已经达到了它的最大值。我们可以预计事务的处理时间和每秒可能发生的错误也会在25分钟前后达到峰值。

 

Average Transaction Response Time

 

平均事务处理时间图表显示了平均每个事务的结束的反应时间。反应时间是从客户端请求到服务器响应的全部时间。通常的响应时间会与当前在测试场景中运行的Vusers的数量一致。

响应时间增加的最通常的原因是运行的用户增加，因为随着用户进入测试场景的增加，服务器的工作量也会增加。服务器会花时间去响应一个增加的负载，于是平均响应时间就会增长。

上述图中我们预期到响应的增长时间，这与其它图 表中在25分钟前后的数据变化一致。看一下响应时间中的“Z_AFIWhitePages_s2_e3_v3_Transaction”事务，这是最早能 分析常规行为的方法，并且进入场景后的10分钟里，总的响应时间增长到110秒左右。在10分钟的时候Vusers运行的人数达到120，所以与前面对 比，服务器开始了很大的工作量。

 

Transactions per Second (Passed/Failed)

 

每秒事务图表显示了随着时间推移，事务成功和失败的数量。一个事务表示单独的一个步骤或一个虚拟用户在一组用户中的执行。例如，这个过程是在一个事务中并发测试在网站上进入并确认登录信息

在规定时间内测试场景中的每秒事务数与运行的虚拟用户数相一致，并且随着虚拟用户的增加，每秒事务数也会增加。如果随着虚拟用户的减少，每 秒事务数也会减少，这时场景中很可能出现了问题。你应该先对比运行的虚拟用户数量与每秒事务图，以核实一次虚拟用户的增加是否导致每秒点击率、事务响应时 间和吞吐量的增加，将这些统计数据放到一起会帮助你找出问题发生的主要原因

Total Transactions per Second

 

每秒总事务图显示的是在测试场景的运行中，所有事务通过与失败的总和。我们可以清晰地看到所有事务的运行情况，像上一张图表一样，有更多特定的每秒事务，这张图表中红线代表失败的总数，说明正在运行的服务器由于一个用户已经超出它可以承载的最大能力

图中的红线说明事务失败的总数，在25分钟左右的时候出现了预期的峰值，表明服务器已经超出了可以承受用户的最大值。注意在35分钟前锐减的错误，这与测试中虚拟用户的减少相对应

Transaction Summary Graph

 

交易总数图表显示测试场景中所有成功、失败和停止事务的的记录。成功的事务是完全成功的，失败的事务是由于未预期事件的出现（一个页面的加载失败，登录失败等）导致的，停止的事务是指没有满足成功或失败条件

分析这张图表你可以发现事务成功/失败的比率，并确定哪个事务看起来需要更多注意。单一事务的大量失败表明在测试场景中有某类型的问题在一个时刻出现了，出现这种问题的原因可能是某个服务器或页面的问题。此外，分析其它结果会有助于确定事务失败的特殊原因。

例如，最右侧的事务失败率达到91.47%，明显地这已经超出了预期值。通过分析其它图表，你会发现它们精确地说明这个事务的失败情况。单独的事务同时出现通过与失败，暗示着场景中在某一点出现了问题。所以对比运行虚拟用户的数量、响应时间和吞吐量是有必要的。

注意这里的“Z_”事务，以且所有出现失败事务的总和，这个值总是大于任意一个单独事务失败的事务

Transaction Performance Summary

 

事务每秒执行总结图表除了在测试场景中规定了最小值、平均值、最大值响应时间之外与事务总结图表相似，

最右侧的事务是“Z_”事务，它在图中有最大值，因为它是所有事务之和。没有哪个事务单独表现出比其他事务高很多的响应时间，但是左边数第二个事务有30.2秒的平均响应时间值。如果可以得到此事务所需资源的更多信息（包括完成数据库的操作，服务器是否正常接收数据），你就会发现高出平均响应时间的原因。

在这个例子中，0响应时间的事务是当虚拟用户被加载和退出测试场景时的初始化和终止，可以忽略不计。如果测试计划需要，初始化和终止行为中 可以包含多个动作，例如场景在总共的三个部分中都需要事务，可以在进入程序时一次（初始化），执行动作时根据设置的次数运行，然后退出程序（终止）

Transaction Response Time (Under Load)

 

事务响应时间（压力下）图表是运行的虚拟用户和平均事务响应时间表的一个结合。它显示了在测试场景的某一时刻事务响应时间与虚拟用户运行的数量是有关系的。这张图表有助于观察虚拟用户加载和分析平缓加载的场景对响应时间产生的影响

平缓的加载使你可以侦测到当虚拟用户数量达到多少时，事务响应时间会出现不好的变化。通过对比测试时间表与这张图表的统计数字，你可以确定响应时间的一个峰值与虚拟用户的增长是否相对应，否则你只能在其它地方找到问题出现的原因。

图中的加载0-20位用户时的平均响应时间是可以被忽略的，因为测试是从20个用户开始的。非常高的响应时间是因为LR测试软件本身的资源 使用，且从0-20用户在测试中没有任何的影响。用户初始化后，运行40用户时，平均响应时间锐减。最可能的原因是这40个用户在不同的网页/服务器之间 重新被分配，之后到达60用户

Transaction Response Time (Percentile)

 

事务响应时间显示了事务在一定时间内的响应百分比。图中事务的平均响应时间（绿线）到达90%时，响应时间已经超过了200秒。基于这点还 很难作出结论，不同于普通的观察。例如，事务在到达90%时的响应时间比在10%时要多。也很难直接地用其它图表而不用这张图表，因为在X轴上衡量事务百 分率这部分数据,想要在这些统计数据的基础上做出对比的结论实在困难。

HTTP Status Code Summary

 

HTTP状态标准总结包含了饼图显示了HTTP响应数量的集合，它按照状态分类。在多数测试中主要的响应标准是200，成功。图中50%的部份是200，25%是500（失败），另25%是请求页面404（未找到）。HTTP响应的详细标准和含义在附加的词汇表中说明

HTTP Responses per Second

 

HTTP每秒响应图统计的是HTTP响应的状态标准，最常用的标准有200（成功），302（重定向），404（未找到）和500（内部服务器问题）。增加的HTTP响应意味着服务器正在处理更多的请求，并成功发送一个HTTP的响应给用户。

图中测试的整个过程中，“成功”响应标准与“页面未找到”标准的数量相对稳定，在响应503标准在18分钟时开始出现了一个峰值，这说明服 务器无法获得请求，在25分钟的时候503标准的每秒响应相当的大，达到每秒16次，说明这时服务器已经超出它可承受的最大值，此结论被其它结果支持。

应用场景
假设有3个不同的测试场景，分别为并发登录、核心业务、可靠性测试，3个场景有先后执行顺序。由于白天测试机器另有用处，只能在晚上进行性能测试，这时我们的期望是能否把测试场景都设定好之后晚上自动运行，第二天我们回来看测试结果呢？
答案是肯定的，可以有两种方式实现。

第一种，相对简单
充分利用LR Controller里面Group的功能。
新建一个场景把3个脚本都添加进来，在Edit Schedule中选择“Schedule by Group”的方式，在StartTime中设置3个脚本的运行顺序为“Start when Group xxx finished”，并在“Scenario Start Time”中设定场景在晚上的运行启动时间。设定完定时执行场景后，点击StartScenario按钮，会出现一个倒计时窗口，这样在固定的某个时间 上，测试场景中的3个脚本将乖乖的按照设定的先后顺序进行测试。注意，如果没有点击StartScenario按钮激活测试，是不会真正进行测试的。（感 谢Athenst朋友的提醒，^_^）

第二种，比较灵活
我们把应用场景稍微扩展一下，假设其中1、3场景只有一个测试脚本，而核心业务场景由数据录入、数据查询、数据上报3个脚本组成，同样的，3个场景仍需按 顺序进行测试。这时如果采用第一种方式，由于第2个场景有3个脚本，所以第三个脚本的启动时间就是一个问题了。由于Controller中每个脚本都对应 一个Group，而且GroupName不能重复，这时第三个场景的StartTime中“Start when group finished”则只能是选择第二个场景中的某个Group，而并非是第二个场景的3个脚本都完成之后再进行，无法达到我们的初衷。
这时，可以通过命令行的方式来进行。
首先创建并设置好3个测试场景，再创建一个一个批处理程序按先后顺序调用这3个场景进行测试，最后通过Windows的定时任务设定批处理的执行时间。
批处理示例如下：
cls
SET M_ROOT="D:\Program Files\MI\Mercury LoadRunner\bin\"
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_1.lrs" -Run
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_2.lrs" -Run
%M_ROOT%\wlrun.exe -TestPath "D:\Program Files\MI\Mercury LoadRunner\scenario\Test\TestScen_3.lrs" -Run
这种方式比较灵活，但需要注意在Result　Settings中设置“Automatically create a results directory for each scenario execution”，以免后面的测试结果覆盖了前面的。


另外补充一下，如果想对某个脚本进行50、100、150...等用户数递增的测试，也可以用以上方法实现，但需要注意的是将事务名称区分开以便进行分析。

1.查找注册成功的信息

web_reg_find("Search=Body",
  "SaveCount=num",
  "Text=Thank you for signing up.",
  LAST);

 lr_start_transaction("reg");

2.通过判断来确认注册是否成功

if(strcmp(lr_eval_string("{num}"),"1")==0)
  lr_end_transaction("reg", LR_PASS);//注册成功
 else
  lr_end_transaction("reg", LR_FAIL);