SIP测试-05-语音机器人项目中的专项性能测试
如果说 SIP、FreeSWITCH、SIPp 这些内容，更多是在解决“电话能不能建立”和“信令能不能承压”，那么一旦进入语音机器人项目，测试重点就会明显变化。
因为你不再只是验证：
- 电话能不能接通
- 挂断是不是正常
- FreeSWITCH 会不会扛不住
你真正要面对的是一条更长、更容易互相影响的业务链：
- 电话接入
- 机器人接听
- 引导语播放
- 语音识别
- 对话服务
- 业务逻辑处理
- 通话结束
- 结果回写
这时候 还会沿用“普通 SIP 压测”的思路：
- 看接通率
- 看 CPS
- 看失败码
这些当然还要看，但已经不够了。
因为机器人项目里，一个非常现实的问题是：
电话接通不等于机器人真正可用。
你完全可能遇到这种情况：
- 电话接通了
- 机器人也接了
- 但识别慢、对话慢、回写慢
- 最后整通电话被拖得很长，系统承压能力迅速恶化
所以这篇文章更想回答的是：
语音机器人项目里的专项性能测试，应该测什么、怎么拆、怎么观测、怎么判断。
一、语音机器人专项测试，和普通语音压测最大的区别是什么
普通语音压测更偏基础设施视角，重点是：
- 注册能不能稳定
- 呼叫能不能建立
- 信令和媒体能不能扛住
而机器人专项测试更偏业务链路视角，重点是：
- 机器人接听是否及时
- 引导语和用户音频是否正常进入流程
- 识别服务响应是否稳定
- 对话系统是否会把会话时长拉长
- 通话记录、结果回写是否能跟上
也就是说，机器人专项压测里最关键的问题不再是：
- 有没有接通
而是：
- 接通以后，这通电话在业务上是不是以合理时长、合理成功率、合理资源成本完成了
二、机器人专项压测更适合拆成 4 个专项对象
为了避免测试目标过于发散，通常会把机器人专项测试拆成下面 4 块。
1. 接听与通话建立专项
回答：
- 机器人是否能稳定接听电话
- 接通阶段是否存在明显抖动或超时
2. 识别与对话专项
回答：
- 音频送入识别服务后响应是否稳定
- 对话系统响应是否会拉长整通电话
3. 通话时长与会话占用专项
回答：
- 单通电话平均占用多久
- 在并发增加时，是否会因为某一步耗时变长，导致会话占用快速放大
4. 结果回写与链路收尾专项
回答：
- 通话结束后结果回写是否稳定
- 是否会因为回写慢或失败，造成链路尾部堆积
这个拆法的价值很大。
因为机器人项目里，很多问题不是“失败得很明显”，而是“整条链路慢慢变长”，最后才拖垮并发。
三、语音机器人项目里，比单次成功率更重要的是通话时长结构
这是和普通接口压测很不一样的一点。
在机器人项目里，一通电话的总时长经常是由多段时间组成的：
- 接入建立时间
- 引导语播放时间
- 用户音频输入时间
- 识别耗时
- 对话耗时
- 业务处理时间
- 结束和回写时间
所以通常会要求现场至少拆出下面这张结构表：
| 阶段 | 典型耗时 | 关注点 |
|---|---|---|
| 接听建立 | 秒级 | 是否稳定接起 |
| 引导与静音等待 | 秒级 | 是否配置合理 |
| 识别请求 | 百毫秒到秒级 | 是否抖动上升 |
| 对话处理 | 百毫秒到秒级 | 是否成为主瓶颈 |
| 回写与收尾 | 百毫秒到秒级 | 是否在尾部堆积 |
这张表特别重要。
因为你后面分析整通电话时长为什么变长，核心就是看哪一段先开始拉长。
四、更常用的一套最小专项执行骨架
如果是新的机器人项目，通常不会一上来就直接做大流量全链路。
更稳的方式是这样：
阶段 1：机器人接听验证
先确认：
- 电话能稳定接进机器人
- 机器人端 SIP 接听和媒体建立正常
阶段 2：识别链路验证
先确认：
- 音频发送后识别结果能正常返回
- 识别耗时在合理区间
阶段 3：对话链路验证
先确认：
- 识别结果进入对话系统后，响应是否稳定
- 是否存在明显长尾
阶段 4：完整通话链路验证
最后才确认：
- 从接听到回写整条链路是否稳定
- 通话时长是否还处在可接受区间
这套节奏的关键不是“保守”，而是尽量避免：
- 一开始把所有问题都糊在一起
- 出现异常后完全不知道该先拆哪一段
五、更常用的一套观察面
做语音机器人专项测试时，通常要同时看 5 组信号。
1. 电话接入面
看：
- 接通率
- 接听时延
- SIP 失败码
2. 机器人处理面
看：
- 机器人是否真正进入处理流程
- 是否有早挂断、未处理、处理中断
3. 识别与对话面
看：
- 识别请求成功率
- 识别耗时
- 对话服务耗时
- 是否出现长尾和堆积
4. 通话时长面
看：
- 平均通话时长
- P95 / P99 通话时长
- 是否随并发上升明显拉长
5. 结果回写面
看：
- 回写成功率
- 回写是否拖慢收尾
- 通话结束后是否出现尾部积压
这套观察面比只看“接通没接通”更贴近真实业务价值。
六、更适合的一套阶段记录表
机器人专项测试里，现场更适合维护这样一张表：
| 阶段 | 并发/速率 | 接通率 | 识别耗时 | 对话耗时 | 平均通话时长 | 初步判断 |
|---|---|---|---|---|---|---|
| stage-1 | 低 | 高 | 稳定 | 稳定 | 正常 | 健康区 |
| stage-2 | 中 | 高 | 略升 | 稳定 | 略升 | 关注识别 |
| stage-3 | 中高 | 略降 | 明显升高 | 跟随升高 | 明显变长 | 接近风险区 |
| stage-4 | 高 | 降低 | 长尾明显 | 长尾明显 | 明显拉长 | 风险区 |
这张表的核心价值是逼着你回答：
- 是接通先坏了
- 还是识别先慢了
- 还是对话把整通电话拖长了
七、我在机器人项目里最常见的几个误区
1. 接通率高，就以为机器人链路没问题
这是非常容易误导人的。
机器人项目里，接通率高只能说明：
- 电话进来了
- 不代表业务链路完成得好
2. 只盯识别成功率，不看识别耗时
很多时候服务没有“失败”，但它在变慢。
而一旦识别或对话开始慢，最先被拉长的往往是通话时长。
3. 只看单条服务指标，不看通话整体时长
机器人项目是典型的链路型系统。
单个服务只要变慢一点点，整通电话就可能被明显拖长。
八、真实案例型段落：一次“电话都接起来了，但机器人链路还是越跑越慢”的排查
场景
一次语音机器人专项压测里，电话接通情况一开始看起来不错：
- 接通率不低
- SIP 层失败码也不算多
- 机器人能正常接听
但随着压测持续，现场开始出现一个更隐蔽的问题：
- 平均通话时长越来越长
- 并发占用越来越高
- 最后整体成功率开始下降
执行
当时执行的是完整机器人链路：
- SIPp 主叫呼入
- FreeSWITCH 转接机器人
- 机器人播放引导语
- 调识别服务
- 调对话服务
- 通话结束后写回结果
现象
这类问题一开始特别容易被误读。
因为表面上看：
- 电话是能接起来的
- 失败也没有立刻暴涨
这时第一反应往往会变成：
- 问题不大，只是偶发抖动
但把时间拉长以后很快就发现：
- 单通电话占用时间越来越长
- 会话释放越来越慢
- 并发很快被放大
排查
我当时没有先去改 SIP 参数，而是按通话时长结构拆：
- 先确认接听建立时间是否稳定
- 再看引导语播放和静音等待是否异常
- 再看识别耗时有没有开始明显上升
- 最后看对话服务和回写服务是否在尾部堆积
排下来以后，真正先开始变差的是：
- 识别和对话耗时开始拉长
它们本身不一定立刻失败，但足以把：
- 单通电话平均时长
- 会话占用时间
- 并发资源消耗
一起往上拉。
修复
后面的收敛动作不是继续加大 FreeSWITCH 或 SIPp 参数，而是：
- 先把识别、对话服务单独压测确认拐点
- 下调专项阶段目标流量，重新观察通话时长变化
- 优先优化慢服务，再回到完整机器人链路复测
这个案例很典型，因为它说明：
机器人项目里，很多问题不是“电话没接通”，而是“电话接通以后被慢服务拖成长电话”。
九、机器人专项测试最后应该输出什么
如果要写结论，通常不会只写：
- 机器人系统支持多少并发
更希望输出的是：
- 在什么强度以内，接听、识别、对话和回写都稳定
- 从哪一个阶段开始，通话时长明显拉长
- 最先退化的是接入层、识别层、对话层还是回写层
- 当前整条机器人链路的安全工作区和风险区分别在哪
这种结论才真正适合指导：
- 容量规划
- 服务优化顺序
- 全链路架构治理
结语
语音机器人项目中的专项性能测试，真正难的地方不是“电话打通没有”，而是你能不能把：
- 接听
- 识别
- 对话
- 回写
- 通话时长
这些指标放进同一条链路里理解。
只有这样，你才会知道：
- 一通电话为什么越来越长
- 哪一段在放大资源占用
- 哪个服务才是真正该先优化的点