一种集客语音专线业务性能与压力测试的方法与系统介绍

王华 肖荣军

中国移动通信集团江苏有限公司

0 引言

随着全业务的快速发展及移动互联网的普及，公益性、经营性呼叫业务平台和保险、金融、电商及客服类呼叫业务平台数量日益增长，对电信运营商提供的专线、业务平台等性能和压力要求很高。集团客户（简称集客）呼叫业务平台一般由电信运营商IMS（IP Multimedia Subsystem，IP多媒体子系统）网络承载呼叫业务。对于提供网络服务的电信运营商，在集客项目上线交付时，需要对服务网络质量以及平台自身运行状况进行业务功能、性能指标以及极限业务量下各项性能的验证，以保障业务和网络的运行质量，降低风险。

现有传统验证测试手段，包括人工拨打和自动拨测，仅能验证业务功能和业务流程的正确性，不能模拟大话务量呼叫，无法对集客业务平台在极限压力场景下的性能进行评估。

（1）集客业务平台设计缺陷或配置的不合理。当业务量增大时，集客呼叫业务平台软硬件资源逐渐耗尽，导致业务降质直至阻断。

（2）服务网络的资源配置不合理。业务高峰期时业务量骤增，对电信运营商的服务网络可能会形成数据风暴冲击，影响网络运行状态，造成服务质量劣化，甚至会影响到服务网络承载的其它集客平台业务质量。

如何在集客业务平台正式上线运行之前，预先模拟正常及极限业务场景，评估网络及业务平台的隐患，对提前解决所发现的问题，降低正式上线后的风险，具有重要意义。

图1 技术方案

1 技术方案

采用软件仿真的方式，模拟多路并发的大话务量对业务平台进行测试，为集客呼叫业务平台的正式上线和维护提供保障、降低风险、节约成本。无需专有硬件支持，采用软件方式模拟信令协议，仿真IMS网络 SBC（Session Border Controller，会话边界控制器）网元，从Gm接口接入现网PCSCF（Proxy Call Session Control Function，代理呼叫会话控制功能）网元设备，模拟IMS用户发起呼叫业务流程，对呼叫业务平台进行大话务量的并发呼叫压力测试，验证集客呼叫业务平台、服务网络在极限话务量场景下的承压能力、运行性能。

1.1 测试方法

（1）网络接入

通过IP承载网物理接入，模拟Gm接口接入IMS网络。

（2）网元设备仿真

仿真SBC网元设备，接入现网PCSCF网元。

（3）SIP协议栈仿真

对IMS SIP协议栈进行构造，从SBC向上级网元发起测试。

（4）业务测试

使用真实IMS用户账号，并发呼叫至集客呼叫业务平台，同步监测呼叫业务的接通率、时延、语音质量等关键KQI指标。

1.2 测试步骤

测试中心按如下步骤进行测试：

（1）在测试中心配置相关测试参数，包括：IMS测试用户账号、仿真的SBC网元属性、接入的现网PCSCF网元属性、被测试的集客呼叫业务平台号码、测试并发度、通话时长、呼叫间隔等。

（2）测试中心自动使用测试号码，从Gm接口发起IMS注册流程，以保障测试号码处于在线活动状态，为后续呼叫测试提供基础。

（3）测试中心以被测试的集客呼叫业务平台号码作为被叫号码，根据测试并发度，自动发起多路并发呼叫，对呼叫信令流程进行控制，接通后，经过预设的通话时长超时后自动挂机，然后重新发起呼叫，以保持一定的话务量CAPS（Call Attempts Per Second，每秒建立呼叫数量）。

测试呼叫信令流程如下：

图2 呼叫信令流程

（4）测试结束后自动生成测试评估报告，并可以对单条测试记录的话单、信令流程进行查询，基于时间、号码等维度进行统计，呈现接通率、接通时延、通话时长、语音质量、失败原因等业务指标。

1.3 方案优势

本方案与其它测试验证手段比对如下表：

表1 测试方法比对

与现有的人工和自动拨测方法相比，本方案对呼叫业务平台上线的高效评估、维护人员数量的减少以及成本的降低有显著的效果，具有发现网络及平台隐患的优点，这是现有测试手段无法做到的。

2 设计思路

2.1 系统架构设计

系统采用分层架构，包括：公共支持层、协议仿真层和测试应用层。

图3 系统架构

（1）公共支持层

提供整个功能的公用支持模块功能。

1）并发管理模块：对呼叫业务的多路并发进行高效管理。

2）配置管理模块：对测试涉及到的配置进行管理，包括：测试号码配置、接口配置、仿真网元配置、互通的现网网元配置等。

3）资源管理模块：对系统所需内存、消息队列、存储等资源进行管理。

4）通信管理模块：对通信通道提供大容量高效管理。

（2）协议仿真层

对IMS SBC网元进行仿真，依据接口协议标准规范进行处理。

1）TCP/IP协议栈仿真处理模块：对IP、TCP、UDP协议进行仿真处理。

2）应用层协议仿真处理模块：对SDP、SIP应用层协议进行仿真处理。

3）接口协议仿真处理模块：对Gm接口进行仿真，与现网PCSCF进行互通。

4）网元仿真处理模块：仿真IMS网络SBC网元实体行为。

（3）测试应用层

提供业务测试、业务质量评估和报表输出。

1）业务测试模块：进行注册、呼叫业务自动并发测试。

2）业务质量分析模块：对业务测试的接通率、时延、语音质量、失败原因等指标进行质量分析。

3）测试报表输出：对测试进行统计分析，生成报表结果，输出给用户。

2.2 大话务量并发测试设计

一个IMS测试的生命周期包含一个状态序列，任一时刻都处于某一种状态中，每个状态为一定时间内稳定的“暂态”，当接收到外部事件触发后，状态会迁移到下一个状态。IMS测试的状态迁移图示例如下：

图4 测试状态迁移

状态之间存在一定的时间间隔，当某一路测试保持于某个状态而无外部消息触发时，则处于“等待”状态，处理机可以转而处理其它测试，从而实现N路并发测试处理。

具体实现中，每一路呼叫在内存中分配一个呼叫控制块,记录呼叫的状态、主叫号码、被叫号码、呼叫进展时间戳、控制面IP地址、媒体面IP地址、端口以及定时器等基本呼叫信息。测试过程中，根据当前所处的状态，对外部触发消息进行处理，更新呼叫控制块中相应的信息后，并迁移到下一个状态，以完成测试流程的控制。

同时采用如下机制，以保障在大话务量并发场景下事务处理的实时性和高效性。

（1）高速消息交互机制：采用零内存拷贝，统一封装的内存管理机制和内存节点链交互，保证了海量数据的实时处理，大大减少了数据交互在临界区的时间。

（2）高效消息队列机制：针对多线程之间的大量交互消息队列，消息通知和定时器消息间相互结合的扫描处理机制，保证了消息的实时处理和高效率。

（3）高速通信机制：封装了实时通信接口模块，同时支持10万量级以上的实时SOCKET无阻塞并发通信，实现了多进程、多线程之间的高速通信交互。

在具备必要的硬件处理资源条件下，即可完成大话务量并发，对呼叫业务平台进行承压性测试。

2.3 信令同步跟踪监控设计

在测试过程中，同步跟踪监控测试号码的所有IMS业务测试流程，自动关联所有的信令交互过程，实时展现在图形终端，提供信令流程显示，流程图上能按时间次序呈现各个子过程的信令流程，供系统操作用户分析使用。根据不同的信令过程自动分色显示，提供详细到比特位的信令解码。存储信令消息码流，实现数据的过程回放功能，为测试结果的分析提供有力的支撑手段。

图5 信令同步跟踪

2.4 测试数据挖掘分析设计

充分利用数据挖掘技术，从测试数据的提取、存储管理、业务呈现方面提高运维效率，方便查找网络问题。

从任务总揽界面图、网元实体指标总览图上通过简单点击，可以获取某个任务最近48小时的运行成功率指标曲线（鱼骨图、柱状图、报表等）、某周的日成功率比较曲线、某月的成功率周比较曲线，从一个测试任务的指标曲线中能显示成功率下降的故障的时间点，并关联到相应的详细话单和码流及告警记录。支持测试业务所有任务的鱼骨分布图，对各种故障原因名称和比例按业务流程顺序呈现在鱼骨图上，并从鱼骨刺上提供查询到相应CDR的功能，从CDR进一步关联到消息码流和过程流程图，并最终能关联到消息的解码显示等。

图6 测试数据挖掘分析

3 应用效果

（1）更接近现网运行场景的一体化性能压力测试

为了向客户提供稳定可靠的服务，采用软件仿真的方式模拟多路并发的大话务量对呼叫中心平台进行测试，并不是孤立的对呼叫平台进行测试，而是在真实网络环境下，使用实际用户账号，经过服务网络进行测试，这实现了呼叫平台和网络环境的一体化测试，更准确地反映实际应用场景下的承压情况、运行性能，为平台的正式上线和维护提供保障、降低风险、节约成本。

（2）风险前置，减轻后续维护隐患

通过对呼叫中心平台的性能压力测试，提前发现传输、平台、网络侧的隐患，在业务交付前对产品进行压力测试，增加了产品的稳定性。为后续产品交付和维护减轻压力。

（3）已在电信运营商网络取得显著的应用效果

本系统已取得显著的应用效果，利用电信运营商IMS网络，对多个大型集客呼叫业务平台实施大话务量压力测试，发现多起服务网络和业务平台隐患。例如：江苏移动公司使用本系统，对宿迁京东商城呼叫中心平台进行入网前的大话务量压力测试，测试结果如下：

表2 测试结果

经测试发现网络和业务平台存在隐患：

运营商网络提供的IMS出口至呼叫中心平台网络带宽不足，当业务量达到阈值后，部分测试呼叫失败。

呼叫中心平台参数配置不合理，存在缺陷，导致极限情况下，平台软件崩溃异常。

经过网络及业务平台的调整，测试结果正常，为业务平台的入网正常运行提供了有力的保障。

4 结束语

通过集客语音专线业务平台性能压力测试系统的实现，为大容量集客呼叫业务平台的入网上线提供了有力的验证支撑手段，最大程度降低了电信运营商和集客用户的运营风险。当然，测试系统还可以进一步完善提高，扩展测试的广度，例如增加对集客专网数据业务的压力测试，以适应更多的应用场景。