Run-TimeSettings设置
Run-TimeSettings设置主要是用于设置在脚本运行过程中脚本运行的策略。在菜单Vuser中选择Run-TimeSettings或按快捷键F4，如图所示。需要注意的设置项有：RunLogic选项卡、Pacing选项卡、ThinkTime选项卡和Miscellaneous选项卡。
Run Logic选项卡
RunLogic选项卡主要是用来设置运行时脚本迭代的次数，可以通过更改Numberofiterations的值来设置迭代的次数，如图所示，
修改NumberofIterations的值只对Run部分的脚本迭代次数有影响，而对Init和End部分的脚本迭代次数并没有影响。在调用脚本时，经常会设置不同的值来查看参数的迭代过程，当脚本调试成功后，在场景中运行时，该项值一般设置为1-3次，但并没有强制一定需要设置为多少，设置值的多少只会影响在单位时间内客户端向服务器提交的HTTP
请求数。其它的没有影响。
Pacing选项卡
Pacing选项卡主要用来设置脚本迭代过程中脚本之间的时间间隔，如在第N次脚本迭代完成后，等待5秒钟后进行第N+1次脚本迭代，如图所示。
Assoonasthepreviousiterationends：
在多次迭代时，上一次迭代执行结束后马上执行下一次迭代，如图所示。
Afterthepreviousiterationends：
可以设置为Fixed或Random方式。Fixed方式表示上一次迭代执行结束后，等待一个固定时间后，再执行下一次迭代；Random方式表示上一次迭代执行结束后，等待一个随机时间后，再执行下一次迭代，随机时间范围为设置的范围。例如把迭代时间设置为固定的6秒，其运行的结果如图所示。
AtFixed/Randomintervals：
表示上一次迭代开始到下一次迭代开始之间的时间间隔，如果设置的时间达到后无论上一次迭代执行是否完成，到达规定的时间就开始执行下一次迭代，包含Fixed和Random两种方式。Fixed表示一个固定的时间长度；Random表示一个随机的时间长度，随机值范围为设置的范围。照样把迭代的时间设置为6秒，结果如图所示，由于第一次迭代需要时间运行，所以第一次迭代结束后不到6秒就开始进行第二次迭代。
综合三个选项，可以看出第一种选择“
Assoonasthepreviousiterationends”对服务器的压力最大，因为这个选项在单位时间内所做的业务数最多，即单位时间内提交的请求数最多，所以服务器的压力最大，所以如果在进行压力测试时，希望尽快找到性能缺陷，那么需要选择该选项。
Think Time选项卡
ThinkTime选项卡用来设置用户操作的思考时间（思考时间是指每个HTTP请求之间的时间间隔），如图所示。
Ignorethinktime：
运行脚本时忽略思考时间，即上一个HTTP请求结束后，直接运行下一个HTTP请求，不进行等待。
Replaythinktime：
设置脚本回放时思考时间，包括Asrecorded、Multiplyrecordedthinktimeby
和Userandompercentageofrecordedthinktime三种方式。
Asrecorded：
按录制时的思考时间来回放，即如果录制时思考时间为5秒，那么回放时也按5秒来计算，如图所示。
Multiplyrecordedthinktimeby：
根据录制时思考时间的整数倍来运行，如设置为2倍，运行结果如图所示。
Userandompercentageofrecordedthinktime：
分别设置一个最大值和一个最小值，并从中选出一个随机值。在实际使用过程中一般会选择这种模式，设置最小值为50%，最大值为150%，运行的结果如图所示。
Limitthinktimeto：
设置thinktime的最大值。如果上面的设置项，在回放时使用的思考时间超过所限制的时间，那么以该限制时间为准进行回放，如图所示。
综上几种情况，当设置为忽略思考时间时，对服务器的压力最大，因为在同样的场景执行时间内，HTTP请求之间的时间缩短说明向服务器提交的请求数增多了，所以服务器的压力增加，如果进行压力测试时，可以选择该项设置。
Miscellaneous选项卡
Miscellaneous选项是一个复合选项，涉及到的功能比较复杂。
如图所示。
这里包括三个设置项：ErrorHandling、Multithreading和AutomaticTransactions。各项设置的含义如下：
ErrorHandling选项：表示脚本运行出现错误时所采取的措施，默认使用缺省值。
Multithreading选项：表示运行时把虚拟用户当作进程还是线程来处理。RunVuserasaprocess表示把虚拟用户当作进程来处理；RunVuserasathread表示把虚拟用户当作线程来处理。在工作如何选择设置该选项呢？在工作中应该分析系统在客户端是与进程还是线程运行，如果是以进程的方式运行，则将该选项设置为以进程的方式运行，反之则应该设置为以线程的方式运行。
注意：当以进程方式运行虚拟用户时，在负载机中的任务管理器中可以看到，每个虚拟用户都会产生一个进程，进程名为mmdrv.exe，如图所示。如果以线程的方式运行时，任务管理器中则不会有这个进程，并且每个进程都需要消耗资源，通过这项数据可以计算出每台负载机最多可以并发多少虚拟用户数。
AutomaticTransactions选项：设置事务的模式。Defineeachactionasatransaction：将一个action看作一个事务；Defineeachstepasatransaction：将每一个操作步骤看作一个事务。
Log选项卡
Log选项卡主要是用于设置脚本回放时的日志格式，如图所示。
LoadRunner一共包括四类日志文件：
ReplayLog（回放日志）、RecordingLog（录制日志）、CorrelationResults（关联结果）和GenerationLog（生成日志）。
ReplayLog是脚本回放时LoadRunner记录的日志信息，包括客户端与服务器之间的通信的日志和HTML源码录制时的快照信息，但该日志信息的内容取决于Log选项卡中的【Extendedlog】选项的设置情况。
RecordingLog提示录制脚本时产生的日志，主要是客户端和服务器端通信时的一些交互信息。
CorrelationResults是当脚本需要关联时，在回放脚本过程中会记录录制和回放时需要关联内容的值。
GenerationLog是在录制完脚本后，LoadRunner会调用相关协议函数，将录制的内容描述成LoadRunner脚本时产生的日志，LoadRunner录制脚本的时候会先把录制的内容保存在一个临时目录中，等录制完成后再调用相关的函数读取临时目录中的内容生成脚本，其内容包括HTML源码的快照信息。
Log选项卡主要是针对脚本回放时日志信息格式进行相关的设置。
Enableloggin：设置日志是否生效，也即在场景运行过程中是否收集日志信息。
Sendmessagesonlywhenanerroroccurs：指当脚本回放时出现错误信息时才收集日志，也即只收集错误日志信息。
Alwayssendmessages：收集所有日志信息，不管是正确的还错误的日志信息。
关于日志信息的收集有两种：
一种是使用标准日志信息（缺省值为标准日志）；二是扩展日志信息；
关于扩展日志信息包含三种：
Parametersubstitution、Datareturnedbyserver、Advancedtrace。
Parametersubstitution
表示客户提交给服务器端的所有参数会记录在日志文件中。
Datareturnedbyserver
表示不仅包括Parametersubstitution的信息还包括服务器返回到客户端的信息也会被记录。
Advancedtrace
表示所以有客户端提交和服务器返回的信息都会被记录。一般情况将日志信息设置为扩展的Parametersubstitution即可，如果选择其它的两种，那么产生的日志信息会很多，这样日志文件很大。
脚本完善
脚本录制完成并不代表这些脚本很接近用户的真实使用情况，为了使这些脚本更接近用户的真实使用情况，需要对脚本进行完善。
首先，为了衡量服务器对某个动作处理的响应时间，需要定义事务（Transaction）。例如在脚本中有一个登录动作，为了衡量多用户同时执行登录服务器的响应时间，可以将此操作定义为一个事务。LoadRunner运行到事务开始点时即开始计时，直到运行至该事务结束点结束计时。这个事务的运行时间在结果中会反映出来，LoadRunner对插入事务的个数没有限制。
其次，为了衡量加重负载的情况下服务器的性能情况，需要插入集合点。例如为了模拟30个用户同时登录的情况，做到真正的并发，就必须添加一个集合点，用来衡量服务器的性能。
最后，在录制脚本的过程中添加注释，因为录制完成之后都是代码，在操作一些复杂的业务时，可能很难一下找到相应的位置进行像参数化一类的动作，这时，注释显得很重要。同时添加注释也可以增强脚本的可读性，方便其他的工程师阅读。
插入事务
在测试过程中如果希望获得用户一系列操作的响应时间就需要插入事务，所以事务也即是客户要实现的业务。事务响应时间则是指在测试过程中一系列的请求完成后，所花费的时间。
事务响应时间的原理是将业务操作结束时的时间点减掉业务开始时的时间点，得到的差值就是事务响应时间，事务响应时间直观反馈了业务的响应时间，所以事务有两部分组成：一是开始事务函数；二是结束事务函数。
插入事务有两种方法：一种是在脚本录制过程中插入开始和结束事务点；另一种是在编辑脚本时插入开始和结束事务点。一般情况下选择在脚本录制过程中插入开始和结束事务点。这样做有两个优点：第一，保证不会遗漏需要插入的事务点；第二，避免在脚本录制完成后找不到确切的插入事务点的地方，对于有经验的性能测试工程师这可能不是问题，但是对于一个新手很有可能无法确切地找到插入事务点的位置。
方法一：在脚本录制过程中插入开始和结束事务点
当脚本录制到需要插入事务点时，在录制工具栏中点击“插入开始事务点”按钮，如图所示。在弹出的“开始事务”对话框中输入开始事务名称，如图3-35所示。事务点名称的格式应该保持统一，使其具有代表性，遵守脚本编辑命名规则。
事务的开始点与事务的结束点具有一一对应的特点，即在脚本中插入了一个事务开始点后一定要在接下来的过程中插入事务结束点，插入结束事务点与插入开始事务点的操作一致，当该业务流程执行完毕后需要添加结束事务点，在录制工具栏中点击“插入结束事务点”按钮，如图3-36所示。在弹出的“结束事务”对话框中输入结束事务名称，一般在下拉框中选择，因为下拉框中包含了所有开始事务点的名称，如图所示。
方法二：在脚本录制完成后插入开始和结束事务点
在生成的脚本中找到要插入开始事务点的地方，选择菜单Insert→StartTransaction（Ctrl+T），如图所示。在弹出的“开始事务”对话框中输入开始事务的名称，如图所示。
插入结束事务点的过程与插入开始事务点的步骤是一致的，在生成的脚本中找到要插入结束事务点的地方，选择菜单Insert→EndTransaction（Ctrl+T），如图所示。在弹出的“结束事务”对话框中输入结束事务的名称，如图所示。
在“结束事务”对话框中，比在脚本录制过程中插入结束事务点时的“结束事务”对话框中多出一项TransactionStatus，其事务状态有四种可选：LR_AUTO、LR_PASS、LR_FAIL和LR_STOP。
LR_AUTO：事务的状态被自动设置，如果事务执行成功，状态设置为PASS；如果事务执行失败，状态设置为FAIL；如果事务异常中断，状态设置成STOP。
LR_PASS：
事务执行成功，代码返回的状态是PASS。
LR_FAIL：
事务执行失败，代码返回的状态是FAIL。
LR_STOP：
事务异常中断，代码返回的状态是STOP。
那么为什么需要事务状态呢？因为在测试过程中不单需要获取事务的响应时间，还需要确定业务是否成功，如果事务响应时间很短，但是事务都失败了，这样的系统性能也是无法满足客户需求的，所以需要通过事务的响应时间来标示业务是否成功。在结果分析器中也有一项是关于结束事务状态的，如图所示。
需要注意的是，在结果分析器中，结束事务状态并没有自动的状态，因为在脚本中设置自动化状态后，LoadRunner会自动判断事务运行后的结果是否正确。
但有一个问题需要注意，当在脚本中把结束事务设置为自动化时，LoadRunner真的能正确的判断事务运行的状态吗？LoadRunner自动化判断事务状态的原理是什么呢？下面来通过一个试验来验证一下这个问题，录制一个登录的脚本，以飞机订票系统的登录为例：
先录制一个正常的脚本，并且插入一个事务，事务的结束状态设置为AUTO，录制好的脚本如下：
web_reg_save_param("WCSParam2",
"LB/IC=userSessionvalue=",
"RB/IC=>",
"Ord=1",
"Search=Body",
"RelFrameId=1",
LAST);
…
lr_start_transaction("login");
lr_think_time(10);
web_submit_data("login.pl",
"Action=http://127.0.0.1:1080/WebTours/login.pl",
"Method=POST",
"RecContentType=text/html",
"Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home",
"Snapshot=t9.inf",
"Mode=HTTP",
ITEMDATA,
"Name=userSession","Value={WCSParam2}",ENDITEM,
"Name=username","Value=test1",ENDITEM,
"Name=password","Value=1",ENDITEM,
"Name=JSFormSubmit","Value=off",ENDITEM,
"Name=login.x","Value=46",ENDITEM,
"Name=login.y","Value=6",ENDITEM,
LAST);
…
lr_end_transaction("login",LR_AUTO);
回放这个脚本时，事务的结束状态为PASS，这是正确的，因为这个脚本是可以正确的登录，但现在将脚本修改一下，将提交用户名与密码的请求，修改为登录不成功的帐号与密码，代码修改后如下：
web_submit_data("login.pl",
"Action=http://127.0.0.1:1080/WebTours/login.pl",
"Method=POST",
"RecContentType=text/html",
"Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home",
"Snapshot=t9.inf",
"Mode=HTTP",
ITEMDATA,
"Name=userSession","Value={WCSParam2}",ENDITEM,
"Name=username","Value=gabbdfbegerfdsf",ENDITEM,
"Name=password","Value=1",ENDITEM,
"Name=JSFormSubmit","Value=off",ENDITEM,
"Name=login.x","Value=46",ENDITEM,
"Name=login.y","Value=6",ENDITEM,
LAST);
回放脚本后，发现回放日志中还是显示事务的结束状态为PASS，但在LoadRunner的Run-TimeViewer窗体中看到并未登录成功（因为如果登录成功，该页面会显示当前登录的用户名），如图所示，当然这个帐号就是不可能登录成功的。
从这个例子中可以看出，事务结束状态为PASS并不代表业务一定做成功了，之所以会出现这种情况是因为LoadRunner在自动判断事务结束状态时是以结束函数是否运行为标准，即只要结束事务函数运行，那么就将事务的结束状态置为PASS，反之将事务的结束状态置为FAIL。
那么再回到这个例子，正常的情况应该是登录后，先检查登录的帐户名是否正确，如果检查到正确后才将事务的结束状态置为PASS，这样才能保证业务成功了。所以一般情况下都需要先设置检查点后，再根据检查点来判断事务是否成功，这样才比较合理，关于使用检查点来判断事务是否成功，在后面的章节中会详细介绍。
插入集合点
集合点是指在脚本中插入集合点函数（LoadRunner中使用的集合函数为lr_rendezvous），当脚本运行到集合点函数时，将停止运行并等待其允许运行的条件（其允许的条件即为集合点策略）达到后才释放集合点开始运行。也即在性能测试过程中如果需要保证虚拟用户真正并发，那必须添加集合点。
集合点可以在脚本录制过程中插入，也可以在脚本录制完成后插入，但需要注意的是，集合点只能插入Action部分的脚本中，不能插入vuser_int和vuser_end两部分脚本中。
方法一：在脚本录制过程中插入集合点
在脚本录制过程中，当录制到需要插入集合点的位置时，点击录制工具栏中“插入集合点”按钮，如图所示。
方法二：在脚本录制完成后插入集合点
在脚本录制完成后，找到脚本中需要插入集合点的位置，选择菜单Insert→Rendezvous，如图所示。
在“集合点”对话框中，输入集合点名称，如图所示，和定义事务点名称一样，集合点名称应该保持统一，使其具有代表性，遵守脚本编辑命名规则。
插入注释
注释可以在录制脚本过程中插入，也可以在脚本录制完成后插入。
方法一：脚本录制过程中插入注释
在脚本录制过程中，当需要对录制的脚本进行注释时，点击录制工具栏中“插入注释”按钮，如图所示。
方法二：脚本录制完成后插入注释
脚本录制完成后，在脚本需要插入注释的地方，选择菜单Insert→Comment，如图所示。 
在弹出的“插入注释”对话框中，输入要注释的内容。
如图所示。
来源：oschina
链接：https://my.oschina.net/u/4398646/blog/4497753