在線計費接口消息檢測的方案研究

張晶晶，劉建，方有軒，范典華（中國移動（深圳）有限公司，深圳 518048）

?

在線計費接口消息檢測的方案研究

張晶晶，劉建，方有軒，范典華
（中國移動（深圳）有限公司，深圳 518048）

摘 要本文介紹了一種通過對真實的歷史接口消息進行有效的分析和比對，對接口消息進行檢測的方案，有效提高測試效率減少測試成本，是值得推廣的一種自動化檢測在線計費接口消息的方式。

關(guān)鍵詞在線計費；接口消息；檢測

1　研究背景

隨著中國移動業(yè)務(wù)種類和數(shù)量的不斷發(fā)展，中國移動通信集團公司委托中國移動（深圳）有限公司進行規(guī)范符合度的測試工作，以檢查各省的業(yè)務(wù)規(guī)范性，提高全網(wǎng)業(yè)務(wù)質(zhì)量。其中一項測試工作即為對在線計費業(yè)務(wù)的接口消息進行規(guī)范符合度檢測，本文主要針對該項測試任務(wù)。該測試任務(wù)有兩大步驟，首先實際生產(chǎn)環(huán)境下的接口消息數(shù)量大，需要從大量消息中找到屬于特定業(yè)務(wù)的消息；其次將找到的消息與標準消息進行比對。這兩項工作若采用人工篩選比對的方式工作量巨大，耗時長，而且準確率不高。為此需要借助計算機利用自動化方式提高測試效率和降低測試成本。簡言之，我們需要研究一種能篩選出某項特定業(yè)務(wù)的消息工具，即能根據(jù)一組條件篩選出符合預期的消息，更進一步，能將符合條件的消息進行更為詳細具體的檢測比對。

2　思路及目標

解決大海撈針第一步，撈的過程實際是條件篩選的過程，要解決這個問題首先需要對接口消息采用的協(xié)議進行解析。目前，接口消息采用的是《中國移動數(shù)據(jù)業(yè)務(wù)實時計費接口規(guī)范-v1.1.0》規(guī)定的DCCA協(xié)議：遵循Diameter基礎(chǔ)協(xié)議，DCCA協(xié)議是在Diameter基礎(chǔ)協(xié)議之上，根據(jù)數(shù)據(jù)業(yè)務(wù)在線計費的具體需求，設(shè)計的用于進行信用控制的應用層協(xié)議。解析協(xié)議需要將按網(wǎng)絡(luò)字節(jié)順序發(fā)送的16進制的原始消息根據(jù)協(xié)議規(guī)定解析為數(shù)值字符等，以便用戶通過易于理解的方式輸入特定條件。同時，篩選出的結(jié)果是發(fā)送的一個消息（簡稱為DCC消息），所以被篩選原始數(shù)據(jù)需要先被拆分為一條或多條的DCC消息。

篩選的條件主要是跟業(yè)務(wù)特征相對應，由于DCC消息的正文內(nèi)容實際為AVPs，AVP是封裝與Diameter消息相關(guān)的信息的一種方法，表現(xiàn)為AVP代碼和值對，所以可以將業(yè)務(wù)特征總結(jié)為對AVP代碼和值的限制條件。例如根據(jù)實際業(yè)務(wù)場景，可能需要查看是否包含一條初始請求CCR-I消息，且同時申請兩個業(yè)務(wù)的錯誤消息。該條件可通過AVP值對的方式表述為包含AVP代碼416取值為1，且包含兩個AVP代碼437，（416：CC-Request-Type，請求類型，取值1：INITIAL_REQUEST、2：UPDATE_REQUEST、3：TERMINATION_REQUEST； 437：Requested-Service-Unit，請求的服務(wù)單元，每個業(yè)務(wù)均需帶一個，多個業(yè)務(wù)需要攜帶多個此AVP），篩選條件如圖1所示。

圖1　篩選條件示例

總之，業(yè)務(wù)的篩選條件可總結(jié)為一條DCC消息需要包含某個AVP、包含某個特定取值的AVP、包含N個（N大于等于1）同一AVP代碼等。

篩選出特定業(yè)務(wù)相關(guān)的消息后，需要編寫測試用例對整個消息進行解析，并與根據(jù)規(guī)范編寫的用例進行測試比對，檢查該消息的符合度。

根據(jù)上述的思路，分別對拆分、解碼、篩選、比對等步驟進行詳細的說明，并構(gòu)建整體的解決方案和進行性能方面的優(yōu)化。

2.1 消息拆分

首先是消息拆分，因為作為原始數(shù)據(jù)輸入是直接從網(wǎng)絡(luò)設(shè)備利用分組抓取工具中獲取的原始的.cap包，此文件讀取到的是文件流或字符串等，需要先根據(jù)網(wǎng)絡(luò)協(xié)議對文件進行拆分。根據(jù)協(xié)議我們能獲取到如下信息。

（1）以太網(wǎng)幀協(xié)議中幀頭為固定字節(jié)數(shù)（14 byte），TCP頭中包含Length字段規(guī)定其長度、IP頭包含Length字段規(guī)定其長度，跳過上述長度后即為消息正文，故程序首先跳過54 byte。

（2）IP頭中包含Length字段，表示消息正文的長度n，故再跳過n字節(jié)后即為下一個消息的頭部。

（3）IP頭中包含Length字段若為0表示正文為空，根據(jù)幀協(xié)議傳輸?shù)拇笮∠拗疲@種情況需要補齊6 byte，已滿足最小長度的規(guī)定，即消息內(nèi)容為空的需要跳過字節(jié)，即為下一個消息的頭部。

程序根據(jù)上述條件將原始的.cap接口消息進行拆分，并舍棄消息頭只保留消息內(nèi)容，形成一條條的DCC消息。消息內(nèi)容為空的不保留。

作為方案的中間產(chǎn)出，在服務(wù)器上保留了拆分后眾多的DCC消息。

2.2 消息解碼與篩選

拆分后的消息全部為16進制的內(nèi)容，在進一步篩選出符合特定條件的DCC消息之前需要先對消息進行解碼。根據(jù)使用的DCCA協(xié)議，協(xié)議中規(guī)定了消息頭的固定格式，先解析出對應字段的相應值，包括與一個全量的文件進行比對，確認根據(jù)協(xié)議解析出來的AVP代碼確實存在；否則判斷為無效的DCC消息，并進入下一個消息；根據(jù)此協(xié)議將DCC消息進行解碼。主要是解碼為AVP代碼和值對的形式。并根據(jù)簡單易懂的條件組合進行篩選，進行條件匹配。

根據(jù)實際業(yè)務(wù)，在進行篩選需要支持能夠找出包含某個AVP代碼的消息、某個AVP代碼的具體取值等于特定值的消息、同一消息中一個或多個重復AVP代碼的消息，并支持上述情況的各類組合條件。

對于包含某個AVP代碼的消息的條件，需要遍歷整個AVP列表，確認是否包含；同一消息中一個或多個重復AVP代碼的條件，需要按照條件個數(shù)進行循環(huán)，并對已匹配過的進行標記在下一循環(huán)中剔除在范圍之外。若包含重復AVP代碼的同時還指定部分的具體取值，則找到該AVP代碼且值相當才算成功，進行下一輪循環(huán)。若其中一個值未找到則視為該消息不符合條件，而不繼續(xù)對下一條件進行循環(huán)。

2.3 消息比對

根據(jù)篩選出的消息，選擇其中一個或多個消息作為被測對象；根據(jù)規(guī)范對該業(yè)務(wù)的相關(guān)要求，編寫對應的測試用例，此時的測試用例會比篩選條件更為詳細，并將此作為參照對象，將被測對象與參照對象進行比對，測試他們之間的符合程度。

測試用例根據(jù)測試用例的模板來進行編制，模板分為CCR/CCA/RAR/RAA 4類，分別為CCR(Credit Control Request，信用控制請求 )，用命令碼設(shè)置為272，消息標志‘R’設(shè)置來表示，該命令用于信用控制的應答；CCA(Credit Control Answer，信用控制應答)，用命令碼設(shè)置為272，消息標志‘R’清除來表示，該命令用于信用控制的請求；業(yè)務(wù)重授權(quán)請求消息：在已建立的實時計費流程中，BOSS向GGSN、P-GW發(fā)送RAR消息，要求針對該Session-ID會話的用戶業(yè)務(wù)作重授權(quán)以及業(yè)務(wù)重授權(quán)響應消息。根據(jù)DCCA協(xié)議對這4種消息的規(guī)定，模板設(shè)置為包含所有必填AVP，并將非必填的設(shè)置為可下拉選擇，用戶可根據(jù)使用需求進行添加，并將全量的AVP和AVP取值進行取值或數(shù)量等進行限制，之后保存作為一個參照對象。同時由于各省各集成商的略有不同，一般需要分別編寫用例并進行保存。

由于用例的模板與被測對象的格式不一致，在比對的后臺執(zhí)行過程中需要首先將被測對象進行解析為DCCA協(xié)議規(guī)定的各個字段，解析的過程與上述消息解碼一致。此時與模板的格式與被測對象的均展現(xiàn)為AVP 和AVP取值的鍵值對的形式，再一一比對，并給出測試結(jié)果展示與規(guī)范的符合程度。

2.4 解決方案

為了提高效率整個方案分為Comp端和Agent端。Agent端提供上傳原始消息的入口，主要實現(xiàn)拆分和篩選，輸出拆分后的DCC消息。Comp端主要實現(xiàn)比對，用戶編寫測試用例作為比對的標準，將篩選后的消息形成測試對象，作為被比對對象。整體部署結(jié)果如下。

由于該測試各省公司均需要使用，各省同步檢測方案，為提升并行測試效率，在各省公司段各部署一套Agent端放在省公司，Comp端進行集中統(tǒng)一維護，需要打通Comp端服務(wù)器到各省公司的網(wǎng)絡(luò)以便省公司用戶能方便的訪問。同時為了使用上的歸一化利用Web Service配置好各省Agent端的地址，在Comp端統(tǒng)一提供上傳原始消息和編寫篩選用例的入口，拆分和篩選過程分配給對應省公司的Agent端具體執(zhí)行，最后將篩選的結(jié)果再通過Web Service傳回到用戶本機，以便作為消息比對的一端對象。

2.5 結(jié)構(gòu)性能優(yōu)化

在實際使用中發(fā)現(xiàn)Agent端拆分原始消息和篩選時耗時最長，為提升整個系統(tǒng)的性能需要提高Agent端的效率。本方案研究時采用的Agent端的基本配置為處理器Intel(R) Xeon(R) CPU E5649 @2.53 GHz 2.53 GHz。內(nèi)存4.0 GB。使用的原始輸入為cap包47.6 M，解析出來的消息（非空消息）數(shù)量為5.6萬條，以下性能數(shù)據(jù)均為在此配置下測試得到的。

在拆分階段通常情況下每兆的原始消息可以拆分出1 200條左右非空的消息，原始的輸入為一個完整文件，無法使用多線程來并行處理，且拆分時只解析了關(guān)鍵字段，無法再優(yōu)化。

篩選階段，耗時較長的情況是在篩選不到要求的消息，此時會將所有的消息遍歷一次，而遍歷的數(shù)量多達數(shù)萬條。系統(tǒng)使用了多線程進行處理，目前使用的是每10 000條消息使用一個線程進行處理的方式，將耗時縮短為原來的1/3(按照常用的30 M的原始文件，拆分為3萬多條消息作為被篩選對象進行的測試)，而對于很快找到消息的條件，耗時基本無變化，可在3～5 s內(nèi)完成。

另外，對于多線程數(shù)量的選取，與處理的篩選條件、消息數(shù)量、服務(wù)器硬件配置等均密切相關(guān)。若篩選條件簡單（如包含416，篩選數(shù)量10個），則線程數(shù)在6個與12個，即每個線程處理10 000條和5 000條，耗時分別為4 s和5 s，此時線程數(shù)越多反而會影響效率；若篩選條件復雜（需要將所有的消息遍歷一次），則線程數(shù)6個與12個耗時差不多均在8 min左右，而線程數(shù)為1則需15 min以上。

消息數(shù)量越多在服務(wù)器性能指標上線的條件下線程數(shù)越多耗時越短；硬件配置越高，線程數(shù)越多耗時越短。所以在實際使用時，需要考慮本身篩選的條件的復雜率（復雜條件占比）、消息數(shù)量等，不能因為條件復雜的耗時有所減少，而犧牲大部分情況下條件簡單的效率等，也不能因為消息數(shù)量多的耗時有所減少，而犧牲大部分情況下消息數(shù)量少的效率等。

3　實施與效果

3.1 整體部署圖

根據(jù)上述解決方案中的設(shè)計，整體的部署圖如圖2所示。

Comp端提供整體的訪問入口，所有用戶均通過一個固定的入口訪問系統(tǒng)。在下發(fā)具體的各個省公司的拆分解析篩選任務(wù)時，Comp端根據(jù)配置將任務(wù)轉(zhuǎn)發(fā)到省公司的Agent端服務(wù)器進行執(zhí)行，并將篩選結(jié)果直接返回給用戶。用戶執(zhí)行下一步的比對時，統(tǒng)一由Comp端的服務(wù)進行。此方案的網(wǎng)絡(luò)要求各省公司用戶能訪問深圳中心的Comp端服務(wù)器，Comp端與各省Agent端能相互訪問。

3.2 減少成本和提高測試質(zhì)量

根據(jù)上述的實施方案利用此系統(tǒng)能大大減少測試的人力成本進而減少測試費用，也能減少測試時間，提高測試的整體效率。下面以一個實際的例子來進行說明。

一個省公司給的原始cap包47.6 M，解析出來的消息（非空消息）數(shù)量為5.6萬條，所需時間為2 min，全部遍歷進行篩選需要8 min，比對只需幾秒鐘。即如果通過系統(tǒng)來完成包括編寫用例的準備工作和操作時間大概為12 min，而人工篩選時可以通過已有工具進行解析，解析后篩選要一條一條的人工看相關(guān)字段，將一個條件和各個條件取平均值約每條2 s，總計約31 h。自動化方式耗時相當于人工時間的0.65%，即人力成本和時間成本均較之前減少了99.35%。

同時由于人工操作時對象數(shù)量達到上萬級別時，人工識別的正確率會大大減少，所以自動化方式也能提高測試質(zhì)量，減少人工失誤。

圖2　整體部署圖

4　結(jié)論

通過在線計費接口消息檢測系統(tǒng)，能夠有效減少測試費用和測試時間，尤其是人力成本，更快更及時更準確的監(jiān)測各省建設(shè)質(zhì)量，減少不規(guī)范的建設(shè)數(shù)量，提升客戶感知。由于各省建設(shè)方案質(zhì)量的提升，更能提升中國移動的品牌價值，這是潛在的經(jīng)濟效益。

參考文獻

[1] W.Richard Stevens.TCP/IP詳解 卷1:協(xié)議[M]. 北京: 機械工業(yè)出版社, 2000.

Scheme research on testing the interface message of online billing business

ZHANG Jing-jing, LIU Jian, FANG You-xuan, FAN Dian-hua
(China Mobile (Shenzhen) Co., Ltd., Shenzhen 518048, China)

AbstractThis paper introduces a kind of scheme then provide an effective analysis and comparison of the interface message through the real historical interface. It can effectively improve the test effi ciency and reduce the test cost. It’s a way to promote the automated testing of online billing interface message.

Keywordsonline billing business ; interface message ; testing

收稿日期：2015-11-02

中圖分類號TN915

文獻標識碼A

文章編號1008-5599（2016）02-0061-04