负载测试不应只反复发送 HTTP 请求，而要模拟完整会话：用户进入、建立连接、发送语音、等待回复、打断、离开，以及异常后的恢复。测试目标也不是拿到一个好看的并发数字，而是确认在计划流量下，用户仍能及时看到和听到可用的反馈。
关键结论
- 用真实会话模型代替大量空闲连接。
- 分开衡量连接成功率、首段音频、首个动作和客户端渲染。
- 为每个会话和轮次使用统一关联 ID。
- 在测试开始前写明通过阈值和停止条件。
1. 先建立会话模型
至少确定四个输入：峰值并发、每分钟新会话数、每轮语音长度，以及短回复与长回复的比例。打开 5,000 个空闲 WebSocket 只能说明连接能力，不能说明音频处理、动作传输或本地渲染是否可用。k6 WebSocket 文档说明了长连接虚拟用户与普通 HTTP 循环的差异。
把安静阶段也放进模型。真实用户可能听 20 秒、打断一次、保持沉默，然后直接退出。冷启动、热启动和不同区域也应分别记录，而不是平均成一个数字。k6 scenarios可以为到达流量、持续会话和短时峰值配置不同执行方式。
2. 贯通整条会话链路
为每个合成会话生成关联 ID，记录令牌签发、连接建立、首段有效音频、首个动作数据、本地首帧动作、结束状态、关闭原因和重试结果。OpenTelemetry Trace可以让不同服务保留自己的日志，同时通过同一会话和轮次标识串联起来。
服务端连接正常不等于体验正常。动作可能已经返回，但设备无法按时渲染。浏览器端可通过 Performance API记录用户可见节点；如果使用 RTC 路径，可参考 WebRTC Stats补充传输指标。
3. 按五个阶段执行
- 基线： 少量会话，确认所有事件、日志和预期结果都可观察。
- 爬坡： 逐步增加新会话，达到计划峰值。
- 持续： 保持峰值，观察内存、队列、令牌过期和资源清理。
- 尖峰： 模拟活动开始、会议整点或重试风暴。
- 恢复： 回到常规流量，确认错误率、队列和启动时间恢复基线。
Google SRE 的过载处理章节解释了为什么系统应在过载时主动拒绝部分工作，而不是让全部请求一起失效。逐步爬坡能帮助团队找到这一临界点。
4. 提前定义通过标准
至少设置连接成功率、P95 启动时间、P95 首个动作、意外断开率、恢复成功率和客户端帧稳定性。k6 支持将 thresholds直接设为通过或失败条件。具体数值应来自产品目标和试点数据，而不是复制通用基准。
同时设置安全和成本边界。负载测试可能触发限流，也可能产生额外 TTS 费用。测试应使用专用凭据、受控内容和批准环境，并检查 OWASP 资源消耗风险。
5. 对 Spatius 集成的测试边界
按照当前 Spatius Developer Docs Map，应用负责 ASR、LLM、TTS、工具和工作流；Spatius 把 Avatar 要说的音频转换为动作数据，AvatarKit 在本地渲染。应根据实际部署使用的 集成路径设计负载，而不是测试另一个拓扑。
测试结束后，可结合生产环境 API 评估清单作出发布判断；若某个会话失败，再用实时 Avatar 会话调试指南定位第一个缺失事件。