摘　要　　系统适配器(SA)是TTCN-3(Testing and Test Control Notation)测试系统与被测系统间通信的媒介。对于TTCN-3测试的实施具有重要的作用，但是系统适配器往往需要针对不同的被测设备进行开发，工作量较大。针对这个问题，提出一种层次化TTCN-3系统适配器的架构，将系统适配器分为与测试系统无关的硬件驱动层、 负责被测设备信令转换的设备消息映射层和与被测设备无关的协议处理层，从而达到软件复用、 减少开发工作量的目的。给出一个SA开发实例，表明这种体系结构可以实现多种被测设备的系统适配器的快速开发，证明了该方法的可行性和有效性。

关键词　　测试　TTCN-3　系统适配器　软件重用

0　引　言

TTCN-3是目前应用最为广泛的测试专用语言，可以被用于进行系统测试、 交互性测试、 协议测试、 业务测试、 模块测试等[1]。TTCN-3的平台独立性和其特殊的测试能力使得它被应用于定义软件系统的正式测试集，目前已经广泛应用于通信、 计算机、 控制等各个领域[2-5]。

在TTCN-3标准中，专门定义了系统适配器SA实体及测试运行时接口TRI(Test Runtime Interface)[6]来规范TTCN-3测试系统和被测系统之间的通信工作。现有的大量TTCN-3的研究主要在于测试例的开发方面，而SA方面的研究相对较少，而SA的设计与实现对于TTCN-3测试系统的实施具有非常重要的作用，某些项目会因为适配器不可用而导致测试工作无法顺利进行，从而导致整个项目开发流程的中断[7]。

在实际项目应用中，SA的开发量往往是巨大的，有时会超过TTCN-3测试例编写的工作量。特别是对于协议一致性测试系统而言，由于要接入多个厂家不同的被测设备，这些设备在接口设计时通常会有所差异，如果每次都针对待测设备重新开发SA，则会增大SA的开发和维护的工作量。本文提出一种层次化的系统适配器结构，将SA分成与设备相关和与设备无关的部分，从而提高SA的通用性，减少系统开发的工作量。

1　TTCN-3测试系统整体结构

TTCN-3测试系统的整体结构如图1所示。其中，测试管理实体TM(Test Management)负责测试系统的整体管理；TTCN-3可执行实体TE(TTCN-3 Executable)负责测试例的执行；测试日志实体TL(Test Logging)负责维护测试中产生的日志；编解码实体CD(Coding and Decoding)负责在外部对数据进行编解码操作，TE也可以内置编解码功能，但外部的CD具有标准化的接口，使其能够方便地移植于不同的TTCN-3系统和工具，提高复用性；组件处理实体CH(Component Handling)负责分配并行的测试组件，用于分布式的测试系统；SA负责将TTCN-3测试系统产生的消息和指令转化为能够由被测系统识别的形式，作为测试系统与被测系统间通信的媒介。

TRI定义了TE、 SA和PA被测系统间的交互，它为TE提供了向被测系统发送数据、 接收从被测系统发来的数据和管理定时器的方法。在实际测试中，TTCN-3测试系统需要能够与被测系统进行通信，控制被测系统的行为，执行测试步骤，并读取被测系统的状态，以验证测试的结果是否符合预期。由图1可见，被测系统与TTCN-3测试系统中的SA直接相连，SA实现测试系统与被测系统之间数据传输的适配，将来自TE的数据发送给被测系统，并在被测系统返回响应时通知TE进行读取。SA与TE间的交互通过TRI进行，SA和TE间的数据都会经由TRI进行传输。

图1　TTCN-3的系统结构图

2　层次化的系统适配器架构

2.1　分层模型

为了能够提高SA代码的重用性，减少开发和维护的工作量，本文提出将TTCN-3系统适配器器分为以下三个层次(如图2所示)：

图2　层次化的系统适配器结构

1) 硬件驱动层主要负责和硬件设备进行通信，可以采用标准的物理层接口或网络协议，如RS232串口或者UDP协议等；

2) 设备消息映射层主要负责将设备特有的命令或者数据格式映射为一种与设备无关的标准信令，再由协议处理层进行处理；

3) 协议处理层负责分析与具体设备实现无关的协议信令信息，更换不同的待测设备或者设备参数无需修改协议处理层的代码。

进行这样层次划分后，硬件驱动层仅与硬件设备接口类型相关，与具体的通信协议无关，可以在不同的测试项目之间进行复用。协议处理层仅与测试系统所使用的通信协议相关，与具体设备的实现方式无关，如果新增加不同厂家的待测设备则不需要修改协议处理层。只有设备消息映射层与待测设备的实现相关，增加新的待测设备有可能需要修改或者替换设备消息映射层的SA。采用这样的层次划分化，可以将与设备相关的部分最大限度地分离出来，从而实现SA的复用。

2.2　层次间接口和通信机制

不同层次间的SA之间仍然可以采用标准的TRI接口进行通信。处于底层的SA先从消息队列中接收数据，完成本层的处理后再利用triEnqueueMsg将数据放入消息队列供上层的SA继续处理；当发送数据时，处于上层的SA先从TE获得数据，待处理完成后，再利用triSend发送数据到消息队列供下层的SA处理，最后再由硬件驱动层发送给待测设备(如图3所示)。

图3　不同层次的SA收发数据序列图

采用这样的通信机制，每层的SA的开发方法同传统的SA开发方法相同，而且SA之间的通信接口完全相同，便于不同的SA之间的自由组配，可以根据需要减少或者增加SA的层次。

3　实现实例

3.1　测试系统组成

本文以TETRA协议互操作性测试系统的开发为例说明层次化TTCN-3系统适配器的开发过程和应用关键。TETRA是ETSI制定的一个集群通信协议[8]，是目前国际上使用得最广泛的专业移动通信系统之一。TETRA协议互操作性测试系统的目标是测试各厂家所生产的基站或移动台设备是否满足协议的规定，实现互联互通的要求。被测系统(SUT)由移动台(MS)和交换与管理基础设施(SwMI)共同构成，测试系统组成如图4所示。

图4　测试系统组成

移动台和交换与管理基础设施之间通过TETRA空中接口协议标准进行信令和数据的传输。TETRA产业联盟针对TETRA系统分组数据业务的互操作性测试制定了测试标准和测试计划。测试系统使用TTCN-3测试语言进行开发，测试系统模拟移动台的功能，通过PEI接口控制移动台发送和接收信令，并将接收到的信令数据和测试标准进行对比，从而实现自动的互操作性测试。

3.2　被测设备的差异性

虽然ETSI制定了测试系统和移动台之间的PEI接口的标准规范[9]，该标准以AT指令为核心，并针对TETRA系统进行了语法扩展，但是不同厂商生产的TETRA移动台所支持AT指令集与PEI标准均存在差异，这种差异给互操作性测试系统的开发带来困难。不同移动台之间的差异性主要有以下几种情况：

(1) AT指令参数格式的差异

不同厂商生产的TETRA移动台所支持的AT指令集中，同一条指令在参数格式上存在差异。为了对TETRA移动台进行相同的配置，不同TETRA移动台所要求的AT指令的参数个数和意义可能不尽相同。举例来说，在测试短数据业务时，需要使用“AT+CTSP”指令来对TETRA移动台进行短数据业务的初始化设置，对于MOTOROLA和SEPURA两个厂商的TETRA移动台，所需使用的指令参数为“AT+CTSP=1,3,130”；而进行相同的配置，EADS生产的TETRA移动台要求的指令为“AT+CTSP=1,2”。

(2) AT指令数量的差异

不同厂商生产的TETRA移动台实现相同功能所使用AT指令的数量存在差异。如在发送短数据后，TETRA移动台会向TTCN-3测试系统发送“+CMGS”指令指示短数据发送的状态。对于MOTOROLA生产的TETRA移动台，共使用两条“+CMGS”指令；对于SEPURA生产的TETRA移动台，共使用三条“+CMGS”指令；而对于EADS生产的TETRA移动台，只使用一条“+CMGS”指令。

(3) AT指令类型的差异

不同厂商生产的TETRA移动台所支持的AT指令集中，存在一些独有的指令。如EADS移动台独有“AT+CMGF”指令，在使用其TETRA移动台进行短数据的相关测试时，还需要额外发送指令“AT+CMGF=7”设置移动台为PEI模式，才能顺利进行之后的测试步骤。

而自动测试系统中的TTCN-3脚本支持的是标准的PEI指令集，TTCN-3测试系统在完成一个测试步骤时对所有的TETRA移动台只使用唯一的标准AT指令，则对于不支持该标准AT指令的TETRA移动台，测试将无法进行下去。而如果在TTCN-3脚本中对于每种移动台都编写不同的代码，显然会使测试例的开发变得非常复杂，而且也破坏了测试标准的一致性，所以最好的办法就是在SA的开发中消除这些差异性。

3.3　SA分层模块组成

在SA的开发中，采用了表1所示的各个功能模块。我们使用的TTWorkbench系统支持将不同层次的模块以插件的形式加入测试系统。

表1　TETRA互操作测试系统的SA模块

而对于不支持插件形式的测试系统，如Loongtesting系统，可以将各层次的模块封装成DLL，然后在SA中顺序调用DLL。

3.4　硬件驱动层的实现

硬件驱动层主要完成对硬件设备的读写工作。TETRA移动台普遍支持串口模式，即使使用USB连接的厂商也可以通过驱动程序支持虚拟串口模式，所以硬件驱动层可以使用TTWorkbench所提供的标准的RS232插件实现，只需在测试环境下进行串口端口号和波特率的设置即可。新版本的PEI接口标准也支持IP网络模式，在这种情况下可以使用TTWorkbench所提供的标准的TCP/UDP插件实现硬件驱动层的SA。

3.5　设备消息映射层的实现

设备映射层的SA主要工作就是解决前述的被测设备的差异性问题，其基本处理流程如图5所示。

图5　在消息映射层的SA中对AT指令进行适配

SA对信令进行分析，针对不同的差异性问题，采用不同的处理方法：

(1) AT指令参数格式的差异

设备映射层将把接收到的各厂家移动台的AT指令映射为PEI标准所规定的标准格式，或者把协议处理层发出的标准格式映射为厂家特有的格式。例如在测试短数据业务时，CD模块采用“AT+CTSP=1,3,130”作为标准的初始化信令，当使用EADS的TETRA移动台发送命令时，设备消息映射层将其转换为 “AT+CTSP=1,2”后再发送给设备驱动层。

(2) AT指令数量的差异

对于这种情况，设备映射层通常会将多余的指令从消息队列中删除。

(3) AT指令类型的差异

对于一些PEI标准外的特殊指令，设备映射层将分析信令的上下文，并根据需要在消息队列中增加相应的指令数据。

在本实例中，设备消息映射层和协议处理层执行的先后顺序是有要求的。接收时，一定要确保设备消息映射层先执行，因为AT命令的格式将影响协议处理层分帧的操作，如果命令格式不先做调整，会导致协议处理层分帧失败。发送时，协议处理层先执行，然后设备消息映射层再根据收到的信令上下文进行消息转换。

对于不同厂商的待测设备，可以采用替换不同的消息映射层SA或者设置SA的参数的方式来适配。对于市场上主流厂商的设备，我们在SA中通过专门的AT命令进行了生产厂商识别，从而可以自动加载预先开发的SA来进行测试，进一步减少了测试配置所需要的工作量。

3.6　协议处理层的实现

串口接收的数据是以比特流的形式存在的，而TTCN-3的TE和CD所处理的数据是信令包形式的，所以协议处理层的ATFilterPlugin的主要工作是对接收的数据进行分帧处理。

PEI收发的数据包括两类：一类是处理TETRA的呼叫和短信业务的AT命令，另一类是处理分组业务的PPP信令。对于AT命令，协议处理层需要根据AT命令格式规定的回车换行符或命令时间间隔进行分帧。而对于PPP信令，需要根据RFC 1661和RFC 1662的规定进行PPP分帧和字符转义等操作。

协议处理层的操作只和TETRA协议和PPP协议的规定相关，与厂商的具体实现无关。

3.7　测试结果

将所开发的层次化的系统适配器模块应用于国家无线电监测中心检测中心的TETRA互可操作性测试系统中，先后对6个厂家的网络和终端设备进行了测试。

图6是在TTWorkbench中进行MOTOROLA的MTP850移动台的短消息测试(测试例编号：SDS 1.4.1)所生成的序列图的局部，从中可以看出设备消息映射层对MOTOROLA所发出的“+CMGS”指令进行了过滤，将多余的指令从消息队列中进行了删除。这说明设备消息映射层的SA实现了将非标准的AT指令转换为标准的AT指令。

图6　设备消息映射层对短数据的处理

我们针对4个厂家的TETRA移动台开发了相应的SA，表2是对采用传统方法设计的SA和层次化SA的代码量进行了对比。在层次化SA中，测试平台中的设备驱动层、 协议处理层的SA均相同，对应不同品牌的移动台采用相应的设备消息映射层SA。由于采用了分层的系统适配器，大量的代码可以继承和重用，所以在新增一个品牌终端开发SA所需要的开发时间可以明显减少，缩短了测试系统建立的时间。

表2　多个品牌移动台的SA开发代码量

4　结　语

本文提出了一种层次化的系统适配器架构，在不同的层次对收发数据进行过滤操作，从而实现将与被测设备相关部分和无关部分的分离，减少SA的开发工作量，增强系统的通用性。本文所提出的方法已经在TETRA互操作性协议测试系统中得到了验证。