工作原理：基于目标的负载测试

LoadView 基于目标的负载测试是一种智能测试工具，可针对目标数量的事务进行测试，并自动调整所有必要的测试参数，例如用户负载和测试持续时间。

在 LoadView 中，事务表示一个测试脚本（测试示例），其中可能包括一个或多个用户作，例如导航到“联系我们”页面、填写表单并提交表单。 Transaction Goal 表示您的网站每分钟可以处理的这些事务的数量。

测试算法解释

为了达到每分钟所需的 事务数 并考虑目标服务器和应用程序性能的潜在波动，LoadView 会分多个周期执行测试。 此迭代过程将一直持续，直到预先确定的 Test Duration 结束。

在每个周期中，系统执行以下步骤。

1. 开始用户负荷计算（仅在第一个周期中）

为了匹配指定的 Transaction Goal，根据设置的 Transaction Goal 和 在测试验证期间执行的单用户测试运行测量的响应时间来计算初始并发用户数：

开始用户负载 = 每分钟的事务目标数 × 验证响应持续时间

2. 负载生成

系统根据计算结果生成虚拟用户负载。

3. 评估每分钟实现的交易数量与交易目标

在完成第一个测试周期后，系统将计算该周期内每分钟的实际事务数。然后，系统根据当前周期的平均响应持续时间 （Avg. Response Duration） 检查生成的并发虚拟用户数是否与所需的 Transaction Goal 匹配。

如果此数字与所需的 Transaction Goal 不匹配，则使用以下公式调整下一个周期的 User Load ：

用户负载 = 每分钟的事务目标 × Avg。 响应持续时间

其中， Avg。 响应持续时间 计算为当前周期测量的平均响应时间。为了确保准确性，测试脚本在每个周期内执行多次，执行次数由 Adjustment Rate 测试参数定义。

真实示例

为了解释它在现实生活中的工作原理，让我们看看下面的报告，其中 Transaction Goal （事务目标） 设置为每分钟 2,000 个事务 （TPM），验证响应持续时间为 0.18 秒。

第一个周期的建议起始用户负载计算如下：

启动用户负载 = 2000 个 TPM × 0.18 秒 = 377 个并发虚拟用户。

第一周期：初步评估

在第一个测试周期中，LoadView 实现了 1,176 个 TPM，低于 2,000 个 TPM 的目标。记录的平均响应时间 （平均响应持续时间） 为 19.39 秒。根据此数据，系统使用以下 公式重新计算下一个周期所需的用户负载：

用户负载₂ = （2000 / 60） × 19.39 ≈ 646 个并发虚拟用户

第二个周期：调整用户负载

在第二个周期中，用户负载增加到 646 个并发虚拟用户。但是，目标服务器响应时间开始增加（如 Response Time 图表上的第一个箭头所示）。这种增加导致平均响应持续时间更高，为 32.39 秒。

尽管用户负载增加，但系统仍然只实现了 1,176 个 TPM。这表明事务率没有随着额外的负载而提高。

第三和第四个周期：进一步的调整和观察

LoadView 重新计算了第三个周期的用户负载：

用户负载₃ = （2000 / 60） × 32.39 ≈ 1079 个并发虚拟用户

在第三个周期中，响应时间继续与用户负载的增加成比例增长。在第四个周期中，服务器响应时间继续随着用户负载的增加而增加，这与前几个周期观察到的趋势相同。此模式表明，随着添加更多用户，服务器性能会下降，从而阻止 LoadView 达到所需的事务目标。

此示例显示，即使用户负载较高，响应时间的显著增加也可能表明需要解决服务器或应用程序性能问题以实现所需的事务目标。