负载测试存在一个认知问题。它仍然被广泛视为一种规模练习：有多少用户、有多少请求、多少吞吐量。这些数字易于配置、易于报告，也易于在不同测试之间进行比较。但它们并不完整。
生产系统并不是以静态数量来感知“用户”。它们感知的是随时间变化的活动。请求并非均匀到达。会话相互重叠。用户会暂停、重试、放弃流程，并在稍后返回。有些会话短暂且轻量，有些则持续时间长并且有状态。这些动态对基础设施行为的影响，远大于单纯的峰值并发。
这正是负载测试建模重要的原因。它不是一个流行词，而是一门描述流量真实行为方式的学科。会话、节奏和用户行为是将合成测试转变为可信模拟的关键机制。缺少它们，即使执行良好的负载测试，也可能产生看似令人安心却无法预测真实世界故障的结果。
负载测试建模并不是用户数量配置
从本质上讲，负载测试建模是定义负载如何进入系统、如何随时间累积并持续存在的过程。它不是一次配置操作，也不等同于选择一个目标虚拟用户数量。负载模型描述的是系统所承受压力的形态，包括压力如何演变、重叠并随着活动持续而叠加。
在真实环境中，负载并非均匀或瞬时施加。它以波动形式到达，通过活跃会话持续存在，在空闲期间暂停，并通过重试和回访再次出现。这些动态决定了资源是被短暂使用还是持续受压，内部状态是趋于稳定还是逐渐偏移，以及故障是迅速显现还是长期潜伏。负载建模的目的，是有意识地捕捉这些动态，而不是将其交给偶然性。
一个负载模型需要回答如下问题：
- 用户如何随时间到达？
- 他们保持活跃多长时间？
- 他们执行哪些操作，以及操作顺序如何？
- 操作之间存在多少空闲时间？
- 他们在何时、为何离开？
两个测试可能产生相同的请求量，但由于这些问题的答案不同，系统行为却可能截然不同。逐步到达的一千个短生命周期会话，并不等同于两百个长时间保持连接、已认证且有状态的会话。这种差异会体现在内存使用、连接池、缓存效率以及后台任务压力上。
当团队只关注并发时，负载就被简化为一个快照。建模重新引入了时间维度，而大多数真实故障正是存在于这一维度中。
会话作为现实的基本单元
会话代表着随时间展开的意图，是对用户实际与应用交互方式最接近的抽象。
会话之所以重要，是因为状态会不断累积。身份验证令牌会被签发和刷新，缓存会升温并衰减，服务器端会话存储会增长，数据库连接保持开启的时间往往超出预期。即便是在无状态架构中，也会通过重复访问模式和共享资源产生类似会话的行为。
在许多系统中，故障与会话持续时间的相关性往往高于与峰值请求速率的相关性。内存泄漏、垃圾回收缓慢、线程耗尽以及连接枯竭，通常是在持续的会话活动之后出现，而不是在短暂的流量尖峰期间。
具备会话意识的负载测试能够揭示这些行为。它迫使系统管理连续性，而不是应对突发流量。它可以显示资源是否被及时释放、后台清理是否跟得上节奏，以及性能是否逐步下降而非突然崩溃。
忽略会话会产生看似激进但在运营层面很肤浅的测试。对会话进行建模引入了持续性，而持续性正是系统被真实检验的地方。
节奏：时间是隐藏的变量
节奏定义了会话内各个操作在时间上的分布方式。它包括思考时间、步骤之间的延迟，以及新会话开始的速率。
不合理的节奏是导致负载测试结果误导性的最常见原因之一。快速循环、连续执行事务，会将数小时的真实活动压缩到几分钟内。这会制造在生产环境中很少出现的人工争用模式，同时掩盖需要持续压力才能显现的时间相关故障。
过度同步的节奏同样存在问题。当所有虚拟用户在同一时刻执行操作时，系统会经历不现实的请求对齐。生产流量是嘈杂的，请求并不会完美同步。有的用户会犹豫，有的会立即重试，还有的会彻底放弃流程。
节奏还区分了开放式和封闭式工作负载模型。在封闭模型中，用户在继续之前会等待响应；在开放模型中，请求到达不受系统健康状况的影响。两者都有合理的使用场景，但会产生截然不同的压力特征。选择错误的模型，可能会得出在真实流量条件下无法成立的自信结论。
准确的节奏不会让测试变慢，而是拉长测试时间。正是这种拉伸，使系统能够暴露出渐进式退化，而不仅仅是急性故障。
用户行为塑造系统结果
用户行为并不是叠加在负载之上的随机噪声，而是负载本身的结构。
不同的行为模式会以根本不同的方式对系统施加压力。以读取为主的浏览会加载缓存和 CDN 边缘节点；以写入为主的事务流程会对数据库和队列施压；空闲会话会消耗内存和连接槽位；重试行为会放大故障，而不是缓解它们。
即使是细微的行为变化，也可能改变结果。在高延迟条件下，重试激进程度的小幅增加，就可能使后端负载翻倍。稍微更长的会话持续时间，可能会将缓存推到有效容量之外。更高的放弃率，可能会留下从未完成清理路径的部分状态。
行为建模迫使团队直面这些现实。它使负载测试从理想化流程转向真实使用中观察到的复杂模式。这并不要求模拟每一个边缘情况，而是要识别主导行为，并让它们随时间自然交互。
系统并非因为用户行为完美而失败，而是因为用户行为真实。
持续负载与峰值负载
峰值负载测试是有价值的。它们可以找到系统上限，显示系统在何处完全停止响应。但许多生产事故发生在远低于这些上限的情况下。
持续负载会暴露出另一类问题：缓慢但无上限的内存增长，随着工作集变化而逐渐失效的缓存，排空速度慢于填充速度的队列，以及最初反应正确但随着时间推移表现不佳的自动扩缩容行为。
这些问题不会在短暂而激进的测试中显现，而是在数小时的真实会话重叠和有节奏的活动之后逐步出现。当它们最终在生产环境中暴露时，往往被错误地归因于“流量异常”，而非架构行为本身。
负载测试建模使持续测试变得可行且有意义。它将测试持续时间与系统实际发生故障的时间尺度对齐。
设计与生产环境匹配的负载模型
有效的负载模型建立在观察之上，而不是假设之上。
生产分析、访问日志和 APM 数据能够揭示到达速率、会话长度和常见路径。它们显示用户在哪里暂停、在哪里重试以及在哪里放弃流程。这些信号应直接指导建模决策。
一种实用的方法是先识别少量具有代表性的会话类型。每种会话类型定义一个流程、一个持续时间范围以及节奏特征。到达速率决定这些会话如何相互重叠。空闲时间和放弃行为应被有意识地纳入，而不是事后补充。
模型应与现实进行验证。如果会话持续时间或吞吐量与观察到的数据存在显著偏差，就需要调整模型。目标不是精确到秒，而是系统层面的真实性。
负载建模是一个迭代过程。随着应用演进，行为会发生变化，测试也必须随之演进。静态模型只会产生静态的信心，而这种信心往往并不可靠。
使用 LoadView 应用负载测试建模
负载建模需要将状态、时序和行为视为一等要素的工具。基于真实浏览器的测试通过保持会话连续性并强制执行真实的执行路径（包括客户端渲染、JavaScript 执行和网络争用）来实现这一点。这些约束之所以重要，是因为它们能够自然地塑造节奏和交互时序，而不是依赖人工延迟来近似用户行为。
LoadView 中的脚本化用户流程允许会话在多步骤交互中持续存在，同时对思考时间、空闲周期和重试行为保持明确控制。基于场景的测试可以在单个测试中并发运行多种会话类型，使长生命周期和短生命周期行为以反映生产流量的比例相互重叠。持续和阶梯式负载配置随后可以揭示系统不仅在峰值需求下的响应情况，还能展示压力随时间累积并持续存在时的表现。
价值不在于生成更多负载，而在于生成正确的负载。
结论：负载测试是一门建模学科
负载测试的成败，在第一条请求发送之前就已经决定。它的成败取决于模型。
会话、节奏和用户行为决定了负载如何在系统内部显现。它们塑造内存使用、连接生命周期、缓存效率以及故障模式。忽略它们，只会产生看起来令人印象深刻、却几乎没有预测价值的测试。
成熟的性能测试将负载建模视为一门核心学科。它重视真实胜过激进，重视时间胜过快照。投入建模的团队不仅能更早发现故障，还能更深入地理解它们。
归根结底，系统并不会对用户数量作出响应，而是对随时间展开的行为作出响应。负载测试也应如此。