基于Jenkins的移動通信業(yè)務自動化測試平臺的設計與測試

朱紅++仇潤鶴

文章編號：2095-6835（2016）07-0012-03

摘 要：隨著移動通信業(yè)務測試需求的增加，為保證通信產品的質量和研發(fā)速度，利用Jenkins搭建了企業(yè)持續(xù)集成自動化測試平臺，用于移動通信業(yè)務的自動化測試。介紹了持續(xù)集成自動化測試平臺的總體框架和各模塊構成，并以GSM基本語音和數據業(yè)務測試為例，給出了平臺測試流程和測試輸出結果，最終使持續(xù)集成與自動化測試在項目中順利應用。此平臺在實際項目的應用中取得了顯著效果，提高了測試工作的效率。

關鍵詞：Jenkins；移動通信；通信業(yè)務；自動化測試平臺

中圖分類號：TP311.52 文獻標識碼：A DOI：10.15913/j.cnki.kjycx.2016.07.012

隨著通信行業(yè)的不斷發(fā)展和用戶業(yè)務的不斷增加，移動通信業(yè)務由傳統(tǒng)的單一語音業(yè)務轉向多元化業(yè)務。通信設備產品在進入市場之前都要進行一系列的測試，而且軟件版本更新前后有大量的測試需求重疊，因此，通過搭建自動化測試平臺完成通信設備軟件的測試非常有必要。

針對現有多元化移動通信業(yè)務的測試，包括語音業(yè)務和數據業(yè)務等，除了一些通用的測試工具外，很多公司都有內部的自動化測試工具。很多測試工具都是基于TTCN-3（測試及測試控制表示法）開發(fā)的，比如TREX、BroadBit、TAU Teste、OpenTTCN3等。TTCN-3是由ETSI（歐洲電信標準化組織）制定和推行的測試專用語言，是全球各大通信設備廠商的主流測試語言。而項目組移動通信業(yè)務的自動化測試則引入了持續(xù)集成（continuous integration，簡稱“CI”）系統(tǒng)。

目前，全球80%以上的軟件項目采用的是持續(xù)集成。持續(xù)集成是一種軟件開發(fā)實踐，每次集成都通過自動化的構建（包括編譯、發(fā)布、自動化測試）來驗證，從而盡快發(fā)現集成錯誤。谷歌作為當前科技領頭羊，率先在內部推行并使用了持續(xù)集成模式。在其內部的持續(xù)集成系統(tǒng)中，數以億計的構建動作會發(fā)起幾百萬次的自動化測試，開辟了快速開發(fā)領域的測試新模式。

Jenkins作為開源集成測試軟件的典型代表，可以用來搭建企業(yè)持續(xù)集成自動化測試項目平臺，對移動通信業(yè)務進行自動化測試。

1 基于Jenkins搭建CI自動化測試平臺

1.1 CI自動化測試平臺框架

移動通信業(yè)務的CI自動化測試平臺框架如圖1所示。該測試平臺主要包括Jenkins、CIS-RC（Continuous Integration Server Remote Control）、Control Unit和L1（Layer 1）物理層測試平臺。

Jenkins和CIS-RC安裝在Windows PC上，而Control Unit、Linalfs、KSIM等測試工具則安裝在Linux PC上，相關移動通信業(yè)務的自動化測試也均是在Linux PC上完成的。Windows PC和Linux PC之間通過TCP連接，進行工具調用、結果傳輸等。

Jenkins是一個配置簡單、使用方便的持續(xù)集成服務器，在CI自動化測試平臺中起著指揮的作用。通過執(zhí)行命令，Jenkins可以調用一些工具，比如CIS-RC和L1 Wait And Check Result File。在Jenkins上，相關人員可以根據不同的測試平臺構建不同的項目來觸發(fā)各類移動通信業(yè)務的自動化測試。

CIS-RC在CI自動化測試平臺中相當于客戶端。Jenkins要想調用CIS-RC，可以通過兩個參數，分別是XML文件名稱和XSD文件名稱。XML文件和XSD文件中包含了一些設置和命令，其中，XML文件包含了關于Control Unit、腳本序列（script sequence，簡稱“ssq”）和結果文件的相關信息，而XSD文件則描述了Control Unit與CIS-RC之間的連接。

Control Unit相當于TCP服務器，同時控制著L1物理層測試工具，包括KSIM、Linalfs等。移動通信業(yè)務測試是在L1測試平臺上進行的，Control Unit會對測試過程和結果進行評估，我們可以在log窗口和單獨的統(tǒng)計窗口中觀察自動化測試相關的log信息和測試結果。

1.2 L1物理層測試平臺

L1物理層測試平臺是基于RRH（Remote Radio Head，射頻拉遠頭）建立的。Linalfs和KSIM等移動通信業(yè)務測試工具在平臺上執(zhí)行腳本命令，并在工具測試界面上返回測試結果。測試工具均采用腳本的方式運行，腳本語言為自定義關鍵字的形式，無需動態(tài)編譯，可以直接運行。這樣不僅節(jié)省了測試時間，而且還便于測試用例的構造。

RRH是用于移動寬帶網絡基站中的新技術設備，可以提升既有訊號的傳輸效率，并在更容易建置的網絡架構下擴大其網絡覆蓋率。RRH技術的特點是可以將基站分成無線基帶控制（Radio Server）和射頻拉遠兩部分。使用RRH技術可以靈活、有效地根據不同環(huán)境構建各種構造的網絡。

除了RRH，L1測試平臺還包括SUMX、RF回環(huán)盒、衰減器、合路器和電纜等。這些部件通過一定的連接方式共同構成了L1物理層測試平臺，如圖2所示。

2 移動通信業(yè)務自動化測試實例

2.1 測試目的

移動通信業(yè)務的測試包含了語音業(yè)務測試和數據業(yè)務測試等。以GSM基本業(yè)務測試為例，在初始化不同GSM載波、Abis接口和PA數的情況下，對物理層GSM基本業(yè)務進行了自動化測試，以檢測接收機的質量，例如接收信號的能力、抗各種干擾的能力以及抗各種無線環(huán)境的能力等。

GSM語音業(yè)務包含全速率語音業(yè)務和半速率語音業(yè)務。采用FR和HR編碼的語音業(yè)務，在不同編碼方案、時隙和信道配置下，驗證系統(tǒng)是否支持FR和HR編碼的移動用戶主叫業(yè)務功能和被叫業(yè)務功能。測試通過表示呼叫成功，主被叫語音正常。

GSM數據業(yè)務也包含全速率數據業(yè)務和半速率數據業(yè)務。在不同編碼方案、時隙和信道配置下，測試短消息業(yè)務，驗證系統(tǒng)是否支持移動用戶發(fā)送和接收短消息業(yè)務。測試通過表示在空閑和通話狀態(tài)下，MSA短消息發(fā)送成功，MSB能正確接收和顯示短消息。

2.2 測試腳本

GSM業(yè)務信道（TCH）攜載編碼語音或用戶數據，有兩類TCH，分別是全速率業(yè)務信道（TCH/F）和半速率業(yè)務信道（TCH/H）。在進行具體業(yè)務測試之前，需要對GSM載波、Abis接口和PA數進行初始化配置。其初始化配置腳本如表1所示，GSM基本語音業(yè)務和數據業(yè)務的測試腳本如表2所示。

RTS：時隙[0…7]

EN：ENC信道配置=12->[TSC=0，ACT=1，DTX=0，T/NT=0，SA=1，TC=0]

DE： DEC信道配置=11->[TSC=0，ACT=1，VGCS=0，T/NT=0，SA=0，A/N=1]

2.3 測試流程

在CI自動化測試平臺上進行GSM基本業(yè)務自動化測試時，將初始化腳本、語音，數據業(yè)務測試腳本和測試過程中需要用的所有其他腳本和參數均按執(zhí)行順序集成到SSQ腳本序列中，然后在SSQ腳本序列執(zhí)行過程中再去調用具體的scr腳本。

在初始化1個和2個GSM載波、Abis接口為1的情況下，將GSM語音業(yè)務和數據業(yè)務在不同編碼方案、時隙和信道配置下的所有測試集成到一個Jenkins job中，新建一個job，并進行相關配置，如圖3所示。

為避免一個job執(zhí)行的測試腳本命令過多，一般將完整業(yè)務的自動化測試分為多個job來執(zhí)行，比如將初始化1個和2個GSM載波、Abis接口為1作為一個job，將初始化1個和2個GSM載波、Abis接口為2作為一個job。以此類推，在初始化所有GSM載波、Abis接口和PA數的情況下將完整業(yè)務的自動化測試分為6個job來執(zhí)行。相關人員只需要在job配置項中選擇上一個執(zhí)行以及下一個執(zhí)行的job，即可按順序執(zhí)行6個job。

新建并配置完成Job后，在第一個job處點擊“Build Now”開始自動化測試。在點擊“Build Now”之前，要確保CIS-RC和Control Unit已經開始運行。

Jenkins執(zhí)行job首先調用CIS-RC，CIS-RC讀取相應job的XML文件，并參照XSD文件對其進行驗證，然后新建一個針對測試環(huán)境下應用Control Unit的TCP連接向Control Unit發(fā)送XML命令，Control Unit根據接收到的XML命令打開測試工具Linalfs、Ksim等，并執(zhí)行相關的SSQ腳本序列，最后待測試結束后將測試結果返回CIS-RC和Jenkins中。

Control Unit執(zhí)行SSQ腳本序列的過程如圖4所示。我們可以從Control Unit的log窗口看到整個測試的執(zhí)行過程，從Linalfs和Ksim界面看到正在執(zhí)行的語音或數據業(yè)務的case，從Running Test界面看到當前正在執(zhí)行的scr腳本和整個測試進程。

2.4 測試結果

在GSM基本業(yè)務測試過程中，一個case的結果是否通過主要看Linalfs測試結果界面上顯示的接收機的質量和幀誤率，然后參考表3作出評判。在測試語音業(yè)務時，測試通過表示呼叫成功，主被叫語音正常。在測試數據業(yè)務時，測試通過表示在空閑和通話狀態(tài)下，MSA短消息發(fā)送成功，MSB能正確接收和顯示短消息。

結果文件中，“Status=OK”表示所有語音和數據業(yè)務case均通過測試。除了XML結果文件，可以在Jenkins界面的Console Output上直接看到測試結果，如圖5所示。Console Output顯示為綠球，并且“Finished：SUCCESS”也表示測試通過，即在初始化所有GSM載波、Abis接口和PA數的情況下，GSM語音業(yè)務和數據業(yè)務在不同編碼方案、時隙和信道配置下均能正常工作。

3 結束語

軟件持續(xù)集成和自動化測試的引入在一定程度上解決了通信產品在軟件系統(tǒng)開發(fā)過程中的測試難題，避免了手動測試的大量人力投入，提高了測試的質量和研發(fā)速度，具有重要的現實意義。

本文基于Jenkins搭建了企業(yè)持續(xù)集成自動化測試平臺，并將所有流程都集成到Jenkins持續(xù)集成平臺上，實現了移動通信業(yè)務的自動化測試。其中，還具體介紹了CI自動化測試平臺的總體框架以及各模塊功能的構成和模塊之間的關系，并以GSM基本業(yè)務測試為例，介紹了整體的測試流程和測試輸出結果，最終使持續(xù)集成與自動化測試在項目中得以順利應用，達到了項目組預期的效果。

參考文獻

[1]劉昶.LTE語音測試解決方案[J].電信網技術，2013（03）.

[2]董宏成，張寧，李小文.基于TTCN-3的RRM小區(qū)重選過程一致性測試[J].電信科學，2013（4）.

[3]陳剛，羌鈴鈴.持續(xù)集成在項目中的分析與研究[J].電腦編程技巧與維護，2011，24.

[4]邢曉偉.持續(xù)集成在軟件開發(fā)過程中的應用[J].金陵科技學院學報，2014，04.

[5]James W，Jason A，Jeff C.Google軟件測試之道[M].黃利，李中杰，薛明，譯.北京：人民郵電出版社，2012.

[6]崔巖，姜良軍.基于GSM系統(tǒng)的TCH指配流程及優(yōu)化研究[J].山東通信技術，2014（1）.

〔編輯：王霞〕