一種集客語音專線業務性能與壓力測試的方法與系統介紹

王華 肖榮軍

中國移動通信集團江蘇有限公司

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 結束語

通過集客語音專線業務平臺性能壓力測試系統的實現，為大容量集客呼叫業務平臺的入網上線提供了有力的驗證支撐手段，最大程度降低了電信運營商和集客用戶的運營風險。當然，測試系統還可以進一步完善提高，擴展測試的廣度，例如增加對集客專網數據業務的壓力測試，以適應更多的應用場景。