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