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

?

在線計(jì)費(fèi)接口消息檢測的方案研究

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

摘 要本文介紹了一種通過對(duì)真實(shí)的歷史接口消息進(jìn)行有效的分析和比對(duì)，對(duì)接口消息進(jìn)行檢測的方案，有效提高測試效率減少測試成本，是值得推廣的一種自動(dòng)化檢測在線計(jì)費(fèi)接口消息的方式。

關(guān)鍵詞在線計(jì)費(fèi)；接口消息；檢測

1　研究背景

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

2　思路及目標(biāo)

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

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

圖1　篩選條件示例

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

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

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

2.1 消息拆分

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

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

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

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

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

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

2.2 消息解碼與篩選

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

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

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

2.3 消息比對(duì)

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

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

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

2.4 解決方案

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

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

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

在實(shí)際使用中發(fā)現(xiàn)Agent端拆分原始消息和篩選時(shí)耗時(shí)最長，為提升整個(gè)系統(tǒng)的性能需要提高Agent端的效率。本方案研究時(shí)采用的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條左右非空的消息，原始的輸入為一個(gè)完整文件，無法使用多線程來并行處理，且拆分時(shí)只解析了關(guān)鍵字段，無法再優(yōu)化。

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

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

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

3　實(shí)施與效果

3.1 整體部署圖

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

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

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

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

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

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

圖2　整體部署圖

4　結(jié)論

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

參考文獻(xiàn)

[1] W.Richard Stevens.TCP/IP詳解 卷1:協(xié)議[M]. 北京: 機(jī)械工業(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

中圖分類號(hào)TN915

文獻(xiàn)標(biāo)識(shí)碼A

文章編號(hào)1008-5599（2016）02-0061-04