在负载测试中，团队犯的最大错误发生在还没有编写任何脚本之前：他们选择了错误的测试规模。太小的负载测试会给您虚假的信心。仪表板上一切看起来都是绿色，但当生产环境流量激增时，裂缝就会显现。太大的负载测试同样糟糕。您会浪费时间、金钱和基础设施来测试一个从未发生的场景，最终追逐虚幻的瓶颈。
有很多警示案例。例如，一家企业在黑色星期五上线新产品，之前只测试了500个并发用户，因为那“看起来很安全”。促销上线几分钟内，流量飙升到2,500用户，结账管道崩溃。另一方面，一所大学坚持在1,000用户下测试其新门户，尽管历史峰值流量从未超过5,000。结果是：云账单被膨胀，一个月的时间浪费在追逐那些在现实中永远不会被触发的瓶颈上。
规模确定是负载测试的艺术与科学相遇之处。您需要一个既足够大以具有意义、又足够扎实以反映现实的数字。问题是大多数团队在项目文档中并没有一个整洁的“并发用户”数字。许多人默认使用像500、1,000或10,000这样的整圆数字，仅仅因为它在幻灯片上看起来权威，而这并不够好。
在本文中，我们将介绍三种经验证的负载测试规模确定方法：1）基于需求，2）基于事务，3）基于分析。每种方法都为您提供了一个框架，将杂乱或不完整的数据转化为可辩护的测试规模——一个符合生产流量而不是猜测的规模。
方法1：基于需求的规模确定
如果幸运的话，您的需求文档中已经包含答案——您只需读懂其中的含义。
有些场景会很明显。如果贵公司计划举办强制参加的直播市政厅会议，并发数等于出席人数。如果有1,000名员工，您应该测试1,100并发用户（出席人数加上10%的安全缓冲）。这大约是最直接的情况了。
其他事件更棘手但仍可预测。以大学课程注册系统为例。大部分时间里，流量平稳且适中。但在注册日，系统会被重击。学生争相抢占热门课程的席位，流量远高于基线。如果您知道有10,000名学生，并且经验告诉您其中90%会在注册期间访问系统，那就是9,000个并发用户。再加上学生请朋友或家人从多个设备登录的行为，实际并发可能超过学生总数的100%。一个安全的测试可能将流量设为学生用户的200%。
这在其他行业也会发生。考虑四月的政府税务门户。系统全年可能使用量轻，但在报税日，并发会急剧上升。或者看看演唱会票务平台。对于大多数活动，流量是分散的。但当某位大牌艺人的门票在上午10:00准时开售时，所有粉丝会同时刷新页面（更不用说试图抢票的机器人，这完全是另一项需要考虑的事情）。这些都是基于需求的时刻，您的负载测试需要相应地确定规模。
陷阱： 需求往往被低估。利益相关者可能为了在预算上保持保守而低报参与人数，或者他们可能没有考虑到提前登录以占位的“旁观者”或机器人。始终质疑该数字，为流量激增建模，并添加缓冲。
经验法则： 当事件具有时间限制且可预测、参与人数明确时，基于需求的规模确定最有效。在这些情况下，需求为您提供了最可辩护的基线。
方法2：基于事务的规模确定
当需求无法给出数字时，业务事务会给出答案。与其以抽象用户来思考，不如按动作考虑：订单、注册、支付、上传、出价。
计算方法如下：
- 识别峰值事务量。 假设您的电子商务平台在典型一天处理1,000个订单，但在假期期间，量激增50%至1,500个订单。
- 找到活跃窗口。 如果大多数订单发生在上午10点到晚上10点之间，那就是一个12小时窗口，大约125单/小时。
- 调整不均匀分布。 流量很少是均匀的。如果高峰时段高出25%，那就是在最繁忙的小时约160单。
- 转换为并发。 如果客户完成订单需要五分钟，那么160单/小时等于2.67单/分钟。乘以五分钟的持续时间，实际下单的并发用户约为14人。
- 添加浏览流量。 购买者并不是全部。如果您的分析显示每位购买者对应10位浏览者，那就是另外140个并发用户。
- 添加缓冲。 以25%的安全边际计算，您现在约为190用户。您甚至可能想添加50%或100%的边际（或根据波动性更多）。
在此示例中，这就是您的测试规模：190个并发用户，重现系统将看到的最繁忙、最有意义的事务模式。
该方法的优点在于它将负载直接与业务结果挂钩。您测试的不仅仅是“190个用户”，而是在验证处理“160峰值订单/小时外加浏览流量”的能力。这个数字是利益相关者能理解并关心的。
第二个例子： 拍卖平台。假设您每天平均看到10,000次出价，其中40%集中在高关注拍卖的最后两小时。两小时内即为4,000次出价，约2,000/小时。如果平均一次出价耗时30秒，那么约有16个并发出价用户。但如果浏览与出价的比例为30:1（在拍卖网站常见），则需要模拟近500名用户以反映真实负载。该测试规模会告诉您系统是否能处理不仅是出价高峰，还有大量观众观看并刷新的冲击。
季节性也很重要。 不只有零售业有高峰。旅行平台在春假和节假日会见到需求激增。税务平台在四月会被压垮。SaaS的入职在新合同签订时会激增。基于事务的规模确定通过将并发与业务特定事件关联，适应所有这些情况。
经验法则： 如果需求模糊但业务指标清晰，使用基于事务的规模确定。它准确、对利益相关者友好，并能直接转化为结果。
方法3：基于分析的规模确定
当需求模糊且没有事务数据时，分析工具可以填补空白。Google Analytics、Adobe Analytics或类似平台为您提供可通过一些数学运算转换为并发的流量数据。
步骤如下：
- 从峰值流量开始。 假设您网站在最繁忙的一天有50,000名访问者。
- 转换为每小时流量。 除以24小时 = 约2,100访问者/小时。
- 调整峰值。 流量并非平坦。为考虑分布不均加入50% → 约3,150访问者/小时。
- 使用平均会话时长。 如果用户平均在站点停留两分钟，则3,150 / 60 × 2 = 约105个并发用户。
- 添加缓冲。 加上25%的边际，您大约需要130个并发用户。
这就是您的测试规模：130名用户，反映分析中见到的最繁重流量。
示例： 一家SaaS公司拥有500,000名月活跃用户。如果日活约为该数字的10%（50,000），且20%在工作高峰时登录，那么最繁忙窗口中有10,000名用户。如果平均会话时长为15分钟，则需要测试约2,500名并发用户。
准确性注意事项： 分析数据优于日志，但并不完美。请考虑：
- 广告拦截器 可能会隐藏部分访问。
- Cookie同意横幅 如果用户选择不被追踪，可能导致漏计。
- 机器人流量 如果未过滤，可能会使数字偏高。
尽管存在这些问题，分析数据仍然是一个可靠的后备。它们反映真实的用户会话，在设备和地点之间进行了归一化，并且如果您的平台具有区域性或以移动为主的流量，可以按地理或设备类型进行细分。
经验法则： 当业务指标不可用但您拥有一致的流量数据时，使用基于分析的规模确定。它是将测试扎根于现实的最实用方法。
特殊情况：全新应用
如果您正在从零开始构建一个全新的应用怎么办？您既没有定义并发的需求，也没有事务历史或分析数据，这就是一个完全不同的问题。
常见错误是选择一个像“2,000并发用户”这样的整圆数字，因为它感觉安全。但如果该数字未与预期行为相关联，则毫无意义。
更好的方法是以事务或会话为单位预测流量。如果您预计每小时有200次上传，就将测试规模设定为验证这一点。如果您预计在发布日有10,000次注册，请将其转换为每小时流量和会话持续时间。即便是这样粗略的估计，也能产生可在业务层面解释的结果——这些都是可建模或计算的数学问题。
示例： 假设您的市场团队预计发布周有5,000次注册，主要集中在一篇重大新闻稿之后。如果您假设其中60%落在第一天，那就是3,000次注册。不均匀分布情况下，前三小时占40%，那就是约1,200次注册。如果创建帐户需要三分钟，那么约为60个并发注册。加上浏览和重试流量，合理的测试规模可能为200–300并发用户。这个数字基于假设，但至少是明确的，且当真实数据到来时可以进行优化。
当管理者想要呈现某种效果时，注意不要凭猜测行事。 利益相关者或管理者可能会推动巨大的整圆数字（“我们要测试50,000用户以向投资者展示我们已准备好扩展”）。抵制这种做法。过大规模的测试不会建立信心——它们制造噪音和浪费。将您的规模确定基于预测的事务，即使这些只是估计。
汇总表：选择正确的方法
| 方法 | 何时使用 | 优点 | 风险/陷阱 |
| 基于需求 | 可预测、有时间限制的事件 | 清晰、可辩护、易于计算 | 利益相关者低估、冲突 |
| 基于事务 | 具有明确业务数据的现有应用 | 直接关联业务结果、比率准确 | 需要良好的指标、季节性影响 |
| 基于分析 | 具有一致流量历史记录的网站 | 易于计算、基于真实会话 | 广告拦截器、机器人、准确性不均 |
| 新应用 | 无历史或数据可用 | 强制做出明确假设，面向未来 | 猜测的风险 |
关于正确确定负载测试规模的结语
负载测试的目的不是达到一个数字——而是回答一个问题。您的系统能否处理对业务重要的特定行为和事件？
- 如果需求给出直接数字，就使用它们。
- 如果没有，事务提供最准确、最贴合业务的锚点。
- 如果那些不可用，分析提供可靠的备选方案。
- 对于全新系统，预测优于任意猜测。
无论您使用哪种方法，都要始终添加缓冲。真实流量具有突发性、不可预测性，并且很少与完美的平均值一致。
LoadView 帮助使每种规模确定策略变得可操作。使用 LoadView，您不仅可以对用户数量建模，还可以模拟现实的模式——报名时的突发流量、混合的浏览与下单行为，或与您的分析相匹配的全球分布。这意味着您的测试不仅仅是一个数字，而是对生产现实的排练。
规模确定是任何负载测试中的第一个决策。做对了，您之后收集的每一个结果都有意义。做错了，再多的脚本或报告也无济于事。使用本文概述的三种方法，您可以自信地确定测试规模，并确保您的性能结果真正与网站或应用上的流量和活动相匹配。