编译整理｜TesterHome社区
作者｜Roger Durham
概括：虽然传统的“封闭系统”模型可能看起来很熟悉，但它们忽略了真实用户到达的不可预测性。本文重点介绍了模拟真实用户行为的开放系统模型如何暴露高负载下的性能瓶颈，而封闭模型无法捕捉到这些瓶颈。请记住，到达率，而不是虚拟用户数量，才是获得准确负载测试结果的关键。
以下为作者观点：
负载测试是质量保证过程的一部分，旨在帮助预测计算机系统在生产中的表现或帮助预测拟议的更改的性能影响。
这需要让被测系统承受合成的、可预测的负载，然后测量其性能。此负载应合理模拟系统在生产中将遇到的工作。负载几乎总是由自动化测试脚本生成，旨在模拟一组人员执行一项或多项特定任务。
在执行负载测试时，我们会按计划向系统提交这些任务。描述和实施该计划是本文的重点。
许多负载测试工具都基于“封闭系统模型”。这种系统的一个思维模型是工厂，当哨声响起时，固定数量的工人就会开始工作。工人的到来由一些外部事件同步，并受到用户数量的限制。
另一种思维模型是“开放系统模型”，其中每个用户独立决定何时开始一项任务。这种时间表是我们在实际系统中看到的最常见的到达分布，可以通过所谓的“泊松到达过程”进行统计建模。泊松开放系统模型的优点在于它会产生一个易于衡量且与业务目标明确相关的简单数字。这个数字就是到达率：单位时间内到达的平均人数。
到达时间的不规则性对系统性能有重要影响。为了说明这一点，我将展示一系列模拟负载测试，并列比较基于开放系统模型和封闭系统模型的测试。这些是单个服务请求（例如，单个网页加载）的模拟，服务时间来自随机分布。我将展示在两种模型下增加负载的非常不同的效果。
对于开放系统模型测试，我将使用一个时间表，该时间表通过从均匀随机数生成器中抽取所需的到达时间数来创建，以便时间轴中的每个时刻都有同等的可能性被选中。这很容易实现，保证了测试期间到达次数的可预测性，并且是泊松过程的良好近似值。我将这些模拟标记为“到达率”。
对于封闭系统模型测试，我将使用固定数量的虚拟用户，每个用户重复执行任务，直到测试结束。我将调整虚拟用户的数量，以获得与配对开放模型测试大致相同的任务数量。我将这些模拟标记为“VU”（虚拟用户）。
每个模拟结果将以包含一对图表的图形呈现（见下图）。在主图中，横轴是模拟时间（以秒为单位），而左侧纵轴（蓝色）是观察到的并发度（任何时间点系统中处于活动状态的任务数）。右侧纵轴是每个任务所消耗的时间，包括等待时间和活动服务时间，每个已完成的作业都有一个标记（红色）。
每个图中较小的图表是所有任务的任务时间分布，其中斑点的宽度与花费该时间的任务数量成正比。我在任务时间的最小值、平均值和（黑色）第 95 个百分位数处添加了线。我强调第 95 个百分位数，因为它是绩效衡量中最常见和最有用的汇总数字。
我将展示，当我们模拟的负载水平低于测试系统的容量时，模型之间的差异很小，但当我们接近并超过系统容量时，差异就会变得很大。封闭模型 VU 测试可能会错过灾难性的系统过载，而开放模型测试可以准确预测。
轻负载
当模拟负载远低于系统容量时，预测的任务时间不会有太大差别。
图1
图 2
并发性（系统中任何时刻的任务数量）的变化明显更大，这导致任务时间略有增加。在到达率测试中，有时并发性大于系统容量，导致短暂的减速；这不会发生在基于 VU 的测试中，因为并发性受 VU 数量的限制。
满负荷
当系统满负荷工作时，我们看到系统模型的选择对负载测试结果有很大的影响。
图 3
图 4
在达到（或接近）满负荷时，测试的服务器在处理随机峰值工作负载时会遇到麻烦；开放系统模型测试表明，服务器有时会落后，导致并发任务数量级联增加。该测试预测平均值会增加，尤其是任务时间的变化；第 95 个百分位数是配对 VU 测试的两倍多。
在封闭系统模型测试中，这些工作负载峰值会被从测试中剔除，因此系统似乎可以顺利运行，预测性能与轻负载系统非常相似。查看基于 VU 的负载测试结果会误导我们认为在这种负载水平下一切都很好。事实上，系统处于故障边缘，性能低于标准。
超载
图 5
这项到达率测试表明系统明显超出容量。未完成任务的数量不断增加，并且会持续增加，直到出现故障。随着测试的进行，任务时间越来越长。
图 6
与之前的图表相比，VU 测试显示任务时间有所增加，因为任务正在等待服务。你可以在图表中看到任务在测试开始时堆积起来，然后按照与之前的 VU 测试相同的模式执行。但是，系统实际上从未陷入过载。由于每个虚拟用户都等待前一个任务完成后再开始下一个任务，因此负载测试已将自身限制在系统容量范围内。由于这种自动限制行为，使用 VU 系统进行系统过载的实际测试非常困难。
上述结果显示了使用封闭系统模型构建负载测试的一些危险。我们知道大多数现实世界的系统更适合开放系统模型，因此除非有充分的理由相信你处于封闭系统环境中，否则我们建议使用开放系统模型进行负载测试。
我们的第一个建议是从到达率的角度来讨论工作负载。如果实际工作负载最好用开放系统模型来表示，那么最好使用到达率来描述工作负载。不要使用虚拟用户数量，因为这可能会产生误导。
我们的第二个建议是，对任何基于 VU 的负载测试的结果都要非常谨慎。这样的测试可能会导致过于乐观的性能预测，并可能错过更好的测试会预测到的故障。
我们的第三个建议是使用基于到达率的工具（如 Tsung 或 Gatling）进行负载测试，或者采用 VU 系统进行到达率模拟。如果使用的是流行的 JMeter 工具，该工具从本质上讲是基于 VU 的，则可以使用插件（Precise Throughput Timer 和 Open Model Thread Group）有效地将其转换为基于速率的工具。如果使用的是基于 VU 的系统，但缺少基于速率的调度选项，则可以通过根据基于速率的调度延迟每个任务的启动来获得到达率调度的效果。（原文链接：https://www.stickyminds.com/article/don-t-let-load-testing-lead-you-astray）
2.原生鸿蒙，真正独立！部分应用只有基础功能，原因是必须进行大量稳定性测试？
3.招聘｜美团--高级测试开发工程师(客户端&服务端方向)，base北京
