接口测试范文
时间：2023-03-07 20:58:51
接口测试范文第1篇
关键词：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.
作者简介：
接口测试范文第2篇
关键字：高速串行接口测试，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》――www.省略
[3]《T2000 6Gbps Serial Port Module ProductDescription》――ADVANTEST
[4]www.省略
作者简介
接口测试范文第3篇
关键词：计算机软件；网络管理；接口一致性测试；事务模型；测试流；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.
[5] 陈颖慧,邱雪松,刘益畅,等.基于模型的Web Service 性能测试方法[J].北京邮电大学学报,2009,32(增刊):44-48.
接口测试范文第4篇
【关键词】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.
[7]W3C.Web Services Description Language（WSDL）1.1.2001.
接口测试范文第5篇
关键词：通信系统 接口管理 外部接口 内部接口
中图分类号：TN914 文献标识码：A 文章编号：1007-9416（2013）05-0116-02
1 前言
麦加轻轨通信系统范围包括传输系统（MSN）、综合监控系统（SCADA）、无线通信（TETRA）系统、广播系统（PAS）、电视监视系统（CCTV）、时钟系统（TDS）、乘客信息系（PIDS）、门禁系统（ACS）、宽带无线接入系统（BBRS）、电话系统（Telephone）、综合维修系统（MMS）。而在项目实施过程中，需要与通信相配合的其他专业还涉及各站的土建、房建、装修、轨道、动力照明、信号、接触网、垂直电梯、防灾报警系统（FAS）、车辆、变电、风、火、水、电等。故对于通信专业来说，接口的管理和协调是通信专业项目管理中一个至关重要的问题。如此多的接口，同时也带来了相当多的协调工作量。但如果该项工作安排不好，轻则延误工期，重则项目无法进行，甚至出现影响开通运营。对于麦加轻轨通信专业接口有效控制，需先了解接口类型。根据本项目的特点，通信专业接口类型及控制方法归纳分别如下：
接口原则及类型分类如下：（1）与土建专业的接口；（2）与房建专业接口；（3）与消防专业接口；（4）与MEP（风、火、水、电）专业接口；（5）与信号专业接口；（6）与变电专业接口；（7）与电梯专业接口；（8）与屏蔽门专业接口；（9）接口有效控制方法分类如下：
接口有效控制工作一般可以分为三个阶段：1）了解掌握接口；2）建立和完善接口文档；3）管理手段的有效运用。
2 了解接口
先从合同出发进行分析，明确项目中含哪些接口，涉及的供应商或外部承包商，以及这些接口的类 型，所处的位置，具体接口数量，何时使用该接口等 信息；并通过系统学习，掌握各接口的技术特性。从接口在项目中所处的位置，可以分为内、外部 两大类。以下是一般轨道交通通信系统可能涉及到的接口。
2.1 外部接口
2.1.1 与土建专业接口
线路部分接口：土建单位在路基段为通信专业在轨道两侧预留电缆通道，即铺设水泥电缆槽；在高架车站两端预留缆线引下孔洞；在高架桥两侧安装支架，并支架上安装遮阳罩；在道岔区制作水泥基础并安装摄像机立柱，并且须安装地线；每隔400米安装1处BBRS钢柱，可利用接触网基础进行安装，若在岔区需重新制做基础并安装立柱，若在路基段须安装在线路上行线外侧（距轨道中心线4.7米），所有钢柱须安装防雷地线；所有在岔区安装钢柱，须计算安装位置是否侵限。
车辆段部分接口：在车辆段内为通信专业预埋管道，并设置一定数量的人井，并保证管孔畅通，无阻塞，人井内安装支架，并设置爬梯，供维修使用；车辆段内摄像机基础预制，并安装钢柱，在预制基础时需根据图纸要求预埋钢管，供穿缆线之用。
2.1.2 与房建专业接口
各车站建筑物内需根据设计图纸要求，预留电缆引入井，并且引入井需有维修平台，引入井需安装有检修门；通信设备室门高度须保证在2.4米以上，并且门须为双向对开门（外开），宽度保证在1.5米以上，方便通信设备运输；设备室需预留电缆桥架通道等；设备室内地面应抄平，保证地面水平，不起沙；室内需安装抬升地板，并且抬升地板底座须与地面固定，并且抬升地板须接地；室内墙壁需刷白，不掉灰；屋顶若做渗水试验时须提前告知通信专业，并且保护好设备；并加装门锁，若无正是门需安装临时门并加锁；室内净空需满足2.5米以上。
及时跟进建筑专业施工进度，建筑专业在砌墙时，有通信管线预埋的，MEP专业应及时跟进预埋管线，避免二次开凿墙壁，并且在管内预留拉丝；室内需有临时照明、空调，保证通信设备安装、调试正常进行。在OCC、阿拉法特1、米娜1、加马拉建筑物屋顶须预留无线钢珠基础，并根据图纸要求预埋螺栓。
2.1.3 与MEP（风火水电）专业接口
（1）与风管专业接口：通信设备室内应保持良好通风条件，以便设备产生的热量及时排放，空调通风专业的排风口必须避开设备正上方，避免冷凝水滴落至设备，引起设备故障；同时影响通信设备散热。
（2）与消防专业接口：激活防火警报时，FACP（防火警报控制板）将向PAS（扩音系统）提供‘防火警报指示’信号，该信号将会激活预录的DVA（数字硬盘录像机）通告。可以在每个车站的PA（扩音） DSP（数字信号处理器）路由器内对该通告和相关的防火警报指示信号进行配置。OCC、各车站为防灾消防报警提供接口。
（3）与电缆桥架接口：应根据通信专业所提需求，完成站台房主干桥架（2层600mm宽）、站台房内电缆桥架（3层400mm宽），并保证桥架连通。此两种类型电缆桥架进入室内30cm，剩余部分有通信承包商完成。站台房之地面房电缆桥架采用廊桥形式连同，但必须完成廊桥上通信用电缆槽（2层200mm宽）。电缆桥架保证电气连通，因此须完成电缆槽与电缆槽之间有接地线连通，电缆槽的接缝处需打磨，不得有毛刺或凸起部分。
（4）与动力照明专业接口：动力照明专业为通信设备室提供地线，在通信设备加电调试之前提交合格的测试数据；在通信设备室为通信专业提供正式照明，并且照明等不允许安装在设备正上方，避免碎片掉入设备内，避免引起设备温度过高而发生故障。为通信专业提供两路UPS电源，从UPS室至通信设备室UPS电源箱缆线为动照专业负责，并且UPS电源箱为动照专业负责，从UPS电源箱至通信电源分配箱缆线为通信专业负责。
2.1.4 与变电专业接口
物理界面：SCADA/PSS之间的界面应通过100Mbps 以太网来连接。对于各PSS界面控制面板，PSS应使一根网络电缆（UTP或光纤，待定）的终端设在与界面连接的网络控制面板/开关中。
协议性质：SCADA和PSS之间的界面协议应以IEC60870-5-104 TCP/IP为依据。SCADA应作为控制站（主站），而PSS应作为受控站（从站）。
通信专业为PSS房间提供电话，供通信联络使用；提供广播、摄像机等。
2.1.5 与电梯专业接口
SCADA与沿线分配的电梯和自动扶梯形成界面连接。SCADA负责监视与控制所有电梯和自动扶梯设备。通信专业CCTV系统为垂直电梯敷设多模光纤至垂直电梯机房，供电梯轿厢摄像头提供通道；电话系统为其提供电话线至电梯机房，为电梯轿厢电话提供通道。
2.1.6 与屏蔽门专业接口
SCADA与站台屏蔽门之间形成界面连接。SCADA负责监视PSD的状态。
2.1.7 与车辆专业接口
列车广播系统用于在发生事故的情况下，控制中心列车调度员和环控（防灾） 调度员利用专用无线通信子系统，通过驾驶室的无线广播接口对车厢内乘客广播。
2.2 内部接口
传输系统是整个通讯系统的神经系统。作为通信系统的核心，系统内部的接口主要集中在传输设备上。通信专业系统内部接口：传输系统为所有通信子系统提供通道。
3 接口控制
3.1 建立和完善接口文档
在了解接口的类型和用途后，需要建立一套完善的接口文档作为指导工作的书面依据。首先，根据了解到的接口技术信息编写一个接口管理表格，并由设计、监理、业主、相关承包商或分包商签字确认。在表格中需要包括如下内容：接口名称，类型，所属系统或子系统、主导专业、功能描述、位置、分界面等。有了这个接口表格后，各方就可以按此执行，如有异议也可以根据此表格解决。其次，为保证接口在项目实施过程中推进顺利，避免因接口故障引起的诸多矛盾，还需要制定一个详细的接口测试计划。这个接口测试计划包括厂验测试计划、模拟测试计划、到货测试计划、现场接口测试验收计划等。厂验测试的主要目的是确定各子系统自身接口性能指标是否符合要求。由于该测试是在供应商生产地进行，相应的测试仪表和手段比较齐全，可以对技术指标尽量全面的测试 ，排除本系统设备自身可能存在的问题，为以后的测试作铺垫。而模拟测试计划主要针对各有条件的系统在同一场地进行互联互通测试，这样就可以在现场安装之前对问题进行定位，提前解决接口上可能出现的问题。对于只能在现场 进行测试的内容就安排在现场测试验收中完成。到货测试的主要工作是对各种缆线进行开盘测试，并对主设备外观检验并请各方签认，以便分清施工方 和设备供应商之间的责任划分。现场接口测试验收主要包括两大部分：一是非机电接口测试验收，主要针对土建、轨道、楼宇、装修等。这些接口一般可以 按站点归类，每完成一个车站，就组织设计、监理、业 主、承包商和相关供应商，携带接口验收测试表格前往现场，对各项逐一验收确认。二是机电接口的现场测试，一般各方应在通信系统设备大部分上电后，对系统之间的接口进行互联互通测试的内容 和方法及所用的仪表应都包含在现场接口测试计划中。由于涉及到项 目进度，现场接口测试验收可以 多系统同时进行，测试以最终用户所需业务为主要测试内容。
3.2 管理手段
有了以上这些接口技术资料和接口控制文档后，如何运用这些工具进行有效管理成为接口工作的关键。分别有以下6点：
（1）专人负责：对于象通信总承包这样的复杂项目，接口管理必须专人负责。接口负责人要对整个系统比较了解，从项目的启动阶段就参与工作，对各系统接口的演变非常清楚；对于单个子系统不需要非常精通，但对于系统之间的连接、接口数量、互连互通方案等，要掌握全面，尤其是子系统的分工界面。
（2）定期会议：高效的定期例会是必不可少的包括接口工作推进会，定期对接口工作进行回顾，明确本阶段的接口工作和下阶段的接口工作计划。制定一个会议模版，使每次议程简明清晰。如果接口工作存在问题，就必须召开接口协调会。会上相关子系统或外部系统承包商描述接口存在的问题，并提出各自的解决办法。总包、业主、监理、设计各方讨论决定采取哪种方案来解决出现的问题。所有会议相关的结论必须体现在会议纪要中。会后各方会签。以后该会议纪要就可作为推进工作的依据。
（3）严格的接口确认制度：由于接口牵涉两方或几方的相关进度和利益，故每个接口相关的正式文件要求各有关方签字确认。比如现场测试验收表格，就必须由接口已完成一方填写，并请接口的另一方确认；监理、总包和业主对此进行见证，并在验收表格上签字。通过这一过程后，该接口的后续工作都由接口的另一方负责，使责任明确，分工清晰。
（4）业主的重要作用：在接口协调方面，业主的作用非常重要。尤其是对于外部系统的接口，如果通信总包单位出面协调往往达不到理想的效果，而有业主出面协调往往能事半功倍。所以对于外部系统接口的协调会议，最好由承包商提交方案，然后协调业主来发起或组织协调会议，最终由业主拍板决定采用何种方案。
（5）以解决问题为出发点：在接口上出现故障或争议时，必须本着解决问题的态度来协调，接口问题才能得到圆满解决。否则接口问题将会演变为责任推托、进度拖延的借口，对整个项目的实施非常不利，也破坏承包商的形象。
（6）时间进度控制：接口往往是轨道交通通信总包项目实施中最难控制的地方，明确严格的进度管理计划将帮助推进该项工作。故在拿到合同后的初期设计阶段就应着手编写进度管理计划。这个计划中需要包含进度事件，该事件关联供应商或承包商、关键里程碑、所需时间段及相应的人工。另需要注意的是通信总承包的进度计划必须和有相关接口的供应商或外部承包商做到同步和统一。通过以上这些方法，一个繁琐的通信系统接口管理工作将变得很有条理且容易控制。
参考文献
[1]魏晓东.城市轨道交通自动化系统与技术[M].北京：电子工业出版社，2004.
[2]成虎.工程项目管理[M].北京：中国建筑工业出版社，1997.
接口测试范文第6篇
关键词：CBI联锁，OCS950系统，一致性测试
中图分类号：U231+.3 文献标识码：A
天津地铁2、3号线信号系统由通号集团总包，庞巴迪作为主要技术分包商，实现了一套完整的CITYFLO650基于无线通信技术的移动闭塞系统。其中，联锁系统作为最核心最基础的系统，使用庞巴迪EBILock 950 CBI联锁与OCS950目标控制器系统[1]。由于地铁2、3号线工期紧凑，给予信号系统安装调试期短，联锁调试显得尤为紧凑和重要。
1 联锁调试前的准备工作
（1）线缆绝缘测试
线缆绝缘测试主要包括：电源屏所有输出供电配线、组合柜到分线柜配线、分线柜至各控制单元配线、以及目标控制器（OBC机柜）到组合柜的配线等。测试要求依次完成各单元每一根线缆的线缆电阻、线间绝缘及线缆对地绝缘的测试。
（2）上电测试
天津地铁2、3号线采用综合UPS供电技术。对于OCS950系统OBC机柜，各模块供电后需要用安装有WinOC test 软件（庞巴迪系统专用）的测试笔记本（设置IP地址为 172.21.0.3）通过网线连接至OBC机柜CCME通信板，以观察各OC板的工作状态是否正常，确认所有供电单元上电正常[2]。
2 联锁测试流程及方法
联锁系统测试包括点对点的测试、轨旁信号设备单体调试、联锁室内外一致性测试三大部分。
2.1 点对点测试
点对点测试是为了确定目标控制器与组合继电器的一一对应关系是否正确，验证目标控制器驱动与采集是否正确。
点对点测试时连接测试笔记本（安装有WinOC test 软件）到目标控制柜，通过软件下发驱动信号，同时确认能够通过软件观察到采集状态的变化。使用DC24V电源端子线，根据各个组合采集电路图及配线图依次将需要测试的继电器驱起和驱落，观察测试笔记本软件内采集状态的变化是否正常。
2.2 轨旁单体测试
（1）信号机测试
信号机单体调试是使用点对点测试软件完成目标控制器对信号机单体设备点对点控制的调试，其中包括信号显示控制调试；信号机单体输入输出电压、电流测试；
① 连接测试笔记本到目标控制柜，通过点对点测试软件完成对信号机红（R）、绿（G）、黄（Y）、红黄（RY）、M红（MR）显示的驱动，并测量其对应信号显示的一次侧电压电流、二次侧电压、及二次侧设定电压值，保证其测量值在系统设计确定的范围内并尽可能趋于范围的中间值。
② 各信号显示电流测量范围如下(参考庞巴迪系统)：
当红黄同时点亮时,红灯和黄灯显示信号电流也要保持在上述范围内。
③ 2、3号线信号机的灯丝报警采用两级报警机制。灯丝报警仪检测作为一级报警，OCS内部板卡检测作为二级报警（降级报警）。对信号机进行降级测试，确定绿灯显示能降级为红灯，黄灯显示能降级为红灯，红黄显示能降级为红灯，M红灯降级为红灯，红灯降级后为灭灯状态。其一级报警设置原则为：M红灯LED灯短2束报警，其他颜色灯位LED灯断4束报警；二级报警设置原则为：黄灯降级报警电流下限为98mA，红灯降级报警电流下限为98mA，绿灯降级报警电流下限为100mA，M红灯降级报警电流下限为110 mA。
（2）转辙机测试
转辙机测试的目的是通过点对点测试软件完成目标控制器对转辙机单体设备点对点控制的测试，其中包括转辙机的定操、反操、定表、反表、失表示、转辙机动作电流、动作电压、动作时间、摩擦电流、摩擦电压及四开状态下的动作时间、4mm转辙机不锁闭失表示、2mm转辙机锁闭有表示等参数。
① 连接测试笔记本到目标控制柜，给转辙机设备上电，通过点对点测试软件对转辙机执行定操和反操命令确定转辙机动作方向是否正确，动作到位后定位和反位表示是否正确。
② 测量转辙机所有需要测量的参数如下：
道岔正常动作时：
动作电压380V±10%；
动作电流
道岔处于四开状态时：
动作电压380V±10%；
动作电流
动作时间
转辙机断表示测试；转辙机断遮断器测试；
道岔岔尖2mm锁闭、4mm不锁闭测试。
（3）PSD（屏蔽门）接口测试
PSD接口测试的目的是为了完成信号系统与屏蔽门系统的硬件接口的测试（如果测试过程中PSD不具备联机条件，本测试可使用封线假条件），为联调联试做准备[3]。
①将屏蔽门全部关闭，确认门控柜门关继电器吸起。在屏蔽门PSL盒激活互锁解除，确认门控柜门旁路继电器吸起，互锁解除恢复时确认门旁路继电器落下。在屏蔽门PSL盒激活本地控制，确认PLC采集到本地控制信号，本地控制恢复时确认PLC采集到的信号消失。
② 在门控柜激活开门信号和关门信号，确认屏蔽门相应的开起和关闭。
③ PSD测试中如果测试的是非集中站，同时需要集中站测试人员确认所测试的非集中站在集中站对应的复视继电器状态与非集中站是否一致。
（4）PEP（紧急停车按钮）接口测试
PEP接口测试是为了完成信号系统紧急停车控制功能的测试。测试中将站台和车控室所有紧急停车按钮恢复，由集中站测试人员确认对应的紧急停车继电器吸起，当按钮被按下时继电器落下，依次激活和恢复每一个紧急停车按钮，确认集中站继电器状态正确。
2.3 联锁室内外一致性测试
联锁室内外一致性测试是通过ATS软件完成ATS工作站站场表示及操作与室外轨旁设备的一致性测试[4]。
① 通过ATS工作站排列进路，开放每一架信号机的每个灯位显示，室内外人员一起校验实际与显示一致性，并通过联锁维护终端查看对应的参数是否正确。由室外人员设置信号机断束报警和断丝报警，然后通过灯丝报警仪设置各个信号机报警电流的上门限值和下门限值，同时确定ATS会有对应的报警显示。
② 通过ATS软件对转辙机进行定操和反操操作，室内外人员一起校验实际与显示一致性，并通过联锁维护终端查看对应的参数是否正确。然后由室外人员对转辙机断表示、断遮断器，确定ATS和联锁维护终端会有相应的报警显示，并且断遮断器时转辙机不能动作成功。
③ 轨旁人员对PSD进行开关门、互锁解除操作，确定屏蔽门状态和ATS、维护终端显示一致。
④ 轨旁人员对站台所有PEP按钮及车控制PEP按钮进行激活，取消激活操作，确定PEP激活状态和ATS、维护终端显示一致。
3 结束语
联锁系统调试是地铁信号系统建设开通的重要环节，联锁控制是关乎地铁安全运营的核心重点。本文介绍了整个联锁系统硬件控制部分的调试流程及方法，笔者根据实际经验概述了天津地铁2、3号线联锁系统调试的实现过程。
参考文献
[1] 天津地铁2号线 工程信号系统详细设计文件.第二册2010.10.
[2] 天津地铁 2&3 号线EBI Lock 950 系统接口.2012.2.
[3] 天津地铁 2&3 号线轨旁ATC系统．2012.1.
[4] 天津地铁 2&3 号线 EBI Screen 操作手册．2012.1.
接口测试范文第7篇
YDF/1156-2001《路由器测试规范一高端路由器》；YD／T1098-2001《路由器测试规范一低端路由器》。以上标准分别参照下面标准制定：YD／T1098-2001《路由器设备技术规范一高端路由器》；YD／T1098-2001《路由器设备技术规范一低端路由器》。
本文的测试介绍主要依据上述路由器测试规范。但是由于以上测试规范只作为设备入网测试标准，是一种入门测试，所以我们重点介绍在上述规范基础上补充的一些其他测试内容。
一、测试的目的和内容
路由器是通过转发数据包来实现网络互连的设备，可以支持多种协议(例如TCP／IP，SPX/IPX，AppleTalk)，可以在多个层次上转发数据包(例如数据链路层、网络层、应用层)。
路由器需要连接两个或多个逻辑端口，至少拥有一个物理端口。路由器根据收到的数据包中网络层地址以及路由器内部维护的路由表，决定输出端口以及下一条路由器地址或主机地址，并且重写链路层数据包头。路由表必须动态维护来反映当前的网络拓扑。路由器通常通过与其他路由器交换路由信息来完成动态维护路由表。
(一)路由器分类
当前路由器分类方法各异。各种分类方法有一定的关联，但是并不完全一致。通常可以按照路由器能力分类、结构分类、网络中位置分类、功能分类和性能分类等方法。在路由器标准制定中主要按照能力分类，按能力分为高端路由器和低端路由器。背板交换能力大干20Gbit／s，吞吐量大干20Mbit／s的路由器称为高端路由器。交换能力在上述数据以下的路由器称为低端路由器。与此对应，路由器测试规范分为高端路由器测试规范和低端踏由器测试规范。
(二)测试目的及内容
通过测试路由器，可以了解到哪些路由器能提供最好的性能、路由器在不同负载下的行为、模型化网络使用路由器的设计参数、路由器能否处理突发流量、路由器的性能限制、路由器能否提供不同服务质量、路由器不同体系结构对功能和性能的影响、路由器的功能特性和性能指标、路由器的使用是否影响网络安全、路由器协议实现的一致性以及路由器可靠性和路由器产品的优势和劣势等内容。
低端路由器设备测试主要包括：常规测试，即电气安全性测试：环境测试，包括高低温、湿度测试和高低温存储测试：物理接口测试。测试低端路由器可能拥有接口的电气和物理测性：协议一致性测试，测试协议实现的一致性：性能测试，测试路由器的主要性能：管理测试，主要测试路由器对网管功能的支持。
高端路由器测试主要包括：接口测试，高端路由器可能拥有的接口测试；ATM协议测试，测试ATM协议要求；PPP协议测试，测试PPP协议的一致性：IP协议测试，测试lP协议一致性：路由协议测试，测试路由协议一致性：网管功能测试，验证测试网关功能：性能和QoS测试，测试路由器性能和QoS能力验证：网络同步测试，测试设备同步定时能力：可靠性测试，验证设备可靠性：供电测试，测试整机功耗等内容：环境测试，包括高低温、湿度测试和高低温存储测试。
上述两个测试规范由于起草单位以及起草时间不同，组织安排有所不同。除上述测试外，建议在测试中考虑下面所列测试项目。(1)功能测试：主要来验证产品是否具备了设计的每一项功能。(2)稳定性和可靠性测试：一般采取加重负载的办法来评估和分析设备在长时间、高负载的情况下的运行能力。(3)互操作性测试：不同的网络产品之间必须能够互操作。互操作性测试考察一个网络产品是否能在一个由不同厂家的、多种网络产品互连的网络环境中很好地工作，如验证路由器与Cisco产品的互操作，交换机与Cisco、3Com、Lucent、Intel等的互操作等。
二、测试方法
路由器测试方法通常分为本地测试法、分布测试法、远端测试法和协同测试法。由于篇幅限制，本文不介绍其他测试法的特点以及适用范围，只列出路由器测试中最常用到的远端测试法。
其中，控制观察点(PCO)：通常由两个先入先出(FlFO)队列组成，其功能类似于一对输入输出端口，向队列一端发送命令，从同一队列的另一端接收应答信号：被测实体(IUT)：Itern Under Test；下测试器(LT)：通过位于被测试实体下层的PCO与被测试层交互的测试系统称为下层测试系统。
三、测试分类
综合上文中的测试内容，路由器测试一般可以分成以下几类：功能测试、性能测试、稳定性可靠性测试、一致性测试、互操作性测试以及网管测试。
(一)功能测试
路由器功能通常可以划分为如下几个方面：
(1)接口功能：该功能用作将路由器连接到网络。可以分为局域网接口及广域网接口两种。局域网接口主要包括以太网、令牌环、令牌总线、FDDl等网络接口。广域网接口主要包括E1r1、E3／I-3、DS3、通用串行口(可转换成x 21 DTE／DCE、V，35DTE／DCE、RS232DTE／DCE、RS449DTE／DCE、EIA530DTE)等网络接口。(2)通信协议功能：该功能负责处理通信协议，可以包括TCP／IP、PPP、x 25、帧中继等协议。(3)数据包转发功能：该功能主要负责按照路由表内容在各端口(包括逻辑端口)间转发数据包并且改写链路层数据包头信息。(4)路由信息维护功能：该功能负责运行路由协议，维护路由表。路由协议可包括RIP、OSPF、BGP等协议。(5)管理控制功能：路由器管理控制功能包括五个功能，SNMP功能，Telnet服务器功能，本地管理、远端监控和RMON功能。通过多种不同的途径对路由器进行控制管理，并且允许记录日志。(6)安全功能：用于完成数据包过滤，地址转换，访问控制，数据加密，防火墙，地址分配等功能。
路由器对上述功能并非必须完全实现。但是由于路由器作为网络设备，存在最小功能集，对最小功能集所规定的功能，路由器必须支持。因为绝大多数功能测试可以由接口测试、性能测试、协议一致性测试和网管测试所涵盖，所以路由器功能测试一般可以只对其他测试无法涵盖的功能做验证性测试。路由器功能测试一般采用远端测试法。
(二)性能测试
路由器是JP网络的核心设备，其性能 的好坏直接影响lP网网络规模、网络稳定性以及网络可扩展性。由于IETF没有对路由器性能测试做出专门规定，一般来说只能按照RFC2544f Benchmarking Methodology forNetwork Interconnect Devices做测试。但路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。例如路由表容量、路由协议收敛时间等指标。
路由器性能测试应当包括下列指标：
(1)吞吐量：测试路由器包转发的能力。通常指路由器在不丢包条件下每秒转发包的极限，一般可以采用二分法查找该极限点。(2)时延：测试路由器在吞吐量范围内从收到包到转发出该包的时间间隔。时延测试应当重复20次然后取其平均值。(3)丢包率：测试路由器在不同负荷下丢弃包占收到包的比例。不同负荷通常指从吞吐量测试到线速(线路上传输包的最高速率)，步长一般使用线速的10％。(4)背靠背帧数：测试路由器在接收到以最小包间隔传输时不丢包条件下所能处理的最大包数。该测试实际考验路由器缓存能力，如果路由器具备线速能力(吞吐量=接口媒体线速)，则该测试没有意义。(5)系统恢复时间：测试路由器在过载后恢复正常工作的时间。测试方法可以采用向路由器端口发送吞吐量110％和线速间的较小值，持续60秒后将速率下降到50％的时刻到最后一个丢包的时间间隔。如果路由器具备线速能力，则该测试没有意义。(6)系统复位：测试路由器从软件复位或关电重启到正常工作的时间间隔。正常工作指能以吞吐量转发数据。
在测试上述RFC2544中规定的指标时应当考虑下列因素：
接口测试范文第8篇
【关键词】TD-SCDMA 终端 机卡接口 USIM 一致性测试
1 引言
所谓一致性测试,即依据某一系列行业标准为不同厂商设备提供更高的互通性而做的测试,使其与某些通信标准协议要求相一致。下文依次介绍TD-SCDMA终端机卡接口(即Cu接口、USIM-ME接口)一致性测试系统的参考标准、测试内容和技术原理、系统结构等。
2 参照标准、测试内容及系统结构
2.1 参照标准
TD-SCDMA终端USIM/ME接口一致性测试系统所依据的标准主要如下:
YD/T 1762.1-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口技术要求第1部分:物理电气逻辑特性;
对应的国际标准:ETSI TS 102 221 V4.13.0。
YD/T 1762.2-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口技术要求第2部分:USIM应用特性;
对应的国际标准:3GPP TS 31.102和3GPP TS 31.111及ISO/IEC 7816系列标准。
YD/T 1762.3-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口技术要求第3部分:USAT特性;
对应的国际标准:3GPP TS 31.111及ISO/IEC 7816系列标准。
YD/T 1763.1-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口测试方法第1部分:物理电气逻辑特性;
对应的国际标准:ETSI TS 102 230 V4.5.0。
YD/T 1763.2-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口测试方法第2部分:USIM应用特性;
对应的国际标准:3GPP TS 31.121和3GPP TS 31.102及ISO/IEC 7816系列标准。
YD/T 1763.3-2008:TD-SCDMA/WCDMA数字蜂窝移动通信网通用用户识别模块(USIM)与终端(ME)间Cu接口测试方法第3部分:USAT特性;
对应的国际标准:3GPP TS 31.124和3GPP TS 31.111及ISO/IEC 7816系列标准。
以上六个标准共分为两类:技术要求(YD/T 1762系列)和测试方法(YD/T 1763系列)。技术要求以说明各种相关过程的原理为主,测试方法以说明具体测试例的操作步骤和测试目的、判定要求等为主,相同技术方面的技术要求和测试方法应配套参照。
TD-SCDMA终端机卡接口的传输协议依据OSI参考模型的分层原则,分为五层,具体如图1所示:
物理层:主要有字符帧的结构和定时要求、正向反向约定等,字符帧所包含的定义对T=0和T=1都通用。
数据链路层:包含字符构成、块的构成、块的标识、发送块、检测传输和序列错误、错误处理、协议同步。
传输层:分别介绍T=0和T=1传输模式,定义了对于每个协议特有的源于应用的消息传输。并介绍C-TPDU和R-TPDU的四种情况(case1―case4)和信令要求。
USAT层:用于承载主动式USAT命令,后文相关部分有详细叙述。
应用层:定义了依照应用协议进行的消息交互,对于T=0和T=1传输模式通用。
2.2 测试内容
从以上对应标准及分层结构图可知,测试内容一共分为三部分:物理电气逻辑特性、USIM应用特性,USAT特性。以下分别进行详细介绍。
(1)物理电气逻辑特性
这部分主要是对USIM/ME接口各触点的物理电气特性和初始通信建立阶段、传输协议等进行测试。
首先USIM卡分为两种:“ID-1 USIM”和“Plug-in USIM”。符合一致性要求的终端必须至少支持其中一种物理类型的USIM卡。对于终端而言,“Plug-in USIM”类型的USIM卡占有绝对市场份额,本文主要关注Plug-in USIM卡,其物理特性应符合通用智能卡要求,在ISO/IEC 7816-1和ISO/IEC 7816-2的相应规定(行标的要求也基于此)。其外型要求,长宽的尺寸,8个触点的相对位置如图2所示,现简要介绍如下:
C1为电源,C2是复位,C3是时钟,C4和C8为保留触点(RFU),C5接地,C6是VPP编程电压触点(是厂家生产卡时编程所用,终端可以不提供触点C6,如存在应对USIM呈高阻状态),C7用于I/O数据传输。另外,每个触点区域内接触单元的曲率半径应≥0.8mm,在任何情况下每个触点的压力都应≤0.5N。
对于电气逻辑特性的测试包括ATR识别、电压类别的识别、终端对卡的激活和去激活过程,包括各触点上电下电顺序、电压要求和T=0/T=1传输协议、传输定时要求等。
(2)USIM应用特性
USIM应用特性测试内容的实现是本测试系统的重点、难点所在。这部分测试例主要是对终端与网络模拟器注册过程中或交互后对USIM中相应文件的识别与读写。以下针对测试内容分大类举例详述:
寻呼处理(IMSI和TMSI处理)
在TD-SCDMA网内,IMSI、TMSI作为识别UE唯一的标识,都存储在USIM中,在UICC-终端初始化过程中被读取。此部分内容目的是验证UE能够正确执行“READ EFIMSI”读取卡中文件命令,并检验UE能否使用USIM中的IMSI、TMSI值正常识别、响应网络侧的寻呼,正确识别长短IMSI和TMSI,且能完成TMSI更新和重分配请求等。
接入控制测试
通过接入控制可以对呼叫进行限制。每个UE都会被随机分配一个普通接入级别(0~9),可选(优先使用)一个或多个特殊接入级别(11~15)。特殊类别仅仅在HPLMN或HPLMN国家内有效,否则将使用随机分配的普通级别(0~9)。
接入级别存储在USIM卡上。在某一个时段,由网络控制哪个接入级别被允许呼叫,哪个接入级别被禁止。另外对于紧急呼叫的接入,网络有一个专门的机制控制,即由接入级别10和其对应接入级别共同遵循如下机制:如果接入级别10被禁止,那么接入级别0~9的UE和没有UICC卡的终端将不能发起紧急呼叫;如果接入级别10和相关的特殊接入级别(11~15)同时被禁止,拥有特殊接入级别(11~15)的UE不允许发起紧急呼叫。除此以外,紧急呼叫可以发起,即使接入级别10被禁止。
针对此部分测试例,分为f、g、h三类情况,具体细节不再赘述。
PIN、PIN2码管理和修改
PIN码是用于安全目的对访问UICC卡的用户进行鉴权的号码。输入正确的PIN码允许用户通过UICC-终端接口访问受PIN码保护的数据。此处测试例即对PIN和PIN2码的输入、修改、锁定等功能依次测试。
FDN功能
固定拨叫号码(FDN)是为USIM定义的服务。激活的FDN服务可以限制终端的呼叫。呼叫限制服务由终端控制。为了确定USIM类别以及FDN状态,终端会在初始化过程中执行FDN能力请求过程,从USIM的EFECC中读取紧急呼叫号码。终端在使用这些紧急呼叫号码建立紧急呼叫时,将使用紧急呼叫业务类型,不受FDN规则限制。
AOC计费处理
如果终端支持计费提示,在收到网络的AoCC信息前应检查USIM的能力。终端应能已制定频率更新USIM中ACM信息,最快不超过5秒,过于频繁的ACM更新会影响USIM的读写周期。当ACM超过最大值ACMmax时,UE应中止当前的付费呼叫,且不能建立新的此类呼叫。本块测试用例分为终端支持AoC功能和USIM不支持AoC功能等两种情况,都有对应测试例。
PLMN读写、PLMN选择相关测试
此部分主要涉及选网时对照卡内各列表的优先级识别,涉及文件有HPLMN、OPLMN列表(Operator controlled PLMN Selector list)、UPLMN列表(User Controlled PLMN Selector list)、FPLMN列表(Forbidden PLMN list)。
短信息读取、溢出等应用特性测试
本块测试例主要验证以下几个相关短消息存储与读取的内容:
当终端收到一个第二类的SMS,且USIM卡上至少有一个SMS域为空,则终端应将接收到的第二类SMS应保存在USIM的EFSMS中,未读的SMS的状态应设置为“3”;当USIM卡上的最后一个空的SMS域被收到的SMS填充后,EFSMSS中应设置SMS存贮空间满的标志标志(对应测试例8.2.1)。
保存在USIM卡中的未读的短消息状态应设为“3”,终端应指示该状态,用户阅读该短消息后,其状态应设置为“1”(对应测试例8.2.2)。
(3)USAT特性
USAT即USIM卡应用工具包,在T=0和T=1的传输协议及各种USIM应用中,终端总是处于控制地位,发送指令给UICC,UICC则不能发送指令给终端,这限制了引入UICC的新特性和多种移动增值业务的发展。为了解决此类问题,在Cu接口的协议栈中引入USAT协议层,USAT层在传输层提供的服务基础之上提供了一种服务机制,允许UICC应用与支持这种机制的终端进行交互和操作,使得UICC可以主动要求终端执行某个操作。支持USAT的Cu接口的协议栈在传统的传输层和应用层之间增加了USAT功能层。
USAT通过一组指令(TERMINAL Profile、FETCH、主动式指令、ENVELOPE、TERMINAL RESPONSE、终端返回状态字SW1 SW2“91 XX”或“93 00”)实现这种服务机制。在分类简述各指令功能及实现方式前先有如下两点说明:
首先需说明终端是可选支持USAT,根据终端能力的不同,将支持USAT的终端分为a、b、c、d、e、f 六类(详见标准YD/T 1762.3-2008中USAT终端分类表),属于某类的终端必需支持该类对应的所有USAT功能。值得一提的是,支持USAT功能的a类终端许多功能属多卡片监控交互功能,USAT为UICC提供监视和控制其他卡片的机制。
ENVELOPE命令
终端通过ENVELOPE指令向UICC传送USAT信息,UICC可以用R-APDU对ENVELOPE指令中的某些BER-TLV(如SMS-PP Data Download)进行响应,也可以不用R-APDU进行响应,仅返回状态字节SW1 SW2。
简言之,终端发送给UICC的带有数据部分的命令都是通过ENVELOPE命令实现的。在多种USAT命令中都有应用,如USIM控制的呼叫和短消息。
2.3 系统结构
总体来看,测试系统由3部分组成,如图3所示:左侧使用卡模拟器针对每个测试例对卡进行精确配置,右侧TD网络模拟器来测试实际的信令流程,第三就是运行于网络模拟器上的测试例软件系统,可针对每个测试例与卡模拟器联合完成结果判定和测试log存取。
TD终端机卡测试系统实物图如图4所示:
3 结束语
本文介绍的TD-SCDMA终端机卡接口一致性测试系统是以行业标准YD/T 1762-2008和YDT 1763-2008为基础和参考,是全球第一套TD-SCDMA终端USIM/ME接口一致性测试系统,填补了TD-SCDMA终端USIM/ME接口测试的空白。截至目前(2009年12月),本系统已完成二百余款TD手机、数据卡的卡接口一致性入网测试工作,发现并解决了TD终端USIM/ME接口存在的普遍问题,极大地带动了终端测试领域仪器仪表的研发,对TD-SCDMA终端技术的健康高速发展及产业化进程的推动具有重大意义。
参考文献
[1]潘娟. Cu接口标准化介绍[J]. 电信网技术,2005.
[2]3GPP TS 31.102. Characteristics of the Universal Subscriber Identity Module(USIM)Application[S].
[3]3GPP TS 31.121. UICC-terminal interface;Universal Subscriber Identity Module(USIM)Application Test Specification[S].
[4]ETSI TS 102 221. Smart Cards;UICC-Terminal Interface;Physical and Logical Characteristics[S].
[5]ETSI TS 102 230. Smart Cards;UICC-Terminal Interface;Physical,Electrical and Logical Test Specification[S].
【作者简介】
刘晋兴:工信部电信研究院通信与信息系统专业,工学硕士。现就职于工信部电信研究院中国泰尔实验室无线通信部,目前主要从事3G移动通信终端测试系统及标准化研究,曾负责TD-SCDMA/WCDMA/CDMA2000等制式终端机卡接口行业标准制定、入网测试等方面的工作。
王 征:毕业于北京工业大学通信工程专业,工学学士,现就职于工信部电信研究院中国泰尔实验室无线通信部,主要从事TD-SCDMA终端机卡接口入网测试工作及相关标准研究制定工作。
接口测试范文第9篇
【关键词】办公软件 自动化 功能 性能 排版
1 引言
随着无纸化办公时代的到来，办公软件逐渐成为我们工作生活中的一部分。伴随着“棱镜门”事件的爆发，我们国家对于信息安全的要求也将越来越高。2014年5月，中央要求机关不得安装WIN8系统，这是信息安全执行层面的一个重要举动。2014年6月，有媒体报道称，部分中央机关及下属部门已内部要求停止使用微软Office，转而使用国产办公软件，这为国产办公软件的发展提供了很好的机遇。
随着我国政府采购的出台，许多国产办公软件正以惊人的速度发展起来，中标普华Office正是国产办公软件中的一个产品。中标普华Office采用先进软件架构，包含文字处理、电子表格、演示文稿三大模块，功能强大，基本涵盖微软Office产品的各项功能，易学易用，全面满足日常办公需要。但中标普华Office与微软Office相比，在功能、性能、排版等方面还存在不小的差距。
2 功能测试自动化
中标普华办公软件是基于开源办公软件OpenOffice发展起来的，由于功能上更多的是参照微软Office的方式，因此跟OpenOffice产品本身的差异还是比较大的。
OpenOffice它有自己的功能测试自动化工具-VclTestTools，从办公软件的功能角度出发，研究自动化测试框架的搭建和设计，以及如何书写高效率的覆盖率和正确率测试脚本，最终用于办公软件的自动化测试，主要工作如下：
（1）对办公软件的功能模块进行研究，对其中各个功能点进行分类和整理，总结出办公软件功能的一般规律。并从此基础上总结出办公软件的测试大纲。
（2）结合办公软件的测试大纲，对现有自动化测试框架模型进行改进，设计出适合产品特点的自动化测试框架模型。
（3）根据自动化测试框架模型，设计自动化测试脚本的类库，测试用例文件以及测试脚本的存储结构。最终通过执行测试脚本实现办公软件的自动化测试。
3 排版测试自动化
目前很多政府部门、企业，他们办公所使用的还是微软Office2003、2007格式的文档。而随着国家对于国产基础软件重视程度的不断加大，摆在我们目前的情况是，我们的国产办公软件该怎么样去兼容这些微软Office2003、2007格式的文档。国产办公软件兼容微软Office格式的能力还有待提高，因此我们需要很好地引入排版测试自动化，去更快速地解决办公软件中的排版问题。
在排版自动化测试实施过程中，我们研究图形文件格式兼容。利用图像虚拟打印机，我们将中标普华办公软件打开的微软格式文档打印成图片，然后用微软办公软件打开同一篇文档，并且也打印出图片。我们将自己开发一个图片像素对比的软件，将中标普华办公软件打印出来的图片与微软办公软件打印出来的图片进行像素逐一对比，最终形成一个数据，即中标普华办公软件打印出来的图片与微软办公软件打印出来的图片偏差率百分比，这个百分比数据就是我们得到的排版测试的结果。图1为排版自动化测试流程。
4 性能测试自动化
由于业界最常用的测试工具――LoadRunner，在Web并发测试上非常好用，但由于中标普华办公软件的特殊性，其没有用户并发的行为，而且其性能参数主要反应在打开文档、新建文档、关闭文档、保存文档的时间上。经过反复的测试及验证，我们最终决定利用软件接口的嵌套来进行中标普华办公软件的性能测试。
软件接口测试是项目测试的一部分，它测试的主要对象是接口，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递和控制管理过程预计系统见的相互依赖关系等。
我们将利用中标普华办公软件二次开发接口，在办公软件内设置不同的断点，通过调用二次开发接口的方式，来得出打开文档、保存文档、新建文档等时间，以此来判断中标普华办公软件的性能。为了更好地进行测试，我们将中标普华办公软件封装在FireFox浏览器中，打开FireFox浏览器会嵌入中标普华办公软件，通过Web显示的方式来记录各个性能参数。
5 结语
由于国产办公软件测试有其特殊性，我们不能利用LoadRunner、QTP等主流的自动化测试工具去对中标普华办公软件进行测试。我们需要自己去研究一些非主流的自动化测试工具，并且还要自行开发测试自动化工具。我们将在功能测试自动化、排版测试自动化、性能测试自动化这三方面不断进行研究与探索。
参考文献
[1]杨平.基于OpenOffice办公软件的自动化测试框架设计和实现[D].天津工业大学.2009.
[2]王敏，邵定鸿.图形文件格式兼容性研究与实现[J].计算机工学与设计，2007（15）.
[3]叶波，孙俊若，林洁.软件接口自动化测试技术研究与实现[J].信息化研究，2015.
作者简介
李峰（1981-），男，东华大学在职工程硕士学位。现供职于东华大学。主要研究方向为软件测试。
作者单位
接口测试范文第10篇
关键词：DSP；汇编语言；测试
中图分类号：TP313文献标识码：A文章编号：1009-3044(2008)23-963-02
DSP Assembly Language Software Testing Method
HU Qing-xia, LIU Qing-feng
(91413 Units, Qinhuangdao 066001,China)
Abstract: The in-depth analysis of the DSP assembly language software testing difficult, given the DSP assembly language software testing strategy, the DSP assembly language software is an important test of significance.
Key words: DSP; assembly language; test
1 引言
目前，DSP硬件系统已具有了很高的可靠性，但其软件系统，特别是用汇编语言设计编写的较为复杂的软件系统，可靠性总是难以得到保证，更是缺少完整的质量保证和评估体系，这已经成为DSP应用方面亟待解决的一个问题。对DSP汇编语言软件的测试与一般的软件测试不同，其自身的特点决定了测试面临的困难。本文首先对其测试难点进行分析，然后给出了DSP汇编语言软件的测试方法。
2 DSP汇编语言软件环境的复杂性分析
2.1 与硬件结合紧密，测试环境难以搭建和选择
汇编语言的程序是烧制到DSP芯片中运行的，DSP芯片种类繁多。这些芯片的外部管脚、内部存储器分配都各不相同 。在搭建宿主机测试环境时必须选择各种不同的相对应的芯片，然后配合仿真器与宿主机连接。这些硬件的配置本身就增加了测试难度，然而这些仿真环境总是和目标环境之间有着不小的差异,比如目标环境的中断难于模拟等。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模拟。
2.2 I/O通道少，测试数据获取比较困难
在DSP汇编语言软件的测试中给主机上载测试数据是很困难的。目前主要是基于以下3 种方式：1）实际的物理通道；2）开发工具IDE的虚拟IO功能；3）直接读取内存区数据。第一种方式就是目标机和主机之间具备物理的通信方式，比如以太网、串口、并口、USB等。这种方式要求系统必须具备这种通信方式和通信软件，一般只适用于系统级的测试。第二种方式是借助开发工具，比如TI CCS，这种方式调试较为复杂也容易出错。第三种方式则是需要占用较多的内存资源。
2.3 实时性要求较强
DSP软件一般都用作控制系统的内核，所以有很高的实时性要求，而实时性的测试是一般的测试方法和测试工具都难以实现的。
2.4缺少相应测试工具
汇编语言结构和语法都比较繁琐和冗长，这首先使测试人员理解程序变得困难，又因为DSP芯片的多样性，使得开发针对DSP汇编语言软件的通用测试工具几乎是不可能的。因此，在测试时，只能够使用一些测试工具（比如覆盖率分析工具等），而把测试的重点放在人工的代码审查上面，这就要求测试人员要很熟悉相应芯片的用法并且还要与开发人员充分的沟通。
3 DSP汇编语言软件的测试策略
DSP汇编语言软件是最难测试的软件之一，必须制定有效的测试策略。在搭建测试环境时，要寻求宿主机与目标机之间的平衡，即要对目标环境和宿主环境的测试内容有所选择，在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更快地完成调试和测试任务。而中断测试、硬件接口测试、系统集成测试等必须要在目标环境中进行。而在测试环境搭建完成之后，考虑到重要性以及测试执行先后顺序，把整个测试依次分为以下几个不同阶段。
1）代码审查阶段。对于DSP汇编语言软件，代码审查是整个测试的重点，要占到整个测试周期的60%。同时，代码审查又是功能测试编写测试用例之前的必要步骤。代码审查最好是在开发环境中通过硬件仿真进行。
2）功能测试阶段。在功能测试阶段，采用功能分解法、等价类划分和猜错法等方法，根据软件需求规格说明中所规定的软件正式合格项设计并执行测试用例，以验证其功能是否满足需求规格说明的要求，并对其功能的适合性和准确性进行验证。对于DSP汇编语言软件系统，功能测试必须首先进行模块化处理，分离出每个模块的输入输出。
在设计功能测试用例时，也包括对边界值的测试，即对输入域(或输出域)的临界状态、数据结构、状态转换、功能界限等的边界或端点情况下的运行状态的测试。此外，设计功能测试用例时运用覆盖测试工具辅助测试用例的设计，以达到功能测试的充分性。
3）性能测试阶段。在DSP软件系统中，程序的性能是非常重要的，要严格根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。在使用环境中，软件的失效过程要平稳（电机运动惯性问题），所以，不仅要检查软件工作过程，也要检查软件失效过程。
可以使用测试工具CODETEST主要对DSP下行的伺服驱动器控制软件中有时间要求和数据处理精度要求的软件合格性项进行测试，并把重点放在测试其实际时间特性与实际数据处理精度上。时间特性主要包括以下几个：中断延迟时间、任务上下文切换时间、任务响应时间、任务创建/删除时间、交替信号量时间、取得/释放信号量时间、交替消息队列传输时间。
4）接口测试阶段。为了保证正确地测试，还须要检验软硬件之间的接口。对接口的测试主要利用各种不同类型接口的监视工具。比如对TMS320LF2407板汇编软件串口测试，可以使用串口监控器EtherPeek.NX，人工设置各软件从RS232串口接收的输入/输出，验证各软件对输入/输出的反应，并监控其输入/输出内容的格式与数据位是否与接口规范一致，验证各接口的正确性和一致性。
5）结构覆盖测试阶段。使用测试工具LDRA TestBed对被测软件程序进行插装。插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。基于测试用例，执行插装后的程序，提取语句/跳转覆盖信息，将程序的执行表现与编码意图进行比较，衡量软件测试工作的充分性。代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。
6）强度测试阶段。在模拟环境下，打开被测软件全部数据采集与数据通信通道，运行全部模拟外设，长时间运行功能测试和接口测试等相关测试用例，检测交流伺服驱动器控制软件在设计能力下的运行情况。
7 ）安全性测试阶段。采用人工测试的方法对被测软件进行安全性测试。检测用户是否能对被测软件进行灾难性操作，被测软件是否具有关键操作的安全性保护等功能。对于电机控制系统的DSP软件，主要检查过压、过流、低压、低流、断电、异常复位等灾难性操作。
8）可恢复性测试阶段。采用人工测试的方法对被测软件进行可恢复性测试。用人工干预的手段模拟硬件故障、链路故障、电源故障等，故意造成系统出现异常，并由此检查被测软件是否具有错误探测功能，在故障发生时能否保护正在运行的作业和系统状态。并检测被测软件在重启之后能否正常地继续进行工作，并不对系统造成损害。
9）回归测试阶段。对于在测试过程中发现的问题，开发方应及时对其进行修正。修正后由测试方通过回归测试进行确认。回归测试必须将所有功能测试、接口测试等测试用例重新执行一遍，以验证所有问题已经全部解决，并且没有引入新的问题。
4 结论
此方法研究在一定程度上减轻了DSP汇编语言软件的测试难点，对以后的测试实践有重要的参考意义。此策略的充分性和自动化程度是今后工作和研究的方向。
参考文献：
[1] 郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992.
[2] 刘艳萍.DSP技术原理及应用教程[M].北京:北京航空航天大学出版社,2005.