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个用户。

• 日志
• 附加参数：自定义一些参数，再在脚本中传值
  如下为设置和使用示例：
  

• 线程模式/进程模式
• 模拟网速
• …

参数化与其他脚本增强技术

• 参数化：实现不同用户的不同请求，逻辑相同，数据不同的操作。
• 关联：用来解决请求之间的依赖
• 事务：用来度量操作的响应时间以及最终TPS
• 检查点：用来判断脚本是否成功
• 思考时间：模拟用户延迟，调节负载压力
• 集合点：模拟用户并发，是用来实现严格的并发

select next row:

• 顺序取值
• 随机取值
• 唯一取值

update：

• 每次迭代：
• 每次出现：
• 仅一次：

关联技术

解决请求之间的依赖。
在测试工具中，关联就是把某些写死的数据编程来自服务器的、动态的、每次不一样的数据 动态保存下来，然后在调用的地方调用即可
需要做关联处理的特征：

• 关联数据一定是来源于服务器的响应
• 关联数据一定要在后面的请求中被用到
• 关联数据一定是动态变化的

在LR中，关联的方式分为自动和手动两种

• 自动：
• • 录制关联（没用
• • 回放管理：理论上同样是对比法（慎用 成功率低
• 手动：根据关联产生的原因，关联数据特征，以及业务熟悉程度来完成先存侯勇的操作
• • 对比法
• • 追溯法：依据关联的特征、数据特征逆向完成

手动关联的步骤：
1 找出出错的请求：
2 设置关联

todotodo

---

手动编写脚本 占坑
场景与结果分析 占坑

jmeter复习 占坑