LR：我可以使 LoadRunner 中的伪随机具有确定性吗？

Question

LoadRunner 场景中有几个随机源：

• rand () 函数
• 随机思考时间增量（运行时设置）
• 随机步调时间组件（运行时设置）
• 随机参数（作为 VUGen 测试的一部分）

I使用这些功能，我可以忍受它们的伪随机性。 然而，我不能接受这样一个事实：所有包含至少其中一个功能的场景运行都表现出伪随机和不确定性，即对于给定的开始状态（随机种子），我希望两次运行生成完全相同的负载，包括计时（节奏和思考时间）。 所以我希望两次运行基于完全相同的随机序列。 这意味着我想自己为所有随机生成器播种，作为每次运行初始化的一部分。

我可以使用 srand () 为 rand () 设置种子值。对于所有虚拟用户，在 init 时设置特定（硬编码）种子值始终会产生由 rand () 传递的相同序列。如果我使用 VUser ID 号作为种子，我什至会为每个 vuser 获得不同的 rand () 序列，而每个用户每次运行时它们仍然是相同的。

LR 中除了 rand () 之外的其他伪随机源怎么样？ 我是否有机会将它们全部播种，以便获得确定性的场景行为？

我认为这会有很大帮助。

如果没有这样的机制，人们就必须计划很长时间和/或非常高流量的测试场景，以便“平均”结果统计中的随机性（您同意这一点吗？），我一整天都在这样做。

Answer 1

已经覆盖了。我从 4.51 开始就开始使用 LoadRunner，不记得哪个版本不能设置随机种子。通常，这是在控制器中设置的场景运行时设置中。通过打开 Acrobat 版本的控制器用户指南并搜索术语“种子”，您应该能够找到适用于您的 LoadRunner 版本的相关文档。

Answer 2

对于像 Load runner 这样的系统来说，播种随机数生成器是必不可少的。完美的例子 - 我有一个代码更改我想测试。我播种随机数生成器，然后在使用或不使用更改的代码的情况下运行。执行的函数的顺序是随机的，但两个测试将使用相同的顺序。这使我能够看到代码更改的确切影响。如果无法看到随机数生成器，我将不得不在非常高的负载下运行很长时间的测试，以尝试平均随机性。

如果没有种子，第二次测试将选择完全不同的路径。在另一次迭代中，又是另一条完全不同的道路。我想要随机序列，但需要可重复的随机序列。这就是为什么所有现代语言都允许您播种随机数生成器。 Load Runner 客户端只需要添加一个文本字段，允许您输入随机数生成器的“种子值”。

Answer 3

您的问题的简短答案是：否。

Random implies just what it says => "Random". 

如果您使用参数的“内置”随机功能，您几乎会被搞砸，因为您无法控制内部随机种子的初始化方式，并且这无法以任何方式预测下一个值。

如果您最终想要实现的是推断结果并预测负载下的服务器行为，那么您将面临一条非常崎岖的道路。

推断结果

Your run with 100 vusers and achieve an avg. of 50-60 hits/sec with
response times under 3 sec.

Logically 1000 vusers (10x load) would give you 500-600 hits/sec ... 

But what about the response times? How do you extrapolate them? How do you know
when the web-server(s) chokes and achieves it's knee-point? 

请记住，每秒点击次数与响应时间成正比...因此预测每秒点击次数（或每秒页数）变得非常困难且不准确

您无法控制的事情< 即使您获得了另一次运行的“精确”副本，

您仍然必须处理响应时间和网络延迟，实际上，无论情况如何（并且完全超出您的控制范围），它们实际上总是不同的。

以更“现实”的方式定义负载

负载测试本身并不是一门精确的科学，没有负载测试可以完全模拟现实世界，但我们可以接近。我们在这里的做法是尝试尽可能接近地模拟单个用户。这样我们就可以根据用户类型设置负载期望，这是“业务”人员通常知道的。

我们还将“用户”分为不同类型，例如高级用户、普通用户或新手用户 - 这些用户的区别在于他们的操作速度（以及他们使用 UI 的方式）。

通过这样做，我们可以使用特定的“预期用户负载”而不是页数/秒或点击数/秒值或其他技术指标来“加载”目标应用程序。

我们还执行更长时间的运行，以了解服务随时间的变化情况，因此 72 小时或更长的测试对于耐力测试阶段来说并不罕见。这还显示服务器上是否随着时间的推移出现任何内存泄漏，以及后台进程在“夜间”期间如何影响服务器性能