在进行性能测试时，我遇到的问题之一是试图将真实世界的 Web 应用程序流量转换为模拟流量。
一个实际的例子是电子商务网站。在电子商务网站上的用户体验期间，他们将在购物车中添加和删除商品、登录和/或编辑他们的联系信息、更新他们的运输信息和偏好、应用付款和显示收据，或者在某些情况下，产品供下载。
例如，客户报告一个小时内创建的购物车总数为 1000，而在 24 小时期间内创建的购物车总数为 10000。并非所有购物车都已完成，但所有购物车都已完成在履行或放弃之前通过上述某些步骤。假设每页的“思考时间”约为 30 秒。
这完全是“我想不到的”场景，与现实生活中的情况无关，它更多的是试图找到一个通用的“经验法则”来确定要使用多少虚拟用户。过去，当我做出判断时，我很难证明我使用的数字是正确的。在上面的例子中，我的判断将基于吞吐量。一个小时内完成了多少购物车？如果这个数字是 400，那么通过反复试验，我可以配置一些虚拟用户，这将近似于每小时完成的购物车数量。
这一切仍然基于猜测工作，背后的推理没有任何具体的内容。那么，如何确定在负载测试中配置的并发虚拟用户数以测试上述负载的性能？
好的，所以 Tristann 好心地修改了他原来的问题，以包含更多关于场景的细节。所以我添加了第二个答案来更直接地解决它。
首先，您可能想再问一些关于客户最关心什么以及他们想要测试什么的问题，这里有一个小样本：
这些问题的答案将用于确定您需要多少不同的购物场景，以及如何定制思考时间，以及随机化它们时使用的范围。正如您开始看到的，看起来我们至少需要三个场景，第一次购物者、返回购物者、废弃购物车。并且您将了解每个场景需要搜索多少物品并将其放入购物车等。
让我们组成一些答案，并专注于回头客的场景。在“高峰时间”测试中。我们假设平均为 10 分钟，最低为 5 分钟，最高为 15 分钟，并且 3/4 的用户是回访用户。
因此，当您创建负载测试场景时，您需要在没有思考时间的情况下对其进行计时，然后在每个步骤中调整合理的思考时间，以便在启用思考时间的情况下完成脚本大约需要 10 分钟。运行脚本时，您需要在思考时间上设置随机化，以允许 +/- 50% 的规定时间。
因此，对于高峰时段测试，我们需要 600 次“废弃购物车”场景迭代、100 次“新用户”场景（在结帐期间注册新用户）和 300 次返回用户场景迭代。
所以对于返回的用户脚本，如果平均运行时间为 10 分钟，那么在我们的测试过程中，单个 vuser 可以运行该脚本 6 次。因此，为了总共获得 300 次迭代，我们需要并行使用 50 个 vuser。超过一小时 (50*6=300)
如果我们暂时假设废弃购物车的持续时间为 4 分钟，那么每个运行该场景的 vuser 可以在一小时内执行 15 次迭代 (60/4)。因此，要在一小时内运行 600 次废弃脚本迭代的目标，您需要 (600/15) 40 个 vuser 在负载测试期间运行该场景。
如果新用户脚本平均需要 15 分钟才能完成，那么每个用户在一小时内进行 4 次迭代，并且需要 25 个 vuser 运行该场景才能在一小时内进行 100 次迭代。
因此，您的总数最终是 40+50+25 或 115 个 vuser 来模拟现有的高峰时间。如果您想在那一小时内模拟更大的流量突发，您可以使用更多的 vuser，并让 loadtest 工具将它们上升然后再下降，这样您仍然可以进行迭代，但在中间有更大的峰值负载考试。
并且（假设您已经创建了很多测试数据）如果客户想要查看站点是否可以承受当前负载的 4 倍，那么您可以运行相同的场景，但使用 160+200+100= 总共 460 个 vuser 而不是115
我在一篇博文中写了关于并发用户和数字的文章：http ://blog.xceptance.de/2011/06/07/get-the-right-load-mix-out-of-a-few-numbers/
等等……我的并发用户在哪里？这很简单：“并发用户”是一种不准确的流量描述方式，所以我们还没有使用这个数字。这是为什么？
为了弄清楚这一点，我们只需检查一次访问需要多长时间。根据商店的不同，平均访问可能需要 2 到 4 分钟。成功购物可能需要 15 分钟。如果我们预计每次访问大约有 10 次页面浏览量，并且页面浏览量需要 1 秒加载和 20 秒阅读（对于平均值来说已经是一个非常非常高的数字），那么一次访问将需要 10 * 1 秒 + 9 * 20 秒 = 190 秒。
让我们平均访问 190 秒。如果我们一次只能为一位访客提供服务，我们可以为 60 分钟（3600 秒）/每次访问 190 秒 = 每小时 19 位访客提供服务。但是因为我们希望每小时服务 10,000 人，所以我们必须同时处理 10,000 / 19 = 526 名访客。这就是著名的并发用户数。
如果我们现在将思考时间加倍，我们就有 1,052 个并发用户/访问者。如果我们将其缩短到 1 秒的思考时间，我们将获得 19 秒的访问长度，因此 10,000 次访问/（3600 秒/19）= 53 个并发访问者。
注意：这个答案是针对问题的早期版本，它要求您在 vuser 等之间建立 1:1 的关系。与其重新措辞，我将让它保持原样，因为里面的信息仍然很合理. 但是现在您知道为什么它似乎没有直接回答新版本的问题。
通常，如果您负担得起（例如 vuser 的许可证、运行 vuser 的测试设备的硬件），最好的答案是使用 1:1 的关系。这意味着在负载场景中的所有步骤之间包括思考时间，并且可能需要大量的 vuser。现在使用一些系统，如开源或 VSTS Ultimate（现在有无限的 vuser 许可证），许可 vuser 的成本并不高，而且由于设计良好的系统可以从单个 cpu 运行超过一千个 vuser，因此硬件成本这样做并不是很好。
这是最好的原因有很多因素，但最重要的是
如果我们谈论的是相对于非常短的时间范围（例如 1-10 秒）或相对于较大的持续时间（例如每小时用户数）的模拟用户，后一点非常重要。如果您要压缩思考时间并使用 100 个 vuser 重复一个需要 36 秒的脚本来模拟 10000 个用户在一小时内的负载，那么在此期间您可以生成的最大“峰值”为 100 个请求。如果您使用 1000 个 vuser，每个 vuser 重复一个需要 6 分钟的脚本，那么您的最大峰值是 1000 个请求，这更接近实际可能发生的情况。
但请注意，在这种情况下，我没有使用 10,000 个 vuser 来表示该小时时间内站点上的负载。由于测试时长为 1 小时（可能代表一天中的高峰时段），而脚本执行平均只需 6 分钟（包括思考时间），因此我可以重新使用该 vuser 来模拟最多 10 个正常的负载一小时内的用户。OTOH，如果在那一小时内“一次”的峰值负载是 2000 个用户，我想要做的是使用 2000 个 vuser，并让他们在脚本迭代之间平均等待 6 分钟，以便每个用户执行大约 5 次迭代几个小时内的脚本。
OTOH，如果您只是想对正在浏览静态页面的未登录访客的“后台负载”进行建模，那么压缩思考时间并使用单个 vuser 在一段时间内模拟来自多个“同时”用户的事务仍然是相当现实，并且当您的每个 vuser 成本很高时可以为您节省一点钱。请注意，这会产生非常平滑的连续负载，这在现实生活中不会发生。
顺便说一句：MS 模式和实践的人创建了一本很棒的免费书（我购买了一本我非常喜欢的印刷版）关于性能测试，它几乎与平台无关，非常值得任何进行性能或负载测试的人阅读。您可以从此Codeplex 链接获取它
对我自己有效的方法，以及其他人教给我的方法，是减少并发用户总数和思考时间（用户除了阅读之外什么都不做的时间），然后缩小一个时间之间的差距。用户离开，另一个人到达。这需要一些数学计算和大量的故障排除，但是，它已经用于一些基本的性能测试。