一直都是用一台机器来学习loadrunner，说实话，还没有好好理解过loadrunner的原理，
前几天从网上搜索了一下，放在这里，以免自己忘记：

loadrunner通过模拟上千万用户实施并发负载，实时性能监控的系统行为和性能方式来确认和查找问题。
    一、 LoadRunner 工具组成 

1、虚拟用户脚本生成器：捕获最终用户业务流程和创建自动性能测试脚本，即我们在以后说的产生测试脚本； 

2、压力产生器：通过运行虚拟用户产生实际的负载； 

3、用户代理：协调不同负载机上虚拟用户，产生步调一致的虚拟用户； 

4、压力调度：根据用户对场景的设置，设置不同脚本的虚拟用户数量； 

5、监视系统：监控主要的性能计数器； 

6、压力结果分析工具：本身不能代替分析人员，但是可以辅助测试结果的分析。
    二、LoadRunner工具原理

    代理（Proxy）是客户端和服务器端之间的中介人，LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流。

     1）虚拟用户脚本生成器通过代理方式接收客户端发送的数据包，记录并将其转发给服务器端；接收到从服务器端返回的数据流，记录并返回给客户端。这样服务器端和客户端都以为在一个真实运行环境中，虚拟脚本生成器能通过这种方式截获数据流；虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理，最终用脚本函数将数据流交互过程体现为我们容易看懂的脚本语句。

    2）压力生成器则是根据脚本内容，产生实际的负载，扮演产生负载的角色。

    3）用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或是线程协作，接受调度系统的命令，调度产生负载压力的进程或线程。

    4）压力调度是根据用户的场景要求，设置各种不同脚本的虚拟用户数量，设置同步点等。

    5）监控系统则可以对数据库 、应用服务器、服务器的主要性能计数器进行监控。

    6）压力结果分析工具是辅助测试结果分析。

那么我现在假如有多台机器，该如何部署呢？例：假如我现在有测试机a、测试机b、测试机c、服务器d。我的做法如下：
我将a、b当作负载机器，将Controller安装在了c机，用c机来控制a机和b机，a、b上都安装了Vuser和loadrunner generator，不知我这样做对不对。如果正确的话，

（1）不知道loadrunner的监控系统是如何监控到服务器d的各种性能计数器的，哪位大侠能给指导一下？

（2）有关c机的系统配置，如内存、处理器应该达到怎样的要求，要跟服务器d机相近吗？

（3）负载的数量是在Controller端输入的，那么a、b端如何读取c机的负载数量？

哪位大侠指导一下，谢谢。

文章出处：http://www.51testing.com/?41972
本次通过loadrunner录制Sql Server介绍一下如何测试一个sql语句或存储过程的执行性能。
主要分如下几个步骤完成：
    第一步、测试准备
    第二步、配置ODBC数据源
    第三步、录制SQL语句在Sql Server查询分析器中的运行过程
    第四步、优化录制脚本，设置事务
    第五步、改变查询数量级查看SQL语句的性能
    第六步、在controller中运行脚本。
下面开始具体的介绍：
    测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装SQL SERVER数据库服务端及客户端，也可以确定一台装好的SQL SERVER服务器。 接下来，准备测试数据：对数据库测试时我们要考虑的不是SQL语句是否能够正确执行，而是在某数量级的情况下SQL语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某SQL语句的执行效率。
    在查询分析器中运行如下脚本：
    --创建测试数据库
    create database loadrunner_test;
    use loadrunner_test
    --创建测试数据表
    create table test_table (username varchar(50),sex int,age int,address varchar(100),post int)
    --通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了
    declare   @i   int    
    set   @i=0    
    while   @i<1000    //循环1000次，可以根据测试数据情况改变插入条数  
    begin      
      BEGIN TRAN T1      
        insert into test_table (username,sex,age,address,post)
      values ('户瑞海'+cast(@i+1 as varchar),@i+1,@i+1,'北京市和平里'+cast(@i+1 as varchar)+'号',123456);        
      IF @@ERROR <> 0         
        begin           
          rollback;           
          select @@error         
        end      
        else
        begin  
          commit;           
          set   @i   =   @i+1         
        end      
    end
    好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置ODBC数据源，为了能让loadrunner能够通过ODBC协议连接到我们建立的SQL SERVER数据路，我们需要在本机上建立ODBC数据源，建立方法如下： 控制面板—性能和维护—管理工具—数据源（ODBC）--添加，在列表中选择SQL SERVER点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成ODBC的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。
    配置好ODBC数据源后就要录制SQL语句在查询分析器中的执行过程了：
    1、  打开loadrunner，选择ODBC协议
    2、  在start recording中的application type 选择win32 application；program to record中录入SQL SERVER查询分析器的路径“..\安装目录\isqlw.exe”
    3、  开始录制，首先通过查询分析器登录SQL SERVER，在打开的查询分析器窗口中输入要测试的SQL语句，如“select * from test_table;”
    4、  在查询分析器中执行该语句，执行完成后，结束录制。
    好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我QQ，我把脚本发给你们），通过这些语句，我们可以看出，登录数据库的过程、执行SQL语句的过程。
    接下来，我们来优化脚本，我们分别为数据库登录部分和执行SQL语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下：
Action()
{ 
       double trans_time;  //定义一个double型变量用来保存事务执行时间
       lr_start_transaction("sqserver_login");  //设置登录事务的开始
       lrd_init(&InitInfo, DBTypeVersion);   //初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）
       lrd_open_context(&Ctx1, LRD_DBTYPE_ODBC, 0, 0, 0);
       lrd_db_option(Ctx1, OT_ODBC_OV_ODBC3, 0, 0);
       lrd_alloc_connection(&Con1, LRD_DBTYPE_ODBC, Ctx1, 0 /*Unused*/, 0);
     ………………
       trans_time=lr_get_transaction_duration( "sqserver_login" ); //获得登录数据库的时间
       lr_output_message("sqserver_login事务耗时 %f 秒", trans_time); //输出该时间 
       lr_end_transaction("sqserver_login", LR_AUTO);  //结束登录事务
       lr_start_transaction("start_select");//开始查询事务
       lrd_cancel(0, Csr2, 0 /*Unused*/, 0);
       lrd_stmt(Csr2, "select * from test_table;\r\n", -1, 1, 0 /*None*/, 0);//此句为执行的SQL
       lrd_bind_cols(Csr2, BCInfo_D42, 0);
       lrd_fetch(Csr2, -10, 1, 0, PrintRow24, 0);
       ……………..
       trans_time=lr_get_transaction_duration( "start_select" ); //获得该SQL的执行时间 
       lr_output_message("start_select事务耗时 %f 秒", trans_time); //输出该时间
       lr_end_transaction("start_select", LR_AUTO); //结束查询事务
 
   
   优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。 接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有Mercury 授权的SQL SERVER用户license，在运行该脚本时回报错，提示“You do not have a license for this Vuser type. Please contact Mercury Interactive to renew your license.”我们公司穷啊买不起。 
    loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！ 最起码在VUGen中运行该脚本我们可以得到任意一个SQL语句及存储过程的执行时间，如果我们测试的B/S结构的程序，我们也可以通过HTML协议录制的脚本在CONTROLLER中监控SQL SERVER服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了。 本人对LOADRUNNER也是在摸索中，如果文章有写的不对，或理解错误的地方请指出，不甚感激。

文章出处：http://blog.csdn.net/cwj007/archive/2005/07/27/436466.aspx

场景介绍   

       最近在做类似于QQ的通信工具的性能测试时发现了一些问题，现总结出来与大家分享一下。希望大家在使用LoadRunner时不仅仅停在只是录制/播放角本，而全面提升角本的编程技术，解决复杂场景。

       本次测试中碰到的问题是这样的，在消息的传送过程中遇到了DEC加密的过程，LoadRunner录 制到的全是加密的消息，比如我录制了某一个用户的登陆，发送消息，退出，但由于是加密的，只能单个用户使用，但如果我想并发多少个用户就存在很多问题，最 直接的一个问题就是用户名是加密的，密码是加密的，当然你可以说让程序那里注掉加密的代码进行明码的测试，当然也是一种办法。但程序组提出了要使用更真实 的方法来模拟，这时就必需使用下面介绍的方法。

       一开始是直接把API移植到LoadRunner中来，不过由于加密算法异常复杂，有几层循环，而角本是解释执行的，进行一次加密运算可能需要好几分钟，当然在角本里可以把角本本身运行的时间去掉，但这样做显然没有直接调用DLL来的效率高。由于程序组比较忙，所以无法提供DLL给测试，所以测试完成了DLL的编写，并在LoadRunner中调用成功，高效的完成了用户信息加密，参数关联，成功的完成了测试。

动态链接库的编写
　　在Visual C++6.0开发环境下，打开FileNewProject选项，可以选择Win32 Dynamic-Link Library建立一个空的DLL工程。
　　1． Win32 Dynamic-Link Library方式创建Non-MFC DLL动态链接库

　　每一个DLL必须有一个入口点，这就象我们用C编写的应用程序一样，必须有一个WINMAIN函数一样。在Non-MFC DLL中DllMain是一个缺省的入口函数，你不需要编写自己的DLL入口函数，用这个缺省的入口函数就能使动态链接库被调用时得到正确的初始化。如果应用程序的DLL需要分配额外的内存或资源时，或者说需要对每个进程或线程初始化和清除操作时，需要在相应的DLL工程的.CPP文件中对DllMain()函数按照下面的格式书写。

　

BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved) { switch( ul_reason_for_call ) { case DLL_PROCESS_ATTACH:     break; case DLL_THREAD_ATTACH:     break; case DLL_THREAD_DETACH:     break; case DLL_PROCESS_DETACH:     break; default:     break; } return TRUE; }

　　

       参数中，hMoudle是动态库被调用时所传递来的一个指向自己的句柄(实际上，它是指向_DGROUP段的一个选择符)；ul_reason_for_call是一个说明动态库被调原因的标志，当进程或线程装入或卸载动态链接库的时候，操作系统调用入口函数，并说明动态链接库被调用的原因，它所有的可能值为：DLL_PROCESS_ATTACH: 进程被调用、DLL_THREAD_ATTACH: 线程被调用、DLL_PROCESS_DETACH: 进程被停止、DLL_THREAD_DETACH: 线程被停止；lpReserved为保留参数。到此为止，DLL的入口函数已经写了，剩下部分的实现也不难，你可以在DLL工程中加入你所想要输出的函数或变量了。

　　我们已经知道DLL是包含若干个函数的库文件，应用程序使用DLL中的函数之前，应该先导出这些函数，以便供给应用程序使用。要导出这些函数有两种方法，一是在定义函数时使用导出关键字_declspec(dllexport)，另外一种方法是在创建DLL文件时使用模块定义文件.Def。需要读者注意的是在使用第一种方法的时候，不能使用DEF文件。下面通过两个例子来说明如何使用这两种方法创建DLL文件。

　　1）使用导出函数关键字_declspec(dllexport)创建MyDll.dll，该动态链接库中有两个函数，分别用来实现得到两个数的最大和最小数。在MyDll.h和MyDLL.cpp文件中分别输入如下原代码：
　

//MyDLL.h extern "C" _declspec(dllexport) int desinit(int mode); extern "C" _declspec(dllexport) void desdone(void); extern "C" _declspec(dllexport) void des_setkey(char *subkey, char *key); extern "C" _declspec(dllexport) void endes(char *block, char *subkey); extern "C" _declspec(dllexport) void dedes(char *block, char *subkey); //MyDll.cpp #include"MyDll.h" //这里我用了比较大小的函数代替了我要实现的函数  int desinit(int a, int b) { if(a>=b)return a; else return b; } int desdone(int a, int b) { if(a>=b)return b; else return a; }

该动态链接库编译成功后，打开MyDll工程中的debug目录，可以看到MyDll.dll、MyDll.lib两个文件。LIB文件中包含DLL文件名和DLL文件中的函数名等，该LIB文件只是对应该DLL文件的"映像文件"，与DLL文件中，LIB文件的长度要小的多，在进行隐式链接DLL时要用到它。读者可能已经注意到在MyDll.h中有关键字"extern C"，它可以使其他编程语言访问你编写的DLL中的函数。

LoadRunner调用动态链接库

       上面完成动态链接库开发后，下面就介绍动态链接库如何被LoadRunner进行调用，其实也是很简单的。在LoadRunner中的DLL调用有局部调用与全局调用，下面介绍局部调用。

首先把你编译的DLL放在角本路径下面，这里是MyDll.dll,MyDll.lib.然后在Action中使用

lr_load_dll("MYDll.dll")，此函数可以把DLL加载进来，让你调用DLL里面的函数，而DLL中的运算是编译级的，所以效率极高，代码样例如下：

#include "lrs.h"

Action()

{

       //

       int nRet = 6;

       char srckey[129];

       memset(srckey, 'a', 128);

       lr_message(lr_eval_string(srckey));

       lr_load_dll("MyDLL.dll");

       nRet = desinit(5,8);

       lr_message("比较的结果为%d",nRet);

    return 0;

}

运行结果

       比较的结果为8

 

       全局的动态链接库的调用则需要修改mdrv.dat，路径在LoadRunner的安装目录下面（LoadRunner/dat directory）；在里面修改如例：

    [WinSock]

ExtPriorityType=protocol

WINNT_EXT_LIBS=wsrun32.dll

WIN95_EXT_LIBS=wsrun32.dll

LINUX_EXT_LIBS=liblrs.so

SOLARIS_EXT_LIBS=liblrs.so

HPUX_EXT_LIBS=liblrs.sl

AIX_EXT_LIBS=liblrs.so

LibCfgFunc=winsock_exten_conf

UtilityExt=lrun_api

ExtMessageQueue=0

ExtCmdLineOverwrite=-WinInet No

ExtCmdLineConc=-UsingWinInet No

WINNT_DLLS=user_dll1.dll, user_dll2.dll, ...

//最后一行是加载你需要的DLL

       这样你就可以在LR中随意的调用程序员写的API函数，进行一些复杂的数据加密，准备的一些操作，进行复杂的测试。同时如果你觉的有大量高复杂的运算也可以放在DLL中进行封装，以提高效率。

不过，今天又发现另一个链接，写的也不错：
http://www.cnitblog.com/tjitty/archive/2008/03/13/40891.html
对我很有帮助。

文章出处：http://www.51testing.com/?41972

Loadrunner关联（一）什么时候需要做关联

1.关联的含义

关联（correlation）：在脚本回放过程中，客户端发出请求，通过关联函数所定义的左右边界值（也就是关联规则），在服务器所响应的内容中查找，得到相应的值，已变量的形式替换录制时的静态值，从而向服务器发出正确的请求，这种动态获得服务器响应内容的方法被称作关联。

其实关联也属于一同特殊的参数化，只是与一般的参数化有些不同：

一般的参数化的参数来源于一个文件、一个定义的table、通过sql写的一个结果集等，但关联所获得的参数是服务器响应请求所返回的一个符合条件的、动态的值。

2.什么时候需要做关联

要想弄清这个问题，我们首先要知道客户端与服务器端的请求与响应的过程。

拿一个登录的过程我们来看一下，过程说明：

客户端发出获得登录页面的请求，

服务器端得到该请求后，返回登录页面，同时动态生成一个Session Id，

当用户输入用户名密码，请求登录时，该Session Id同时被发送到服务器端，

如果该Session Id在当前会话中有效，那么返回登录成功的页面，如果不正确则登录失败。

在第一次录制过程中loadrunner把这个值记录了下来，写到了脚本中，但再次回放时，客户端发出同样的请求，而服务器端再一次动态的生成了Session Id，此时客户端发出的请求就是错误的，为了获得这个动态的Session Id我们这里用到了关联。

所以我们得出结论：

当客户端的某个请求是随着服务器端的相应而动态变化的时候，我们就需要用到关联。

当然我们在录制脚本时应该对项目进行适当的了解，知道哪些请求需要用到服务器响应的动态值，如果我们不明确那些值需要做关联的话，我们也可以将脚本录制两遍，通过对比脚本的方法来查找需要关联的部分，但并不是说两次录制的所有不同点都需要关联，这个要具体情况具体分析。

Loadrunner关联（二）loadrunner中的自动关联

自动关联包含两种机制：

一种是loadrunner通过对比录制和回放时服务器响应的不同，而提示用户是否进行关联，用户可自己创建关联规则，这个功能可以方便的使我们获得需要关联的部分，但同时也存在一定的问题，如：自动关联所检测到的关联点不一定真的需要进行关联，这要我们更具实际情况进行判断；有些需要关联的动态数据自动关联无法找到，这是就需要做手动关联。

另一种是loadrunner自带的自动关联规则，在录制脚本时，会根据这些规则自动创建关联。

自动关联的步骤如下：

1.开启自动关联选项

刚才提到的两种关联机制，如果用户想使用loadrunner自带的关联规则创建关联，那么需要在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则，选中“Enable correlation during recording”，当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。也可以在【Recording Options】>【Internet Protocol】>【Correlation】中添加关联规则，达到自动关联的目的。

如果需要在回放脚本时，loadrunner自动检测需要关联的部分，那么需要在【Tools】>【general options】>【Correlation】中选中“save correlation information during replay”和“show scan for correlations popup after replay of vuser”，当回放玩脚本后，会弹出Scan action for correlation窗口，进行关联点的搜索。

 

2.录制脚本

录制脚本的过程在这里就不多说了。

 

3.回放脚本

如果录制的脚本存在需要做关联的部分，那么在回放脚本时会出现错误。

 

4.系统自动弹出检测关联对话框，或手动启动关联检测对话框

如果选择了【Tools】>【general options】>【Correlation】中的“save correlation information during replay”和“show scan for correlations popup after replay of vuser”，那么在回放脚本后会自动弹出“Scan action for correlation”窗口，点击“yes”进行自动查找。

如果没有选择上述设置，那么也可以按CTRL+F8启动关联自动搜索。

 

5.查看系统检测出的关联点进行关联设置

如果在录制和回放中存在差异，loadrunner会在“Correlation Results”中列出需要做关联的内容，用鼠标点击一条需要做关联的内容，点击“Create Rule”，系统会显示获得当前数据的规则，点击“yes”，完成规则的创建，同时查看脚本中增加了一个web_reg_save_param函数。

也可以点击【Correlate】按钮创建关联，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。

注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。

 

6.回放脚本检查关联的正确性

   创建好关联后，回放脚本检查关联的正确性。

Loadrunner关联（三）loadrunner中的手动关联

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

第一步：录制脚本，录制二遍。

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

第三步：确定插入关联的位置。51Testing软件测试网g.e/f0BX'l
第四步：在VIEW TREE中使用web_reg_save_param函数手动建立关联。

d_J.^8q)~T't74947第五步：将脚本中有用到关联的数据，用参数代替。

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

 

下面详细介绍：

第一步：

录制测试脚本，录制二遍

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

第二步：

使用WinDiff工具协助找出需要关联的数据
^9s7Zg1x#E749471. 在第二份脚本中，点选VuGen的【Tools】>【Compare with Vuser…】，并选择第一份脚本。
J$z NL[749472. 接着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。

 

第三步：

确认插入关联的位置

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

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

 

第四步：

插入关联函数

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

  一个web_reg_save_param函数的例子：

web_reg_save_param ("sessionid",

      "LB=Session_id:",

      "RB=;",

      "Search=Body",

      LAST);

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

语法说明：

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”中输入，刚才记录下的不同点字符串的左面的几个字符，定义左边界，Session_id:

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

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

点击“ok”

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

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

web_reg_save_param ("sessionid",

      "LB=Session_id:",

      "RB=;",

      "Search=Body",

      LAST);

 

第五步：

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

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

  web_submit_form("login.php_2",

      "Snapshot=t2.inf",

      ITEMDATA,

      "Name=login", "Value=wangjin", ENDITEM,

      "Name=password", "Value=wangjin", ENDITEM,

        "Name=Session_id","Value={ sessionid } ", ENDITEM,

      "Name=Submit", "Value=Login", ENDITEM,

      EXTRARES,

      "URL=/media/images/border_bg_l.gif", ENDITEM,

      "URL=/media/images/header_bg.gif", ENDITEM,

      "URL=/media/images/th.gif", ENDITEM,

      LAST);

 

第六步：

验证关联的正确性

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

文章出处：http://www.51testing.com/?41972

51Testing软件测试网

---

D7{

---

VEv%A;V
    虚拟用户已线程还是进程的方式运行，对被测服务器的压力是完全不同的，首先我们要知道在loadrunner中有3个地方涉及到虚拟用户的运行方式，分别是：
XwT5A!_+qr3m$BT749471、在Vug->run-time settings->miscellane->multithreading中可以设置虚拟用户是以线程还是进程的方式运行。
%]si7Ut
x?F749472、在controller中设置场景时，是以单场景模式运行还是以场景组方式运行，在这两种不同的运行方式下，虚拟用户的运行方式也是不同的。
Hj!HrS'o3R%d a749473、在controller中使用IP欺骗时，在专家模式下的tools->options->general->multiple IP address mode中也可以选择每个IP是以线程还是进程方式运行。

下面我们介绍一下这三个设置线程和进程之间的关系：51Testing软件测试网K9G#Y6K3|*`3hB

首先说一下run-time settings中的设置与controller中单场景和场景组的关系：2j8J#t Gi+^要记住虚拟用户是以线程还是进程方式运行是在Vug->run-time settings中设置的。

其次在controller中如果使用单场景运行，那么该场景中无论有多少个脚本、多少个负载生成器，运行这些脚本的虚拟用户均依照Vug->run-time settings中设置的线程还是进程方式运行51Testing软件测试网Az
T"O+}/DB。

但是如果在controller中如果以场景组方式运行时，每个场景组均会作为一个进程被启动，而每个组中的用户又是按照Vug->run-time settings中设置的线程还是进程方式运行。

再说一下在controller中使用IP欺骗时，在专家模式下的tools->options->general->multiple IP address mode中的设置：51Testing软件测试网#{
z"y(VA'nKT/X
如果选择的是进程方式：51Testing软件测试网O‑Ns5m
oc

---

JX
1、如果这个ip是在单场景中，那么有几个不同的ip的负载生成器就会启动几个进程，每个负载生成器的虚拟用户的运行方式仍然按照Vug->run-time settings中设置的线程还是进程方式运行51Testing软件测试网 i*Ww9?s

---

At­@。
2、如果是在场景组中运行，这就要看场景组是如何设置的了，有两种情况：51Testing软件测试网
H4PeJ#](D[1]X
a、每个场景组中添加一个虚拟ip，这时运行每个场景组时只启动一个进程。51Testing软件测试网
{2dZ.l1uK
b、每个场景组中添加多个虚拟ip，这时运行每个场景组时，每个场景组启动一个进程，每个ip启动一个进程，每个ip的虚拟用户的运行方式按照Vug->run-time settings中设置的线程还是进程方式运行。

如果在controller中使用IP欺骗时，在专家模式下的tools->options->general->multiple IP address mode中选择的线程方式：
0a O cJS'W*_
r'S?749471、如果这个ip是在单场景中，那么对于不同的ip的负载生成器只会启动一个进程，每个负载生成器的虚拟用户的运行方式仍然按照Vug->run-time settings中设置的线程还是进程方式运行
2、如果是在场景组中运行，每个场景组启动一个进程，所有ip已线程的方式在组进程中运行，每个ip的虚拟用户的运行方式按照Vug->run-time settings中设置的线程还是进程方式运行51Testing软件测试网9^3dIJLK

今天解决了一个报错的问题：
我用的是LR8.0，录制我们项目组软件（C/S架构的，采用web service协议）。
录制完，回放，总是报错：大体是wsdl文件不存在。
但我已经把那个文件下载下来了，很是纳闷。
四处寻求答案，终于，在论坛上发现了解决方式：
在wsdl management中将那个文件加载一遍，
问题解决！

 WSDL（Web Service Descrīption Language）Web服务器描述语言是用XML文档来描述Web服务的标准，是Web服务的接口定义语言，由Ariba、Intel、IBM、MS等共同提出，通过WSDL，可描述Web服务的三个基本属性：

·服务做些什么——服务所提供的操作（方法）

·如何访问服务——和服务交互的数据格式以及必要协议

·服务位于何处——协议相关的地址，如URL