1、Start Vuser
ep1： Strat 100 Vusers :2 every 00:00:15(HH:MM:SS)
解释： 场景总共要跑100个虚拟用户，每15秒启动2个虚拟用户Vuser，总共需要12分30秒启动完100个虚拟用户
ep2：Strat 100 Vusers simultaneously
解释：场景在开始跑的那一秒同时出动100个虚拟用户。
2、Duration（持续时间）
ep: Run for 00:05:00（HH:MM:SS）
场景中的虚拟用户在场景中总共要不断的执行5分钟。（如果录制的时间执行一次只需要10秒钟，那么一个Vuser 在5分钟内执行某一时间就执行了几十次，100个Vuser在5分钟内的事件数就达到几千件）；
3、Stop Vuser
ep1：Stop all Vusers : 5 every 00:00:30(HH:MM:SS)
解释：当Vuser跑完了，怎么停止掉场景中的所有的Vuser呢？在这里是设置了每30秒中停止5个Vuser，100个Vuser需要10分钟全部停止。
ep2：Stop all Vusers simultaneously
解释：跑完场景后，设置同时停止所有运行中的Vuser。
在场景设置右侧的Interactive Schedule Graph 这张图反应的就是左侧的设置，可以对照着理解下。
在LR工具做性能测试中，最关键的一步是Controller场景的设计，因为场景的设计与测试用例的设计相关联，而测试用例的执行，直接影响最终的测试结果是怎么的，因此，我们每设计一种场景，就有可能是一个测试用例的执行（一个场景设计里面可以有多个脚本，场景计划方式可以按组方式，也可以按场景方式），如果场景的设计不正确或不合理，那也无谓在Analysis中结果分析了，对吧?
下面分享一下，在Controller设计场景时需要注意和理解的问题：
1、在场景中持续时间设置将覆盖Vuser迭代设置。这意味着，如果将持续时间设置为5分钟，那么，Vuser将继续在5分钟时间内运行尽可能多的迭代，即便运行时设置的迭代仅指定1次或2次。
2、在场景全局计划中的初始化Vuser活动的数量会影响超时值。例如，100个Vuser尝试初始化将比10个Vuser尝试初始化花费更长时间。LoadRunner将基于活动的Vuser的数量向指定的超时值中添加内部值。
3、VuGen在脚本中回放过程中将不执行lr_think_Times函数，因为这样将给服务器造成更大的压力。推荐在运行时设置中（Run-time settings）设置合理的思考时间，一般为3～5秒。
4、在场景中是否设置添加集合点以及集合点策略都会或多或少影响性能测试结果（前提条件是在脚本中有添加集合点函数），若场景中添加了集合点，测试结果中“每次点击次数”、“总点击次量”、“吞吐量”等数据都会比不添加集合点时多，而响应时间相对来说比较真实能够体现出压力测试的效果，特别是在用户数比较多时做并发。
下面分享一下，在Controller设计场景时需要注意和理解的问题：
1、在场景中持续时间设置将覆盖Vuser迭代设置。这意味着，如果将持续时间设置为5分钟，那么，Vuser将继续在5分钟时间内运行尽可能多的迭代，即便运行时设置的迭代仅指定1次或2次。
2、在场景全局计划中的初始化Vuser活动的数量会影响超时值。例如，100个Vuser尝试初始化将比10个Vuser尝试初始化花费更长时间。LoadRunner将基于活动的Vuser的数量向指定的超时值中添加内部值。
3、VuGen在脚本中回放过程中将不执行lr_think_Times函数，因为这样将给服务器造成更大的压力。推荐在运行时设置中（Run-time settings）设置合理的思考时间，一般为3～5秒。
4、在场景中是否设置添加集合点以及集合点策略都会或多或少影响性能测试结果（前提条件是在脚本中有添加集合点函数），若场景中添加了集合点，测试结果中“每次点击次数”、“总点击次量”、“吞吐量”等数据都会比不添加集合点时多，而响应时间相对来说比较真实能够体现出压力测试的效果，特别是在用户数比较多时做并发。