LoadRunner学习：RuntimeSetting、参数化、关联、（unfinished

在这里插入图片描述

LoadRunner RuntimeSetting

运行时设置
在Vuser中设置Run-time Settings
在这里插入图片描述

RunLogic：运行逻辑，决定了脚本真正执行逻辑， Init和End部分代码只能执行一次。决定脚本真正执行逻辑的意思是，在Run中的代码和Number of Iteration决定了真正运行的代码和迭代次数。在properities中可以选择Run中Action是顺序执行还是随机执行（如果随机执行可以自行配置每个Action中的概率。

讲讲insert block 块技术，可以单独控制每个块的迭代次数。下述示例图中即为Block1中Action1执行2次，Block0中Action2执行1次，整个Run再执行2次
Pacing（步长）：迭代间规则
默认：as soon as…: 每次迭代无间隔时间
After…：上次迭代结束后，再下次迭代开始之前，会有个等待时间
at…从上次迭代开始到本次迭代开始的时间

为什么需要设置pacing？⭐️

评价一个系统的性能，需要从两个视角去看待：客户端视角和服务器视角即用户视角和系统视角。
有下述性能需求：“要去系统的事务处理能力达到100个/秒”
当LoadRunner模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且收到响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的，
即对每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间，而处理时间是不可控的。如果我们想要在测试过程中维持一个稳定的每秒请求数RPS，只有一个方法，就是通过增加并发用户数的数量来达到这个目的。

而在测试中，通常会对场景设置一个持续运行时间（多次迭代），通过多个事务的取样平均值来保证测试结果的准确性，即测试场景是以迭代的方式进行的。

如果不设置pacing，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，就马上发送下一次请求。而LR中当客户将请求发出去之后，就开始计算响应时间，一直到收到响应。
这时，如果服务器处于忙碌状态，那么心情求就会驻留在服务器的线程中，并没有对服务器端产生真正的负载，这样这个计时就会变长，失去真正意义。

为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。

虽然性能测试通常从客户端活动的角度定义，但是应该以服务器为中心的视角看待。因此需要强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络。要评价软件系统真正的性能，所以必须排除其他一切因素对系统性能造成的影响。

think time：思考时间，模拟用户的等待时间

在这里插入图片描述
假设每个做完整个操作需要5s，做完之后停顿5s，思考如果要达到每分钟有6000个在线用户，共10台服务器，需要多少个虚拟用户？
-----> 一个用户操作加等待需要10s，即一个用户一分钟可以迭代6次，一次迭代对应两次web_url()请求，即一分钟12次请求
那么6000/12 = 500; 500/10 = 50个用户。