時間：2023-03-15 15:07:22
序論：在您撰寫接口測試時，參考他人的優(yōu)秀作品可以開闊視野，小編為您整理的7篇范文，希望這些建議能夠激發(fā)您的創(chuàng)作熱情，引導(dǎo)您走向新的創(chuàng)作高度。
關(guān)鍵詞：Iur-g+接口; TD-SCDMA; GSM; 切換; 測試方案
中圖分類號：TN929.53-34文獻(xiàn)標(biāo)識碼：A 文章編號：1004-373X(2011)21-0112-03
Analysis of Iur-g+ Interface Testing Program
ZHAO Dong
(China Mobile Group Design Institute Co. Ltd., Xi’an 710077, China)
Abstract：
To switch voice service between GSM and TD-SCDMA network, an experiment of Iur-g+ interface was performed by China Mobile. China Mobile performed field test in various typical wireless environment though upgrading and constructing network elements. Compared the data of switching on with the data of switching off about Iur-g+ interface, the Iur-g+ interface performance of these equipment manufactures were gained. The program of interface test and the notice in testing provide relative methods for further test in Iur-g+ functions.
Keywords： Iur-g+ interface; TD-SCDMA; GSM; handover; test program
收稿日期：2011-05-22
0 引 言
隨著TD-SCDMA網(wǎng)絡(luò)規(guī)模不斷擴(kuò)大，如何將全新的3G網(wǎng)絡(luò)與GSM網(wǎng)絡(luò)充分融合，成為中國移動的┮桓鼉藪筇粽劍而兩張網(wǎng)絡(luò)之間的互操作問題則是挑戰(zhàn)的重點(diǎn)之一。通過分析傳統(tǒng)的2G/3G語音切換信令流程可知，切換信令串行通過了所有網(wǎng)元，其時延大大降低了系統(tǒng)對切換判決的及時性、準(zhǔn)確性，也降低了切換的成功率。
Iur接口是3G系統(tǒng)中兩個RNC之間的邏輯接口，用來傳送RNC之間的控制信令和用戶數(shù)據(jù)。在應(yīng)用中發(fā)現(xiàn)了上述問題后，為提高2G/3G網(wǎng)絡(luò)之間切換的成功率，3GPP的R5版本協(xié)議中在GERAN里引入了Iur-g+接口［1-2］。該接口可以支持兩個BSC之間、BSC和RNC之間的測量、負(fù)載信息交互，避免因網(wǎng)絡(luò)資源緊張而造成的切換失敗，同時可以提前進(jìn)行無線資源的準(zhǔn)備，有效地降低了切換的時延。
1 Iur-g+接口的位置
圖1給出Iur-g+接口的位置\[3-4\]。Iur-g+接口的出現(xiàn)改變了原有的切換流程，雖然不需要終端的配合，但是對系統(tǒng)側(cè)BSC,RNC之間，以及核心網(wǎng)的配合上仍提出了一定的要求。
圖1 Iur-g+接口在網(wǎng)絡(luò)中的位置
2 Iur-g+接口原理及效果
標(biāo)準(zhǔn)的Iur-g+包含信息交互、公共測量兩個流程［1-2］。信息交互流程用于在RNC和BSC之間交換不同系統(tǒng)下配置的小區(qū)無線資源容量信息，而公共測量流程則以負(fù)荷(LOAD)的方式在RNC與BSC之間報告當(dāng)前無線資源占用情況，使雙方可以用切換目標(biāo)系統(tǒng)的負(fù)荷作為切換判決條件。
2.1 正常切換信令流程
在增加了Iur-g+接口后，無線側(cè)3G2G的切換信令流程有所調(diào)整，圖2為調(diào)整后的3G2G正常切換的信令流程\[2，4-5\]。
圖2 Iur-g+切換流程
從流程圖中可以看到，新增的Iur-g+接口信令改變了原有的RNC與核心網(wǎng)之間的信令順序。BSC收到RNC發(fā)出的重定位請求后，以IMSI為標(biāo)識，為用戶分配相應(yīng)的無線資源，RNC在收到資源確認(rèn)消息后，向核心網(wǎng)發(fā)出重定位請求，并在空口緩發(fā)定時器規(guī)定的時間到達(dá)后直接向UE發(fā)送切換指令；同時，核心網(wǎng)與BSS之間僅需要根據(jù)IMSI標(biāo)識建立承載后，即可為UE提供服務(wù)，而RNC在收到核心網(wǎng)發(fā)來的重定位指令后不再對UE進(jìn)行任何處理。
這種切換的處理方式將原有的串行信令流程中的部分流程變?yōu)椴⑿刑幚?，因此提高了切換的時延，同時，由于切換時首先進(jìn)行了BSS側(cè)的無線資源分配，標(biāo)準(zhǔn)中還增加了BSC資源預(yù)留失敗流程［4,6-7］，還提高了在GSM高負(fù)荷區(qū)域的切換功率。
2.2 現(xiàn)網(wǎng)測試結(jié)果
根據(jù)廠家的支持情況，早在2009年5月―2010年1月間，現(xiàn)網(wǎng)已有部分同廠家BSC/RNC之間的Iur-g+接口進(jìn)行了測試。從測試的結(jié)果可以看到，主要KPI在開啟Iur-g+重定位流程后沒有出現(xiàn)下降的情況。通過開啟Iur-g+功能后，提高了切換準(zhǔn)備成功率；而優(yōu)化的切換流程縮短了切換的時延，也有效地提高了切換成功率。
3 Iur-g+接口測試方案
3.1 測試目標(biāo)
根據(jù)Iur-g+接口的主要功能，測試主要關(guān)注切換成功率的改善情況，同時還需要分析以下消息及其流程［8-9］：
Iur-g+接口消息流程［4］；
Iur-g+接口公共測量流程［4,7］；
Iur-g+接口重定位流程［4,10］。
3.2 測試方案
根據(jù)Iur-g+接口測試目標(biāo)，測試分為兩階段。第一階段選取特殊場景進(jìn)行路測，驗證Iur-g+接口的可用性及對特殊場景的改善效果，第二階段測試針對現(xiàn)網(wǎng)用戶，進(jìn)行大范圍的網(wǎng)絡(luò)性能檢測，驗證Iur-g+接口的穩(wěn)定性等其他性能。
第二階段測試僅需要在打開Iur-g+重定位流程后觀察KPI、切換性能等指標(biāo)，而在第一階段測試方案中應(yīng)包含以下重點(diǎn)內(nèi)容。
(1) 搭建測試平臺
測試平臺包括RAN,BSS,NSS系統(tǒng)的所有網(wǎng)元，其中NodeB、BTS由于需求量較大、重新建設(shè)難度高，可直接使用現(xiàn)網(wǎng)設(shè)備。RNC,BSC的選擇則考慮網(wǎng)絡(luò)安全性選擇新建實驗網(wǎng)。由于測試中RNC,BSC需要分別進(jìn)行共用MSC和跨MSC兩種方式的切換測試，因此，核心網(wǎng)部分一般也建議采用現(xiàn)網(wǎng)網(wǎng)元升級的方式進(jìn)行測試。
(2) 選擇測試區(qū)域
根據(jù)Iur-g+的功能特點(diǎn)，其主要目標(biāo)為降低切換時延、提高切換成功率，現(xiàn)網(wǎng)中主要應(yīng)選取具有街角效應(yīng)的快衰落場景、2G話務(wù)量較高導(dǎo)致切換準(zhǔn)備成功率低的場景、高速移動場景進(jìn)行測試。
(3) 系統(tǒng)升級方案
現(xiàn)網(wǎng)網(wǎng)元應(yīng)根據(jù)各廠家的不同要求，進(jìn)行軟件版本的升級，以支持Iur-g+功能。
對于新建實驗網(wǎng)方式進(jìn)行測試的，可直接使新建網(wǎng)元具備相應(yīng)版本軟件。
(4) 系統(tǒng)數(shù)據(jù)倒換方案
根據(jù)測試的要求，測試區(qū)域必須在開啟Iur-g+重定位流程與傳統(tǒng)重定位流程之間每日切換，因此需要準(zhǔn)備兩套完整的設(shè)置數(shù)據(jù)，并做好替換腳本，在每天的固定時間進(jìn)行數(shù)據(jù)倒換，使統(tǒng)計指標(biāo)能夠進(jìn)行每日對比。
(5) 路測方案
在確定測試區(qū)域后，要根據(jù)這些區(qū)域的具體情況建立路測方案。需要注意的是，由于本測試是以檢查2G/3G之間的切換流程為主要目標(biāo)的，因此，本次路測也主要以產(chǎn)生2G/3G間的切換為目標(biāo)。
同時，為達(dá)到增加切換次數(shù)的目的，有必要在測試區(qū)域采取降低發(fā)射功率、調(diào)整切換門限等人為因素來控制切換點(diǎn)位置、提高切換數(shù)量。
在測試完成后，剔除不合理數(shù)據(jù)，結(jié)合測試時同步采集的信令監(jiān)控數(shù)據(jù)進(jìn)行分析。
(6) 系統(tǒng)割接方案
系統(tǒng)割接包括基站割接，RNC，BSC的共MSC及跨MSC測試割接。
為保證2G/3G覆蓋區(qū)域重合，首先將區(qū)域內(nèi)的NodeB(BTS)割接至測試所使用的RNC(BSC)上。其次將新建的實驗網(wǎng)設(shè)備(RNC/BSC)掛接在同一MSC下進(jìn)行2G/3G共MSC的測試，完成后將RNC的Iu-CS接口割接至另一MSC下進(jìn)行2G/3G跨MSC的測試。
在搭建實驗網(wǎng)的測試環(huán)境下進(jìn)行網(wǎng)絡(luò)割接較為方便，無需調(diào)整數(shù)量繁多的基站割接，但跨局進(jìn)行RNC割接時，修改局?jǐn)?shù)據(jù)較多，應(yīng)隨時監(jiān)控網(wǎng)絡(luò)質(zhì)量，以降低網(wǎng)絡(luò)調(diào)整帶來的風(fēng)險。
以上是Iur-g+測試方案中的一些重點(diǎn)問題。在考慮上面技術(shù)問題的基礎(chǔ)上，還需要注意的是，本次測試涉及了全網(wǎng)所有類型的網(wǎng)元，因此，在各維護(hù)部門之間的人力資源協(xié)調(diào)、工期協(xié)調(diào)方面都需要注意，避免影響測試進(jìn)度。
3.3 測試方案分析
3.3.1 可行性
(1) 網(wǎng)絡(luò)結(jié)構(gòu)
如在現(xiàn)網(wǎng)基礎(chǔ)上進(jìn)行測試，可直接升級軟件版本，方案中確認(rèn)了升級進(jìn)度與測試進(jìn)度的配合；如采用新建RAN/BSS網(wǎng)元，可利用在建未入網(wǎng)的設(shè)備進(jìn)行測試；
(2) 網(wǎng)絡(luò)安全
不論是否利用現(xiàn)網(wǎng)RAN/BSS網(wǎng)元進(jìn)行測試，在測試區(qū)域中的基站仍然要負(fù)載正常用戶的業(yè)務(wù)，方案中利用晚間啟閉Iur-g+功能，降低了對普通用戶的影響，并且在系統(tǒng)升級、割接方面考慮到了方案的復(fù)雜性，盡可能降低測試對網(wǎng)絡(luò)的影響。
3.3.2 有效性
覆蓋面
測試方案包含了從核心網(wǎng)到終端之間的所有網(wǎng)元，可以檢驗在Iur-g+重定位流程開啟的情況下，對其他網(wǎng)元的影響情況，和其他網(wǎng)元與該流程的配合情況。
測試區(qū)域
本方案的測試區(qū)域包含了大多數(shù)日常無線環(huán)境，并對Iur-g+接口應(yīng)用效果較為明顯的部分特殊場景進(jìn)行了測試。
路由完整
測試方案包括了RNC/BSC共用MSC和跨MSC兩種情況，使測試能夠模擬規(guī)模應(yīng)用后的所有信令交互流程。
用戶模擬
在路測過程中，會產(chǎn)生大量3G2G的切換過程，盡可能模擬用戶行為對Iur-g+接口進(jìn)行測試，并且在第二階段測試用開啟1~2個RNC的Iur-g+接口，完全利用普通用戶的行為對Iur-g+接口進(jìn)行測試。
綜上所述，該方案能夠可以在較少影響現(xiàn)網(wǎng)的情況下，有效地驗證Iur-g+接口的性能，并能夠記錄下Iur-g+接口應(yīng)用后各網(wǎng)元可能產(chǎn)生的問題，為Iur-g+接口正式應(yīng)用打好基礎(chǔ)。
4 重點(diǎn)關(guān)注問題
4.1 對現(xiàn)網(wǎng)的影響
由于第二階段測試的需求，測試基站必須使用現(xiàn)網(wǎng)基站以保證覆蓋區(qū)域內(nèi)的用戶數(shù)量。這就需要在測試效果、工程難易度、對現(xiàn)網(wǎng)VIP用戶的影響等多方面因素之間權(quán)衡，既要保證測試的有效性，也要降低對在網(wǎng)用戶的影響。
同時，如果采用現(xiàn)網(wǎng)升級的方式進(jìn)行測試平臺的搭建，還需要注意各廠家軟件升級的粒度為OMC。如果該OMC下掛網(wǎng)元數(shù)量較多，則會帶來升級時間長、影響范圍大、測試版本軟件穩(wěn)定性不高等問題。
因此，建議在有條件的情況下，第一階段測試盡可能采用搭建專用測試平臺的方式，減少軟件升級范圍，降低對現(xiàn)網(wǎng)的影響。在第二階段測試時，選擇少量RNC覆蓋區(qū)域進(jìn)行測試。
4.2 各種接口的傳輸方式
采用新建實驗網(wǎng)的方式中，涉及到BSC、RNC與基站傳輸、軟交換、SGSN等網(wǎng)元的連接，在現(xiàn)網(wǎng)傳輸、軟交換端口等資源都比較緊張的情況下，需要合理的設(shè)置新增網(wǎng)元的位置、接口類型等。對于現(xiàn)網(wǎng)已經(jīng)IP化的端口，應(yīng)盡量使用IP接口鏈接，傳統(tǒng)的E1鏈接方式由于涉及工程量大、割接復(fù)雜，不推薦使用。
4.3 測試場景的選擇
測試場景要滿足前面所述的幾種特殊場景的要求，部分不易選取場景可以考慮使用人工調(diào)整的方式，滿足測試要求，待第一階段測試完成后，返回正常設(shè)置。
5 結(jié) 語
Iur-g+技術(shù)可提高3G2G的切換成功率，降低切換時延，有效地提升用戶在2G/3G網(wǎng)絡(luò)切換區(qū)域的感受。本文通過分析Iur-g+接口測試的重點(diǎn)內(nèi)容，并根據(jù)工作經(jīng)驗提出了部分注意事項，希望能夠為后續(xù)Iur-g+接口測試工作起到一定的引導(dǎo)作用。
參考文獻(xiàn)
［1］3GPP.TS 25.422 UTRAN Iur interface signalling transport \[M\]. \[S.l.\]: 3GPP, 2009.
［2］3GPP.TS 25.423 UTRAN Iur interface RNSAP signalling \[M\]. \[S.l.\]: 3GPP, 2005.
［3］3GPP.TS 25.420 UTRAN Iur interface general aspects and principles \[M\]. \[S.l.\]: 3GPP, 2010.
［4］3GPP.TS 25.421 UTRAN Iur interface layer 1\[M\].\[S.l.\]:3GPP,2009.
［5］中國移動通信有限公司.中國移動TD-SCDMA Iur-g+接口方案總體技術(shù)要V1.2.0\[S\].北京：中國移動通信有限公司,2010.
［6］3GPP.TS 25.424 UTRAN Iur interface data transport & transport signalling for Common Transport Channel data streams \[M\]. \[S.l.\]: 3GPP, 2006.
［7］3GPP.TS 25.425 UTRAN Iur interface user plane protocols for Common Transport Channel data streams \[M\]. \[S.l.\]: 3GPP,2008.
［8］中國移動通信有限公司.2-3G無線網(wǎng)融合測試規(guī)范(Iur-g+)_V2.0.2\[S\].北京：中國移動通信有限公司，2009.
［9］中國移動通信有限公司.2G與TD網(wǎng)絡(luò)融合Iur-g+接口外場測試方案要求\[S\].北京：中國移動通信有限公司，2010.
［10］3GPP.TS 25.426 UTRAN Iur and Iub interface data transport & transport signalling for DCH data streams \[M\]. \[S.l.\]: 3GPP,2006.
關(guān)鍵字：高速串行接口測試，T2000，6GSPM，HDMI
1 高速串行接口簡介
隨著各類電子設(shè)備對數(shù)據(jù)傳輸速率提出了越來越高的要求，高速串行接口正被越來越多地應(yīng)用到了各類電子設(shè)備中。高速串行接口通過串行的方式逐位發(fā)送和接受數(shù)據(jù)，可以在保證高數(shù)據(jù)傳輸速率的同時避免并行接口中常見的通道間互相串?dāng)_等問題。USB、SATA、PCI Express、HyperTransport、HDMI、Display Port等當(dāng)今流行的接口均屬于高速串行接口。圖1所示的PC機(jī)內(nèi)部結(jié)構(gòu)圖很好地從一個側(cè)面反映了高速串行接口的普及程度?？梢哉f，高速串行接口已經(jīng)完全融入到了人們的日常生活中。
2 高速串行接口的測試需求
在高速串行接口的測試中存在著一系列的挑戰(zhàn)：
1)產(chǎn)生和比較高速數(shù)字信號
高速串行接口的傳輸速率通常在Gbps級別。例如HDMI每通道的傳輸速率為3.4Gbps；USB 3.0的傳輸速率為5.0Gbps；SATA 3.0的傳輸速率為6Gbps。要測定此類高速串行接口，測試設(shè)備就必須能夠產(chǎn)生和采集相應(yīng)速率的數(shù)字輸入信號。
此外，由于傳輸通路中的空間電容、電感的影響，高速數(shù)字信號在傳輸過程中無可避免地會發(fā)生畸變(主要表現(xiàn)在0／1之間的跳變趨于平緩)。此時就需要信號發(fā)生端具備Pre-Emphasis功能，通過在發(fā)生信號時強(qiáng)化跳變沿來抵消空間電容、電感對傳輸信號施加的影響。
2)支持各種時鐘類型
高速串行接口的時鐘通?？梢苑譃槿悾簳r鐘頻率與數(shù)據(jù)速率保持1：1(sDR)或1：2(DDR)的Source Synchronous時鐘、時鐘頻率遠(yuǎn)低于數(shù)據(jù)速率的Forwarded Clock(如HDMI接口中的TMDS時鐘頻率僅為TMDS數(shù)據(jù)速率的1／10)，以及將時鐘信息通過編碼算法嵌入到數(shù)據(jù)流中的EmbeddedClock。
高速串行接口的測試設(shè)備應(yīng)當(dāng)能夠靈活對應(yīng)各利，類型的時鐘信號。
3)Jilter注入測試能力
高速串行接口必須對輸入信號中的Jitter有一定的容忍度。為了測定該指標(biāo)，就需要測試設(shè)備能夠向發(fā)送給高速串行接口的數(shù)字信號中注入各種頻率及強(qiáng)度的Jitter。
4)誤碼率測試能力
誤碼率測試是高速串行接口測試中的一項重要指標(biāo)。它體現(xiàn)了高速串行接口的輸出信號質(zhì)量與準(zhǔn)確度。
5)眼圖繪制能力
眼圖是用來評價高速串行接口輸出信號質(zhì)量的重要工具。通過分析眼圖，可以方便地評價信號的寬度、幅度、Jitter等一系列參數(shù)。
6)Loopback測試回路
為便于測試，不少高速串行接口提供了Loopback測試功能。測試設(shè)備需具備Loopback測試回路，才能實現(xiàn)高速串行接口的Loopback測試。3基于T2000的高速串口測試方案
T2000是愛德萬測試(ADVANTEST)基于開放式模塊化的一種全新概念的測試平臺。它采用了完全開放的構(gòu)架從真正意義上實現(xiàn)了擴(kuò)展性、靈活性以及經(jīng)濟(jì)性。
T2000測試系統(tǒng)由各種不同功能的軟硬件模塊(Module)組成，也就是所謂的模塊化架構(gòu)。這種構(gòu)架的優(yōu)點(diǎn)在于：
系統(tǒng)靈活，擁有持續(xù)升級的可能性。
方便硬件更換和升級，使測試系統(tǒng)升級配置時的投資達(dá)到最小化。
減少人力成本，升級后沿用同一平臺／環(huán)境，測試人員可以很快熟悉新(配置)系統(tǒng)。
這種針對多樣化的產(chǎn)品群體、具有可以靈活應(yīng)用的模塊化結(jié)構(gòu)的測試系統(tǒng)可以利用相同的技術(shù)環(huán)境，實現(xiàn)產(chǎn)品開發(fā)方面的高性能化及批量生產(chǎn)方面的低成本化。通過不同級別模塊的開發(fā)，擴(kuò)大技術(shù)解決能力，同時有效地縮短開發(fā)時間。
針對高速串行接口的特點(diǎn)，ADVANTEST的T2000提供了6GSPM測試模塊，可充分滿足高速串行接口的測試需求：
1)充足的高速測試通道資源
T2000 6GSPM可以支持最高6.375Gbps的測試速率，充分滿足HDMI(3.4Gbps)、USB 3.0(5 0Gbps)、SATA 3.0(6Gbps)等各種高速串行接口的測試需求。
每塊6GSPM包含16組測試通道，每組測試通道又包含一對差分高速信號發(fā)生回路和一對差分高速信號采集回路。
其中的高速差分信號發(fā)生回路支持Pre-Emphasis功能，可通過強(qiáng)化跳變沿來抵消空間電容與電感對信號質(zhì)量的影響。圖4為T20006GSPM使用Pre-Emphasis功能前后的波形質(zhì)量對比。
2)支持各種主流時鐘類型
T2000 6GSPM內(nèi)置PLL倍頻回路及CDR(Clock Data Recover)回路，可以支持Sourcesvnchronous Clock(包括SDR和DDR)、ForwardedClock、Embedded Clock等各種主流時鐘類型。
3)具備時鐘源同步功能
高速數(shù)字電路的內(nèi)部時鐘或多或少地會存在Jitter。這類Jitter會導(dǎo)致高速串行接口輸出的時鐘信號和數(shù)據(jù)信號發(fā)生同步的漂移。T2000 6GSPM支持時鐘源同步功能，可以通過判別高速串行接口輸出的時鐘沿的位置來調(diào)整各數(shù)據(jù)通道的采樣時刻，從而消除高速串行接口輸出的時鐘與數(shù)據(jù)之間的同源Jitter。
4)具備Jitter注入測試功能
T2000 6GSPM內(nèi)置Jitter發(fā)生回路，可根據(jù)程序設(shè)置向高速串行接口的輸入信號中注入30KHz～25MHz的Jitter(幅度為20ps～700ps可設(shè)定)，測定高速串行接口對Jitter的容忍度。
5)具備眼圖繪制功能
T2000 6GSPM可通過連續(xù)掃描采樣時刻和門限電壓繪制出眼圖，方便對高速串行接口的輸出信號質(zhì)量進(jìn)行分析。
6)支持Loopback測試
T2000 6GSPM支持Loopbaek測試。它可將從高速串行接口TX端接收到的數(shù)據(jù)發(fā)往高速串行接口的RX端，并可在Loopback測試的同時分析高速串行接口的誤碼率及Jitter容忍度。
7)豐富的圖形界面工具
T2000內(nèi)置了豐富的圖形界面工具，可方便用戶對測試程序及待測器件進(jìn)行調(diào)試。通過系統(tǒng)內(nèi)置的圖形界面工具，用戶可以方便地調(diào)整測試參數(shù)、繪制Shmoo圖、眼圖、澡盆圖，對高速串行接口的性能進(jìn)行評價。
4 總結(jié)
當(dāng)今，高速串行接口正得到越來越廣泛的應(yīng)用。高速芯片不同于普通低速SoC的特點(diǎn)帶來了芯片測試的挑戰(zhàn)。高速芯片需要更先進(jìn)的測試方法來進(jìn)行評價與量產(chǎn)測試，包括：
1)高速差分信號發(fā)生與采集回路
2)Pre-Emphasis功能
3)CDR(Clock DataRecover)功能
4)時鐘源同步功能
5)Jitter注入功能
6)與多種高速串行接口兼容
Advantest T2000擁有豐富強(qiáng)大的測試功能，其中的6GSPM測試模塊為高速串行接口芯片提供了全面的測試解決方案。
參考文獻(xiàn)
[1]《High Speed Serial Interfaces Testing Solution》――ADVANTEST
[2]《HDMI Specification Ver.l.4a》――省略
[3]《T2000 6Gbps Serial Port Module ProductDescription》――ADVANTEST
[4]省略
關(guān)鍵詞：CORBA; DII; Java
中圖分類號：TP311文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044(2008)06-11010-02
The Design and Implementation of the CORBA Server Interfaces Test Tool
BI Xue-jun,XIAO Qing,HAO Na
(Department of Information Engineering of Academy of Armored Force Engineering,Beijing 100072,China)
Abstract: The paper introduces the design and implementation of the CORBA server interfaces test tool CTester. It is independent of platform, providing a graphic user interface,supporting for script definition and dynamic invocation. It provides an easy way to test distribute system.
Key words: CORBA(Common Object Request Broker Architecture); DII (Dynamic Invocation Interface); Java
1 引言
隨著Internet的廣泛運(yùn)用，將應(yīng)用擴(kuò)展到局域網(wǎng)、廣域網(wǎng)甚至Internet上已成為用戶的普遍需求，為此分布式計算成了新的熱點(diǎn)。在分布式計算環(huán)境中，異構(gòu)性是一個十分明顯的特點(diǎn)。一個典型的分布環(huán)境包括有大型主機(jī)、UNIX工作站和PC機(jī)，各種機(jī)器所采用的操作系統(tǒng)和網(wǎng)絡(luò)通信協(xié)議也是千差萬別，在這樣的異構(gòu)環(huán)境下實現(xiàn)信息和軟件資源的共享將十分困難，而一個健壯的分布計算框架將為分布應(yīng)用軟件的開發(fā)帶來極大的好處。為了實現(xiàn)這一目標(biāo)，OMG組織于1991年提出了公用對象請求程序結(jié)構(gòu)的技術(shù)規(guī)范CORBA[1]（Common Object Request Broker Architecture，通用對象請求體系結(jié)構(gòu)）。CORBA規(guī)范充分利用了現(xiàn)今軟件技術(shù)發(fā)展的最新成果，在基于網(wǎng)絡(luò)的分布式應(yīng)用環(huán)境下實現(xiàn)應(yīng)用軟件的集成，使得面向?qū)ο蟮能浖诜植?、異?gòu)環(huán)境下實現(xiàn)可重用、可移植和互操作。
要想編寫一個良好健壯的CORBA應(yīng)用程序，首先需要進(jìn)行有效的測試。一般的測試過程是，開發(fā)人員編寫完CORBA服務(wù)器程序后，首先花費(fèi)一定的時間開發(fā)客戶程序來調(diào)用CORBA服務(wù)器對象。如果要針對大量的各種輸入數(shù)據(jù)進(jìn)行測試，那么客戶端測試程序的開發(fā)工作量將會很大。因此需要研制開發(fā)CORBA服務(wù)器接口測試工具，進(jìn)行有效的CORBA對象接口測試，驗證CORBA接口實現(xiàn)的正確性。
2 系統(tǒng)設(shè)計
該CORBA服務(wù)器接口測試工具以下簡稱為CTester，它能夠向CORBA對象調(diào)用指定的操作，獲取或設(shè)置CORBA對象的屬性，驗證CORBA接口的實現(xiàn)，其參數(shù)設(shè)置方便，測試結(jié)果顯示直觀。支持測試腳本定義，用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復(fù)使用。該工具完全采用java編寫，遵從CORBA2.3規(guī)范[2]，工作平臺為IONA公司的orbix2000[3]。
2.1 設(shè)計原則
Ctester測試工具在開發(fā)過程中，遵循以下幾個原則：
1)平臺無關(guān)性：測試工具的運(yùn)行應(yīng)保證與操作系統(tǒng)無關(guān)，因此系統(tǒng)采用JAVA語言實現(xiàn)；
2)使用簡便靈活：采用圖形化GUI界面，使用簡便靈活，顯示結(jié)果直觀，操作易于掌握；
3)支持腳本定義：用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復(fù)使用；
4)采用動態(tài)調(diào)用DII：動態(tài)方式允許對任意對象進(jìn)行操作，借助接口庫，動態(tài)方式可以在運(yùn)行時刻查詢各對象所支持的操作，無論是操作的對象、發(fā)起調(diào)用的參數(shù)，還是發(fā)起調(diào)用的次數(shù)等等都可以由客戶程序在運(yùn)行時刻視當(dāng)時環(huán)境和需要而決定。因此，采用動態(tài)方式相對靜態(tài)方式而言靈活性大大增強(qiáng)。
2.2 系統(tǒng)結(jié)構(gòu)
整個系統(tǒng)結(jié)構(gòu)按功能劃分為六個模塊，分別是測試控制模塊、腳本定制模塊、腳本解釋模塊、測試驅(qū)動模塊、動態(tài)調(diào)用模塊、結(jié)果處理模塊。其中測試控制模塊提供了一個總的控制界面，進(jìn)行測試過程的控制和管理，測試人員輸入指令，進(jìn)行任意指定參數(shù)的操作或?qū)傩哉{(diào)用。在調(diào)用結(jié)束后，由測試結(jié)果處理模塊處理并顯示返回值及輸入/輸出參數(shù)，結(jié)果也可以保存在文件中。
腳本定制模塊采用IDL格式定義測試腳本，能夠編輯、管理測試腳本文件。用戶熟悉IDL就可以編寫測試腳本，測試腳本的解釋由腳本解釋模塊進(jìn)行。通過測試腳本可以向CORBA對象調(diào)用指定的操作，也可以獲取或設(shè)置CORBA對象的屬性。
在測試執(zhí)行過程中，測試驅(qū)動模塊和動態(tài)調(diào)用模塊從接口存儲庫載入被測CORBA對象IDL細(xì)節(jié)。為了保持測試工具的靈活性，采用動態(tài)調(diào)用方式。系統(tǒng)結(jié)構(gòu)如圖1所示：
3 CTester工具實現(xiàn)的關(guān)鍵技術(shù)
3.1 動態(tài)調(diào)用技術(shù)DII
CORBA服務(wù)器接口測試工具CTester從Client/Server模式看，實際上相當(dāng)于客戶端，客戶程序?qū)h(yuǎn)端對象的調(diào)用，有兩種方式：靜態(tài)方式和動態(tài)方式。本測試工具需要對任意CORBA服務(wù)器的屬性/操作進(jìn)行調(diào)用，因此采用動態(tài)調(diào)用DII[4]的方式，相對靜態(tài)方式而言，該種方式有以下幾個優(yōu)點(diǎn)：
(1)靈活。動態(tài)方式允許對任意對象進(jìn)行操作，所需要的只是目標(biāo)對象的對象引用。借助接口庫，動態(tài)方式可以在運(yùn)行時刻查詢對象所支持的屬性/操作信息，大大提高了程序的靈活性。
(2)客戶程序的可移植性增強(qiáng)。由于DII與客戶之間的接口是標(biāo)準(zhǔn)的，因此由動態(tài)方式實現(xiàn)的代碼具有良好的可移植性。
(3)可執(zhí)行程序的“體積”小。與靜態(tài)方式不同，DII不需要為每個接口生成碼根和框架，無論程序中使用多少接口，所需要的只是一套支持DII的接口庫，這樣可執(zhí)行程序的“體積”會相對較小。
當(dāng)然，與靜態(tài)方式相比，動態(tài)方式有以下的缺點(diǎn)：
(1)使用復(fù)雜。使用靜態(tài)方式時，對目標(biāo)對象的操作都施加在一個本地的對象上，相應(yīng)對象支持的所有操作及格式都已經(jīng)預(yù)先定義在這個對象中，因而使用方便。在動態(tài)方式下，程序員需要自己動手，“臨時”構(gòu)建一個請求并發(fā)送，同時程序還需要查詢接口庫以獲得屬性/操作必要描述信息，這些過程都較靜態(tài)方式復(fù)雜。
(2)速度緩慢。由于靜態(tài)方式下類型信息都是確定的，因此速度較快；而動態(tài)方式實現(xiàn)時，類型信息都是動態(tài)獲知，速度不可避免要慢一些。此外，程序要花去大量時間來查詢接口庫，尤其當(dāng)被查詢的接口定義存放在遠(yuǎn)端時，這些查詢還會引發(fā)遠(yuǎn)端調(diào)用，致使動態(tài)方式的速度變得更慢。
鑒于上述動態(tài)調(diào)用速度緩慢的缺點(diǎn)，為避免程序每次調(diào)用都去查詢接口庫來獲得屬性/操作的描述信息，我們采用預(yù)先將接口庫中所有數(shù)據(jù)類型的接口定義對象轉(zhuǎn)化為本地用java實現(xiàn)的類對象，這樣程序就不必花費(fèi)大量的時間來查詢接口庫，而只需調(diào)用所需類的屬性或方法即可，大大提高了調(diào)用執(zhí)行的效率。
動態(tài)調(diào)用的過程簡要?dú)w納如下：
(1)獲得接口名，將目標(biāo)對象接口信息注冊到接口庫中；
(2)從接口庫的對象中，找到所要調(diào)用的操作（或方法）的描述；
(3)建立調(diào)用參數(shù)表，并逐一填入?yún)?shù)；
(4)創(chuàng)建請求，請求中應(yīng)包括目標(biāo)對象的引用、方法名、參數(shù)表和返回值；
(5)調(diào)用請求，并作結(jié)果處理。
3.2 采用面向?qū)ο蟮南到y(tǒng)實現(xiàn)系統(tǒng)采用面向?qū)ο蟮乃枷?，將接口庫中各種數(shù)據(jù)類型對象一一轉(zhuǎn)化為用java類實現(xiàn)的對象，對CORBA服務(wù)器屬性/操作的調(diào)用變成了對相應(yīng)java類的屬性方法調(diào)用，提高了接口庫查詢效率，使得程序結(jié)構(gòu)更加合理，易于維護(hù)。啟動CTester工具后首先要執(zhí)行“Load-ifr”命令，將接口庫中所有IDL文件詳細(xì)描述信息裝入CorbaRepository類[5]，其中也包括要測試的CORBA服務(wù)器IDL描述文件信息，然后再調(diào)用“attribute”或“operation”命令對CORBA服務(wù)器中的屬性、參數(shù)進(jìn)行設(shè)置/獲取，對CORBA服務(wù)器中的操作進(jìn)行調(diào)用，獲得inout/out參數(shù)結(jié)果和返回值，驗證結(jié)果返回值是否正確。
4 總結(jié)
本課題在對CORBA服務(wù)器接口測試技術(shù)經(jīng)過大量的研究后，開發(fā)了相應(yīng)的測試工具來驗證CORBA接口的實現(xiàn)，該工具可以為分布式系統(tǒng)的開發(fā)提供測試手段。
參考文獻(xiàn)：
[1] 汪蕓．CORBA技術(shù)及其應(yīng)用[M]．江蘇：東南大學(xué)出版社，1999.1-12.
[2] 朱其亮,鄭斌．CORBA 原理及應(yīng)用[M]．北京：北京郵電大學(xué)出版社，2001.15-37.
[3] Orbix 2000 Programmer’s Guide Java Edition[EB/OL]．．2004-09-16.
關(guān)鍵詞： 模型檢驗；接口變異；切片技術(shù)；功能依賴圖
中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2015）02-0211-04
Abstract：Motivated by compressing the model of component through slicing technique， this paper employs the interactive relationship of the components. Then it proposes a method of constructing a function dependence graph for component system， which is made of a test driver node and some extended component nodes. Finally， by an example， it demonstrates that this method could not only decrease the size of the state space and increase the efficiency for testing generation， but also guarantee the comprehension and the validity of the interface testing for JavaBean components while applying the method of interface mutation testing based on model checking.
Key words： model checking； interface mutation； slicing technique； function dependence graph
模型檢驗技術(shù)作為一種形式化驗證方法，以其自動化程度高的特點(diǎn)已經(jīng)廣泛應(yīng)用于計算機(jī)硬件、通信協(xié)議的分析與驗證等許多領(lǐng)域，它通過窮盡地搜索有限狀態(tài)系統(tǒng)的狀態(tài)空間，從而判定系統(tǒng)（模型）的每一個狀態(tài)是否滿足給定的性質(zhì)，并且總會以“是”或“否”為結(jié)果而終止[1]。目前，利用模型檢驗技術(shù)進(jìn)行測試用例生成的研究也十分活躍，并且也取得了一定的研究成果[2]。同時，隨著程序模型檢驗工具的誕生，一些將變異測試方法與程序模型檢驗工具相結(jié)合并生成測試用例的研究工作也得到了一定進(jìn)展[3]。
盡管模型檢驗技術(shù)在自動化方面具有許多優(yōu)點(diǎn)，但它是采用窮盡搜索系統(tǒng)空間的方法對所給定的性質(zhì)進(jìn)行驗證，因此，對并發(fā)系統(tǒng)而言，其狀態(tài)數(shù)往往隨并發(fā)分量的增加呈指數(shù)增長，這樣就產(chǎn)生了“狀態(tài)空間爆炸”（state-explosion）問題[1]。對于基于模型檢驗的變異測試來說，當(dāng)對非等價變異體采用“搜索所有的反例路徑”的策略進(jìn)行驗證，以及對等價變異體進(jìn)行驗證時，都必須通過搜索整個系統(tǒng)的狀態(tài)空間才能夠進(jìn)行判定，所以這樣就影響了模型檢驗的驗證效率。
因此，為了壓縮系統(tǒng)狀態(tài)空間的數(shù)量，本文將通過建立構(gòu)件系統(tǒng)的功能依賴圖，然后運(yùn)用切片技術(shù)[4]對其進(jìn)行切片。最后，本文將以Java PathFinder作為模型檢驗工具，采用基于模型檢驗技術(shù)的接口變異測試方法[5]對JavaBean構(gòu)件進(jìn)行接口變異測試，并對所切片效果進(jìn)行驗證。圖1給出了該方法的測試用例生成框架。
1 構(gòu)件系統(tǒng)的功能依賴圖
S.Horwitz等人通過引入系統(tǒng)依賴圖（System Dependence Graph，SDG）的概念表示了具有多個過程的程序依賴圖[6]，但是使用該方法就必須知道每一個過程內(nèi)部的具體細(xì)節(jié)信息，因此這種方法并不適用于在源碼未知情況下的構(gòu)件化軟件切片；雖然文獻(xiàn)[7]提出了一種能夠?qū)τ蓸?gòu)件所組成的系統(tǒng)進(jìn)行切片的方法，但是這種方法卻只考慮了構(gòu)件之間接口的交互關(guān)系而忽略了構(gòu)件在系統(tǒng)中的狀態(tài)。因此，本文以文獻(xiàn)[8]所提出的構(gòu)件之間接口的交互關(guān)系為基礎(chǔ)，在細(xì)化了構(gòu)件之間的接互圖后，使其能夠在清晰描述源碼未知情況下被測試構(gòu)件的狀態(tài)和接口函數(shù)之間的關(guān)系的同時，也能夠使切片技術(shù)適用于對被測試構(gòu)件系統(tǒng)的接口調(diào)用關(guān)系模型的狀態(tài)空間的壓縮。
1.1 功能依賴圖的組成
本文以該被測試構(gòu)件的接口規(guī)約說明為依據(jù)，通過測試驅(qū)動程序?qū)Ρ粶y試構(gòu)件，或者是將該被測試構(gòu)件和與之相關(guān)的構(gòu)件關(guān)聯(lián)后進(jìn)行建模，從而建立被測試構(gòu)件的接口調(diào)用關(guān)系模型。通過這個構(gòu)件系統(tǒng)的接口調(diào)用關(guān)系模型，被測試構(gòu)件所具備的相關(guān)功能會在利用模型檢驗技術(shù)進(jìn)行驗證的過程中表現(xiàn)出來。因此，將細(xì)化后的構(gòu)件之間的接互關(guān)系稱之為構(gòu)件系統(tǒng)的功能依賴圖（Function Dependence Graph，F(xiàn)DG），并且該圖是由測試驅(qū)動節(jié)點(diǎn)（Test Driver Node）和構(gòu)件節(jié)點(diǎn)（Component Node）兩種類型的節(jié)點(diǎn)所組成。
測試驅(qū)動節(jié)點(diǎn)是由被測試構(gòu)件的測試驅(qū)動程序所虛擬出來的一個節(jié)點(diǎn)，它是整個構(gòu)件系統(tǒng)的主體框架。從切片技術(shù)的觀點(diǎn)來分析，該節(jié)點(diǎn)實際上就是它所代表的測試驅(qū)動程序的過程依賴圖[3]（Process Dependence Graph）。
構(gòu)件節(jié)點(diǎn)實際上在代表被測試構(gòu)件的同時，也可以代表與被測試構(gòu)件相關(guān)聯(lián)的構(gòu)件。為了能夠應(yīng)用切片技術(shù)對其進(jìn)行切片，需要通過添加一些輔助接點(diǎn)對構(gòu)件節(jié)點(diǎn)及輔助邊對其進(jìn)行細(xì)化。這里通過定義一個五元組C = 來描述一個構(gòu)件節(jié)點(diǎn)，具體如圖2所示。
1） 構(gòu)造函數(shù)輔助節(jié)點(diǎn)（Construction Assistant Node）的集合Con
對于JavaBean構(gòu)件來說，為了體現(xiàn)面向?qū)ο蟮奶卣?，在?gòu)件節(jié)點(diǎn)中應(yīng)該添加與之相關(guān)的所有構(gòu)造函數(shù)的構(gòu)造函數(shù)輔助節(jié)點(diǎn)（Conk表示構(gòu)件中第k個構(gòu)造函數(shù)）。輔助節(jié)點(diǎn)實際上就是該構(gòu)件的入口節(jié)點(diǎn)。
2） 狀態(tài)輔助節(jié)點(diǎn)（State Assistant Node）的集合S
由于在代碼未知情況下的構(gòu)件接口測試是一種黑盒測試，因此，還必須在構(gòu)件節(jié)點(diǎn)中添加表示構(gòu)件狀態(tài)的狀態(tài)輔助節(jié)點(diǎn)（Si表示構(gòu)件中第i個狀態(tài)）。
3） 接口函數(shù)輔助節(jié)點(diǎn)（Interface Function Assistant Node）的集合I
在構(gòu)件節(jié)點(diǎn)中添加表示該構(gòu)件所包含的所有接口函數(shù)的接口函數(shù)輔助節(jié)點(diǎn)（Im表示構(gòu)件中第m個接口函數(shù)）。
4） 輸入?yún)?shù)輔助節(jié)點(diǎn)（Input Parameter Assistant Node）的集合p
對于每一個包含輸入?yún)?shù)的接口函數(shù)應(yīng)該在其所對應(yīng)的接口函數(shù)輔助節(jié)點(diǎn)中添加表示該接口函數(shù)中所有參數(shù)的輸入?yún)?shù)輔助節(jié)點(diǎn)（pn表示該接口函數(shù)中的第n個參數(shù)）。
5） 輔助節(jié)點(diǎn)之間輔助邊（Assistant Edge）的集合E
為了能夠體現(xiàn)出上述輔助節(jié)點(diǎn)之間的內(nèi)在關(guān)系并使切片技術(shù)能夠適用于構(gòu)件節(jié)點(diǎn)，還必須根據(jù)構(gòu)件的規(guī)約說明在輔助接點(diǎn)之間添加相應(yīng)的邊。首先，由于通過構(gòu)造函數(shù)在實例化一個構(gòu)件的時候，與該構(gòu)件相關(guān)的狀態(tài)和接口調(diào)用函數(shù)也會被創(chuàng)建，因此，就必須在構(gòu)造函數(shù)輔助節(jié)點(diǎn)和狀態(tài)輔助節(jié)點(diǎn)以及構(gòu)造函數(shù)輔助節(jié)點(diǎn)和接口函數(shù)輔助節(jié)點(diǎn)之間添加一條控制依賴邊；其次，根據(jù)構(gòu)件的接口規(guī)約說明，應(yīng)該在具有控制依賴關(guān)系的接口函數(shù)之間添加能夠代表它們之間控制依賴關(guān)系的控制依賴邊；最后，由于構(gòu)件相關(guān)的狀態(tài)信息是通過與之相關(guān)的構(gòu)件接口函數(shù)進(jìn)行改變的，所以需要在接口函數(shù)輔助節(jié)點(diǎn)和狀態(tài)輔助節(jié)點(diǎn)之間添加一條控制依賴邊，同時，構(gòu)件的狀態(tài)信息也需要通過接口函數(shù)向外界進(jìn)行表現(xiàn)，因此，還應(yīng)該在狀態(tài)輔助節(jié)點(diǎn)和與之相關(guān)接口函數(shù)輔助節(jié)點(diǎn)之間添加一條數(shù)據(jù)依賴邊。綜上所述，構(gòu)件節(jié)點(diǎn)之間輔助邊的集合E是控制依賴邊Ec和數(shù)據(jù)依賴邊Ed的并集，即：E = Ec U Ed。
1.2 功能依賴圖的建立及其切片
在明確了構(gòu)件系統(tǒng)的功能依賴圖的組成后，就應(yīng)該根據(jù)測試驅(qū)動程序?qū)y試驅(qū)動節(jié)點(diǎn)和構(gòu)件節(jié)點(diǎn)進(jìn)行關(guān)聯(lián)，從而建立整個構(gòu)件系統(tǒng)的功能依賴圖，它主要包括建立測試驅(qū)動程序的過程依賴圖和確立該過程依賴圖與構(gòu)件節(jié)點(diǎn)之間關(guān)聯(lián)關(guān)系兩個主要步驟。
文獻(xiàn)[9]給出了建立測試驅(qū)動程序過程依賴圖的具體方法和步驟，故本文在此不作熬述。
本文的研究重點(diǎn)在于對構(gòu)件的接口進(jìn)行測試，因此，對被測試構(gòu)件系統(tǒng)的功能依賴圖的建立主要就體現(xiàn)在確立測試驅(qū)動程序的過程依賴圖和構(gòu)件節(jié)點(diǎn)之間的關(guān)系之上，這些關(guān)系主要包括了如下四個方面：
1） 測試驅(qū)動程序?qū)?gòu)件的實例化
在測試驅(qū)動程序中需要通過構(gòu)造函數(shù)對JavaBean構(gòu)件進(jìn)行實例化。這樣，就必須添加一條描述測試驅(qū)動程序?qū)?gòu)件進(jìn)行實例化的控制依賴邊。
2） 測試驅(qū)動程序?qū)?gòu)件中接口函數(shù)的調(diào)用
對構(gòu)件中接口函數(shù)的每一次調(diào)用，需要添加一條描述測試驅(qū)動程序?qū)涌诤瘮?shù)進(jìn)行調(diào)用的接口函數(shù)調(diào)用邊。
3） 測試驅(qū)動程序?qū)?gòu)件中接口函數(shù)的參數(shù)輸入
對于擁有輸入?yún)?shù)的接口函數(shù)來說，測試驅(qū)動程序在對其進(jìn)行調(diào)用時，對于每一個輸入?yún)?shù)都需要添加一條描述測試驅(qū)動程序在對其進(jìn)行調(diào)用時的參數(shù)輸入邊。
4） 構(gòu)件中接口函數(shù)對測試驅(qū)動程序的響應(yīng)
對接口函數(shù)的調(diào)用實際上相當(dāng)于對構(gòu)件中相關(guān)功能進(jìn)行了一次使用，因此，構(gòu)件就必須向外界產(chǎn)生這個調(diào)用的一個響應(yīng)，這樣，就必須添加一條描述構(gòu)件中接口函數(shù)響應(yīng)的邊。
本文以三角形問題的JavaBean構(gòu)件為例進(jìn)行研究，表1給出了三角形問題構(gòu)件中的接口函數(shù)及接口函數(shù)所對應(yīng)的狀態(tài)。
在依據(jù)三角形問題構(gòu)件的接口規(guī)約說明建立測試驅(qū)動程序后，圖3給出了其構(gòu)件系統(tǒng)的功能依賴圖。圖中右側(cè)部分是測試驅(qū)動程序節(jié)點(diǎn)，它是由被測試構(gòu)件的測試驅(qū)動程序所建立的過程依賴圖組成的[5]；圖中左側(cè)部分是三角形問題構(gòu)件的構(gòu)件節(jié)點(diǎn)，該節(jié)點(diǎn)中的S1、S2和S3分別代表了構(gòu)件中的三個狀態(tài)：bTriangle、 bRight和tType。由于三個接口函數(shù)的輸入?yún)?shù)都是三個整形變量，因此，為了便于觀察，在具體作圖的過程中將輸入?yún)?shù)a、b、c三個節(jié)點(diǎn)視為一個節(jié)點(diǎn)。
建立構(gòu)件系統(tǒng)的功能依賴圖后，就可以運(yùn)用切片技術(shù)對其進(jìn)行切片。在基于模型檢驗技術(shù)的變異測試方法的測試用例的生成過程中，是通過引入斷言違背機(jī)制將原有模型和變異模型結(jié)合并對構(gòu)件的狀態(tài)進(jìn)行判定從而誘發(fā)錯誤生成并得到反例路徑。因此，為了能夠找到導(dǎo)致這個斷言違背所產(chǎn)生錯誤的原因，就必須找到在這個斷言違背之前，系統(tǒng)模型中哪些語句或者是哪個謂詞表達(dá)式影響了所關(guān)注的這個斷言違背，并且它們是如何傳播到這個地方。這樣在對功能依賴圖進(jìn)行切片時，就可以采用文獻(xiàn)[6]中所提出的后向切片準(zhǔn)則和兩步圖的可達(dá)性算法對構(gòu)件系統(tǒng)的功能依賴圖進(jìn)行切片。
2 實驗結(jié)果和分析
2.1 實驗對象說明及實驗結(jié)果
本節(jié)以三角形問題構(gòu)件中反應(yīng)三角形類型的狀態(tài)“tType”作為興趣點(diǎn)，對其構(gòu)件系統(tǒng)的功能依賴圖進(jìn)行切片試驗。圖4所得到的即為切片后的三角形問題構(gòu)件系統(tǒng)的功能依賴圖。
在利用基于模型檢驗的接口變異測試方法對構(gòu)件系統(tǒng)進(jìn)行驗證并生成測試用例時，為了能夠體現(xiàn)出構(gòu)件系統(tǒng)模型中存在的“狀態(tài)空間爆炸”問題以及通過切片技術(shù)對系統(tǒng)的狀態(tài)空間進(jìn)行壓縮后的效果，首先選擇三角形問題構(gòu)件的接口函數(shù)TriType（int a， int b， int c）的等價變異體TriType（int c， int b， int a）作為研究對象，并將三邊的輸入域劃分為5組進(jìn)行對比分析。
表2給出了在上述實驗條件下，JPF對切片前后的構(gòu)件系統(tǒng)在模型驗證后所得到的狀態(tài)數(shù)，它是由JPF統(tǒng)計信息中“state”里面的“new”與“visited”相加所得到的。
對表2進(jìn)行分析可知：
首先，除去最后一行對壓縮率的分析外，表格中的每一行都反應(yīng)出隨著三角形三邊輸入域的增加，整個模型檢驗過程所耗費(fèi)的時間以及在驗證過程中所產(chǎn)生的狀態(tài)數(shù)都在以指數(shù)形式增加，這就體現(xiàn)了在本章最開始所提到的“狀態(tài)空間爆炸”問題。
其次，表格中的每一列說明了在對構(gòu)件接口調(diào)用關(guān)系模型運(yùn)用切片技術(shù)后，模型檢驗工具在驗證過程中所耗費(fèi)的時間有了一定的減少，而且在整個驗證過程中系統(tǒng)模型所產(chǎn)生的狀態(tài)空間的數(shù)量也得到了壓縮，模型檢驗的驗證效率得到了提高。
再次，由于上述五組實驗只改變了三角形問題構(gòu)件的輸入域，對于構(gòu)件系統(tǒng)模型本身并沒有進(jìn)行改變，因此，在使用相同的切片準(zhǔn)則并運(yùn)用切片技術(shù)對構(gòu)件系統(tǒng)的功能依賴圖進(jìn)行切片后，所得到的系統(tǒng)模型的狀態(tài)空間壓縮率在效果上基本是相同的。
最后。上述五組實驗的驗證結(jié)果都沒有檢驗出任何反例路徑，因此，切片技術(shù)的運(yùn)用并不會影響“基于模型檢驗技術(shù)的接口變異測試方法”對等價變異體的正確判定。
2.2 統(tǒng)計分析
在上一小節(jié)中，通過利用JPF對同一個等價變異體TriType（int c， int b， int a）的五組不同輸入域的檢驗，說明了運(yùn)用切片技術(shù)對構(gòu)件系統(tǒng)中單個接口函數(shù)的等價變異體進(jìn)行壓縮后，依然能夠通過“基于模型檢驗技術(shù)的接口變異測試方法”對等價變異體進(jìn)行有效地判定。但是，當(dāng)同一個構(gòu)件中所有不同的接口函數(shù)在分別運(yùn)用切片技術(shù)對構(gòu)件系統(tǒng)模型進(jìn)行壓縮后，上述實驗結(jié)果并不能夠說明切片技術(shù)對整個構(gòu)件系統(tǒng)的驗證以及對接口測試用例生成所產(chǎn)生的影響。因此，本小節(jié)將就這一問題作進(jìn)一步的討論。
這里，分別以三角形問題構(gòu)件中的三個狀態(tài)屬性作為興趣點(diǎn)對構(gòu)件系統(tǒng)進(jìn)行切片，然后三個接口函數(shù)的非等價變異體對切片后的構(gòu)件系統(tǒng)模型進(jìn)行變異并驗證。表4給出了三個接口函數(shù)在切片前后進(jìn)行變異并生成測試用例的相關(guān)驗證信息，為了能夠達(dá)到對系統(tǒng)模型狀態(tài)空間進(jìn)行窮盡搜索以及對非等價變異體生成所有測試用例的目的，這里將JPF中的搜索配置策略設(shè)置為“搜索顯示多條反例路徑”。同樣地，表3所產(chǎn)生的狀態(tài)數(shù)也是由統(tǒng)計信息“states”中“new”與“visited”相加得到的。
通過對表3可以發(fā)現(xiàn)：
首先，對于每一個需要驗證的系統(tǒng)模型來說，在運(yùn)用切片技術(shù)對系統(tǒng)模型進(jìn)行切片之后，都能夠達(dá)到壓縮系統(tǒng)模型狀態(tài)空間數(shù)量，并提高驗證效率的目的。
其次，表中的數(shù)據(jù)以及實際的實驗結(jié)果說明，切片后的系統(tǒng)模型在驗證后所產(chǎn)生的反例路徑與切片之前所產(chǎn)生的反例路徑是相同的，因此，切片前后所產(chǎn)生的測試用例也是一樣的。
最后，盡管切片技術(shù)是對構(gòu)件系統(tǒng)的功能依賴圖進(jìn)行切片，但其實質(zhì)上是對構(gòu)件系統(tǒng)的狀態(tài)空間進(jìn)行縮減。由于三角形構(gòu)件系統(tǒng)中僅由一個三角形構(gòu)件組成，因此其狀態(tài)空間是由三邊的輸入域所確定，這樣，表中三組實驗所對應(yīng)的切片前的構(gòu)件系統(tǒng)模型在驗證后所產(chǎn)生的狀態(tài)空間總數(shù)是一樣的；同時，對于每一個切片后的構(gòu)件系統(tǒng)模型來說，其狀態(tài)空間是由三角形構(gòu)件中的一個狀態(tài)所決定的，而該狀態(tài)又是由相同的輸入域確定，因此在切片后，構(gòu)件系統(tǒng)模型的狀態(tài)空間總數(shù)也是一樣的。綜上所述，三組實驗的狀態(tài)空間壓縮率也是相同的。
3 結(jié)束語
目前，基于模型檢驗的測試用例生成技術(shù)作為一種新興的軟件測試方法已經(jīng)得到了測試人員的廣泛關(guān)注，但是由于模型檢驗技術(shù)中所存在的“狀態(tài)空間爆炸”問題會使得驗證的效率較為低下，因此，本文主要講解了運(yùn)用切片技術(shù)對系統(tǒng)模型進(jìn)行切片從而達(dá)到壓縮系統(tǒng)模型狀態(tài)空間，并提高驗證效率的目的。
本文以構(gòu)件之間接口的交互關(guān)系為基礎(chǔ)，通過擴(kuò)展構(gòu)件之間接互圖后，提出了一種建立構(gòu)件系統(tǒng)的功能依賴圖的具體方法，然后運(yùn)用切片算法實現(xiàn)了對其進(jìn)行切片的目標(biāo)。最后，本文通過基于模型檢驗的接口變異測試方法對三角形問題的JavaBean構(gòu)件的實驗說明：在運(yùn)用切片技術(shù)對系統(tǒng)模型進(jìn)行切片以后，達(dá)到了有效壓縮系統(tǒng)狀態(tài)空間數(shù)量并提高驗證效率的目的，同時，不但可以對等價變異體模型進(jìn)行正確地判定，而且對于非等價變異體模型來說還可以正確地生成測試用例。
參考文獻(xiàn)：
[1] 林惠民， 張文輝. 模型檢測：理論，言方法與應(yīng)用[J]. 電子學(xué)報， 2002， 30（12A）： 1907-1912.
[2] 梁陳良， 聶長海， 徐寶文， 陳振宇. 一種基于模型檢驗的類測試用例生成方法[J]. 東南大學(xué)學(xué)報（自然科學(xué)版）， 2007， 37（5）： 776-781.
[3] W. Visser， C. Pasareanu， S. Khurshid. Test Input Generation with Java PathFinder[C]. Proceedings of ISSTA 2004， New York： ACM Press， July 2004， 97-107.
[4] 李必信. 程序切片技術(shù)及其應(yīng)用[M]. 北京： 科學(xué)出版社， 2006： 3.
[5] 張K， 王[， 韓柯， 歐陽志強(qiáng). 面向構(gòu)件接口變異的模型檢驗技術(shù)研究[J]. 電腦知識與技術(shù)， 2010（6）： 1954-1956.
[6] Horwitz S B， et al. Interprocedural slicing using dependence graphs[J]. ACM Transactions on Programming Languages and Systems， 1990， 12（1）：26-60.
關(guān)鍵詞：計算機(jī)軟件；網(wǎng)絡(luò)管理；接口一致性測試；事務(wù)模型；測試流；XML語言
中圖分類號：TP311文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2011)07-1516-04
Description Method of Transaction Model for General Network Management Interface Test
LI Cai-yun, CHEN Ying-hui
(Beijing University of Posts and Telecommunications, Beijing 100876, China)
Abstract: The automation technology of network management interface conformance test has been the focus of related testing research, and the proposed test transaction model makes network management interface conformance test automation degree to a new level. By analyzing the research and practice of the network management interface consistency test, a test transaction model description method is proposed based on the XML format, and The Schema definition of the this method is given. The method in this paper can be applied for mainstream technology of network management interface. In the testing process of network management interface, the method can reduce a lot of manual operations, shorten test cycle, and improve the test efficiency and test automation degree obviously.
Key words: computer software; network management; consistency test of interface; transaction model; test flow; XML language
網(wǎng)絡(luò)管理接口的一致性測試是保證不同的網(wǎng)管系統(tǒng)之間能進(jìn)行互聯(lián)、互通和互操作的重要手段和必要步驟[1]。網(wǎng)絡(luò)管理接口一致性測試是面向電信級網(wǎng)絡(luò)管理軟件的測試，要完成對如此復(fù)雜龐大的軟件接口的測試任務(wù)，僅靠人工手動測試不但耗時耗力，而且難以保證測試的質(zhì)量[2]。因此，網(wǎng)管接口一致性測試的自動化程度，始終是相關(guān)測試研究工作所追求的目標(biāo)之一。要提高網(wǎng)管接口一致性測試的自動化程度，測試過程自動化的將成為一個重要環(huán)節(jié)。在實際的接口測試中，一方面需要對同一接口規(guī)范不同提供者的實現(xiàn)分別進(jìn)行測試，另一方面又要對某些接口實現(xiàn)進(jìn)行回歸測試[3]。因此將測試過程自動化機(jī)制引入網(wǎng)管接口的一致性測試很有意義。
目前在網(wǎng)管接口一致性測試中，測試過程自動化方面已有一些研究成果，文獻(xiàn)[4]提出了測試流技術(shù)，通過測試流技術(shù)實現(xiàn)測試過程自動化，并將測試流控制語句按功能分為基本功能語句模塊、判斷語句模塊、循環(huán)語句模塊、異常捕獲語句模塊和輔助語句模塊共五個模塊。但是該文獻(xiàn)并未給出測試流技術(shù)的具體設(shè)計實現(xiàn)與應(yīng)用，隨著網(wǎng)管接口測試技術(shù)的發(fā)展，測試流在實際的測試應(yīng)用過程中存在本有以下兩個弊端：
1）測試流采用純文本方式定義，其格式不可通用，而且由于沒有層次結(jié)構(gòu)，當(dāng)腳本文件較大時，測試人員很難看明白腳本，如果腳本有錯誤時，檢查也很困難。
2）測試流腳本與接口技術(shù)直接關(guān)聯(lián)，對于不同的接口技術(shù)，要為之定義專門的測試流腳本。
本文將基于文獻(xiàn)[4]中提出的測試流技術(shù)，進(jìn)一步進(jìn)行擴(kuò)展，引入測試事務(wù)[5]的概念，同時本文對測試流控制語句進(jìn)行擴(kuò)充，設(shè)計出了一套格式通用且與網(wǎng)管接口技術(shù)無關(guān)的測試事務(wù)描述方法。該測試事務(wù)描述方法采用目前使用非常廣泛的XML格式來進(jìn)行定義，所以該描述方法具有理解容易、操作簡單、使用方便等特性。另外，該描述方法還具備通用性和可擴(kuò)展性，不僅可以應(yīng)用于目前所有的主流網(wǎng)管接口技術(shù)，如CORBA、WebService、SNMP等技術(shù)，而且對于以后出現(xiàn)的新接口技術(shù)也可以使用該方法。
1 測試事務(wù)模型介紹
分散的、獨(dú)立的測試用例無法體現(xiàn)實際應(yīng)用環(huán)境中用戶的動態(tài)行為，因此需要一種方法來描述測試用例[6]間的組織關(guān)系。測試事務(wù)就是若干個相關(guān)聯(lián)的、可能具有數(shù)據(jù)或業(yè)務(wù)依賴關(guān)系并按照一定的業(yè)務(wù)邏輯順序執(zhí)行的測試用例的組合。測試事務(wù)即可以是簡單事務(wù)（例如修改對象屬性值），也可以是復(fù)雜事務(wù)（例如創(chuàng)建一個對象，然后修改該對象的屬性值，最后將該對象刪除，并在創(chuàng)建、修改和刪除操作之間，進(jìn)行查詢該對象屬性值的操作）。測試事務(wù)必須能夠體現(xiàn)出測試用例的邏輯順序調(diào)用關(guān)系、根據(jù)上一測試用例的執(zhí)行結(jié)果判定選擇下一測試步驟分支、測試步驟的條件迭代、測試用例的參數(shù)賦值（包括變量賦值和測試用例上下文賦值）、測試結(jié)果數(shù)據(jù)的保留和再利用、測試結(jié)果的評判等。
在網(wǎng)管接口一致性測試中，測試人員在拿到測試規(guī)范之后，需要將測試規(guī)范按照功能模塊劃分為若干測試事務(wù)，每個測試事務(wù)對應(yīng)一個測試流腳本，而測試流是一系列的基本測試用例和相關(guān)的邏輯控制信息的組合。如圖1所示。
2 測試事務(wù)描述方法
在測試事務(wù)的描述方法中，基本單元為測試用例（稱為TC），主要的邏輯控制信息包括：Transaction、varDefineClause、varDefineFunctionClause、ifClause、forClause、whileClause、exportClause、pauseClause、descriptionClause、Debug 、break和exit，通過這些邏輯控制信息，控制TC的執(zhí)行邏輯順序，并實現(xiàn)測試數(shù)據(jù)在TC間的傳遞。
測試事務(wù)描述方法采用XML格式進(jìn)行定義，所以我們需要定義一套Schema，下面主要介紹Schema中各個節(jié)點(diǎn)的定義以及結(jié)構(gòu)。
2.1 節(jié)點(diǎn)的定義
testFlow節(jié)點(diǎn)：XML文件的根節(jié)點(diǎn)，不能被其它任何節(jié)點(diǎn)包含，在測試過程中不具有實際意義。
TC節(jié)點(diǎn)：測試用例調(diào)用節(jié)點(diǎn)，每個TC代表一個接口中的操作。
Transaction節(jié)點(diǎn)：交易節(jié)點(diǎn)，該節(jié)點(diǎn)可以將若干個測試用例（TC）集合在一起，如在3G通信網(wǎng)中將所有與通知相關(guān)的操作放在一個交易中，將所有與告警相關(guān)的操作放在一個交易中，這樣便于整個測試流語言的管理。
varDefineClause節(jié)點(diǎn)：變量定義節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于定義能夠存儲和交換數(shù)據(jù)的變量，并給變量賦值，定義后的變量可以在后面操作中使用。
varDefineFunctionClause節(jié)點(diǎn)：變量定義節(jié)點(diǎn)，該節(jié)點(diǎn)與varDefineClause節(jié)點(diǎn)不同的是對變量的賦值是通過已經(jīng)定義好的函數(shù)進(jìn)行賦值。例如要定義一個整數(shù)變量n，但是n的值不能事先知道，需要通過取一個字符串的長度來確定，這樣就可以通過一個取字符串長度的函數(shù)來給變量n賦值。
ifClause節(jié)點(diǎn)：條件控制節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于上下文的條件判斷以選擇要執(zhí)行的下一步，如果條件判斷結(jié)果為true，則執(zhí)行該節(jié)點(diǎn)下的測試用例，如果判斷結(jié)果為false，則不執(zhí)行該節(jié)點(diǎn)下的測試用例。
forClause節(jié)點(diǎn)：循環(huán)控制節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于控制特定步驟的循環(huán)執(zhí)行，主要應(yīng)用與已經(jīng)知道循環(huán)次數(shù)的情況下。
whileClause節(jié)點(diǎn)：循環(huán)控制節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于控制特定步驟的循環(huán)執(zhí)行，主要用于不確定循環(huán)次數(shù)的情況下。例如在測試過程中，某個操作的返回參數(shù)為“FALSE”時，循環(huán)體中的測試用例就要執(zhí)行，如果該操作的返回參數(shù)為“TRUE”時，循環(huán)結(jié)束，這種情況下我們只能使用該節(jié)點(diǎn)。
exportClause節(jié)點(diǎn)：輸出節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于將某個操作的參數(shù)的返回值輸出出來，輸出方式有兩種，一種是輸出到文件中，另一種是輸出到一個變量中。
descriptionClause節(jié)點(diǎn)：描述節(jié)點(diǎn)，該節(jié)點(diǎn)主要是用于對測試流增加注釋或者描述，便于測試人員編寫和查看測試流文件。
pauseClause節(jié)點(diǎn)：暫停節(jié)點(diǎn)，該節(jié)點(diǎn)主要作用為暫定，可以將測試流的執(zhí)行暫停若干時間，時間單位為秒。例如某些操作在下發(fā)之后，需要等幾秒鐘才能查看操作的狀態(tài)，那么就需要該節(jié)點(diǎn)來進(jìn)行暫停。
Debug節(jié)點(diǎn)：調(diào)試節(jié)點(diǎn)，該節(jié)點(diǎn)與編程中的斷點(diǎn)類似，設(shè)置了該節(jié)點(diǎn)之后，測試流在執(zhí)行到該節(jié)點(diǎn)時會停下，給用戶彈出詢問窗口，如果用戶選擇繼續(xù)執(zhí)行，則測試流繼續(xù)執(zhí)行，如果用戶選擇停止，則測試流終止執(zhí)行。
break節(jié)點(diǎn)：循環(huán)體結(jié)束節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于結(jié)束其所在的循環(huán)體。
exit節(jié)點(diǎn)：測試流結(jié)束節(jié)點(diǎn)，該節(jié)點(diǎn)主要用于結(jié)束整個測試流。
2.2 節(jié)點(diǎn)的結(jié)構(gòu)及其描述
2.2.1 testFlow節(jié)點(diǎn)
testFlow節(jié)點(diǎn)為根節(jié)點(diǎn)，其結(jié)構(gòu)圖如圖2所示。從圖中可以看出根節(jié)點(diǎn)下可以包含除了break和exit之外的所有節(jié)點(diǎn)。
2.2.2 TC節(jié)點(diǎn)
TC節(jié)點(diǎn)代表接口中的操作，其結(jié)構(gòu)圖如圖3所示，每個TC包含三部分，分別是基本屬性Attributes、參數(shù)列表ParameterList和檢查列表CheckList。
其中基本屬性包含1個可選屬性和2個必選屬性，下面給出各個屬性的含義和示意性的用法說明：
alias：當(dāng)前測試用例的別名，為了讓測試人員更好的區(qū)分所下發(fā)的操作，例如對于訂購?fù)ㄖ掳l(fā)的操作都是一樣的，但是有可能某個操作訂購的是配置相關(guān)的通知，另外一個訂購的是告警相關(guān)的通知，有了別名之后就可以更好的來進(jìn)行區(qū)分。alias為可選屬性，用戶可以根據(jù)實際情況來決定是否需要。
InterfaceType：接口類型，用來區(qū)分下發(fā)的操作是采用哪種接口技術(shù)，如：CORBA、WebService、SNMP等等。
Opinfo：操作的具體信息，用來表示下發(fā)的操作的具體信息。
參數(shù)列表ParameterList：主要是為TC中的參數(shù)賦值，參數(shù)列表中的每個參數(shù)都可以分別給他們賦值，參數(shù)的結(jié)構(gòu)圖如圖4所示。每個參數(shù)都兩個屬性paraName（參數(shù)名稱）和type（參數(shù)類型），另外有5種賦值方式，分別是set（直接為參數(shù)賦值），assign（將其它TC的返回值賦值給該參數(shù)），varAssign（將已經(jīng)定義好的變量的值賦值給該參數(shù)），default（默認(rèn)值），function（將函數(shù)的返回值賦值給該參數(shù)）。
檢查列表CheckList：主要是用來判定TC的執(zhí)行結(jié)果，同時也可以作為if和while的條件判定。其結(jié)構(gòu)圖如5所示，檢查列表將若干個檢查點(diǎn)（CheckPoint），通過and、or或not相互連接組合（and節(jié)點(diǎn)是邏輯與關(guān)系，or節(jié)點(diǎn)邏輯或關(guān)系，not節(jié)點(diǎn)是邏輯非關(guān)系），從而滿足一定的判定要求。
2.2.3 Transaction節(jié)點(diǎn)
Transaction節(jié)點(diǎn)可以自包含，其結(jié)構(gòu)與根節(jié)點(diǎn)testFlow相同，下可以包含除了break和exit之外的所有節(jié)點(diǎn)，這里不再給出其結(jié)構(gòu)圖。該節(jié)點(diǎn)有一個屬性transactionName（交易名稱），用來區(qū)分不同的交易。
2.2.4 varDefineClause節(jié)點(diǎn)
varDefineClause節(jié)點(diǎn)為變量定義節(jié)點(diǎn)，其結(jié)構(gòu)如圖6所示，該節(jié)點(diǎn)包含3個屬性，分別是varName（變量名）、varType（變量類型）和varValue（變量值）。
2.2.5 varDefineFunctionClause節(jié)點(diǎn)
varDefineFunctionClause節(jié)點(diǎn)為變量定義節(jié)點(diǎn)，其結(jié)構(gòu)如圖7所示，由于該節(jié)點(diǎn)是通過函數(shù)為變量賦值，所以該節(jié)點(diǎn)的三個元素分別是varName（變量名）、varType（變量類型）和functionName（函數(shù)名）。
2.2.6 ifClause節(jié)點(diǎn)
ifClause節(jié)點(diǎn)為條件控制節(jié)點(diǎn)，其結(jié)構(gòu)如圖8所示。ifClause節(jié)點(diǎn)有一個CheckList元素，與TC中的檢查列表是相同的，這里不再說明。ifClause下可以包含所有的節(jié)點(diǎn)。
2.2.7 forClause節(jié)點(diǎn)
forClause節(jié)點(diǎn)為循環(huán)控制節(jié)點(diǎn)，其結(jié)構(gòu)與根節(jié)點(diǎn)testFlow相同，下可以包含除了break和exit之外的所有節(jié)點(diǎn)，這里不再給出其結(jié)構(gòu)圖。該節(jié)點(diǎn)有4個屬性分別是varName（變量名），from（變量的初始值），to（變量的終止值），step（循環(huán)的步長）。
2.2.8 whileClause節(jié)點(diǎn)
whileClause節(jié)點(diǎn)為循環(huán)控制節(jié)點(diǎn)，其結(jié)構(gòu)與根節(jié)點(diǎn)testFlow相同，下可以包含除了break和exit之外的所有節(jié)點(diǎn)，這里不再給出其結(jié)構(gòu)圖。該節(jié)點(diǎn)有一個CheckList元素，與TC中的檢查列表是相同的，這里不再說明。
2.2.9 exportClause節(jié)點(diǎn)
exportClause節(jié)點(diǎn)為輸出節(jié)點(diǎn)，其結(jié)構(gòu)如圖9所示。該節(jié)點(diǎn)有5個必選屬性和一個可選屬性，下面給出各個屬性的含義和示意性的用法說明：
InterfaceType：接口類型，用來區(qū)分下發(fā)的操作是采用哪種接口技術(shù)，如：CORBA、WebService、SNMP等等。
Opinfo：操作的具體信息，用來表示下發(fā)的操作的具體信息。
para：操作的參數(shù)名，用來表示要將操作中的哪一個參數(shù)的值輸出。
exportType：輸出類型，分為兩種，一種是輸出到變量（取值為var），一種是輸出到文件中（取值為file）。
value：輸出的變量名稱或者文件路徑，如果exportType取值為var，則該屬性的值為參數(shù)名，如果exportType取值為file，則該屬性的值為文件的絕對路徑。
operatorType：對文件的操作類型，該屬性為可選屬性，當(dāng)exportType取值為file時有效。該屬性取值有三種，分別是：overwrite（替換原來的文件）、append（追加到原來的文件中）和askuser（彈出對話框，詢問用戶）。
2.2.10 descriptionClause和pauseClause節(jié)點(diǎn)
descriptionClause和pauseClause節(jié)點(diǎn)都只有一個屬性value，用來表示描述值和暫停值。
3 結(jié)論
在測試工作越來越自動化的情況下，測試過程的自動化執(zhí)行和測試結(jié)果的自動化判定都成了關(guān)鍵。本文提出的測試事務(wù)描述方法，是從本實驗室進(jìn)行的基于CORBA、WebService、SNMP技術(shù)的接口測試系統(tǒng)的相關(guān)研究和實踐中總結(jié)出來的，并且已經(jīng)完成了相應(yīng)的開發(fā)工作，在模擬環(huán)境中通過了的相應(yīng)的測試，該描述方法在測試過程自動化進(jìn)行的情況下，對測試執(zhí)行結(jié)果進(jìn)行自動化判定，大大減少了人工操作，提高了測試效率和測試過程的自動化程度。該描述方法可以應(yīng)用于單個接口技術(shù)的網(wǎng)管接口測試中，同時也可以應(yīng)用到有多種接口技術(shù)混合的網(wǎng)管接口測試中。而且本文研究的測試事務(wù)描述方法與特定的接口技術(shù)無關(guān)，因此具有較高的通用性，能夠指導(dǎo)以后基于其他技術(shù)的接口測試系統(tǒng)相關(guān)功能的研究和開發(fā)，并且按這種描述方法開發(fā)的測試評判子系統(tǒng)也具有較好的軟件重用性。
參考文獻(xiàn)：
[1] 王智立.網(wǎng)絡(luò)管理接口一致性測試的方法、技術(shù)及應(yīng)用[D].北京:北京郵電大學(xué),2005.
[2] 劉益暢.模型驅(qū)動的3G網(wǎng)管接口測試系統(tǒng)的設(shè)計與實現(xiàn)[D].北京:北京郵電大學(xué),2010
[3] 朱鴻,金凌紫.軟件質(zhì)量保障與測試[M].北京:科學(xué)出版社,1997.
[4] 芮蘭蘭,孟洛明,邱雪松,等.基于CORBA 的網(wǎng)絡(luò)管理接口一致性測試中的測試流技術(shù)[J].北京郵電大學(xué)學(xué)報,2002,25(3):41-45.
關(guān)鍵詞：串口調(diào)試；PC機(jī)；串行通訊；RS-232
中圖分類號：TM76 文獻(xiàn)標(biāo)識碼：A 文章編號：1671-2064（2017）03-0180-02
近年來，工控PC機(jī)以其優(yōu)越的性價比和豐富的軟件資源成為自動化設(shè)備的主流機(jī)種。在電力系統(tǒng)得到廣泛的應(yīng)用，自動化系統(tǒng)的集中管理需要對現(xiàn)場數(shù)據(jù)進(jìn)行采集統(tǒng)計，同時又要求對現(xiàn)場設(shè)備進(jìn)行實時控制，完成各種規(guī)定操作，達(dá)到集中管理的目的?，F(xiàn)代電力系統(tǒng)網(wǎng)絡(luò)技術(shù)的一個突出特點(diǎn)，就是使電網(wǎng)系統(tǒng)中的所有設(shè)備連接成網(wǎng)，在一個核心軟件管理下實現(xiàn)遠(yuǎn)程監(jiān)控（4遙、5遙），形成一個有機(jī)的整體。這樣的網(wǎng)絡(luò)監(jiān)視控制系統(tǒng)，極大的提高電力系統(tǒng)的安全性和可靠性。完成數(shù)據(jù)采集是通過計算機(jī)數(shù)據(jù)通訊完成的，要維護(hù)和擴(kuò)展自動化系統(tǒng)的應(yīng)用，必須熟悉數(shù)字通訊原理和實施過程，未來以網(wǎng)絡(luò)為核心的分布式多點(diǎn)系統(tǒng)是發(fā)展趨勢。因此用最簡單的測試手段檢測智能的通訊規(guī)約具有重要的現(xiàn)實意義。
1 實現(xiàn)RS232通訊的條件
測試計算機(jī)串口通訊的基本條件：一臺帶有RS232接口的電腦、一個能插入電腦RS232口的接頭和串口測試軟件。
1.1 硬件定義
串行口也是計算機(jī)的一種標(biāo)準(zhǔn)接口，PC機(jī)一般至少有兩個串行口Com1和Com2。串行口不同于并行口，它的數(shù)據(jù)和控制訊息是一位接一位在一根傳輸線上傳送的，這樣串行口^并行口能夠進(jìn)行遠(yuǎn)距離傳送信息。串行口通常使用9針D形連接器，有些老式則使用25針D形連接器。
由于CPU與接口間按并行方式傳輸，接口與外設(shè)之間按串行方式傳輸，因此，在串行接口中，要由接收移位寄存器把串行方式轉(zhuǎn)換成并行方式，由發(fā)送移位寄存器把并行方式轉(zhuǎn)換成串行方式。完成這種轉(zhuǎn)換功能的電路叫做通用異步收發(fā)機(jī)UART。
目前RS-232是PC機(jī)與通訊工業(yè)中應(yīng)用最廣泛的一種串行接口。典型的RS-232信號在正負(fù)電平之間擺動，在發(fā)送數(shù)據(jù)時，發(fā)送端驅(qū)動器輸出正電平在5V～15V，負(fù)電平在-5V～-15V；在接收數(shù)據(jù)時，接收器的典型工作電平是3V～12V和-3V～-12V。串口傳輸數(shù)據(jù)只要有接收數(shù)據(jù)針腳和發(fā)送數(shù)據(jù)針腳就能實現(xiàn)，其接口定義如圖1所示。（引腳說明：1-CD載波檢測、2-RXD接收數(shù)據(jù)、3-TXD發(fā)送數(shù)據(jù)、4-DTR數(shù)據(jù)終端、5-GND地、6- DSR通信設(shè)備準(zhǔn)備好、7-RTS請求發(fā)送、8-CTS允許發(fā)送、9-RI響鈴指示器）。
（1）關(guān)于直連線與交叉線：直連線用于兩邊設(shè)備的接口定義不同的情況，比如RS232，標(biāo)準(zhǔn)的DTE與DCE設(shè)備，就可以直連，即DTE的1腳和DCE的1腳可以直接相連，因為DTE與DCE的引腳定義不同，如DTE的2腳發(fā)正好對應(yīng)著DCE的2腳收，這才是可以直連的原因，這才有了直連線。而交叉線指的是，兩邊設(shè)備接口定義相同，那么必須設(shè)備A的2腳發(fā)對應(yīng)設(shè)備B的3腳收，這樣做成的線就是交叉線，現(xiàn)在兩臺計算機(jī)的網(wǎng)口用網(wǎng)線相連，需用交叉線，因為接口定義相同，但現(xiàn)在的網(wǎng)卡具有自適應(yīng)功能，能夠認(rèn)出連接的線是直連線還是交叉線，自動完成通訊。RS232的db9接口的連接線包括三種公對母線，公對公，和母對母線。注意，這三種連接線都分別有交叉線和直連線，所以總共有6中連接線。下邊的一個示例為母對母交叉線。圖2是常有兩種連接。
（2）區(qū)分電路中母頭和的符號：為插針，母頭為插孔，但有時畫的不夠明確，最好是根 據(jù)引腳號的順序進(jìn)行判斷，大頭那一側(cè)5個引腳，若引腳1到5為從左到右的順序則為，反之1到5為從右到左的順序則為母頭。與母頭插在一起時，兩者同號引腳會對插在一起。
（3）標(biāo)準(zhǔn)RS-232串口主要的3個引腳號2，3，5：pin2-RX，pin3-TX，pin5-GND。
（4）連接線連接好兩個設(shè)備的串口后應(yīng)保證兩個串口引腳以匹配方式連接，即發(fā)送（pin3）對接收 （pin2），地對地（pin5）。而直連線同引腳號相連，故其兩端必有一個是非標(biāo)準(zhǔn)接口，另一個是標(biāo)準(zhǔn)接口。交叉線內(nèi)部已做交叉匹配，故其兩端可同為標(biāo)準(zhǔn)接口。
（5）直連線兩端的接頭同號引腳直接相連，用于連接標(biāo)準(zhǔn)接口和非標(biāo)準(zhǔn)接口的兩個設(shè)備，交叉線兩端接頭發(fā)送與接收交叉相連，用于連接兩個都是標(biāo)準(zhǔn)接口的設(shè)備。
（6）設(shè)備上的RS-232端口可以是或母頭，電腦端口都是。所以電腦與外設(shè)之間連接可以是 交叉線或是直連線。電腦與電腦之間連接則只能是交叉線，外設(shè)與外設(shè)之間連接則可能是交叉線或直連線。
1.2 測試軟件
常見的測試軟件有很多，可以網(wǎng)上下載串口調(diào)試助手、com調(diào)試工具等，也可自己編寫簡單的串口通訊代碼。測試用現(xiàn)成的串口調(diào)試助手比較方便，多數(shù)為綠色軟件無需安裝，體積小使用方便，界面簡單易操作易理解，能滿足大多數(shù)規(guī)約測試。
2 規(guī)約測試
2.1 接口調(diào)試
首先，要在電腦上拷貝好串口調(diào)試程序，找到串口調(diào)試程序的目錄雙擊即可運(yùn)行。運(yùn)行前要確定RS-232插頭對應(yīng)那個com。斷接RS-232頭的2針和3針，并插入電腦的串口。如果不確定對應(yīng)在com幾上，可查看電腦設(shè)備管理器中的串口3等一共有幾個見圖3。
啟動串口調(diào)試程序，如果找不到正確的com口，在串口下拉選項中選擇不同的com，直到選到的com能正確打開，見圖4。
其他參數(shù)設(shè)置見圖5。端口設(shè)置完成后在發(fā)送區(qū)輸入“hello”（不含雙引號，可輸入除漢字以外的文本）單擊“手動發(fā)送”，接收區(qū)同時顯示“hello”，如果斷開RS-232頭的2，3針，再次單擊“手動發(fā)送”測試接收區(qū)不會顯示“hello”，說明該com口調(diào)試成功，已具備接收和發(fā)送數(shù)據(jù)的功能。
2.2 通訊協(xié)議測試
將RS-232接口中的2，3，5針分別與被測試設(shè)備RS-232接口的3，2，5針連接，這時就完成了測試系統(tǒng)的連接。
（1）用modbus協(xié)議，讀取18b20溫度傳感器模塊數(shù)據(jù)，18b20定時發(fā)送檢測到的溫度數(shù)值，串口循環(huán)讀取。
（2）連接10KV柱上開關(guān)智能保護(hù)單元串口，用101規(guī)約讀取遙測、遙信數(shù)據(jù)，讀取數(shù)據(jù)完全正確。
【關(guān)鍵詞】IEC61968CX;WebServices攔截器
1.引言
隨首電力信息化系統(tǒng)的發(fā)展，各開發(fā)商為不同的業(yè)務(wù)部門開發(fā)了相應(yīng)的業(yè)務(wù)信息化系統(tǒng)，由于各開發(fā)商所使用的技術(shù)不同、開發(fā)周期不同，沒有采用統(tǒng)一的技術(shù)，從而導(dǎo)致各業(yè)務(wù)系統(tǒng)相互獨(dú)立，業(yè)務(wù)系統(tǒng)間形成數(shù)據(jù)的壁壘，數(shù)據(jù)只能在各業(yè)務(wù)系統(tǒng)內(nèi)流轉(zhuǎn)，從而產(chǎn)生“數(shù)據(jù)孤島”問題，嚴(yán)重阻礙了信息化建設(shè)的開展，容易形成重復(fù)建設(shè)的情況，降低了數(shù)據(jù)作為“資產(chǎn)”的價值。
“信息孤島”現(xiàn)象不是一個個案，在電力行業(yè)乃至信息化行業(yè)內(nèi)普遍存在，為了解決電力行業(yè)內(nèi)的“信息孤島”問題，國際電力標(biāo)準(zhǔn)委員會制定了IEC 61970/IEC 61968系列標(biāo)準(zhǔn)。IEC 61970標(biāo)準(zhǔn)中定義了公共信息模型（Common Information Model，CIM[1]）和組件接口規(guī)范（Component Interface Specification，CIS[2]），為各應(yīng)用系統(tǒng)間的交互提供了語義和語法上的依據(jù)。IEC 61970定義的CIS接口采用CORBA（Common Object Request Broker Architecture，CORBA[3]）技術(shù)，技術(shù)門檻較高，且采用緊耦合的方式，適合以高性能進(jìn)行大量數(shù)據(jù)的傳輸，對于一些通知消息類的小數(shù)據(jù)量傳輸來說，其結(jié)構(gòu)過于龐大，不利于開發(fā)商的快速實現(xiàn)，為此IEC 61968標(biāo)準(zhǔn)在IEC 61970 CIM/CIS標(biāo)準(zhǔn)的基礎(chǔ)之上，擴(kuò)展了配電管理部分的CIM模型，并定義了業(yè)務(wù)系統(tǒng)信息交換模型（Information Exchange Model，IEM[4]）和另一種松耦合方式的消息傳遞標(biāo)準(zhǔn)，以當(dāng)前流行的WebServices技術(shù)進(jìn)行實現(xiàn)。
本文對IEC 61968標(biāo)準(zhǔn)定義的WebServices標(biāo)準(zhǔn)接口進(jìn)行了介紹，同時描述了一個采用Apache CXF[5]實現(xiàn)的IEC 61968標(biāo)準(zhǔn)接口的測試方法，采用JAVA編程語言，以CXF中攔截器的方式實現(xiàn)對WebServices輸入輸出的攔截，并對輸入輸出XML[6]內(nèi)容進(jìn)行查看和編輯，可以為不同的要求配置不同的WebServices輸入內(nèi)容，從而實現(xiàn)IEC 61968標(biāo)準(zhǔn)接口的自動化測試。
2.IEC 61968 WebServices接口
IEC 61968接口可以通過多種技術(shù)方式進(jìn)行實現(xiàn)，如WebServices、JMS等，本文對WebServices實現(xiàn)方式進(jìn)行了說明。
IEC 61968標(biāo)準(zhǔn)定義了一個通用的接口，并以WSDL[7]的方式對接口進(jìn)行了規(guī)范化定義，其中WebServices服務(wù)名稱為：Service，該服務(wù)只包含三個方法：
PublishEvent：事件方法，用于事件通知。PublishEvent方法的輸入?yún)?shù)為EventMessage，返回值為ResponseMessage。
Request：請求方法，用于查詢或更新操作。Request方法的輸入?yún)?shù)為RequestMessage，返回值為ResponseMessage。
Response：響應(yīng)方法，用于對通知消息的確認(rèn)，或是對數(shù)據(jù)處理結(jié)果的反饋。Response方法的輸入?yún)?shù)為ResponseMessage，返回值為ResponseMessage。
3.IEC 61968消息結(jié)構(gòu)
3.1 消息頭結(jié)構(gòu)
IEC 61968 Header（消息頭）包含了一些消息基本描述與控制信息。請求、響應(yīng)、事件消息都有消息頭結(jié)構(gòu)。消息頭只有Verb（動詞）和Noun（名詞）兩個必須的字段，其他的字段都是可選的，消息頭包括以下元素：
Verb（動詞）：描述要進(jìn)行的動作，用來標(biāo)識要采取的動作類型，如create（創(chuàng)建）、close（關(guān)閉）、cancel（取消）;created（已創(chuàng)建）、closed（已關(guān)閉）、changed（已更改）。IEC 61968標(biāo)準(zhǔn)規(guī)范了一個動詞列表，動詞取值只能從動詞列表中選擇。
Noun（名詞）：用來標(biāo)識Payload（消息有效內(nèi)容）的類型，描述消息的主題。
Revision（修訂）：消息修訂版本號。
ReplayDetection（重發(fā)檢測）：這是一個復(fù)雜元素，包含一個timestamp（時標(biāo)）和一個nonce（隨機(jī)數(shù)）用于防止重發(fā)攻擊。時標(biāo)由源系統(tǒng)生成表示消息創(chuàng)建的時間;隨機(jī)數(shù)是一個序列號或隨機(jī)生成的字符串（例如UUID），由源系統(tǒng)生成，并且在一天內(nèi)不允許重復(fù)。
Context（上下文）：表示消息上下文，如PRODUCTION（生產(chǎn)）、TESTING（測試）、STUDY（研究）、TRAINING（培訓(xùn)）等。
Timestamp（時標(biāo)）：一個遵循ISO-8601的字符串，表示消息發(fā)送的時間。
Source（來源）：消息產(chǎn)生的來源，系統(tǒng)或組織的名稱，如EMS、GIS。
AsyncReplyFlag（異步應(yīng)答標(biāo)志）：表示應(yīng)答消息是否異步發(fā)送。
ReplyAddress（應(yīng)答地址）：異步應(yīng)答發(fā)送消息的目標(biāo)地址。
AckRequired（確認(rèn)請求）：表示請求的消息是否需要一個回傳的確認(rèn)消息。
User（用戶）：一個復(fù)雜結(jié)構(gòu)表示用戶以及相關(guān)的組織，包含一個UserID（用戶標(biāo)識）Organization（組織標(biāo)識）。
MessageID（消息ID）：消息的唯一標(biāo)識，兩個消息不允許有相同的MessageID。
CorrelationID（關(guān)聯(lián)ID）：該字段用于將消息連接在一起。該字段可以在請求中提供，因此客戶端可以關(guān)聯(lián)對應(yīng)的應(yīng)答消息。服務(wù)器段會將應(yīng)答消息的CorrelationID設(shè)置為源消息的CorrelationID取值。
Comment（注釋）：任何描述性的文字。
Property（性質(zhì)）：復(fù)合類型允許客戶以鍵/值對的方式擴(kuò)展傳輸?shù)男畔?，包含一個Name（名稱）和Value（取值）。
other（其他）：其他的客戶擴(kuò)展，由開發(fā)商自行定義擴(kuò)展。
IEC 61968標(biāo)準(zhǔn)規(guī)范了一個動詞列表，Verb（動詞）只能為下表的取值。
表1 IEC 61968推薦動詞表
請求動詞 回復(fù)動詞 事件動詞 使用場景
Get Reply 無 查詢
Create Reply Created 事務(wù)
Change Reply Changed 事務(wù)
Cancel Reply Canceled 事務(wù)
Close Reply Closed 事務(wù)
Delete Reply Deleted 事務(wù)
Execute Reply Executed 事務(wù)
Request（請求動詞）的使用方法如下：
Get用于查詢消息名詞中指定類型的對象。
Create用于創(chuàng)建消息名詞中指定類型的對象。
Delete用于刪除對象，為了維持修訂歷史，有時目錄系統(tǒng)并不是真正刪除對象。
Close和Cancel用于與業(yè)務(wù)處理相關(guān)的動作，如關(guān)閉一個工作訂單或取消了控制請求。
Change用于更改對象，但需注意，當(dāng)通過業(yè)務(wù)規(guī)則進(jìn)行表示時會模棱兩可，尤其是在復(fù)雜數(shù)據(jù)集的情況下（復(fù)雜數(shù)據(jù)集一般具有N：1的關(guān)系）。
Execute用于使用操作集進(jìn)行傳輸?shù)膹?fù)雜事務(wù)，可能包含一個以上的動詞。
每個Request（請求）都使用Reply（回復(fù)動詞）進(jìn)行回復(fù)。Event（事件動詞）常常是請求的結(jié)果，一個Create可導(dǎo)致一個Created事件的產(chǎn)生。事件中使用的動詞為相應(yīng)請求動詞的“過去式”。
消息頭的定義如圖1所示：
圖1 消息頭定義
3.2 消息請求結(jié)構(gòu)
IEC 61968Request（消息請求）結(jié)構(gòu)只用于請求消息中，用于存放請求消息的請求參數(shù)，請求結(jié)構(gòu)中的元素都不是必須的，在實際應(yīng)用中可以根據(jù)實際情況進(jìn)行選用。消息請求結(jié)構(gòu)包括的元素描述如下：
StartTime（起始時間）：當(dāng)一個請求需要起始時間作為過濾條件時使用。
EndTime（結(jié)束時間）：當(dāng)一個請求需要結(jié)束時間作為過濾條件時使用。
Option（配置）：名值對方式，在查詢請求時可作為過濾條件，可用于規(guī)定超時時間或規(guī)范化響應(yīng)模式等，在具體實現(xiàn)時作為自定義的擴(kuò)展。
ID（標(biāo)識）：在查詢請求時，可以作為過濾條件標(biāo)識一個或多個對象，可以在“close”、“delete”、“cancel”事務(wù)中標(biāo)識特定的對象。每個ID都有一組屬性，“kind”用于說明標(biāo)識的類型，如名稱、UUID、事務(wù)ID或其他類型，UUID默認(rèn)采用對象的mRID屬性取值;如果取值為名稱，“idType”和“idAuthority”需要提供。
Other：其他的自定義擴(kuò)展。
消息請求的定義如圖2所示：
圖2 消息請求定義
3.3 消息回復(fù)結(jié)構(gòu)
Reply（消息回復(fù)）作為對其他消息的響應(yīng)，包括的元素描述如下：
Result（結(jié)果）：消息回復(fù)的結(jié)果，取值為以下之一：
OK：沒有錯誤，返回所有的結(jié)果，“Error”元素不需要。
PARTIAL：部分，返回部分結(jié)果，有一個或多個“Error”元素。
FAILED：錯誤，沒有返回結(jié)果，有一個或多個“Error”元素。
Error（錯誤）：錯誤描述。
ID（標(biāo)識）：錯誤對象ID。
Other（其他）：其他的自定義擴(kuò)展。
OperationId（操作ID）：操作ID，與請求的操作相同，用于描述是對哪個請求的回復(fù)。
消息回復(fù)的定義如圖3所示：
圖3 消息回復(fù)定義
Error元素描述處理的錯誤信息，其元素描述如下：
code（錯誤代碼）：用來描述錯誤的類型。
level（嚴(yán)重級別）：分為：INFORM（信息）、WARNING（警告的）、FATAL（嚴(yán)重的）、CATASTROPHIC（災(zāi)難的）。
reason（錯誤原因）：一般為人可讀的錯誤名。
detail（詳細(xì)信息）：自由格式描述錯誤具體的信息。
xpath（出錯路徑）：XPath表達(dá)式標(biāo)識具體的出錯的XML元素，
stackTrace（異常堆棧）：軟件產(chǎn)生的異常堆棧。
Location（異常位置）：軟件產(chǎn)生異常的位置。
ID（事務(wù)ID）：對應(yīng)的事務(wù)ID。
relationID（關(guān)聯(lián)ID）：出錯的關(guān)聯(lián)對象，用于描述兩個對象間的關(guān)聯(lián)出錯。
opertionId（操作ID）：與請求的操作相同，用于描述是對哪個請求的回復(fù)。
3.4 消息有效內(nèi)容結(jié)構(gòu)
Payload（消息有效內(nèi)容）可以看作是CIM模型的一個子集，通過定義包含在該消息中的IEC TC57 CIM模型的類和屬性實現(xiàn)。并不是所有的消息都需要有效內(nèi)容，例如get，close，cancel，reply操作等只需要消息頭，有效內(nèi)容可以為空。
有些類型的消息必須提供有效內(nèi)容，如果帶有動詞create或change的請求消息，以及一些響應(yīng)消息和一些事件消息。
有效內(nèi)容一般包含遵循一個已定義了XSD[8]的XML文檔。
有些情況也會有例外，例如：一些XML有效內(nèi)容沒有XML Schemas，如RDF文件或動態(tài)查詢結(jié)果，還可能是非XML格式，如CSV和PDF。
還有些情況，有效內(nèi)容很大，必須進(jìn)行壓縮，否則將浪費(fèi)大量帶寬。為了適應(yīng)多種格式選項，有效內(nèi)容提供了以下的格式（圖4）：
圖4 消息有效內(nèi)容定義
在消息有效內(nèi)容中，我們可以通過使用XML的“any”結(jié)構(gòu)，來包含任何類型的XML文件。另外，它也提供了松耦合選項，也能使用由XSD定義的特殊復(fù)雜類型。
一些情況下可能需要zip格式、Base64+編碼的字符串，此時可在消息中使用“compressed”標(biāo)簽。下列情況需要使用壓縮方式：
一個遵循XML Schema的有效內(nèi)容，超出了預(yù)定義的大?。ㄈ纾?MB）。這種情況很常見。
具有非XML格式的有效內(nèi)容，如PDF，Excel表格，CSV文件，或二進(jìn)制圖片。
使用XML格式但沒有XML Schema的有效內(nèi)容，超出了預(yù)定義的大?。ㄈ纾?MB）。如作為一個SQL XML查詢結(jié)果生成的動態(tài)XML。
當(dāng)有效內(nèi)容采用Base64編碼的壓縮方式時，它作為一個string存儲于compressed消息元素內(nèi)。另外，為了支持二進(jìn)制格式數(shù)據(jù)的高效傳輸，數(shù)據(jù)采用Base64編碼，但不壓縮。如果XML格式不能滿足性能的要求，可以對數(shù)據(jù)進(jìn)行分類，通過壓縮方式來實現(xiàn)“高速”傳輸。
Format標(biāo)簽可以用于標(biāo)識特定的數(shù)據(jù)格式，比如XML、RDF、SVG、BINARY、PDF、DOC、CSV等。該標(biāo)簽是可選字段，它一般只用于當(dāng)有效內(nèi)容的存儲使用compressed消息元素時。
4.Apache CXF
Apache CXF是一個開源的WebServices框架，大大簡化了WebServices的創(chuàng)建，并可以在多種傳輸協(xié)議上運(yùn)行。采用CXF構(gòu)建WebServices服務(wù)非常方便，通過CXF的工具將WSDL生成為相應(yīng)的JAVA編碼后，只需要編寫少量代碼就可以實現(xiàn)WebServices服務(wù)的調(diào)用和。作為WebServices客戶端，對其他WebServices服務(wù)進(jìn)行調(diào)用時，相應(yīng)的主要代碼如下：首先構(gòu)建工廠JaxWsProxyFactoryBean對象，設(shè)置要調(diào)用的服務(wù)類型Operations和服務(wù)地址，創(chuàng)建相應(yīng)的客戶端對象client，構(gòu)建相應(yīng)的參數(shù)，調(diào)用相應(yīng)的服務(wù)方法。作為WebServices服務(wù)端，對外提供WebServices服務(wù)供其他客戶端調(diào)用時，相應(yīng)的主要代碼如下：首先要實現(xiàn)對應(yīng)的WebServices接口方法，通過Endpoint.publish，設(shè)置的地址和實現(xiàn)的對象即可。
5.CXF攔截器
通過Apache CXF實現(xiàn)WebServices的服務(wù)調(diào)用和服務(wù)非常簡單，這些作用客戶端應(yīng)用進(jìn)行服務(wù)調(diào)用和實現(xiàn)WebServices服務(wù)器很有用，但作為測試來講，只能看到高層的JAVA對象是不夠的，必須能夠查看底層的消息并可以對消息進(jìn)行隨意的編輯才能實現(xiàn)測試的目的，這可以通過CXF的攔截器來實現(xiàn)。
CXF的攔截器是CXF功能最主要的擴(kuò)展點(diǎn)。通過自定義的攔截器，可以改變請求和響應(yīng)的一些消息處理，其中最基本的原理還是一個動態(tài)。當(dāng)服務(wù)被調(diào)用時，一個攔截器鏈表被創(chuàng)建并調(diào)用。每一個攔截器都有機(jī)會做他們想要處理的消息，包括：讀取，轉(zhuǎn)化，處理頭部，驗證消息，等。攔截器可以用于CXF的客戶端和服務(wù)端。當(dāng)一個CXF客戶端調(diào)用一個CXF服務(wù)端的時候，客戶端有一個傳出（Out）的攔截器鏈，服務(wù)端有一個傳入（In）的攔截器鏈。當(dāng)服務(wù)端發(fā)送響應(yīng)給客戶端時，服務(wù)端有一個傳出（Out）的攔截器鏈，客戶端有一個傳入（In）的攔截器鏈。此外，在調(diào)用出錯的情況下，一個CXF服務(wù)將創(chuàng)建單獨(dú)的對外輸出錯誤處理鏈，客戶端將創(chuàng)建一個傳入（In）的錯誤處理鏈。
創(chuàng)建工廠后分別向攔截器鏈表中添加相應(yīng)的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對應(yīng)客戶端的傳入攔截器和傳出攔截器。服務(wù)器后分別向攔截器鏈表中添加相應(yīng)的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對應(yīng)服務(wù)端的傳入攔截器和傳出攔截器。代碼的主要思想是將原始的消息內(nèi)容XML展示出來，對其進(jìn)行修改后，將修改后的內(nèi)容放到消息流中，替換原來的消息內(nèi)容，在發(fā)送消息時發(fā)送的就是修改后的消息內(nèi)容。測試軟件的界面如圖5所示：
圖5 測試軟件界面
6.結(jié)束語
測試工具的開發(fā)平臺是Eclipse 3.6.2，采用Eclipse RCP技術(shù)開發(fā)圖形化界面，使用JAVA開發(fā)語言。這種針對IEC 61968WebServices標(biāo)準(zhǔn)接口測試方法，可針對不同的應(yīng)用場景修改相應(yīng)的測試消息內(nèi)容，具有很好的通用性，測試效率高。此種測試方法沒有考慮IEC 61868 對Payload定義XSD限制的情況，未對Payload的內(nèi)容進(jìn)一步的處理，可在此基礎(chǔ)上對其進(jìn)行改進(jìn)以適應(yīng)更廣泛的測試要求。
參考文獻(xiàn)
[1]IEC 61970-301 Energy management system application program interface（EMS-API）：Part 301 Common Information Model（CIM）Base[S].2004.
[2]IEC 61970-401 Energy management system application program interface（EMS-API）：Part 401 Component interface specification（CIS）f ramework[S].2005.
[3]OMG.CORBA/IIOP2.3 Specification[S].1998.
[4]IEC 61968-1 Application integration at electric utilities-System interfaces for distribution management-Part 1：Interface architecture and general requirements[C].2003.
[5]CXF，http：//.
[6]W3C.Extensible Markup Language（XML）1.0（Fifth Edition）.2008.
