時間：2023-03-15 15:07:22
序論：在您撰寫接口測試時，參考他人的優秀作品可以開闊視野，小編為您整理的7篇范文，希望這些建議能夠激發您的創作熱情，引導您走向新的創作高度。
關鍵詞：Iur-g+接口; TD-SCDMA; GSM; 切換; 測試方案
中圖分類號：TN929.53-34文獻標識碼：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網絡規模不斷擴大，如何將全新的3G網絡與GSM網絡充分融合，成為中國移動的┮桓鼉藪筇粽劍而兩張網絡之間的互操作問題則是挑戰的重點之一。通過分析傳統的2G/3G語音切換信令流程可知，切換信令串行通過了所有網元，其時延大大降低了系統對切換判決的及時性、準確性，也降低了切換的成功率。
Iur接口是3G系統中兩個RNC之間的邏輯接口，用來傳送RNC之間的控制信令和用戶數據。在應用中發現了上述問題后，為提高2G/3G網絡之間切換的成功率，3GPP的R5版本協議中在GERAN里引入了Iur-g+接口［1-2］。該接口可以支持兩個BSC之間、BSC和RNC之間的測量、負載信息交互，避免因網絡資源緊張而造成的切換失敗，同時可以提前進行無線資源的準備，有效地降低了切換的時延。
1 Iur-g+接口的位置
圖1給出Iur-g+接口的位置\[3-4\]。Iur-g+接口的出現改變了原有的切換流程，雖然不需要終端的配合，但是對系統側BSC,RNC之間，以及核心網的配合上仍提出了一定的要求。
圖1 Iur-g+接口在網絡中的位置
2 Iur-g+接口原理及效果
標準的Iur-g+包含信息交互、公共測量兩個流程［1-2］。信息交互流程用于在RNC和BSC之間交換不同系統下配置的小區無線資源容量信息，而公共測量流程則以負荷(LOAD)的方式在RNC與BSC之間報告當前無線資源占用情況，使雙方可以用切換目標系統的負荷作為切換判決條件。
2.1 正常切換信令流程
在增加了Iur-g+接口后，無線側3G2G的切換信令流程有所調整，圖2為調整后的3G2G正常切換的信令流程\[2，4-5\]。
圖2 Iur-g+切換流程
從流程圖中可以看到，新增的Iur-g+接口信令改變了原有的RNC與核心網之間的信令順序。BSC收到RNC發出的重定位請求后，以IMSI為標識，為用戶分配相應的無線資源，RNC在收到資源確認消息后，向核心網發出重定位請求，并在空口緩發定時器規定的時間到達后直接向UE發送切換指令；同時，核心網與BSS之間僅需要根據IMSI標識建立承載后，即可為UE提供服務，而RNC在收到核心網發來的重定位指令后不再對UE進行任何處理。
這種切換的處理方式將原有的串行信令流程中的部分流程變為并行處理，因此提高了切換的時延，同時，由于切換時首先進行了BSS側的無線資源分配，標準中還增加了BSC資源預留失敗流程［4,6-7］，還提高了在GSM高負荷區域的切換功率。
2.2 現網測試結果
根據廠家的支持情況，早在2009年5月―2010年1月間，現網已有部分同廠家BSC/RNC之間的Iur-g+接口進行了測試。從測試的結果可以看到，主要KPI在開啟Iur-g+重定位流程后沒有出現下降的情況。通過開啟Iur-g+功能后，提高了切換準備成功率；而優化的切換流程縮短了切換的時延，也有效地提高了切換成功率。
3 Iur-g+接口測試方案
3.1 測試目標
根據Iur-g+接口的主要功能，測試主要關注切換成功率的改善情況，同時還需要分析以下消息及其流程［8-9］：
Iur-g+接口消息流程［4］；
Iur-g+接口公共測量流程［4,7］；
Iur-g+接口重定位流程［4,10］。
3.2 測試方案
根據Iur-g+接口測試目標，測試分為兩階段。第一階段選取特殊場景進行路測，驗證Iur-g+接口的可用性及對特殊場景的改善效果，第二階段測試針對現網用戶，進行大范圍的網絡性能檢測，驗證Iur-g+接口的穩定性等其他性能。
第二階段測試僅需要在打開Iur-g+重定位流程后觀察KPI、切換性能等指標，而在第一階段測試方案中應包含以下重點內容。
(1) 搭建測試平臺
測試平臺包括RAN,BSS,NSS系統的所有網元，其中NodeB、BTS由于需求量較大、重新建設難度高，可直接使用現網設備。RNC,BSC的選擇則考慮網絡安全性選擇新建實驗網。由于測試中RNC,BSC需要分別進行共用MSC和跨MSC兩種方式的切換測試，因此，核心網部分一般也建議采用現網網元升級的方式進行測試。
(2) 選擇測試區域
根據Iur-g+的功能特點，其主要目標為降低切換時延、提高切換成功率，現網中主要應選取具有街角效應的快衰落場景、2G話務量較高導致切換準備成功率低的場景、高速移動場景進行測試。
(3) 系統升級方案
現網網元應根據各廠家的不同要求，進行軟件版本的升級，以支持Iur-g+功能。
對于新建實驗網方式進行測試的，可直接使新建網元具備相應版本軟件。
(4) 系統數據倒換方案
根據測試的要求，測試區域必須在開啟Iur-g+重定位流程與傳統重定位流程之間每日切換，因此需要準備兩套完整的設置數據，并做好替換腳本，在每天的固定時間進行數據倒換，使統計指標能夠進行每日對比。
(5) 路測方案
在確定測試區域后，要根據這些區域的具體情況建立路測方案。需要注意的是，由于本測試是以檢查2G/3G之間的切換流程為主要目標的，因此，本次路測也主要以產生2G/3G間的切換為目標。
同時，為達到增加切換次數的目的，有必要在測試區域采取降低發射功率、調整切換門限等人為因素來控制切換點位置、提高切換數量。
在測試完成后，剔除不合理數據，結合測試時同步采集的信令監控數據進行分析。
(6) 系統割接方案
系統割接包括基站割接，RNC，BSC的共MSC及跨MSC測試割接。
為保證2G/3G覆蓋區域重合，首先將區域內的NodeB(BTS)割接至測試所使用的RNC(BSC)上。其次將新建的實驗網設備(RNC/BSC)掛接在同一MSC下進行2G/3G共MSC的測試，完成后將RNC的Iu-CS接口割接至另一MSC下進行2G/3G跨MSC的測試。
在搭建實驗網的測試環境下進行網絡割接較為方便，無需調整數量繁多的基站割接，但跨局進行RNC割接時，修改局數據較多，應隨時監控網絡質量，以降低網絡調整帶來的風險。
以上是Iur-g+測試方案中的一些重點問題。在考慮上面技術問題的基礎上，還需要注意的是，本次測試涉及了全網所有類型的網元，因此，在各維護部門之間的人力資源協調、工期協調方面都需要注意，避免影響測試進度。
3.3 測試方案分析
3.3.1 可行性
(1) 網絡結構
如在現網基礎上進行測試，可直接升級軟件版本，方案中確認了升級進度與測試進度的配合；如采用新建RAN/BSS網元，可利用在建未入網的設備進行測試；
(2) 網絡安全
不論是否利用現網RAN/BSS網元進行測試，在測試區域中的基站仍然要負載正常用戶的業務，方案中利用晚間啟閉Iur-g+功能，降低了對普通用戶的影響，并且在系統升級、割接方面考慮到了方案的復雜性，盡可能降低測試對網絡的影響。
3.3.2 有效性
覆蓋面
測試方案包含了從核心網到終端之間的所有網元，可以檢驗在Iur-g+重定位流程開啟的情況下，對其他網元的影響情況，和其他網元與該流程的配合情況。
測試區域
本方案的測試區域包含了大多數日常無線環境，并對Iur-g+接口應用效果較為明顯的部分特殊場景進行了測試。
路由完整
測試方案包括了RNC/BSC共用MSC和跨MSC兩種情況，使測試能夠模擬規模應用后的所有信令交互流程。
用戶模擬
在路測過程中，會產生大量3G2G的切換過程，盡可能模擬用戶行為對Iur-g+接口進行測試，并且在第二階段測試用開啟1~2個RNC的Iur-g+接口，完全利用普通用戶的行為對Iur-g+接口進行測試。
綜上所述，該方案能夠可以在較少影響現網的情況下，有效地驗證Iur-g+接口的性能，并能夠記錄下Iur-g+接口應用后各網元可能產生的問題，為Iur-g+接口正式應用打好基礎。
4 重點關注問題
4.1 對現網的影響
由于第二階段測試的需求，測試基站必須使用現網基站以保證覆蓋區域內的用戶數量。這就需要在測試效果、工程難易度、對現網VIP用戶的影響等多方面因素之間權衡，既要保證測試的有效性，也要降低對在網用戶的影響。
同時，如果采用現網升級的方式進行測試平臺的搭建，還需要注意各廠家軟件升級的粒度為OMC。如果該OMC下掛網元數量較多，則會帶來升級時間長、影響范圍大、測試版本軟件穩定性不高等問題。
因此，建議在有條件的情況下，第一階段測試盡可能采用搭建專用測試平臺的方式，減少軟件升級范圍，降低對現網的影響。在第二階段測試時，選擇少量RNC覆蓋區域進行測試。
4.2 各種接口的傳輸方式
采用新建實驗網的方式中，涉及到BSC、RNC與基站傳輸、軟交換、SGSN等網元的連接，在現網傳輸、軟交換端口等資源都比較緊張的情況下，需要合理的設置新增網元的位置、接口類型等。對于現網已經IP化的端口，應盡量使用IP接口鏈接，傳統的E1鏈接方式由于涉及工程量大、割接復雜，不推薦使用。
4.3 測試場景的選擇
測試場景要滿足前面所述的幾種特殊場景的要求，部分不易選取場景可以考慮使用人工調整的方式，滿足測試要求，待第一階段測試完成后，返回正常設置。
5 結 語
Iur-g+技術可提高3G2G的切換成功率，降低切換時延，有效地提升用戶在2G/3G網絡切換區域的感受。本文通過分析Iur-g+接口測試的重點內容，并根據工作經驗提出了部分注意事項，希望能夠為后續Iur-g+接口測試工作起到一定的引導作用。
參考文獻
［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+接口方案總體技術要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無線網融合測試規范(Iur-g+)_V2.0.2\[S\].北京：中國移動通信有限公司，2009.
［9］中國移動通信有限公司.2G與TD網絡融合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.
關鍵字：高速串行接口測試，T2000，6GSPM，HDMI
1 高速串行接口簡介
隨著各類電子設備對數據傳輸速率提出了越來越高的要求，高速串行接口正被越來越多地應用到了各類電子設備中。高速串行接口通過串行的方式逐位發送和接受數據，可以在保證高數據傳輸速率的同時避免并行接口中常見的通道間互相串擾等問題。USB、SATA、PCI Express、HyperTransport、HDMI、Display Port等當今流行的接口均屬于高速串行接口。圖1所示的PC機內部結構圖很好地從一個側面反映了高速串行接口的普及程度?？梢哉f，高速串行接口已經完全融入到了人們的日常生活中。
2 高速串行接口的測試需求
在高速串行接口的測試中存在著一系列的挑戰：
1)產生和比較高速數字信號
高速串行接口的傳輸速率通常在Gbps級別。例如HDMI每通道的傳輸速率為3.4Gbps；USB 3.0的傳輸速率為5.0Gbps；SATA 3.0的傳輸速率為6Gbps。要測定此類高速串行接口，測試設備就必須能夠產生和采集相應速率的數字輸入信號。
此外，由于傳輸通路中的空間電容、電感的影響，高速數字信號在傳輸過程中無可避免地會發生畸變(主要表現在0／1之間的跳變趨于平緩)。此時就需要信號發生端具備Pre-Emphasis功能，通過在發生信號時強化跳變沿來抵消空間電容、電感對傳輸信號施加的影響。
2)支持各種時鐘類型
高速串行接口的時鐘通?？梢苑譃槿悾簳r鐘頻率與數據速率保持1：1(sDR)或1：2(DDR)的Source Synchronous時鐘、時鐘頻率遠低于數據速率的Forwarded Clock(如HDMI接口中的TMDS時鐘頻率僅為TMDS數據速率的1／10)，以及將時鐘信息通過編碼算法嵌入到數據流中的EmbeddedClock。
高速串行接口的測試設備應當能夠靈活對應各利，類型的時鐘信號。
3)Jilter注入測試能力
高速串行接口必須對輸入信號中的Jitter有一定的容忍度。為了測定該指標，就需要測試設備能夠向發送給高速串行接口的數字信號中注入各種頻率及強度的Jitter。
4)誤碼率測試能力
誤碼率測試是高速串行接口測試中的一項重要指標。它體現了高速串行接口的輸出信號質量與準確度。
5)眼圖繪制能力
眼圖是用來評價高速串行接口輸出信號質量的重要工具。通過分析眼圖，可以方便地評價信號的寬度、幅度、Jitter等一系列參數。
6)Loopback測試回路
為便于測試，不少高速串行接口提供了Loopback測試功能。測試設備需具備Loopback測試回路，才能實現高速串行接口的Loopback測試。3基于T2000的高速串口測試方案
T2000是愛德萬測試(ADVANTEST)基于開放式模塊化的一種全新概念的測試平臺。它采用了完全開放的構架從真正意義上實現了擴展性、靈活性以及經濟性。
T2000測試系統由各種不同功能的軟硬件模塊(Module)組成，也就是所謂的模塊化架構。這種構架的優點在于：
系統靈活，擁有持續升級的可能性。
方便硬件更換和升級，使測試系統升級配置時的投資達到最小化。
減少人力成本，升級后沿用同一平臺／環境，測試人員可以很快熟悉新(配置)系統。
這種針對多樣化的產品群體、具有可以靈活應用的模塊化結構的測試系統可以利用相同的技術環境，實現產品開發方面的高性能化及批量生產方面的低成本化。通過不同級別模塊的開發，擴大技術解決能力，同時有效地縮短開發時間。
針對高速串行接口的特點，ADVANTEST的T2000提供了6GSPM測試模塊，可充分滿足高速串行接口的測試需求：
1)充足的高速測試通道資源
T2000 6GSPM可以支持最高6.375Gbps的測試速率，充分滿足HDMI(3.4Gbps)、USB 3.0(5 0Gbps)、SATA 3.0(6Gbps)等各種高速串行接口的測試需求。
每塊6GSPM包含16組測試通道，每組測試通道又包含一對差分高速信號發生回路和一對差分高速信號采集回路。
其中的高速差分信號發生回路支持Pre-Emphasis功能，可通過強化跳變沿來抵消空間電容與電感對信號質量的影響。圖4為T20006GSPM使用Pre-Emphasis功能前后的波形質量對比。
2)支持各種主流時鐘類型
T2000 6GSPM內置PLL倍頻回路及CDR(Clock Data Recover)回路，可以支持Sourcesvnchronous Clock(包括SDR和DDR)、ForwardedClock、Embedded Clock等各種主流時鐘類型。
3)具備時鐘源同步功能
高速數字電路的內部時鐘或多或少地會存在Jitter。這類Jitter會導致高速串行接口輸出的時鐘信號和數據信號發生同步的漂移。T2000 6GSPM支持時鐘源同步功能，可以通過判別高速串行接口輸出的時鐘沿的位置來調整各數據通道的采樣時刻，從而消除高速串行接口輸出的時鐘與數據之間的同源Jitter。
4)具備Jitter注入測試功能
T2000 6GSPM內置Jitter發生回路，可根據程序設置向高速串行接口的輸入信號中注入30KHz～25MHz的Jitter(幅度為20ps～700ps可設定)，測定高速串行接口對Jitter的容忍度。
5)具備眼圖繪制功能
T2000 6GSPM可通過連續掃描采樣時刻和門限電壓繪制出眼圖，方便對高速串行接口的輸出信號質量進行分析。
6)支持Loopback測試
T2000 6GSPM支持Loopbaek測試。它可將從高速串行接口TX端接收到的數據發往高速串行接口的RX端，并可在Loopback測試的同時分析高速串行接口的誤碼率及Jitter容忍度。
7)豐富的圖形界面工具
T2000內置了豐富的圖形界面工具，可方便用戶對測試程序及待測器件進行調試。通過系統內置的圖形界面工具，用戶可以方便地調整測試參數、繪制Shmoo圖、眼圖、澡盆圖，對高速串行接口的性能進行評價。
4 總結
當今，高速串行接口正得到越來越廣泛的應用。高速芯片不同于普通低速SoC的特點帶來了芯片測試的挑戰。高速芯片需要更先進的測試方法來進行評價與量產測試，包括：
1)高速差分信號發生與采集回路
2)Pre-Emphasis功能
3)CDR(Clock DataRecover)功能
4)時鐘源同步功能
5)Jitter注入功能
6)與多種高速串行接口兼容
Advantest T2000擁有豐富強大的測試功能，其中的6GSPM測試模塊為高速串行接口芯片提供了全面的測試解決方案。
參考文獻
[1]《High Speed Serial Interfaces Testing Solution》――ADVANTEST
[2]《HDMI Specification Ver.l.4a》――省略
[3]《T2000 6Gbps Serial Port Module ProductDescription》――ADVANTEST
[4]省略
關鍵詞：CORBA; DII; Java
中圖分類號：TP311文獻標識碼：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的廣泛運用，將應用擴展到局域網、廣域網甚至Internet上已成為用戶的普遍需求，為此分布式計算成了新的熱點。在分布式計算環境中，異構性是一個十分明顯的特點。一個典型的分布環境包括有大型主機、UNIX工作站和PC機，各種機器所采用的操作系統和網絡通信協議也是千差萬別，在這樣的異構環境下實現信息和軟件資源的共享將十分困難，而一個健壯的分布計算框架將為分布應用軟件的開發帶來極大的好處。為了實現這一目標，OMG組織于1991年提出了公用對象請求程序結構的技術規范CORBA[1]（Common Object Request Broker Architecture，通用對象請求體系結構）。CORBA規范充分利用了現今軟件技術發展的最新成果，在基于網絡的分布式應用環境下實現應用軟件的集成，使得面向對象的軟件在分布、異構環境下實現可重用、可移植和互操作。
要想編寫一個良好健壯的CORBA應用程序，首先需要進行有效的測試。一般的測試過程是，開發人員編寫完CORBA服務器程序后，首先花費一定的時間開發客戶程序來調用CORBA服務器對象。如果要針對大量的各種輸入數據進行測試，那么客戶端測試程序的開發工作量將會很大。因此需要研制開發CORBA服務器接口測試工具，進行有效的CORBA對象接口測試，驗證CORBA接口實現的正確性。
2 系統設計
該CORBA服務器接口測試工具以下簡稱為CTester，它能夠向CORBA對象調用指定的操作，獲取或設置CORBA對象的屬性，驗證CORBA接口的實現，其參數設置方便，測試結果顯示直觀。支持測試腳本定義，用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復使用。該工具完全采用java編寫，遵從CORBA2.3規范[2]，工作平臺為IONA公司的orbix2000[3]。
2.1 設計原則
Ctester測試工具在開發過程中，遵循以下幾個原則：
1)平臺無關性：測試工具的運行應保證與操作系統無關，因此系統采用JAVA語言實現；
2)使用簡便靈活：采用圖形化GUI界面，使用簡便靈活，顯示結果直觀，操作易于掌握；
3)支持腳本定義：用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復使用；
4)采用動態調用DII：動態方式允許對任意對象進行操作，借助接口庫，動態方式可以在運行時刻查詢各對象所支持的操作，無論是操作的對象、發起調用的參數，還是發起調用的次數等等都可以由客戶程序在運行時刻視當時環境和需要而決定。因此，采用動態方式相對靜態方式而言靈活性大大增強。
2.2 系統結構
整個系統結構按功能劃分為六個模塊，分別是測試控制模塊、腳本定制模塊、腳本解釋模塊、測試驅動模塊、動態調用模塊、結果處理模塊。其中測試控制模塊提供了一個總的控制界面，進行測試過程的控制和管理，測試人員輸入指令，進行任意指定參數的操作或屬性調用。在調用結束后，由測試結果處理模塊處理并顯示返回值及輸入/輸出參數，結果也可以保存在文件中。
腳本定制模塊采用IDL格式定義測試腳本，能夠編輯、管理測試腳本文件。用戶熟悉IDL就可以編寫測試腳本，測試腳本的解釋由腳本解釋模塊進行。通過測試腳本可以向CORBA對象調用指定的操作，也可以獲取或設置CORBA對象的屬性。
在測試執行過程中，測試驅動模塊和動態調用模塊從接口存儲庫載入被測CORBA對象IDL細節。為了保持測試工具的靈活性，采用動態調用方式。系統結構如圖1所示：
3 CTester工具實現的關鍵技術
3.1 動態調用技術DII
CORBA服務器接口測試工具CTester從Client/Server模式看，實際上相當于客戶端，客戶程序對遠端對象的調用，有兩種方式：靜態方式和動態方式。本測試工具需要對任意CORBA服務器的屬性/操作進行調用，因此采用動態調用DII[4]的方式，相對靜態方式而言，該種方式有以下幾個優點：
(1)靈活。動態方式允許對任意對象進行操作，所需要的只是目標對象的對象引用。借助接口庫，動態方式可以在運行時刻查詢對象所支持的屬性/操作信息，大大提高了程序的靈活性。
(2)客戶程序的可移植性增強。由于DII與客戶之間的接口是標準的，因此由動態方式實現的代碼具有良好的可移植性。
(3)可執行程序的“體積”小。與靜態方式不同，DII不需要為每個接口生成碼根和框架，無論程序中使用多少接口，所需要的只是一套支持DII的接口庫，這樣可執行程序的“體積”會相對較小。
當然，與靜態方式相比，動態方式有以下的缺點：
(1)使用復雜。使用靜態方式時，對目標對象的操作都施加在一個本地的對象上，相應對象支持的所有操作及格式都已經預先定義在這個對象中，因而使用方便。在動態方式下，程序員需要自己動手，“臨時”構建一個請求并發送，同時程序還需要查詢接口庫以獲得屬性/操作必要描述信息，這些過程都較靜態方式復雜。
(2)速度緩慢。由于靜態方式下類型信息都是確定的，因此速度較快；而動態方式實現時，類型信息都是動態獲知，速度不可避免要慢一些。此外，程序要花去大量時間來查詢接口庫，尤其當被查詢的接口定義存放在遠端時，這些查詢還會引發遠端調用，致使動態方式的速度變得更慢。
鑒于上述動態調用速度緩慢的缺點，為避免程序每次調用都去查詢接口庫來獲得屬性/操作的描述信息，我們采用預先將接口庫中所有數據類型的接口定義對象轉化為本地用java實現的類對象，這樣程序就不必花費大量的時間來查詢接口庫，而只需調用所需類的屬性或方法即可，大大提高了調用執行的效率。
動態調用的過程簡要歸納如下：
(1)獲得接口名，將目標對象接口信息注冊到接口庫中；
(2)從接口庫的對象中，找到所要調用的操作（或方法）的描述；
(3)建立調用參數表，并逐一填入參數；
(4)創建請求，請求中應包括目標對象的引用、方法名、參數表和返回值；
(5)調用請求，并作結果處理。
3.2 采用面向對象的系統實現系統采用面向對象的思想，將接口庫中各種數據類型對象一一轉化為用java類實現的對象，對CORBA服務器屬性/操作的調用變成了對相應java類的屬性方法調用，提高了接口庫查詢效率，使得程序結構更加合理，易于維護。啟動CTester工具后首先要執行“Load-ifr”命令，將接口庫中所有IDL文件詳細描述信息裝入CorbaRepository類[5]，其中也包括要測試的CORBA服務器IDL描述文件信息，然后再調用“attribute”或“operation”命令對CORBA服務器中的屬性、參數進行設置/獲取，對CORBA服務器中的操作進行調用，獲得inout/out參數結果和返回值，驗證結果返回值是否正確。
4 總結
本課題在對CORBA服務器接口測試技術經過大量的研究后，開發了相應的測試工具來驗證CORBA接口的實現，該工具可以為分布式系統的開發提供測試手段。
參考文獻：
[1] 汪蕓．CORBA技術及其應用[M]．江蘇：東南大學出版社，1999.1-12.
[2] 朱其亮,鄭斌．CORBA 原理及應用[M]．北京：北京郵電大學出版社，2001.15-37.
[3] Orbix 2000 Programmer’s Guide Java Edition[EB/OL]．．2004-09-16.
關鍵詞： 模型檢驗；接口變異；切片技術；功能依賴圖
中圖分類號：TP311 文獻標識碼：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
模型檢驗技術作為一種形式化驗證方法，以其自動化程度高的特點已經廣泛應用于計算機硬件、通信協議的分析與驗證等許多領域，它通過窮盡地搜索有限狀態系統的狀態空間，從而判定系統（模型）的每一個狀態是否滿足給定的性質，并且總會以“是”或“否”為結果而終止[1]。目前，利用模型檢驗技術進行測試用例生成的研究也十分活躍，并且也取得了一定的研究成果[2]。同時，隨著程序模型檢驗工具的誕生，一些將變異測試方法與程序模型檢驗工具相結合并生成測試用例的研究工作也得到了一定進展[3]。
盡管模型檢驗技術在自動化方面具有許多優點，但它是采用窮盡搜索系統空間的方法對所給定的性質進行驗證，因此，對并發系統而言，其狀態數往往隨并發分量的增加呈指數增長，這樣就產生了“狀態空間爆炸”（state-explosion）問題[1]。對于基于模型檢驗的變異測試來說，當對非等價變異體采用“搜索所有的反例路徑”的策略進行驗證，以及對等價變異體進行驗證時，都必須通過搜索整個系統的狀態空間才能夠進行判定，所以這樣就影響了模型檢驗的驗證效率。
因此，為了壓縮系統狀態空間的數量，本文將通過建立構件系統的功能依賴圖，然后運用切片技術[4]對其進行切片。最后，本文將以Java PathFinder作為模型檢驗工具，采用基于模型檢驗技術的接口變異測試方法[5]對JavaBean構件進行接口變異測試，并對所切片效果進行驗證。圖1給出了該方法的測試用例生成框架。
1 構件系統的功能依賴圖
S.Horwitz等人通過引入系統依賴圖（System Dependence Graph，SDG）的概念表示了具有多個過程的程序依賴圖[6]，但是使用該方法就必須知道每一個過程內部的具體細節信息，因此這種方法并不適用于在源碼未知情況下的構件化軟件切片；雖然文獻[7]提出了一種能夠對由構件所組成的系統進行切片的方法，但是這種方法卻只考慮了構件之間接口的交互關系而忽略了構件在系統中的狀態。因此，本文以文獻[8]所提出的構件之間接口的交互關系為基礎，在細化了構件之間的接互圖后，使其能夠在清晰描述源碼未知情況下被測試構件的狀態和接口函數之間的關系的同時，也能夠使切片技術適用于對被測試構件系統的接口調用關系模型的狀態空間的壓縮。
1.1 功能依賴圖的組成
本文以該被測試構件的接口規約說明為依據，通過測試驅動程序對被測試構件，或者是將該被測試構件和與之相關的構件關聯后進行建模，從而建立被測試構件的接口調用關系模型。通過這個構件系統的接口調用關系模型，被測試構件所具備的相關功能會在利用模型檢驗技術進行驗證的過程中表現出來。因此，將細化后的構件之間的接互關系稱之為構件系統的功能依賴圖（Function Dependence Graph，FDG），并且該圖是由測試驅動節點（Test Driver Node）和構件節點（Component Node）兩種類型的節點所組成。
測試驅動節點是由被測試構件的測試驅動程序所虛擬出來的一個節點，它是整個構件系統的主體框架。從切片技術的觀點來分析，該節點實際上就是它所代表的測試驅動程序的過程依賴圖[3]（Process Dependence Graph）。
構件節點實際上在代表被測試構件的同時，也可以代表與被測試構件相關聯的構件。為了能夠應用切片技術對其進行切片，需要通過添加一些輔助接點對構件節點及輔助邊對其進行細化。這里通過定義一個五元組C = 來描述一個構件節點，具體如圖2所示。
1） 構造函數輔助節點（Construction Assistant Node）的集合Con
對于JavaBean構件來說，為了體現面向對象的特征，在構件節點中應該添加與之相關的所有構造函數的構造函數輔助節點（Conk表示構件中第k個構造函數）。輔助節點實際上就是該構件的入口節點。
2） 狀態輔助節點（State Assistant Node）的集合S
由于在代碼未知情況下的構件接口測試是一種黑盒測試，因此，還必須在構件節點中添加表示構件狀態的狀態輔助節點（Si表示構件中第i個狀態）。
3） 接口函數輔助節點（Interface Function Assistant Node）的集合I
在構件節點中添加表示該構件所包含的所有接口函數的接口函數輔助節點（Im表示構件中第m個接口函數）。
4） 輸入參數輔助節點（Input Parameter Assistant Node）的集合p
對于每一個包含輸入參數的接口函數應該在其所對應的接口函數輔助節點中添加表示該接口函數中所有參數的輸入參數輔助節點（pn表示該接口函數中的第n個參數）。
5） 輔助節點之間輔助邊（Assistant Edge）的集合E
為了能夠體現出上述輔助節點之間的內在關系并使切片技術能夠適用于構件節點，還必須根據構件的規約說明在輔助接點之間添加相應的邊。首先，由于通過構造函數在實例化一個構件的時候，與該構件相關的狀態和接口調用函數也會被創建，因此，就必須在構造函數輔助節點和狀態輔助節點以及構造函數輔助節點和接口函數輔助節點之間添加一條控制依賴邊；其次，根據構件的接口規約說明，應該在具有控制依賴關系的接口函數之間添加能夠代表它們之間控制依賴關系的控制依賴邊；最后，由于構件相關的狀態信息是通過與之相關的構件接口函數進行改變的，所以需要在接口函數輔助節點和狀態輔助節點之間添加一條控制依賴邊，同時，構件的狀態信息也需要通過接口函數向外界進行表現，因此，還應該在狀態輔助節點和與之相關接口函數輔助節點之間添加一條數據依賴邊。綜上所述，構件節點之間輔助邊的集合E是控制依賴邊Ec和數據依賴邊Ed的并集，即：E = Ec U Ed。
1.2 功能依賴圖的建立及其切片
在明確了構件系統的功能依賴圖的組成后，就應該根據測試驅動程序將測試驅動節點和構件節點進行關聯，從而建立整個構件系統的功能依賴圖，它主要包括建立測試驅動程序的過程依賴圖和確立該過程依賴圖與構件節點之間關聯關系兩個主要步驟。
文獻[9]給出了建立測試驅動程序過程依賴圖的具體方法和步驟，故本文在此不作熬述。
本文的研究重點在于對構件的接口進行測試，因此，對被測試構件系統的功能依賴圖的建立主要就體現在確立測試驅動程序的過程依賴圖和構件節點之間的關系之上，這些關系主要包括了如下四個方面：
1） 測試驅動程序對構件的實例化
在測試驅動程序中需要通過構造函數對JavaBean構件進行實例化。這樣，就必須添加一條描述測試驅動程序對構件進行實例化的控制依賴邊。
2） 測試驅動程序對構件中接口函數的調用
對構件中接口函數的每一次調用，需要添加一條描述測試驅動程序對接口函數進行調用的接口函數調用邊。
3） 測試驅動程序對構件中接口函數的參數輸入
對于擁有輸入參數的接口函數來說，測試驅動程序在對其進行調用時，對于每一個輸入參數都需要添加一條描述測試驅動程序在對其進行調用時的參數輸入邊。
4） 構件中接口函數對測試驅動程序的響應
對接口函數的調用實際上相當于對構件中相關功能進行了一次使用，因此，構件就必須向外界產生這個調用的一個響應，這樣，就必須添加一條描述構件中接口函數響應的邊。
本文以三角形問題的JavaBean構件為例進行研究，表1給出了三角形問題構件中的接口函數及接口函數所對應的狀態。
在依據三角形問題構件的接口規約說明建立測試驅動程序后，圖3給出了其構件系統的功能依賴圖。圖中右側部分是測試驅動程序節點，它是由被測試構件的測試驅動程序所建立的過程依賴圖組成的[5]；圖中左側部分是三角形問題構件的構件節點，該節點中的S1、S2和S3分別代表了構件中的三個狀態：bTriangle、 bRight和tType。由于三個接口函數的輸入參數都是三個整形變量，因此，為了便于觀察，在具體作圖的過程中將輸入參數a、b、c三個節點視為一個節點。
建立構件系統的功能依賴圖后，就可以運用切片技術對其進行切片。在基于模型檢驗技術的變異測試方法的測試用例的生成過程中，是通過引入斷言違背機制將原有模型和變異模型結合并對構件的狀態進行判定從而誘發錯誤生成并得到反例路徑。因此，為了能夠找到導致這個斷言違背所產生錯誤的原因，就必須找到在這個斷言違背之前，系統模型中哪些語句或者是哪個謂詞表達式影響了所關注的這個斷言違背，并且它們是如何傳播到這個地方。這樣在對功能依賴圖進行切片時，就可以采用文獻[6]中所提出的后向切片準則和兩步圖的可達性算法對構件系統的功能依賴圖進行切片。
2 實驗結果和分析
2.1 實驗對象說明及實驗結果
本節以三角形問題構件中反應三角形類型的狀態“tType”作為興趣點，對其構件系統的功能依賴圖進行切片試驗。圖4所得到的即為切片后的三角形問題構件系統的功能依賴圖。
在利用基于模型檢驗的接口變異測試方法對構件系統進行驗證并生成測試用例時，為了能夠體現出構件系統模型中存在的“狀態空間爆炸”問題以及通過切片技術對系統的狀態空間進行壓縮后的效果，首先選擇三角形問題構件的接口函數TriType（int a， int b， int c）的等價變異體TriType（int c， int b， int a）作為研究對象，并將三邊的輸入域劃分為5組進行對比分析。
表2給出了在上述實驗條件下，JPF對切片前后的構件系統在模型驗證后所得到的狀態數，它是由JPF統計信息中“state”里面的“new”與“visited”相加所得到的。
對表2進行分析可知：
首先，除去最后一行對壓縮率的分析外，表格中的每一行都反應出隨著三角形三邊輸入域的增加，整個模型檢驗過程所耗費的時間以及在驗證過程中所產生的狀態數都在以指數形式增加，這就體現了在本章最開始所提到的“狀態空間爆炸”問題。
其次，表格中的每一列說明了在對構件接口調用關系模型運用切片技術后，模型檢驗工具在驗證過程中所耗費的時間有了一定的減少，而且在整個驗證過程中系統模型所產生的狀態空間的數量也得到了壓縮，模型檢驗的驗證效率得到了提高。
再次，由于上述五組實驗只改變了三角形問題構件的輸入域，對于構件系統模型本身并沒有進行改變，因此，在使用相同的切片準則并運用切片技術對構件系統的功能依賴圖進行切片后，所得到的系統模型的狀態空間壓縮率在效果上基本是相同的。
最后。上述五組實驗的驗證結果都沒有檢驗出任何反例路徑，因此，切片技術的運用并不會影響“基于模型檢驗技術的接口變異測試方法”對等價變異體的正確判定。
2.2 統計分析
在上一小節中，通過利用JPF對同一個等價變異體TriType（int c， int b， int a）的五組不同輸入域的檢驗，說明了運用切片技術對構件系統中單個接口函數的等價變異體進行壓縮后，依然能夠通過“基于模型檢驗技術的接口變異測試方法”對等價變異體進行有效地判定。但是，當同一個構件中所有不同的接口函數在分別運用切片技術對構件系統模型進行壓縮后，上述實驗結果并不能夠說明切片技術對整個構件系統的驗證以及對接口測試用例生成所產生的影響。因此，本小節將就這一問題作進一步的討論。
這里，分別以三角形問題構件中的三個狀態屬性作為興趣點對構件系統進行切片，然后三個接口函數的非等價變異體對切片后的構件系統模型進行變異并驗證。表4給出了三個接口函數在切片前后進行變異并生成測試用例的相關驗證信息，為了能夠達到對系統模型狀態空間進行窮盡搜索以及對非等價變異體生成所有測試用例的目的，這里將JPF中的搜索配置策略設置為“搜索顯示多條反例路徑”。同樣地，表3所產生的狀態數也是由統計信息“states”中“new”與“visited”相加得到的。
通過對表3可以發現：
首先，對于每一個需要驗證的系統模型來說，在運用切片技術對系統模型進行切片之后，都能夠達到壓縮系統模型狀態空間數量，并提高驗證效率的目的。
其次，表中的數據以及實際的實驗結果說明，切片后的系統模型在驗證后所產生的反例路徑與切片之前所產生的反例路徑是相同的，因此，切片前后所產生的測試用例也是一樣的。
最后，盡管切片技術是對構件系統的功能依賴圖進行切片，但其實質上是對構件系統的狀態空間進行縮減。由于三角形構件系統中僅由一個三角形構件組成，因此其狀態空間是由三邊的輸入域所確定，這樣，表中三組實驗所對應的切片前的構件系統模型在驗證后所產生的狀態空間總數是一樣的；同時，對于每一個切片后的構件系統模型來說，其狀態空間是由三角形構件中的一個狀態所決定的，而該狀態又是由相同的輸入域確定，因此在切片后，構件系統模型的狀態空間總數也是一樣的。綜上所述，三組實驗的狀態空間壓縮率也是相同的。
3 結束語
目前，基于模型檢驗的測試用例生成技術作為一種新興的軟件測試方法已經得到了測試人員的廣泛關注，但是由于模型檢驗技術中所存在的“狀態空間爆炸”問題會使得驗證的效率較為低下，因此，本文主要講解了運用切片技術對系統模型進行切片從而達到壓縮系統模型狀態空間，并提高驗證效率的目的。
本文以構件之間接口的交互關系為基礎，通過擴展構件之間接互圖后，提出了一種建立構件系統的功能依賴圖的具體方法，然后運用切片算法實現了對其進行切片的目標。最后，本文通過基于模型檢驗的接口變異測試方法對三角形問題的JavaBean構件的實驗說明：在運用切片技術對系統模型進行切片以后，達到了有效壓縮系統狀態空間數量并提高驗證效率的目的，同時，不但可以對等價變異體模型進行正確地判定，而且對于非等價變異體模型來說還可以正確地生成測試用例。
參考文獻：
[1] 林惠民， 張文輝. 模型檢測：理論，言方法與應用[J]. 電子學報， 2002， 30（12A）： 1907-1912.
[2] 梁陳良， 聶長海， 徐寶文， 陳振宇. 一種基于模型檢驗的類測試用例生成方法[J]. 東南大學學報（自然科學版）， 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] 李必信. 程序切片技術及其應用[M]. 北京： 科學出版社， 2006： 3.
[5] 張K， 王[， 韓柯， 歐陽志強. 面向構件接口變異的模型檢驗技術研究[J]. 電腦知識與技術， 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.
關鍵詞：計算機軟件；網絡管理；接口一致性測試；事務模型；測試流；XML語言
中圖分類號：TP311文獻標識碼：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
網絡管理接口的一致性測試是保證不同的網管系統之間能進行互聯、互通和互操作的重要手段和必要步驟[1]。網絡管理接口一致性測試是面向電信級網絡管理軟件的測試，要完成對如此復雜龐大的軟件接口的測試任務，僅靠人工手動測試不但耗時耗力，而且難以保證測試的質量[2]。因此，網管接口一致性測試的自動化程度，始終是相關測試研究工作所追求的目標之一。要提高網管接口一致性測試的自動化程度，測試過程自動化的將成為一個重要環節。在實際的接口測試中，一方面需要對同一接口規范不同提供者的實現分別進行測試，另一方面又要對某些接口實現進行回歸測試[3]。因此將測試過程自動化機制引入網管接口的一致性測試很有意義。
目前在網管接口一致性測試中，測試過程自動化方面已有一些研究成果，文獻[4]提出了測試流技術，通過測試流技術實現測試過程自動化，并將測試流控制語句按功能分為基本功能語句模塊、判斷語句模塊、循環語句模塊、異常捕獲語句模塊和輔助語句模塊共五個模塊。但是該文獻并未給出測試流技術的具體設計實現與應用，隨著網管接口測試技術的發展，測試流在實際的測試應用過程中存在本有以下兩個弊端：
1）測試流采用純文本方式定義，其格式不可通用，而且由于沒有層次結構，當腳本文件較大時，測試人員很難看明白腳本，如果腳本有錯誤時，檢查也很困難。
2）測試流腳本與接口技術直接關聯，對于不同的接口技術，要為之定義專門的測試流腳本。
本文將基于文獻[4]中提出的測試流技術，進一步進行擴展，引入測試事務[5]的概念，同時本文對測試流控制語句進行擴充，設計出了一套格式通用且與網管接口技術無關的測試事務描述方法。該測試事務描述方法采用目前使用非常廣泛的XML格式來進行定義，所以該描述方法具有理解容易、操作簡單、使用方便等特性。另外，該描述方法還具備通用性和可擴展性，不僅可以應用于目前所有的主流網管接口技術，如CORBA、WebService、SNMP等技術，而且對于以后出現的新接口技術也可以使用該方法。
1 測試事務模型介紹
分散的、獨立的測試用例無法體現實際應用環境中用戶的動態行為，因此需要一種方法來描述測試用例[6]間的組織關系。測試事務就是若干個相關聯的、可能具有數據或業務依賴關系并按照一定的業務邏輯順序執行的測試用例的組合。測試事務即可以是簡單事務（例如修改對象屬性值），也可以是復雜事務（例如創建一個對象，然后修改該對象的屬性值，最后將該對象刪除，并在創建、修改和刪除操作之間，進行查詢該對象屬性值的操作）。測試事務必須能夠體現出測試用例的邏輯順序調用關系、根據上一測試用例的執行結果判定選擇下一測試步驟分支、測試步驟的條件迭代、測試用例的參數賦值（包括變量賦值和測試用例上下文賦值）、測試結果數據的保留和再利用、測試結果的評判等。
在網管接口一致性測試中，測試人員在拿到測試規范之后，需要將測試規范按照功能模塊劃分為若干測試事務，每個測試事務對應一個測試流腳本，而測試流是一系列的基本測試用例和相關的邏輯控制信息的組合。如圖1所示。
2 測試事務描述方法
在測試事務的描述方法中，基本單元為測試用例（稱為TC），主要的邏輯控制信息包括：Transaction、varDefineClause、varDefineFunctionClause、ifClause、forClause、whileClause、exportClause、pauseClause、descriptionClause、Debug 、break和exit，通過這些邏輯控制信息，控制TC的執行邏輯順序，并實現測試數據在TC間的傳遞。
測試事務描述方法采用XML格式進行定義，所以我們需要定義一套Schema，下面主要介紹Schema中各個節點的定義以及結構。
2.1 節點的定義
testFlow節點：XML文件的根節點，不能被其它任何節點包含，在測試過程中不具有實際意義。
TC節點：測試用例調用節點，每個TC代表一個接口中的操作。
Transaction節點：交易節點，該節點可以將若干個測試用例（TC）集合在一起，如在3G通信網中將所有與通知相關的操作放在一個交易中，將所有與告警相關的操作放在一個交易中，這樣便于整個測試流語言的管理。
varDefineClause節點：變量定義節點，該節點主要用于定義能夠存儲和交換數據的變量，并給變量賦值，定義后的變量可以在后面操作中使用。
varDefineFunctionClause節點：變量定義節點，該節點與varDefineClause節點不同的是對變量的賦值是通過已經定義好的函數進行賦值。例如要定義一個整數變量n，但是n的值不能事先知道，需要通過取一個字符串的長度來確定，這樣就可以通過一個取字符串長度的函數來給變量n賦值。
ifClause節點：條件控制節點，該節點主要用于上下文的條件判斷以選擇要執行的下一步，如果條件判斷結果為true，則執行該節點下的測試用例，如果判斷結果為false，則不執行該節點下的測試用例。
forClause節點：循環控制節點，該節點主要用于控制特定步驟的循環執行，主要應用與已經知道循環次數的情況下。
whileClause節點：循環控制節點，該節點主要用于控制特定步驟的循環執行，主要用于不確定循環次數的情況下。例如在測試過程中，某個操作的返回參數為“FALSE”時，循環體中的測試用例就要執行，如果該操作的返回參數為“TRUE”時，循環結束，這種情況下我們只能使用該節點。
exportClause節點：輸出節點，該節點主要用于將某個操作的參數的返回值輸出出來，輸出方式有兩種，一種是輸出到文件中，另一種是輸出到一個變量中。
descriptionClause節點：描述節點，該節點主要是用于對測試流增加注釋或者描述，便于測試人員編寫和查看測試流文件。
pauseClause節點：暫停節點，該節點主要作用為暫定，可以將測試流的執行暫停若干時間，時間單位為秒。例如某些操作在下發之后，需要等幾秒鐘才能查看操作的狀態，那么就需要該節點來進行暫停。
Debug節點：調試節點，該節點與編程中的斷點類似，設置了該節點之后，測試流在執行到該節點時會停下，給用戶彈出詢問窗口，如果用戶選擇繼續執行，則測試流繼續執行，如果用戶選擇停止，則測試流終止執行。
break節點：循環體結束節點，該節點主要用于結束其所在的循環體。
exit節點：測試流結束節點，該節點主要用于結束整個測試流。
2.2 節點的結構及其描述
2.2.1 testFlow節點
testFlow節點為根節點，其結構圖如圖2所示。從圖中可以看出根節點下可以包含除了break和exit之外的所有節點。
2.2.2 TC節點
TC節點代表接口中的操作，其結構圖如圖3所示，每個TC包含三部分，分別是基本屬性Attributes、參數列表ParameterList和檢查列表CheckList。
其中基本屬性包含1個可選屬性和2個必選屬性，下面給出各個屬性的含義和示意性的用法說明：
alias：當前測試用例的別名，為了讓測試人員更好的區分所下發的操作，例如對于訂購通知，下發的操作都是一樣的，但是有可能某個操作訂購的是配置相關的通知，另外一個訂購的是告警相關的通知，有了別名之后就可以更好的來進行區分。alias為可選屬性，用戶可以根據實際情況來決定是否需要。
InterfaceType：接口類型，用來區分下發的操作是采用哪種接口技術，如：CORBA、WebService、SNMP等等。
Opinfo：操作的具體信息，用來表示下發的操作的具體信息。
參數列表ParameterList：主要是為TC中的參數賦值，參數列表中的每個參數都可以分別給他們賦值，參數的結構圖如圖4所示。每個參數都兩個屬性paraName（參數名稱）和type（參數類型），另外有5種賦值方式，分別是set（直接為參數賦值），assign（將其它TC的返回值賦值給該參數），varAssign（將已經定義好的變量的值賦值給該參數），default（默認值），function（將函數的返回值賦值給該參數）。
檢查列表CheckList：主要是用來判定TC的執行結果，同時也可以作為if和while的條件判定。其結構圖如5所示，檢查列表將若干個檢查點（CheckPoint），通過and、or或not相互連接組合（and節點是邏輯與關系，or節點邏輯或關系，not節點是邏輯非關系），從而滿足一定的判定要求。
2.2.3 Transaction節點
Transaction節點可以自包含，其結構與根節點testFlow相同，下可以包含除了break和exit之外的所有節點，這里不再給出其結構圖。該節點有一個屬性transactionName（交易名稱），用來區分不同的交易。
2.2.4 varDefineClause節點
varDefineClause節點為變量定義節點，其結構如圖6所示，該節點包含3個屬性，分別是varName（變量名）、varType（變量類型）和varValue（變量值）。
2.2.5 varDefineFunctionClause節點
varDefineFunctionClause節點為變量定義節點，其結構如圖7所示，由于該節點是通過函數為變量賦值，所以該節點的三個元素分別是varName（變量名）、varType（變量類型）和functionName（函數名）。
2.2.6 ifClause節點
ifClause節點為條件控制節點，其結構如圖8所示。ifClause節點有一個CheckList元素，與TC中的檢查列表是相同的，這里不再說明。ifClause下可以包含所有的節點。
2.2.7 forClause節點
forClause節點為循環控制節點，其結構與根節點testFlow相同，下可以包含除了break和exit之外的所有節點，這里不再給出其結構圖。該節點有4個屬性分別是varName（變量名），from（變量的初始值），to（變量的終止值），step（循環的步長）。
2.2.8 whileClause節點
whileClause節點為循環控制節點，其結構與根節點testFlow相同，下可以包含除了break和exit之外的所有節點，這里不再給出其結構圖。該節點有一個CheckList元素，與TC中的檢查列表是相同的，這里不再說明。
2.2.9 exportClause節點
exportClause節點為輸出節點，其結構如圖9所示。該節點有5個必選屬性和一個可選屬性，下面給出各個屬性的含義和示意性的用法說明：
InterfaceType：接口類型，用來區分下發的操作是采用哪種接口技術，如：CORBA、WebService、SNMP等等。
Opinfo：操作的具體信息，用來表示下發的操作的具體信息。
para：操作的參數名，用來表示要將操作中的哪一個參數的值輸出。
exportType：輸出類型，分為兩種，一種是輸出到變量（取值為var），一種是輸出到文件中（取值為file）。
value：輸出的變量名稱或者文件路徑，如果exportType取值為var，則該屬性的值為參數名，如果exportType取值為file，則該屬性的值為文件的絕對路徑。
operatorType：對文件的操作類型，該屬性為可選屬性，當exportType取值為file時有效。該屬性取值有三種，分別是：overwrite（替換原來的文件）、append（追加到原來的文件中）和askuser（彈出對話框，詢問用戶）。
2.2.10 descriptionClause和pauseClause節點
descriptionClause和pauseClause節點都只有一個屬性value，用來表示描述值和暫停值。
3 結論
在測試工作越來越自動化的情況下，測試過程的自動化執行和測試結果的自動化判定都成了關鍵。本文提出的測試事務描述方法，是從本實驗室進行的基于CORBA、WebService、SNMP技術的接口測試系統的相關研究和實踐中總結出來的，并且已經完成了相應的開發工作，在模擬環境中通過了的相應的測試，該描述方法在測試過程自動化進行的情況下，對測試執行結果進行自動化判定，大大減少了人工操作，提高了測試效率和測試過程的自動化程度。該描述方法可以應用于單個接口技術的網管接口測試中，同時也可以應用到有多種接口技術混合的網管接口測試中。而且本文研究的測試事務描述方法與特定的接口技術無關，因此具有較高的通用性，能夠指導以后基于其他技術的接口測試系統相關功能的研究和開發，并且按這種描述方法開發的測試評判子系統也具有較好的軟件重用性。
參考文獻：
[1] 王智立.網絡管理接口一致性測試的方法、技術及應用[D].北京:北京郵電大學,2005.
[2] 劉益暢.模型驅動的3G網管接口測試系統的設計與實現[D].北京:北京郵電大學,2010
[3] 朱鴻,金凌紫.軟件質量保障與測試[M].北京:科學出版社,1997.
[4] 芮蘭蘭,孟洛明,邱雪松,等.基于CORBA 的網絡管理接口一致性測試中的測試流技術[J].北京郵電大學學報,2002,25(3):41-45.
關鍵詞：串口調試；PC機；串行通訊；RS-232
中圖分類號：TM76 文獻標識碼：A 文章編號：1671-2064（2017）03-0180-02
近年來，工控PC機以其優越的性價比和豐富的軟件資源成為自動化設備的主流機種。在電力系統得到廣泛的應用，自動化系統的集中管理需要對現場數據進行采集統計，同時又要求對現場設備進行實時控制，完成各種規定操作，達到集中管理的目的。現代電力系統網絡技術的一個突出特點，就是使電網系統中的所有設備連接成網，在一個核心軟件管理下實現遠程監控（4遙、5遙），形成一個有機的整體。這樣的網絡監視控制系統，極大的提高電力系統的安全性和可靠性。完成數據采集是通過計算機數據通訊完成的，要維護和擴展自動化系統的應用，必須熟悉數字通訊原理和實施過程，未來以網絡為核心的分布式多點系統是發展趨勢。因此用最簡單的測試手段檢測智能的通訊規約具有重要的現實意義。
1 實現RS232通訊的條件
測試計算機串口通訊的基本條件：一臺帶有RS232接口的電腦、一個能插入電腦RS232口的接頭和串口測試軟件。
1.1 硬件定義
串行口也是計算機的一種標準接口，PC機一般至少有兩個串行口Com1和Com2。串行口不同于并行口，它的數據和控制訊息是一位接一位在一根傳輸線上傳送的，這樣串行口^并行口能夠進行遠距離傳送信息。串行口通常使用9針D形連接器，有些老式則使用25針D形連接器。
由于CPU與接口間按并行方式傳輸，接口與外設之間按串行方式傳輸，因此，在串行接口中，要由接收移位寄存器把串行方式轉換成并行方式，由發送移位寄存器把并行方式轉換成串行方式。完成這種轉換功能的電路叫做通用異步收發機UART。
目前RS-232是PC機與通訊工業中應用最廣泛的一種串行接口。典型的RS-232信號在正負電平之間擺動，在發送數據時，發送端驅動器輸出正電平在5V～15V，負電平在-5V～-15V；在接收數據時，接收器的典型工作電平是3V～12V和-3V～-12V。串口傳輸數據只要有接收數據針腳和發送數據針腳就能實現，其接口定義如圖1所示。（引腳說明：1-CD載波檢測、2-RXD接收數據、3-TXD發送數據、4-DTR數據終端、5-GND地、6- DSR通信設備準備好、7-RTS請求發送、8-CTS允許發送、9-RI響鈴指示器）。
（1）關于直連線與交叉線：直連線用于兩邊設備的接口定義不同的情況，比如RS232，標準的DTE與DCE設備，就可以直連，即DTE的1腳和DCE的1腳可以直接相連，因為DTE與DCE的引腳定義不同，如DTE的2腳發正好對應著DCE的2腳收，這才是可以直連的原因，這才有了直連線。而交叉線指的是，兩邊設備接口定義相同，那么必須設備A的2腳發對應設備B的3腳收，這樣做成的線就是交叉線，現在兩臺計算機的網口用網線相連，需用交叉線，因為接口定義相同，但現在的網卡具有自適應功能，能夠認出連接的線是直連線還是交叉線，自動完成通訊。RS232的db9接口的連接線包括三種公對母線，公對公，和母對母線。注意，這三種連接線都分別有交叉線和直連線，所以總共有6中連接線。下邊的一個示例為母對母交叉線。圖2是常有兩種連接。
（2）區分電路中母頭和的符號：為插針，母頭為插孔，但有時畫的不夠明確，最好是根 據引腳號的順序進行判斷，大頭那一側5個引腳，若引腳1到5為從左到右的順序則為，反之1到5為從右到左的順序則為母頭。與母頭插在一起時，兩者同號引腳會對插在一起。
（3）標準RS-232串口主要的3個引腳號2，3，5：pin2-RX，pin3-TX，pin5-GND。
（4）連接線連接好兩個設備的串口后應保證兩個串口引腳以匹配方式連接，即發送（pin3）對接收 （pin2），地對地（pin5）。而直連線同引腳號相連，故其兩端必有一個是非標準接口，另一個是標準接口。交叉線內部已做交叉匹配，故其兩端可同為標準接口。
（5）直連線兩端的接頭同號引腳直接相連，用于連接標準接口和非標準接口的兩個設備，交叉線兩端接頭發送與接收交叉相連，用于連接兩個都是標準接口的設備。
（6）設備上的RS-232端口可以是或母頭，電腦端口都是。所以電腦與外設之間連接可以是 交叉線或是直連線。電腦與電腦之間連接則只能是交叉線，外設與外設之間連接則可能是交叉線或直連線。
1.2 測試軟件
常見的測試軟件有很多，可以網上下載串口調試助手、com調試工具等，也可自己編寫簡單的串口通訊代碼。測試用現成的串口調試助手比較方便，多數為綠色軟件無需安裝，體積小使用方便，界面簡單易操作易理解，能滿足大多數規約測試。
2 規約測試
2.1 接口調試
首先，要在電腦上拷貝好串口調試程序，找到串口調試程序的目錄雙擊即可運行。運行前要確定RS-232插頭對應那個com。斷接RS-232頭的2針和3針，并插入電腦的串口。如果不確定對應在com幾上，可查看電腦設備管理器中的串口3等一共有幾個見圖3。
啟動串口調試程序，如果找不到正確的com口，在串口下拉選項中選擇不同的com，直到選到的com能正確打開，見圖4。
其他參數設置見圖5。端口設置完成后在發送區輸入“hello”（不含雙引號，可輸入除漢字以外的文本）單擊“手動發送”，接收區同時顯示“hello”，如果斷開RS-232頭的2，3針，再次單擊“手動發送”測試接收區不會顯示“hello”，說明該com口調試成功，已具備接收和發送數據的功能。
2.2 通訊協議測試
將RS-232接口中的2，3，5針分別與被測試設備RS-232接口的3，2，5針連接，這時就完成了測試系統的連接。
（1）用modbus協議，讀取18b20溫度傳感器模塊數據，18b20定時發送檢測到的溫度數值，串口循環讀取。
（2）連接10KV柱上開關智能保護單元串口，用101規約讀取遙測、遙信數據，讀取數據完全正確。
【關鍵詞】IEC61968CX;WebServices攔截器
1.引言
隨首電力信息化系統的發展，各開發商為不同的業務部門開發了相應的業務信息化系統，由于各開發商所使用的技術不同、開發周期不同，沒有采用統一的技術，從而導致各業務系統相互獨立，業務系統間形成數據的壁壘，數據只能在各業務系統內流轉，從而產生“數據孤島”問題，嚴重阻礙了信息化建設的開展，容易形成重復建設的情況，降低了數據作為“資產”的價值。
“信息孤島”現象不是一個個案，在電力行業乃至信息化行業內普遍存在，為了解決電力行業內的“信息孤島”問題，國際電力標準委員會制定了IEC 61970/IEC 61968系列標準。IEC 61970標準中定義了公共信息模型（Common Information Model，CIM[1]）和組件接口規范（Component Interface Specification，CIS[2]），為各應用系統間的交互提供了語義和語法上的依據。IEC 61970定義的CIS接口采用CORBA（Common Object Request Broker Architecture，CORBA[3]）技術，技術門檻較高，且采用緊耦合的方式，適合以高性能進行大量數據的傳輸，對于一些通知消息類的小數據量傳輸來說，其結構過于龐大，不利于開發商的快速實現，為此IEC 61968標準在IEC 61970 CIM/CIS標準的基礎之上，擴展了配電管理部分的CIM模型，并定義了業務系統信息交換模型（Information Exchange Model，IEM[4]）和另一種松耦合方式的消息傳遞標準，以當前流行的WebServices技術進行實現。
本文對IEC 61968標準定義的WebServices標準接口進行了介紹，同時描述了一個采用Apache CXF[5]實現的IEC 61968標準接口的測試方法，采用JAVA編程語言，以CXF中攔截器的方式實現對WebServices輸入輸出的攔截，并對輸入輸出XML[6]內容進行查看和編輯，可以為不同的要求配置不同的WebServices輸入內容，從而實現IEC 61968標準接口的自動化測試。
2.IEC 61968 WebServices接口
IEC 61968接口可以通過多種技術方式進行實現，如WebServices、JMS等，本文對WebServices實現方式進行了說明。
IEC 61968標準定義了一個通用的接口，并以WSDL[7]的方式對接口進行了規范化定義，其中WebServices服務名稱為：Service，該服務只包含三個方法：
PublishEvent：事件方法，用于事件通知。PublishEvent方法的輸入參數為EventMessage，返回值為ResponseMessage。
Request：請求方法，用于查詢或更新操作。Request方法的輸入參數為RequestMessage，返回值為ResponseMessage。
Response：響應方法，用于對通知消息的確認，或是對數據處理結果的反饋。Response方法的輸入參數為ResponseMessage，返回值為ResponseMessage。
3.IEC 61968消息結構
3.1 消息頭結構
IEC 61968 Header（消息頭）包含了一些消息基本描述與控制信息。請求、響應、事件消息都有消息頭結構。消息頭只有Verb（動詞）和Noun（名詞）兩個必須的字段，其他的字段都是可選的，消息頭包括以下元素：
Verb（動詞）：描述要進行的動作，用來標識要采取的動作類型，如create（創建）、close（關閉）、cancel（取消）;created（已創建）、closed（已關閉）、changed（已更改）。IEC 61968標準規范了一個動詞列表，動詞取值只能從動詞列表中選擇。
Noun（名詞）：用來標識Payload（消息有效內容）的類型，描述消息的主題。
Revision（修訂）：消息修訂版本號。
ReplayDetection（重發檢測）：這是一個復雜元素，包含一個timestamp（時標）和一個nonce（隨機數）用于防止重發攻擊。時標由源系統生成表示消息創建的時間;隨機數是一個序列號或隨機生成的字符串（例如UUID），由源系統生成，并且在一天內不允許重復。
Context（上下文）：表示消息上下文，如PRODUCTION（生產）、TESTING（測試）、STUDY（研究）、TRAINING（培訓）等。
Timestamp（時標）：一個遵循ISO-8601的字符串，表示消息發送的時間。
Source（來源）：消息產生的來源，系統或組織的名稱，如EMS、GIS。
AsyncReplyFlag（異步應答標志）：表示應答消息是否異步發送。
ReplyAddress（應答地址）：異步應答發送消息的目標地址。
AckRequired（確認請求）：表示請求的消息是否需要一個回傳的確認消息。
User（用戶）：一個復雜結構表示用戶以及相關的組織，包含一個UserID（用戶標識）Organization（組織標識）。
MessageID（消息ID）：消息的唯一標識，兩個消息不允許有相同的MessageID。
CorrelationID（關聯ID）：該字段用于將消息連接在一起。該字段可以在請求中提供，因此客戶端可以關聯對應的應答消息。服務器段會將應答消息的CorrelationID設置為源消息的CorrelationID取值。
Comment（注釋）：任何描述性的文字。
Property（性質）：復合類型允許客戶以鍵/值對的方式擴展傳輸的信息，包含一個Name（名稱）和Value（取值）。
other（其他）：其他的客戶擴展，由開發商自行定義擴展。
IEC 61968標準規范了一個動詞列表，Verb（動詞）只能為下表的取值。
表1 IEC 61968推薦動詞表
請求動詞 回復動詞 事件動詞 使用場景
Get Reply 無 查詢
Create Reply Created 事務
Change Reply Changed 事務
Cancel Reply Canceled 事務
Close Reply Closed 事務
Delete Reply Deleted 事務
Execute Reply Executed 事務
Request（請求動詞）的使用方法如下：
Get用于查詢消息名詞中指定類型的對象。
Create用于創建消息名詞中指定類型的對象。
Delete用于刪除對象，為了維持修訂歷史，有時目錄系統并不是真正刪除對象。
Close和Cancel用于與業務處理相關的動作，如關閉一個工作訂單或取消了控制請求。
Change用于更改對象，但需注意，當通過業務規則進行表示時會模棱兩可，尤其是在復雜數據集的情況下（復雜數據集一般具有N：1的關系）。
Execute用于使用操作集進行傳輸的復雜事務，可能包含一個以上的動詞。
每個Request（請求）都使用Reply（回復動詞）進行回復。Event（事件動詞）常常是請求的結果，一個Create可導致一個Created事件的產生。事件中使用的動詞為相應請求動詞的“過去式”。
消息頭的定義如圖1所示：
圖1 消息頭定義
3.2 消息請求結構
IEC 61968Request（消息請求）結構只用于請求消息中，用于存放請求消息的請求參數，請求結構中的元素都不是必須的，在實際應用中可以根據實際情況進行選用。消息請求結構包括的元素描述如下：
StartTime（起始時間）：當一個請求需要起始時間作為過濾條件時使用。
EndTime（結束時間）：當一個請求需要結束時間作為過濾條件時使用。
Option（配置）：名值對方式，在查詢請求時可作為過濾條件，可用于規定超時時間或規范化響應模式等，在具體實現時作為自定義的擴展。
ID（標識）：在查詢請求時，可以作為過濾條件標識一個或多個對象，可以在“close”、“delete”、“cancel”事務中標識特定的對象。每個ID都有一組屬性，“kind”用于說明標識的類型，如名稱、UUID、事務ID或其他類型，UUID默認采用對象的mRID屬性取值;如果取值為名稱，“idType”和“idAuthority”需要提供。
Other：其他的自定義擴展。
消息請求的定義如圖2所示：
圖2 消息請求定義
3.3 消息回復結構
Reply（消息回復）作為對其他消息的響應，包括的元素描述如下：
Result（結果）：消息回復的結果，取值為以下之一：
OK：沒有錯誤，返回所有的結果，“Error”元素不需要。
PARTIAL：部分，返回部分結果，有一個或多個“Error”元素。
FAILED：錯誤，沒有返回結果，有一個或多個“Error”元素。
Error（錯誤）：錯誤描述。
ID（標識）：錯誤對象ID。
Other（其他）：其他的自定義擴展。
OperationId（操作ID）：操作ID，與請求的操作相同，用于描述是對哪個請求的回復。
消息回復的定義如圖3所示：
圖3 消息回復定義
Error元素描述處理的錯誤信息，其元素描述如下：
code（錯誤代碼）：用來描述錯誤的類型。
level（嚴重級別）：分為：INFORM（信息）、WARNING（警告的）、FATAL（嚴重的）、CATASTROPHIC（災難的）。
reason（錯誤原因）：一般為人可讀的錯誤名。
detail（詳細信息）：自由格式描述錯誤具體的信息。
xpath（出錯路徑）：XPath表達式標識具體的出錯的XML元素，
stackTrace（異常堆棧）：軟件產生的異常堆棧。
Location（異常位置）：軟件產生異常的位置。
ID（事務ID）：對應的事務ID。
relationID（關聯ID）：出錯的關聯對象，用于描述兩個對象間的關聯出錯。
opertionId（操作ID）：與請求的操作相同，用于描述是對哪個請求的回復。
3.4 消息有效內容結構
Payload（消息有效內容）可以看作是CIM模型的一個子集，通過定義包含在該消息中的IEC TC57 CIM模型的類和屬性實現。并不是所有的消息都需要有效內容，例如get，close，cancel，reply操作等只需要消息頭，有效內容可以為空。
有些類型的消息必須提供有效內容，如果帶有動詞create或change的請求消息，以及一些響應消息和一些事件消息。
有效內容一般包含遵循一個已定義了XSD[8]的XML文檔。
有些情況也會有例外，例如：一些XML有效內容沒有XML Schemas，如RDF文件或動態查詢結果，還可能是非XML格式，如CSV和PDF。
還有些情況，有效內容很大，必須進行壓縮，否則將浪費大量帶寬。為了適應多種格式選項，有效內容提供了以下的格式（圖4）：
圖4 消息有效內容定義
在消息有效內容中，我們可以通過使用XML的“any”結構，來包含任何類型的XML文件。另外，它也提供了松耦合選項，也能使用由XSD定義的特殊復雜類型。
一些情況下可能需要zip格式、Base64+編碼的字符串，此時可在消息中使用“compressed”標簽。下列情況需要使用壓縮方式：
一個遵循XML Schema的有效內容，超出了預定義的大?。ㄈ纾?MB）。這種情況很常見。
具有非XML格式的有效內容，如PDF，Excel表格，CSV文件，或二進制圖片。
使用XML格式但沒有XML Schema的有效內容，超出了預定義的大小（如，1MB）。如作為一個SQL XML查詢結果生成的動態XML。
當有效內容采用Base64編碼的壓縮方式時，它作為一個string存儲于compressed消息元素內。另外，為了支持二進制格式數據的高效傳輸，數據采用Base64編碼，但不壓縮。如果XML格式不能滿足性能的要求，可以對數據進行分類，通過壓縮方式來實現“高速”傳輸。
Format標簽可以用于標識特定的數據格式，比如XML、RDF、SVG、BINARY、PDF、DOC、CSV等。該標簽是可選字段，它一般只用于當有效內容的存儲使用compressed消息元素時。
4.Apache CXF
Apache CXF是一個開源的WebServices框架，大大簡化了WebServices的創建，并可以在多種傳輸協議上運行。采用CXF構建WebServices服務非常方便，通過CXF的工具將WSDL生成為相應的JAVA編碼后，只需要編寫少量代碼就可以實現WebServices服務的調用和。作為WebServices客戶端，對其他WebServices服務進行調用時，相應的主要代碼如下：首先構建工廠JaxWsProxyFactoryBean對象，設置要調用的服務類型Operations和服務地址，創建相應的客戶端對象client，構建相應的參數，調用相應的服務方法。作為WebServices服務端，對外提供WebServices服務供其他客戶端調用時，相應的主要代碼如下：首先要實現對應的WebServices接口方法，通過Endpoint.publish，設置的地址和實現的對象即可。
5.CXF攔截器
通過Apache CXF實現WebServices的服務調用和服務非常簡單，這些作用客戶端應用進行服務調用和實現WebServices服務器很有用，但作為測試來講，只能看到高層的JAVA對象是不夠的，必須能夠查看底層的消息并可以對消息進行隨意的編輯才能實現測試的目的，這可以通過CXF的攔截器來實現。
CXF的攔截器是CXF功能最主要的擴展點。通過自定義的攔截器，可以改變請求和響應的一些消息處理，其中最基本的原理還是一個動態。當服務被調用時，一個攔截器鏈表被創建并調用。每一個攔截器都有機會做他們想要處理的消息，包括：讀取，轉化，處理頭部，驗證消息，等。攔截器可以用于CXF的客戶端和服務端。當一個CXF客戶端調用一個CXF服務端的時候，客戶端有一個傳出（Out）的攔截器鏈，服務端有一個傳入（In）的攔截器鏈。當服務端發送響應給客戶端時，服務端有一個傳出（Out）的攔截器鏈，客戶端有一個傳入（In）的攔截器鏈。此外，在調用出錯的情況下，一個CXF服務將創建單獨的對外輸出錯誤處理鏈，客戶端將創建一個傳入（In）的錯誤處理鏈。
創建工廠后分別向攔截器鏈表中添加相應的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對應客戶端的傳入攔截器和傳出攔截器。服務器后分別向攔截器鏈表中添加相應的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對應服務端的傳入攔截器和傳出攔截器。代碼的主要思想是將原始的消息內容XML展示出來，對其進行修改后，將修改后的內容放到消息流中，替換原來的消息內容，在發送消息時發送的就是修改后的消息內容。測試軟件的界面如圖5所示：
圖5 測試軟件界面
6.結束語
測試工具的開發平臺是Eclipse 3.6.2，采用Eclipse RCP技術開發圖形化界面，使用JAVA開發語言。這種針對IEC 61968WebServices標準接口測試方法，可針對不同的應用場景修改相應的測試消息內容，具有很好的通用性，測試效率高。此種測試方法沒有考慮IEC 61868 對Payload定義XSD限制的情況，未對Payload的內容進一步的處理，可在此基礎上對其進行改進以適應更廣泛的測試要求。
參考文獻
[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.
