一、虚拟用户迭代一次的时间对整个压力场景的影响。
1、虚拟用户迭代一次的时间大于等于压力场景的上行周期。
此种情况，在压力场景的上行周期中，所有虚拟用户根据压力场景设置的策略全部依次运行。压力场景的上行周期过后，进入虚拟用户运行的稳定期，因为此时第一个运行的虚拟用户尚未退出迭代。当第一个运行的虚拟用户退出迭代时，即进入运动期。在运动期中，会不断的有虚拟用户上线和下线，此起彼伏，但当前运行的总虚拟用户数与总虚拟用户数接近，实际中会有所偏差，偏差的数量与压力场景步长的设定以及脚本的睡眠时间有关。当场景设置的步长为0时，运动期的时间等于压力场景的上行周期，因为当步长设置为0时，意味着虚拟用户一上线便下线，这与他们上行的速率相等。运动期后，便又进入稳定期，因为运动其第一个运行的虚拟用户尚未退出迭代。如果结束时间点落在稳定期时，虚拟用户不会立即停止迭代，而是等到下一次的运动期时才会陆续退出运行。如果结束时间点落在运动期，当有虚拟用户退出迭代时，便将该用户下线，不会再进入下一次的迭代，因为运动期时刻都有用户上线下线，所以虚拟用户会按照压力场景设置的退出策略全部退出迭代。
2、虚拟用户迭代一次的时间小于压力场景的上行周期。
此种情况是没有稳定期的，虚拟用户的上线下线贯穿于整个压力测试始末。假设有100个虚拟用户，每秒钟上一个虚拟用户，如上图所示。在虚拟用户第一次迭代的时间里，前50个用户依次上线。在虚拟用户第二次迭代的时间里，第51个用户到第100个用户依次上线，同时，因为虚拟用户第一次迭代时间里的1到50个用户陆续下线和上线，所以当第51个用户上线时，第1个用户也上线，第2个用户下线；当第52个用户上线时，第2个用户上线，第3个用户下线。按照此种规律，在压力场景的上行周期中，后一次迭代时间里的虚拟用户上下线是前几次迭代时间里的虚拟用户的同步上下线。当进入压力场景的运行周期时，虚拟用户上下线是上行周期所有迭代时间里的虚拟用户的同步上下线，所以当进入运行周期时，第1个和第51个虚拟用户上线，同时因为第2个和第52个虚拟用户上一次迭代时间的结束，所以第2个和第52个虚拟用户下线。在下一秒时，第2个和第52个虚拟用户上线，第3个和第53个虚拟用户下线，以此类推。因为此种情况没有稳定期，时刻都有虚拟用户上线下线，所以当到达结束时间点时，虚拟用户会按照压力场景设置的退出策略全部退出迭代。值得注意的是，当进入压力场景的运行周期时，实际正在运行的虚拟用户总数接近与所有虚拟用户总数。他们的偏差与压力周期的上行周期与虚拟用户一次迭代的时间的商值有关，微观看来，在压力场景运行周期的某个时间点上，商值个数的虚拟用户正在上线，同时商值个数的虚拟用户正在下线，其余的虚拟用户正在执行迭代，当然这是理论状况，实际运行情况将会复杂得多，与脚本的逻辑和场景的设置有关系。
二、File参数化的设置。
上图中，将参数选择策略设定为Unique、Each iteration、Continue in a cyclic manner，意思是每次迭代时从File中选择参数(同一迭代内的相同参数取值一样)，每次都取不一样的参数，如果备选的参数全部选完，以循环的方式从头继续选择参数。我们更深入的挖掘一下，LoadRunner是如何做到上述策略的呢？做法是这样的，假设有10个虚拟用户，备选的参数有1000个，为了保证10个虚拟用户每次的取值不一样，将备选的1000个参数平均分为10等份，每一份分给一个虚拟用户。每个虚拟用户来取值时，都顺序取自己分得的Block，当达到Block的末尾时，再重头取值。注意，上述策略只有在迭代有效的情况下有效，即必须要选择下图中的第二个选项，否则当1000个参数被全部取光时，LoadRunner将会报错。
有时我们需要将两个参数一一对应，例如每个用户都有自己的用户名，即UserID参数和TrueName参数是一一对应的，如何实现参数的一一对应呢？做法是这样的，将这两个参数的数据源记录到一个参数表中，并将选择参数的策略设置为一样。
注意，上图中的记事本的最后一行必须为空行，否则LoadRunner会报“Missing Line”的异常。
三、场景设置。
1、步长的设置：
步长的设置会影响虚拟用户一次迭代中的Action之间的等待时间和该虚拟用户上次迭代和下次迭代的等待时间，不同虚拟用户之间的迭代等待时间是不受影响的。
2、压力场景上行策略设置：
上图设置的策略是每隔3秒上10个用户，不是3秒内陆续上10个用户。
3、其他设置。
停用日志：
设置思考时间：
错误处理策略和虚拟用户的运行策略：
网络速度控制策略：
