时间：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机内部结构图很好地从一个侧面反映了高速串行接口的普及程度。可以说，高速串行接口已经完全融入到了人们的日常生活中。
2 高速串行接口的测试需求
在高速串行接口的测试中存在着一系列的挑战：
1)产生和比较高速数字信号
高速串行接口的传输速率通常在Gbps级别。例如HDMI每通道的传输速率为3.4Gbps；USB 3.0的传输速率为5.0Gbps；SATA 3.0的传输速率为6Gbps。要测定此类高速串行接口，测试设备就必须能够产生和采集相应速率的数字输入信号。
此外，由于传输通路中的空间电容、电感的影响，高速数字信号在传输过程中无可避免地会发生畸变(主要表现在0／1之间的跳变趋于平缓)。此时就需要信号发生端具备Pre-Emphasis功能，通过在发生信号时强化跳变沿来抵消空间电容、电感对传输信号施加的影响。
2)支持各种时钟类型
高速串行接口的时钟通常可以分为三类：时钟频率与数据速率保持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的有效内容，超出了预定义的大小（如，1MB）。这种情况很常见。
具有非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.
