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