数据一致性测试（精选7篇）
数据一致性测试 篇1
0引言
Link16数据链是美军制定的大容量、抗干扰、保密、时分多址的战术信息分发系统,具有相对导航、识别、任务管理、武器协同、监视、空中控制、数字保密话音和电子对抗能力,已成为美军陆、海、空三军联合作战的主要通信方式[1,2]。
Link16数据链消息标准虽然制定了完备的消息格式、信息交换和处理规则,但由于消息种类多、消息规则复杂,使消息的不同实现存在差异,也使系统/平台之间的信息交换存在问题。要确保这些消息实现遵照消息标准,即与标准相一致,就必须对消息实现进行协议一致性测试。协议一致性测试检验被测消息实现是否遵循Link16消息标准,以评价数据链功能的实现情况。
Link16数据链消息多达111条,且各条消息的实现方法差异大,如何有效测试Link16数据链消息实现成为难题,本研究针对Link16数据链消息处理的复杂性,提出协议一致性的测试方法,确保平台间数据链消息实现的一致,有效支撑数据链装备的测试。
1Link16数据链消息标准
Link16数据链使用J系列消息进行信息交换, 由美军标准MIL-STD-6016规定,规定了消息格式、消息内容、数据元素、发送/接收规则等内容,是美国三军互联互通的基础[3,4]。
1.1消息格式
J系列消息格式有固定格式、可变格式和自由电文几种,主要为固定格式,通过标识符和子标识符进行识别。J系列消息总共可以定义256条消息, 目前已经定义了111条,具体可归纳到如下12个功能领域:系统信息交换与网络管理、参与者精确定位与识别、监视、电子战、情报、信息管理、反潜战、威胁报警、任务 管理、武器协 同和管理、控 制、国家使用等。
每条固定格式消息由1个或多个消息字组成, 最多包含8个字。消息字又分为初始字、延长字和继续字3种,初始字包括消息最基本的数据信息;延长字用于传输与基本数据逻辑上关系密切的信息; 继续字传输相应的附加信息。1条消息必须以初始字开始,之后可以跟延长字,用于发送超出初始字容量的逻辑上与初始字相关联的数据字段。延长字之后可以跟有继续字,用于发送不常用的补充信息。
1.2数据元素
消息字是由若干数据元素组成,每个数据元素可以存在于若干消息字中,形成1个多对多的关系。数据元素的属性包括元素名称、比特数,以及必要的数据元素说明,如名称为“目标属性”的数据元素,比特数是3,对应有8个数据项,具体如表1所示。
1.3消息处理规则
消息处理规则,描述消息发送与接收应执行的消息处理,主要包括发送规则、接收规则、应答/执行3个方面。
(1)发送规则
发送规则主要包括以下方面内容:①指明消息为寻址发送或广播发送。②消息发送周期或发送 次数,如空中航迹消息J3.2规定实时空中航迹应以12s为周期发送,非实时空中航迹应以48s为周期发送。③指明发送的消息字或发送的数据元素要求和条件,如发送的威胁警告消息J15.0,在取消1个威胁警告的情况下,只需发送J15.0初始化字;在报告1个威胁警告的情况下,需要发送J15.0初始化字、继续字和延长字。④消息中应答/执行字段的指定,指明该消息是否需要应答,如指控单元变更消息J12.4的应答/执行字段为0时,要求接收方应答。
(2)接收规则
接收规则主要包括以下两方面内容:①指明具有强制告知标识的消息不应被过滤。②对收到的 消息执行应答。
(3)应答/执行
为了确保系统/平台能够正确收到数据链消息, Link16数据链制定了消息应答机制。消息应答分为两种,即机器应答和操作员应答。机器应答由数据链端机自动完成;操作员应答由应用系统或操作员负责完成。
2测试原理
协议一致性测试利用一组测试用例,在一定的测试环境 下,对被测实 现 (Implementationunder test,IUT)进行黑盒测试。Link16数据链由战术数据系统(Tacticaldatasystem,TDS)和端机组成,数据链消息处理主要由TDS实现,因此文章主要对TDS进行测试,即TDS为IUT,通过统计、比对等方法分析被测实现的实际输出是否符合预期结果, 判定被测实现是否遵循消息标准。
数据链测试仪分为上位测试单元、下位测试单元和数据分析与显示等部分。上位测试单元能够模拟系统/平台生成 操作员指 令,并通过上 位口向TDS发送;能够模拟产生传感器探测数据、平台行动路线等场景数据;能够采集和记录TDS向系统/ 平台发送的数据。下位测试单元能够模拟产生数据链消息,并通过下位口向TDS发送;能够模拟网络对端消息处理,包括应答、相关消息处理等,并将处理的结果发送给TDS;能够采集并记录TDS向数据链端机发送的数据。数据分析与显示将上位测试单元和下位测试单元采集的数据,与预期结果进行比对、统计分析,判断测试的功能是否达到预期结果,并显示采集数据和测试结果,实现对消息的充分、有效测试。上位口、下位口为测试口,支持场景数据、数据链消息等数据的注入和采集。协议一致性测试原理如图1所示。
协议一致性测试分为基本测试、收发规则测试、功能测试等方面。基本测试包括两方面:①测试TDS与数据链端机、任务系统接口的正确性,验证数据链与系统/平台连通性。②测试TDS消息编解码的正确性,验证TDS对消息的基本处理能力。收发规则测试检验TDS是否按消息标准正确实现消息发送规则、接收规则和应答/执行规则。功能测试,由于数据链消息复杂,1条数据链消息支持多种战术功能,功能测试就是要测试消息是否正确实现消息标准中要求的战术功能。
3测试方法
3.1测试用例设计
Link16消息种类多,消息实现复杂。例如数据更新请求消息J7.1,支持通过编识号和通过信息类别两种方式请求数据更新,请求更新的数据有航迹类、紧急点、参考点等10类,每种数据的请求处理各不相同。因此,测试用例的设计特别关键,直接影响数据链协议一致性测试的完备性,文章采用因果图方法设计测试用例集[5],具体方法如下:
(1)根据消息标准,分析每个消息处理的输入条件是什么(原因),输出结果是什么,包括输入消息、输入数据、输出消息、输出数据以及其他场景数据。同时,为了便于分析,给每个原因和结果赋予1个标识符。
(2)分析消息标准中关于数据链消息处理的描述,包括消息发送要求、处理要求,找出原因与结果之间、原因与原因之间对应关系,并根据这些关系画出因果图。
(3)分析数据链消息处理约束条件,在因果图上用一些记号表明约束或限制条件。
(4)把因果图转换为判定表。判定表是分析和表达多逻辑条件下执行不同操作情况的工具。它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
(5)以判定表的每1列为依据,设计测试用例, 形成测试用例集。
因果法测试用例设计方法,能够根据消息处理输入、输出之间对应关系,以及消息处理路径,设计对应测试用例,保证测试用例的完备性;同时,考虑消息处理的约束条件,使生成的测试用例集避免了冗余性。
3.2测试流程
触发TDS的方法有两种:①由操作员下达指令触发。②由远端收到的消息触发,相应测试也分为两部分:本地操作员触发的测试和远端消息触发的测试。本地操作员触发的测试,重点测试TDS与任务系统的接口、消息编解码、消息发送规则以及本地操作员触发的数据链战术功能处理等内容;远端消息触发的测试,重点测试TDS与数据链端机的接口、接收规则以及由远端消息触发的数据链战术功能处理等内容。
3.2.1本地操作员触发的测试
根据测试内容选择测试用例,并根据测试用例的输入条件,上位测试单元模拟产生场景数据和操作员指令,通过上位口发送给TDS。TDS对操作员指令进行解析并触发相应数据链消息处理流程;数据链消息处理完成以后,下位测试单元采集处理结果,并触发数据分析与显示单元对其进行分析,显示消息处理结果和测试结果,如果测试出错或消息处理完成,则结束测试。TDS处理后如果需要数据链对端处理,则将处理的结果通过消息发送给下位测试单元,下位测试单元模拟数据链网络对端消息处理过程,通过应答或消息响应TDS的处理请求,TDS再对应答或响应的消息进行处理,直至数据链消息处理完成。数据链测试仪采集、分析TDS每个处理步骤的数据,形成最终测试结果。本地操作员触发的数据链协议一致性测试流程如图2所示。
3.2.2远端消息触发的测试
下位测试单元模拟远端系统/平台。测试时,根据测试内容选择测试用例,并根据测试用例的输入条件,上位测试单元模拟产生场景数据;同时,下位测试单元模拟产生远端数据链消息,通过下位口发送给TDS。TDS在特定场景下对远端数据链消息进行解码,触发相应的数据链消息处理流程;数据链消息处理完成以后,产生应答消息或相应的消息,响应远端系统/平台的处理请求。数据链测试仪采集、分析TDS每个处理步骤的数据,形成最终测试结果。远端消息触发的测试流程如图3所示。
4结束语
Link16已成为美军和北约主用数据链,大量装备于陆、海、空三军作战平台。文章针对Link16数据链消息实现的复杂性,提出了Link16协议一致性测试方法,可以对数据链消息编解码、收发规则、战术功能处理进行全面测试,确保各平台消息实现的一致性,提升平台间互操作性。本文的方法也可应用于其他数据链的测试。
协议一致性测试方法的研究 篇2
协议测试是软件测试领域的一个分支, 属于黑盒测试, 它包括了三种类型的测试:一致性测试, 互操作性测试以及性能测试。
协议一致性测试是协议测试的一种, 依据某种协议对该协议的实现进行测试, 并判断该协议的实现是否与标准一致, 属于功能性测试。其主要目的是确认产品的功能符合标准规范的要求, 减少产品在运行过程中发生错误的风险。
协议一致性测试依据的标准是某种协议, 测试对象是设备的相应协议的实现, 目的是检验实现的输出是否与标准规定的一致。协议一致性测试的两大要素一是测试执行的标准, 另外是测试对象的输出结果与期望值的对比, 以确定被测系统的实现的可靠性以及提高在与其他同类型设备互联时的成功率。
2. 协议一致性测试的方法
测试系统对被测系统的访问模型依据被测协议实现的所处的上下层次来建立的。上下层的访问和被测协议实现是通过服务访问点来连接的, 测试系统对被测协议实现的测试控制和观察的接口可以设置在服务访问点, 也可以设置在服务提供层上或其他系统接口上。一个测试系统两个测试控制和观察的接口, 分别对应于被测实现的上层和下层访问点。测试系统对应于上层访问点的部分是上测试体, 对应于下层访问点的是下测试体。
IUT (Implementation Under Test) 和上层测试体之间通过抽象服务原语言 (ASP) 来通信, IUT和下层测试体协议数据单元 (PDU) 交换数据。在实际测试中, PDU采用抽象服务原语编码基本的消息信令, 而不是直接进行交互。协议一致性测试使用了被测试系统实现所使用的层间服务原语和协议数据单元PDU进行控制和解析。根据不同观察点的设置位置, 可以分为本地测试和外部测试, 本地测试适用于产品的内部测试而外部测试使用于远程方的测试。协议测试多用外部测试, 加上辅助的内部测试。外部测试可分为分布式, 协调式和远程式, 每一种又可以根据测试层次分为单层的, 多层的或嵌入式的。
本地测试法是协议测试中最常见的一种方法, 如图1所示。在这种测试模型中, 上下测试体以及协议协调过程是在同一个系统中完成的。这种模型假设被测协议层的上下层边界都存在访问接口, 测试系统通过接口对IUT施加激励进而观察输出的响应, 从测试系统的角度来说, 这种接口也成为控制观察点PCO (Point of Control and Observation) 。
分布式测试法, 协调式测试法和远程测试法这三种模型都假设IUT的下边界不存在接口。分布式测试模型下层测试体和IUT处于两个不同的系统中, 并且通过底层的服务协议来实现互连。同本地测试法不同, 分布式测试法的协调过程使用PCO交换的抽象服务原语来进行的, 上下测试体之间的同步是通过被测试系统实现的, 因此测试判决是通过下测试体作出的。
协调测试法是一种高级的抽象测试方法, 与分布式测试法相比较, 被测试IUT上边界与上测试体之间不需要有访问接口, 使用标准的测试管理协议和测试管理数据单元进行自动化的测试和管理。下测试体作为主控方, 自动对测试作出判决。上下测试体之间的通信可以基于被测试的协议, 也可以使用其他可靠的协议来传输控制数据单元, 用于高层协议的一致性测试。
远程测试法的主要优点是不需要显式地测试协调过程, 同时下测试体和IUT之间的同步依靠被测试的协议来实现, 上测试体的存在也是可以选择的。远程测试模型采用下测试模型通过其下层的服务系统与同一层次的被测系统交换数据单元。
3. 协议一致性测试的内容
协议一致性测试的内容主要包括了分析被测实体的具体实现所采用的协议规范和特性。要根据协议的规范, 研究协议的每个特性, 结合具体的被测实现, 建立仿真测试事件集合或交互行为序列, 这个用于描绘测试任务的事件集合或交互序列直观上使用时序的信令图来表示, 在具体的编程时使用TTCN3语言来编写事件集合或交互序列的测试用例。
协议一致性测试的标准包括了3个部分:抽象测试集, 协议实现一致性说明和协议实施附加信息, 如图2所示。可执行的协议测试集合基于上诉三部分基础上生成。测试生成使用抽象测试集描述特定的协议文本, 并且要求抽象测试集也是标准的。测试实现特定测试集的执行方法过程, 在这个过程中, 抽象测试集被转变为可以在具体测试设备或平台上可执行的测试用例, 也就是测试用例的编译选项的配置和编译过程以及可执行体和动态运行配置文件的生成。测试执行是运行已经可执行化的测试执行体, 观察被测实现的外部响应最终得到测试判决。
被测试对象应该自己系统协议实现的标准说明, 以用于测试时能以此作为测试对照。测试方可以根据PICS (Protocol Implementation conformance statements) 协议实现的一致性陈述和PIXIT (Protocol Implementation Ixtra information for testing) 进行配置参数和测试用例的选择, 进而得到将要测试的用例。
测试过程的状态变化经历了稳定状态, 被测试状态, 测试体结束状态, 验证结束状态。具体转换过程如图3所示:
在测试过程开始阶段, IUT首先由前置动作过程设置成初始的测试状态, 并且由测试用例激活测试过程, 即从稳定状态进入到测试状态。测试用例在测试体中经过一段时间运行后, 进入结束状态, 如果结果不一致, 就需要进一步分析结果中存在的问题, 进而转入验证结束状态, 如果结果相同, 通过后置动作恢复为稳定状态, 并且等待进入下一次测试过程。
协议一致性测试的过程分为了三个阶段, 第一阶段是测试生成, 其主要为某一特定的协议描述一个独立的抽象测试集合, 包括使用自然语言, 信令流图和测试编程语言。第二阶段是测试实现, 即将一组抽象测试集中的抽象测试用例转变为在实际测试设备或平台上可以执行的测试实体, 通常包括了测试用例的编译和链接以及测试环境的配置, 通常要模拟被测对象的具体所处的外部环境和执行要素等细节。第三个阶段即是执行测试用例, 对被测对象的协议实现施加测试激励, 通过观察返回的激励响应, 测试系统对比响应协议标准说明而得出的一致性判决, 必将测试判决记录到对应的测试日志或报告中。
测试生成是一致性测试的第一个阶段, 其要求是从协议描述中抽象独立的协议实现, 该实现是用标准化的协议测试语言描述的, 并且能够对协议的多方面进行描述, 生成测试集, 如图4所示。
通常抽象测试集使用一种抽象的测试方法。因此, 标准测试集更加应该使用一种标准话的经过严格定义的并且独立于任何实现的测试表示法来描述。国际标准化组织推荐了一种半形式化的测试语言TTCN (树表结合表示法) , 它具有严格的语法定义和灵活的抽象数据描述功能, 使抽象测试集描述更加标准化, 通用化和可变化。TTCN的描述具有典型的结构化层次, 在每个测试集是由称为测试用例的Test Case组成, 一个测试用例描述了一组测试步, 用来测试协议的一个需求或者一致性。每个测试用例又可以分为测试步和测试事件, 测试步包含了多个测试事件, 一个测试事件是在PCO上发生的一个交互动作, 如发送和接受动作。测试步就是由多个连续的测试事件组成。
从图上可以看出, 测试执行阶段首先是静态一致性检查, 依据协议标准的静态一致性需求对IUT进行静态检查, 而后在执行器上执行测试用例来检查IUT对动态一致性的满足程度。每个测试用例的判决结果为:通过, 失败或不确定性。最后静态一致性检查的结果和所有的测试用例执行的结果通过组合判断, 才会形成一个有关IUT的判决。只有当所有的测试都为失败时, 最终的结果才会是通过, 并且有专门的测试报告或测试日志来记录。
测试执行的机制是基于编译的测试执行, 基于编译的测试执行过程, 可执行的测试体是由许多的测试用例集编译而成的可执行文件体, 由抽象测试集到可执行体的转换是由转换器或编译器在测试之前完成的。可执行体只有在测试过程中才存在, 它顺序地读取测试事件, 编解码协议描述抽象服务原语和传输服务原语, 并将接受到经过解码的抽象服务原语与测试用例中的抽象原语模板比较, 以确定下一步要执行的测试步。
5. 总结
本文主要讨论了协议一致性测试方法的概念以及应用过程, 分别介绍了本地测试法、协调式测试发、分布式测试法和远程式测试法四种测试模型, 最后对协议一致性测试方法的测试内容进行了详细的论述。
参考文献
[1]庞其详, 刘云龙.通信协议的一致性测试[J].通信技术与发展, 1995, 34 (3)
[2]赵会群.通信软件测试技术基础[M].北京:人民邮电出版社, 2004, 35 (5)
[3]ETSI.ETSI ES 201 563-1 V3.2.1-2007 Methods For Testing AndSpecification (MTS) -The Testing And Test Control Notation Version 3, Part1:TTCN-3 Core Language[S], 2007, 53.
终端一致性测试专利技术综述 篇3
一致性测试作为测试领域中的一个重要分支, 源于对通信协议栈进行测试的需求。在两个需要通信的实体之间, 必须遵循相同的, 也即“一致”的通信协议, 才能完成正常的通信。通信协议栈的作用是保证通信实体之间遵循一致的交流语言和一致的交流规则, 而一致性测试正是一种验证通信协议栈正确工作的测试手段。
在移动终端 (手机) 的一致性测试中, 一致性测试的含义有所扩展, 它不仅包括了通信协议栈, 也包括了移动终端射频的接收和发送特性、射频的性能测试, 辐射杂散特性、SIM/USIM卡的电气指标等测试, 而这些也是3GPP核心规范的要求, 对保证移动终端的正常工作同样重要。至此, 可以引出一致性测试更广义的定义:一种检测通信实体与特定标准或者规范的要求相符合程度的测试。对移动终端而言, 就是检测其对通信标准规范 (如3GPP/ETSI/OMA等) 遵从的程度。针对移动终端的一致性测试, 其一致性还体现在下面两点:
(1) 测试环境的一致性, 这包括设备、电磁屏蔽、温度、湿度等条件。
(2) 测试结果的一致性, 在不同的测试设备上需得到一致的测试结果。
本文主要针对中国专利申请进行分析, 因此选取了检索噪声较小的CNABS数据库进行检索。CNABS数据库收录了自2000年至今在中国申请的全部专利文献, 其中整合了所收集到的中国专利数据信息、中国专利英文文摘数据、外文数据库如DWPI和SIPOABS中收录的中国文献的信息, 以及深加工数据库的信息, 并且包含大量丰富的字段, 便于检索和后期的技术分析。
2 终端一致性测试的专利技术演进及中国终端一致性测试技术的发展
1999-2004年专利申请量呈现缓慢上升趋势, 从2005年开始, 申请量开始逐渐增加, 并且在2010年申请量达到25件, 而2011年申请量有所下降, 随后持续增长, 并在2013年达到高峰, 2014年的数据有所下降, 主要原因可能是近两年申请的专利还有大量未公开。
中国公司在专利文献共提交LTE方面的文稿数量逐年上升, 据统计到2009年下半年专利文献总数的比例已经达到了20%以上, 对于我们重点关注的TD-LTE的系统设计, 中国公司提交的专利文献更是接近总数的50%。
在检索获得的中国专利申请中, 其中有97件来自公司、48件来自研究所、21件高校申请、个人申请占有率为0, 由此可以看出, 在终端一致性测试的研究中, 公司占据了相当重要的地位, 而研究所相比其他技术领域比例偏高, 个人申请却少之又少的状态, 这可能与终端一致性测试领域的研究门槛偏高, 研究成本以及市场应用的局限性所致。作为下一代移动通信系统一个最重要的发展方向, 在TD-LTE终端一致性标准化方面国内的工信部电信研究院、中国移动研究院、华为、中兴等公司和单位在相关技术研究和国际标准化领域也投入很多, 积极参与了TD-LTE的测试标准的制定工作。
国内目前的专利申请主要集中在以下三方面。协议一致性测试主要包括:终端射频一致性测试、终端协议一致性测试和终端无线资源管理 (RRM, Radio Resource Management) 一致性测试。
(1) 对于终端协议一致性测试, 一般须由专业的仪器仪表公司开发专门的系统模拟器, 按照3GPP定义的测试要求用测试和测试控制表示法 (TTCN-3, Test and Test Control Notation3) 编写抽象测试集, 从而完成一致性测试。
(2) 专网终端射频自动测试系统是指采用计算机控制, 自动完成建立通话、链路切换、信号测量、数据计算处理并输出测试结果的自动化测试系统, 主要应用于无线通信终端的射频指标测试及自动测试系统搭建, 其中包括数字对讲机、数字集群、数传电台、模拟对讲机等无线通信终端的射频指标测试及自动测试系统塔建。
(3) 终端RRM一致性测试主要包括:空闲状态下移动性管理, 连接模式下移动性管理, RRC连接控制, 终端测量过程要求以及测试性能要求等。
3 实际审查案例
申请号:201010525914
发明名称:一种一致性测试的方法和系统
技术方案:一种一致性测试的系统, 包括至少两个测试仪表, 所述至少两个测试仪表中包括第一测试仪表和第二测试仪表, 其特征在于, 该系统还包括主控模块、至少两个适配模块和至少两个定时同步模块, 所述至少两个适配模块中包括第一适配模块和第二适配模块, 所述至少两个定时同步模块包括第一定时同步模块和第二定时同步模块;其中:所述主控模块, 用于向所述第一适配模块发送第一测试用例信息, 并向所述第二适配模块发送第二测试用例信息;
所述第一定时同步模块, 用于向所述第二适配模块发送第一同步指示信息;所述第二定时同步模块, 用于向所述第一适配模块发送第二同步指示信息;所述第一适配模块, 用于根据所述第一测试用例信息和所述第二同步指示信息控制所述第一测试仪表执行所述第一测试用例信息对应的测试用例, 并将测试结果返回给所述主控模块;所述第二适配模块, 用于根据所述第二测试用例信息和所述第一同步指示信息控制所述第二测试仪表执行所述第二测试用例信息对应的测试用例, 并将测试结果返回给所述主控模块。
审查过程:审查员通过全面阅读本申请的原始申请文件了解到, 本申请的目的在于供一种一致性测试的方法和系统, 以提高终端协议一致性测试的效率, 保证严格的时延控制和时序控制。
首先判断本申请的领域属于协议一致性测试领域, 通过在中文专利库中采用关键词一致性、协议, 以及分类号H04W24/ic等检索要素检索到一篇2010年02月24日公开的CN101656637A专利申请, 其也是涉及一种一致性测试的系统, 因此将其作为对比文件用来评述三性。该对比文件公开了一种一致性测试的系统, 包括一台物理测试器具有多个 (可以是两个) 不同的虚拟测试模块, 分别负责测试各个测试端口的测试工作, 还包括中心控制模块, 用于协调管理各个虚拟测试模块的测试行为, 从而解决了多个物理测试器之间复杂的协调同步问题。
4 结语
本文主要对终端一致性测试的专利申请中, 中国专利申请的年度变化趋势、申请类型、专利申请人类型、地区布局、专利技术应用领域、改进方向、技术演进和发展等方面进行分析。该领域通用性较高, 一致性测试技术的发展直接推动了该领域的技术演进;而通信领域热门的射频、协议、无线资源管理容易被直接应用到该领域中。
在专利审查过程中, 把握本领域的现有技术和专业知识对于本申请文件的新颖性、创造性审查具有重要作用, 专利技术综述帮助审查员分析专利发展趋势和把握技术实质, 更能提高审查员的技术素养, 提高审查质量和审查效率。
摘要：一致性测试技术是保证移动终端产品质量的重要测试手段, 也是评价移动终端软、硬件质量的重要指标手段, 本文主要简要介绍了一致性测试的基本概念和技术构成, 基于专利介绍了国内终端一致性测试专利的技术演进。
数据一致性测试 篇4
研究协议测试理论的原因是一个标准化的协议并不不能确保该协议的实现之间能够成功的进行通信。虽然形式化验证的方法尽量的避免了协议实现与协议描述的差距, 但在一个协议入网之前还是需要一种有效的方法来对协议的实现进行判别。协议的测试就是要解决以上问题。协议的测试理论包括了协议测试的整个过程, 其主要研究内容包括测试组织、测试方法、测试生成、测试集描述、测试执行和判决、测试结果分析等多个方面。其中研究的重点是如下几个方面:
1测试生成
主要关注如何从协议标准的描述中获得进行协议测试所需要的测试集。
2测试集描述
目的是寻找一种合适的语言或公式, 从而能以简洁、通用和结构化的方式表达协议测试所需要的测试例。
3测试的执行和判决
这是协议测试过程中的关键阶段, 如何解释测试例的含义以及如何做出测试判决是它的研究内容。
4测试结果分析
协议测试过程的最后一个阶段, 研究如何从测试结果中分析生成测试报告并得出对被测协议实现的结论。
由于协议行为的复杂性, 难以用人为构造测试例的办法覆盖一个协议的所有行为, 所以研究一种测试例自动生成的方法十分必要。测试例经过协议实现的执行之后就要对运行结果进行判断, 有严格语法语义定义的形式化方法是自动、准确判断协议行为的关键。基于Petri网的协议测试技术是解决以上问题的有效方案。
基于Petri网的协议一致性测试方案
一致性测试是一种“功能测试”, 它依据一个协议的描述对协议的某个实现进行测试, 判别一个协议的实现与所对应的协议标准是否相一致。本文对协议的测试主要采取以下几个步骤如图1:
1测试准备:抽象测试集的生成, 是为一个特定的协议产生一个独立于所有协议实现的抽象测试集ATS (Abstract Test Suite) 。
2测试操作:也称为测试实现。在这一阶段, 根据协议实现的“协议实现一致性声明”PICS (Protocol Implement Conformance Statements) 和要测试的内容从ATS中生成可在实际的测试系统上执行的测试例, 最终产生参数化的可执行测试例ITI (Implemental Test Illustration) 。
3测试执行:可执行测试例的执行, 让IUT (被测实现Implementation Under Test) 执行已具体化的测试例, 并对IUT的外部行为响应进行观察和记录。
4测试判定:将IUT的实际响应序列与测试例期望产生的结果比较, 判别IUT的运行结果是否与PICS的描述一致, 如有错误找出错误发生的位置。将测试结果生成测试报告, 便于测试人员对协议实现分析。
测试方案中关键问题的解决
协议测试中涉及的关键技术主要有抽象测试集的生成, 从抽象测试集到可执行测试例的转化和测试判定。本文将利用Petri网的理论解决以上问题, 主要采取以下思路如图2。
测试执行子模块负责测试系统在测试执行阶段的工作。它将测试实现子模块预处理过的可执行测试集ITI的一个个测试例逐步在被测实现IUT上执行, 每一个测试例可能有不同的报文结构组合。对每一个具体的测试例, 测试执行子模块将每一个测试步的动态行为和数据行为输入到被测实现IUT的上侧服务访问点, 激励被测实现并观察被测实现的响应。将被测实现的响应与预期的测试响应序列进行比较, 做出一致性判断。最后根据测试结果生成测试报告。
总结
本文给出了用Petri网理论对协议一致性测试的总体方案, 重点解决了两个难点问题: (1) 测试集和测试例的表示和生成; (2) 被测实现的实际响应序列和预期响应序列的比对。
对于第 (1) 个问题, 测试集合我们用协议的网模型表示, 因为协议网模型的运行可以反映协议的实际运行情况, 从而以简洁、结构化的方式表达出了对协议功能测试的测试集合, 测试例我们用进程表示, 一个进程只能反映Petri网的一种可能运行情况。可以用进程表达式表示一个网系统的所有进程, 这样我们可以用求取进程表达式的方式得到尽可能覆盖协议所有行为的测试例。对于第 (2) 问题, 通过观察代表具体测试例的进程的变迁序列求取协议的预期响应序列。
数据一致性测试 篇5
随着核心规范的完成以及核心技术的进一步完善,TD - LTE测试标准规范的逐步深入, 作为LTE商用之前的最终验证,测试环节是必不可少的。 原始的测试平台及方案已很难满足测试过程中信号的随机变化, 所以搭建新的协议一致性测试平台以及设计新的测试方案是非常必要的。 目前在协议一致性测试方面的研究主要有:简单分析基于TTCN3 的TD-LTE协议一致性测试平台的设计与实现方案,搭建软件测试架构[3]; 为重选搭建的测试平台单一的用户设备与基站的具体通信过程, 对无线环境的模拟并未考虑在内,采用的是理想环境[4];搭建了基于单系统一致性测试框架, 但是设备具体自动模拟方面不够完善[5]。 本文首先搭建了基于重选的新协议一致性测试框架, 然后在TTCN3 上编写测试套, 通过对测试套的运行来实现重选测试方案的可行性与搭建平台的优越性。
1 测试平台的搭建
基于TTCN -3 的TD -LTE系统终端RRM小区重选过程平台, 主要由TTCN-3 软件的PC( 用于代替协议栈层三的功能)、用于模拟网络端小区的测试仪表1 和仪表2 分别代表小区1 和小区2 、 开关箱( 主要由TTCN - 3 软件的PC来控制开关箱内部的转接)、信道模拟设备(主要用于模拟信道环境,如增加噪声等;模拟信号在信道传输过程中的合路分路等)以及被测体(本文中被测体为用户设备手机)组成。 具体整体测试框架如图1 所示。 PC和测试仪表之间通过面向非连接的UDP端口通信,而测试仪表和终端则通过射频口(很好地模拟无线环境) 进行通信。 PC部分安装了TTCN3 软件,测试仪表由主控部分和协议栈层2(分组汇聚协议层、无线链路控制层以及媒体接入层)和层1(物理层)组成。UDP通信原理如图2 所示。
在TTCN-3 的测试套中定义了MTC和PTC。 并在相关成分中定义用于发送和接收消息的端口。 然后将需要进行信息交互的PTC之间的端口以及PTC和MTC之间的端口进行连接, 映射需要与被测体(SUT) 通信的PTC端口和MTC端口到SYSTEM成分类型中的相关端口。最后将SYSTEM成分类型中的虚拟端口通过适配层的配置全部统一映射到PC上的物理端口, 并实现由TTCN - 3 核心语言到仪表中开发所使用的C语言的转换。 最后将仪表1(模拟小区1)、仪表2(模拟小区2)、以及信道模拟仪器和被测终端连接到开关箱上,整个测试系统就搭建成功了。 其中安装有TTCN3 的PC机作为整个模拟场景的总控中心, 负责控制模拟小区1 的仪表1 、 小区2 的仪表2 、 以及开关箱内开关的切换工作。
本平台在搭建过程中,各个模块通过测试类ID可以实现测试系统自动化,不需要人为控制信息收发过程,并且平台在主控(MC) 的控制之下, 可以实现相同系统之间不同小区的切换、重选、测量等RRC诸多过程。 在信道模拟过程中加入信道无线环境模拟设备, 能够很好地模拟无线环境,使得模拟效果与真实环境非常接近。
2 测试方案
2 . 1 测试场景描述
平台搭建之后就可以编写测试代码, 本次模拟的是针对E-UTRAN TDD-TDD的同频小区重选。 首先终端( UE ) 最初在小区1 上驻留, 然后通过PC ( 装有TTCN3 软件的PC) 的控制来改变两个小区功率的值。 当UE检测到小区2 的信号功率比小区质量好时, 重选到小区2 上,UE在小区2 上驻留一段时间之后, 再通过改变小区1 与小区2 的功率, 使得小区1 的功率优于小区2 且满足重选的条件, 从而使UE检测到小区1 , 而且信号质量满足UE驻留的条件, 并重新驻留到小区1 上。
2 . 2 重选相关内容
2 . 2 . 1 RRC重选过程
在LTE系统中, 对于空闲状态终端的移动性完全是由非接入层控制,而不由接入层控制。 当终端驻留到某个服务小区后即可根据网络下发的测量报告( 可以周期触发也可以事件触发)对服务小区以及邻小区进行测量,UE会把测量结果上报给网络,网络根据测量结果分析决定小区是否进行重选。 具体评估准则参照R准则[6,7]。
2 . 2 . 2 测试目的
情景1 终端在E-UTRA RRC空闲状态下, 一个小区除了不满足R准则外,满足所有的重选条件。 因此不能重选到目的小区。
情景2 终端在E-UTRA RRC空闲状态下, 网络端接收到终端用户设备发来的测量报告,并且根据重选的准则来进行判决,终端满足重选到优先级更高的服务小区,重选成功。
2 . 2 . 3 测试环境配置
系统模拟器(SS) 配置: 配置小区1 为正常的服务小区。
终端(UE) 配置: 测试例开始前, 保证终端在小区1中处于已注册的空闲空闲模式, 即状态2A( 即经注册进入idle状态并且测试模式激活)。
2 . 3 测试过程描述
本测试包含了一个激活的小区和一个相邻小区。 要求UE在一个E-UTRA TDD载波上监测相邻小区。 测试中具有3 个连续的时间段, 并各自具有T1、T2 和T3 的持续时间。 只有小区1 在测试之前就已经通过UE鉴定。 小区1 和小区2 属于不同的跟踪区。 此外,UE还没有向网络注册包含小区2 的跟踪区。 在接下来的测试过程中,UE响应代表为了发送RRC连接请求消息进行跟踪区更新过程,UE开始在PRACH上发送前导, 向网络发起随机接入,具体测试步骤详细描述如图3 所示。
( 1 ) 确定UE处于状态2A ( 指的是UE开机接收基站已发送的系统信息并向网络成功注册且测试模式激活)。 设置小区2 的物理小区标识为小区2 初始物理小区标识。
( 2 ) 在T1 时间段内设置小区功率等参数( 此次设置功率参数不满足重选的条件,即R准则)。 即2.2.2 节中描述的情景1。
( 3 ) 由于步骤( 2 ) 中设置的功率等参数不满足重选的条件。 所以若T1 超时时,从T1 到T2 时间内网络应该改变功率设置,UE可以监测到小区且满足重选的条件。
( 4 ) 网络等待来自UE的随机接入请求信息, 以执行小区重选过程, 重选到一个新的可检测的小区, 即为小区2。
( 5 ) 从时间T2 开始, 在T2 持续时间的34 s内, 如果UE响应了新的可检测小区( 即小区2 ) , 即为重选到新检测的小区2 成功。 即2.2.2 章节中描述的情景2。
( 6 ) 如果UE在时间T2 内重选到小区2 , 在重选之后或者T2 超时时,继续改变小区1 与小区2 的功率,使得小区2 上的功率变差, 而小区1 上的功率则变得良好,从而为UE重选回小区1 作准备。
( 7 ) 当UE监测到小区1 的功率良好之后, 网络等待来自UE的随机接入请求信息来执行小区重选过程, 重选到一个已经检测的小区,即为小区1。
( 8 ) 从时间T3 开始, 在T3 持续时间的8 s之内, 如果UE响应了已检测的小区( 即小区1 ) , 即为重选到已检测的小区1 成功。
2 . 4 测试函数的编写
f_RRM422_Set Cell Power ( ) ; 函数的主要作用是改变在重选过程中的基站功率,使得UE可以监测小区参考信号功率的变化, 并在条件满足的情况下进行重选到其他小区。
f_RRM_LTE_BS_Config (Test ID); 函数的作用主要是发送测试例ID, 使得各个模拟仪表时间上的先后顺序与实际相符,实现各部分的自动配置而不用人为去控制。
f_RRM_Set Physicaly Cell Identity(p_physicalycellidentity);函数的主要作用是改变在重选过程中物理小区的标识,以便在重选过程中可以很好地识别重选小区。
f_RRM_PRACHChannel Transmited();函数的主要作用是当满足重选条件时,UE向基站发起随机接入的请求,改变所驻留的小区,达到重选的目的。
3 测试结果分析
根据协议中规定RRC连接重选一致性测试的流程,在TTworkbench平台上运行测试套生成GFT图, 如图4所示。 观察可知终端重选过程一致性测试套的实现, 完全满足协议一致性测试协议规范。 另外, 通过TTworkbench中的TT - man平台运行TTCN - 3 测试套生成可执行的.clf文件, 产生如图5 所示重选过程的TTCN-3 测试例仿真图。 图5 位于测试套中的主测试组件定义了基于消息的虚拟发送端口,对于模拟小区1 与小区2 的仪表也同样定义了虚拟端口,且相应端口与测试套中的主测试组件的端口进行虚拟映射。 测试例中的消息通过MTC对应的虚拟端口经过系统端口发往模拟小区1 仪表与模拟小区2 仪表,模拟小区1 与小区2 的模拟仪将所有的发送数据经过逻辑复用到某个端口,再通过UDP端口发送到测试仪表来控制测试仪表的运行。 以射频信号通过射频线导入到开关箱,开关箱经过对信号进行加噪声以及分波合波处理,最后通过射频口发送到用户设备端进行接收, 在此过程中携带控制信息, 例如让用户设备执行重选、切换或进行其他操作。 LTE_BTS1 是模拟TD - LTE小区1 仪表的发送接收端口, LTE_BTS2 是模拟TD - LTE小区2 仪表的发送接收端口, CTL是UE最终驻留的模拟小区仪表的端口, 在UE成功注册到某个小区时将给网络回复注册成功的消息。
通过研究可以看到,TTCN -3 的仿真图更加形象直观并且可以严格控制时间,使得时间与执行过程一一对应,并且在测试过程中通过测试例ID实现自动控制,不需要人为来改变某些内容与控制某些参数。 log(用于标记重要内容的函数)函数的引用使得图中重要内容更加形象、 过程更加具体, 并且易于检查在代码编写过程中的重要错误, 从而使得系统精度更高, 这样可将复杂问题模块化,便于解决复杂问题,从而有利于系统的完善。
由于4G技术的飞速发展以及5G技术的萌生, 用TTCN3 软件平台来构建测试套在今后的协议一致性测试中,TTCN3 将会发挥更大的作用。 本文以TD-LTE系统一致性测试需求为前提,设计了新的协议一致性测试平台, 并对测试生成的GFT图以及通过.clf文件生成的测试例仿真图进行比较,证明了测试平台在搭建方面的优越性。 该方法完善了TD-LTE系统协议一致性测试技术理论并且为以后的研究提供了可行的方案。
摘要：鉴于以往协议一致性测试平台整体框架的不完善,首先搭建了新的协议一致性测试平台,然后通过TTCN-3设计了关于重选测试套的新方案来进行仿真。通过将仿真图与原来GFT图比较得出了测试方案的优越性以及所搭建平台的合理性与可行性。
数据一致性测试 篇6
随着移动通信技术的不断发展和用户对高速率无线数据业务的需求激增,第三代合作伙伴计划(3rd Generation Partnership Project,3GPP)已经完成了R8的标准制定,设备、终端制造商也推出了长时期演进(Long Term Evolution,LTE)的商用产品。网络运营商将逐步推进LTE网络的实验网搭建、测试以及小规模商用。在网络部署中,通常会采用多厂商设备进行对接。由于协议规范采用自然语言描述,协议栈开发人员在协议理解上往往存在一定的差异性,这就造成了多厂商设备组网时的协议一致性问题,所以需要对LTE设备进行协议一致性测试。协议一致性测试是一种功能性测试[1,2]。由于协议规范在软件实现过程中受人为因素影响较大,协议一致性测试并不能保证满足绝对的标准,但作为一个标尺,可以保证通过该测试的设备在网络中出现协议一致性问题的机率大大降低。如图1所示,LTE采用扁平结构[3,4],演进型Node B(Evolved NodeB,eNB)通过Mesh方式连接,涉及的接口包括连接eNB的X2接口、连接eNB和演进型分组核心网(Evolved Packet Core,EPC)的S1接口。其中S1接口分为连接eNB和移动性管理实体(Mobility Management Entity,MME)的S1-MME接口和连接eNB和服务网关(Serving GateWay,S-GW)的S1-U接口。本文提出了一种LTE协议一致性测试解决方案,拟解决多厂商设备在S1-MME和X2这两个控制平面接口的协议一致性验证问题。
1 一致性测试仪的系统架构
一致性测试仪采用高性能工业控制机上扩展高速率网络接口卡实现,其系统架构如图2所示。其中,NIC为网络接口卡,从数据接口接收/发送数据包,进行物理层到网络层的协议解码和处理功能。为了支持一致性测试中多种物理和逻辑接口同时工作以及仪表组网功能,测试仪需要配备多个接口卡。在这种情况下,外部设备互联总线(Peripheral Component Interface,PCI)的共享式连接方式将导致每张板卡的实际传输速率降低,难以保证高速数据包的处理。所以本方案中采用PCI-Express[5]这种点对点串行连接的设备连接方式,保证了通道的专有性,避免了多板卡间的干扰,经过优化,单个设备的读速率可达到最大166Mbyte/s以及136Mbyte/s[6]的写速率。硬件平台再通过板卡驱动和上层的Win32系统进行交互,在Win32系统上搭载一致性测试软件系统。包括协议栈仿真套件、测试例生成和验证套件、用户二次开发接口。在本方案中软硬件平台的研究与开发是关键,下面分别详细介绍软硬件平台中所涉及到的关键技术。
2 硬件实现
LTE作为面向更高用户数据率和更大系统容量的新一代移动通信系统,LTE在空中接口上采用了正交频分复用(Orthogonal Frequency Division Multiplex,OFDM)[7]和多天线技术[8],能够支持下行和上行无线接入承载的瞬时峰值分组速率是100 Mbit/s和50 Mbit/s[9],S1接口上的速率将远超过UTRAN中Iu接口所采用的155 Mbit/s速率,所以现有的网络处理器(Network Processor,NP)无法满足要求。而FPGA性能优于NP,还可实现深度分处理和软硬件的可升级性。下面分别介绍硬件实现的数字前端和FPGA协议处理。
2.1 数字前端
数据采集是协议分析的首要环节。数据采集模块需要完成的功能包括:IP数据包的接收、流量过滤或者协议解码、转发等,功能多,数据速率高,因此选择成本合适的功能强大的处理器极为关键。随着集成技术的快速发展,功能强大的多核处理器已经出现,这将使得处理器的选择更为灵活。IP数据处理模块处理器可选择专用的网络处理器,目前,能用于高速IP数据处理的网络处理器(network process units,NPU)有很多,选择也较多,可以根据实际需要选择一款符合要求的网络处理器(NPU)。然而,用于用户数据包协议(User Datagram Protocol,UDP)、GPRS隧道协议用户面(GPRS Tunnel Protocol,GTP-U)、SCTP协议处理的处理器在市场上却没有,因此需要设计一款专用于以上3个协议的处理器。相对于网络处理器以软件为中心的编程特性,FPGA是以硬件为中心的编程特性。
基于FPGA的高速数据包处理模块架构如图3所示。在通道最前端是多个PHY芯片,它为不同物理介质提供支持,每种类型的PHY芯片都有其相应的MAC芯片,将采集到的数据恢复成标准的帧结构或将需要发送的数据进行封装,因此,FPGA的性能优于NPU。FPGA优于NPU还体现在深度处理、硬件可升级性、软件可升级性等方面,因此选择FPGA处理协议。
2.2 FPGA协议处理模块
FPGA协议处理模块的最前端是IP分离子层,完成IP数据包分离和接口转换,使得多端口调度模块以同样的操作流程对各个端口进行调度。多端口调度模块输出IP数据包到上层IP解封装模块进行处理,同时告知上层模块当前IP包关联的物理端口。
IP解封装模块首先提取IP地址生成IP地址表,IP地址表根据物理端口的数量被分为多个段,每个段存放在相应端口上传输的IP地址。为了明确数据来源,这里将IP地址与端口关联在一起。IP过滤模块根据上层应用感兴趣的数据进行IP地址过滤,减少了上层应用处理的数据量。
过滤之后的数据根据类型不同分别送到UDP解封模块或SCTP模块进行协议解析,提取出的参数按照控制平面和用户平面数据包分别存放到UDP端口表和SCTP信息存储空间中。其中控制平面数据经过SCTP处理后,所承载的上层数据被存放到特定存储空间供应用层调用分析;用户平面数据经过UDP解封处理后,送入GTP-U处理模块进行协议处理,并且将相应信息与IP地址和UDP端口按一定方式进行关联。用户寄存器主要用于存储相关协议的参数配置,包括源/目的IP地址、源/目的UDP端口、SCTP参数及GTP-U参数。这些参数主要用于协议产生模块生成高速大流量协议数据。
3 软件实现
与针对其他网络的协议一致性测试平台[10]类似,本方案的软件平台同样包括了测试例生成和扩展的二次开发接口。作为LTE这一新型网络的协议一致性测试仪,针对S1和X2接口设计出了协议仿真技术,采用实例注册技术,支持多对多接口实例仿真,真实地仿真网络设备的各种控制行为和业务能力。
协议栈架构如图4所示。基于S1和X2接口协议栈传输网络层一致的情况,采用多用户注册架构的SCTP协议栈。采用同样的架构,同时支持注册多个上层应用,为支持S1/X2接口实例同时测试提供支撑。
SCTP协议栈、S1-AP协议栈与X2-AP协议栈采用一致性架构,具有良好的扩展能力和友好的维护接口,而且支持不同层次的监测,在协议栈内部各模块间提供监测借口。其中S1-AP同时支持EPC侧和eNB侧,并根据注册实例决定协议栈的行为能力。主要模块功能如下:1) 主处理模块完成协议栈的具体实现及接口协议的对外体现;2) 维护接口模块接受服务用户的配置和管理,实现维护协议栈的运行;3) 数据库模块维护注册实例的信息、运行数据和工作状态;4) 用户接口模块为服务用户的接口,对注册实例提供行为能力支持,并且提供二次开发接口,支持测试例和新协议的开发。
4 小结
TD-LTE的网络测试验证于2009年完成了概念验证,而技术验证也进入了后期,2010年下半年已经逐步启动规模试验。这是一个全面推动网络技术、设备与测试仪表、组网技术等方面技术进步的关键阶段,通过规模试验可以及早发现和解决问题。本文通过结合重邮东电通信技术有限公司在通信测试仪表软硬件开发上的积累,提出了一种LTE协议一致性测试的产品方案。目前,该方案已进入实际开发阶段,并且将联合泰尔实验室、中国移动设计院等单位进行标准化测试和试运行。这将对推动LTE合理化产业布局产生积极的作用。
摘要：在研究LTE网络演进进程、网络架构及接口协议特性的基础上提出了一种针对X2和S1接口的协议一致性测试方案。从产品实现的角度介绍了该方案的软硬件平台架构。该方案采用硬件解码技术应对LTE网络中高速网络流所带来的协议数据包处理问题,在软件架构中提供开放的用户接口支持自定义的测试例扩展和自定义协议开发,为不断演进的网络在组网上提供支撑。
关键词：协议,一致性,LTE,测试
参考文献
[1]李校林,文小强.LTE-Uu接口协议栈中ASN.1模块的设计与应用[J].电视技术,2010,34(10):71-73.
[2]JING Zhong,JIANG Xiong.Protocol conformance test suite for home a-gent of mobile IPv6[J].Electronic Commerce and Business Intelligence,2009(6/7):45-48.
[3]QIU Qinlong,CHEN Jian,ZHANG Qifei,et al.LTE/SAE model and itsimplementation in NS2[C]//Proc.5th International Conference on Mo-bile Ad-hoc and Sensor Networks.[S.l.]:IEEE Press,2009:299-303.
[4]3GPP TS 36.300,Evolved universal terrestrial radio access(E-UTRA)and evolved universal terrestrial radio access network(E-UTRAN);over-all description;stage 2[S].2009.
[5]3GPP TS 36.423,Evolved universal terrestrial radio access network(E-UTRAN);X2 application protocol(X2AP)[S].2009.
[6]FROCK H,GERUSO M,WETZEL M.A survey of high speed bus tech-nologies for data movement in ATE systems[C]//Proc.IEEE SystemReadiness Technology Conference.[S.l.]:IEEE Press,2006:655-657.
[7]PENG Yu,LI Bo,LIU Datong,et al.A high speed DMA transactionmethod for PCI express devices[C]//Proc.IEEE Circuits and SystemsInternational Conference on Testing and Diagnosis.[S.l.]:IEEE Press,2009:1-4.
[8]CAI Qipeng,ZHAO Zhao,SCZYSLO S,et al.A novel simulation systemfor the performance evaluation of 3GPP LTE System in Indoor Scenarios[C]//Proc.3rd International Symposium on Wireless Pervasive Compu-ting.[S.l.]:IEEE Press,2008:415-419.
[9]3GPP TR 25.913,Requirements for evolved UTRA(E-UTRA)and e-volved UTRAN(E-UTRAN)[S].2005.
数据一致性测试 篇7
RMTP协议的发布实施极大的推进了监测系统联网进程,但由于厂家研发能力不同、协议理解不同,在联网过程中还存在一些问题。本文结合实际工作内容,设计研发了一套RMTP协议一致性测试系统(以下简称测试系统),能够验证监测设施RMTP协议的实现情况,进一步规范协议的使用。
2 测试系统方案概述
测试系统将验证不同的无线电监测设备提供的RMTP标准接口是否符合RMTP协议的规范,测试系统通过模拟协议信令与设备接口的交互,验证消息结构的规范性、消息内容的正确性以及消息流程的完整性,确保RMTP协议所规定的所有功能在该设备接口上得到正确的实现。
测试系统基于正在执行的RMTP1.01版本为依据,涵盖监测指令8项,非监测指令8项。RMTP协议分是客户端(全国联网系统)和服务端(接口程序)模型,对两端都要进行验证,基础测试例需设计实现32个。
3 测试系统架构设计
3.1 RMTP测试集
RMTP测试集定义了RMTP测试场景(测试用例)、数据类型、消息模板、RMTP组件仿真、组件接口定义。
3.2 编解码器
模块在发送消息时,将TTCN-3定义的消息编码为R MTP协议中定义的网络数据包格式,通过TCP连接进行发送。在接收消息的时,将网络数据包进行解码,还原为TTCN-3数据结构,使之能够在测试用例中对消息结构及数据正确性进行操作,并使日志具有良好的可读性。
3.3 系统适配器与平台适配器
系统及平台适配器为测试用例提供网络通信支持以及操作系统平台的支持,在本系统中支持TCP协议的通信,测试系统采用TCP协议和待测系统进行通信。
3.4 测试过程
测试例子执行启动后,首先由TE(TTCN-3Executable)控制,重置SA(SUT Adapter)与PA(Platform Adapter)。然后执行测试例,测试例执行时,通过建立端口映射建立RMTP的TCP/IP连接。如图2所示,在建立连接后,TE模拟协议信令进行编码,发送给SUT(待测系统),并启动计时器,用于监控超时。当SUT返回响应指令后,为缓解解码及判定的处理压力,首先将返回的内容加入消息队列,再开始解码,解码后与预先定义的模板进行比对,判定是否通过。测试结束后终止计时器,并解除端口映射。
4 测试系统实现
测试系统的最基本测试单位是测试例testcase,现以固定频率测量(FIXFQ)为例介绍RMTP测试系统的实现过程。
4.1 固定频率测量测试例实现
固定频率测量的测试例TC_Ser ver_FIXFQ中测试系统模拟整个固定频率监测业务的信令过程,以及对接收数据的判定,测试例中每个步骤由一个函数function实现。测试例启动后首先通过已经配置好的收发端口映射map建立与待测系统的TCP连接,之后按照协议要求执行登陆f_client_login函数,预执行f_client_Pre_Exe cution函数,接收测试结果f_client_Receive_Result函数,接收设备参数信息f_client_Receive_Device_Info函数,接收数据描述头信息f_client_Receive_Data_Des函数,然后接收经纬度信息f_client_Receive_Longitude_Latitude函数,完成经纬度信息的接收后,接收业务数据f_client_Reveive_Business_Data函数,业务数据接收完毕验证后,停止监测f_client_Stop,该测试例测试完成后断开TCP连接unmap。如图3所示。
4.2 登陆函数实现
登陆函数f_client_login是每个测试例开始时都要执行的函数,因此定义为公共函数,每个测试例都可以引用调用。登陆函数启动后根据用户配置参数,Rmtp_mtc Port调用send方法发送登陆请求消息,参数是m_RMTP_Login Request With Auth模板,在执行send时再最终发给待测设备之前要根据模板的内容进行编码。登陆请求发送后,启动计时器Rmtp Client Timer.start,等待待测系统返回结果,按照协议要求首先返回版本号,将返回的消息解码后,与预先定义的版本号进行比较,如果一致返回成功继续执行,如果不一致返回失败停止测试,如果超时返回警告继续执行。待测设备继续返回第二个消息,待测系统返回OK,测试系统返回成功;待测系统返回REFUSE,测试系统返回失败,超时返回警告。如图4所示。
登陆参数模板定义,参数是m_RMTP_Login Request With Auth模板,模板中定义了协议为RMTP,类型为验证VERIF,以及消息体,消息体中包含了验证类型,用户名和密码。如图5所示。
4.3 登陆编解码实现
(2)解码。在接到登陆返回的消息后首先进行解码,调用Text Message的类初始化构造函数将接收到的码流按照协议要求进行拆分,并将内容放到aTxtMsg对象中,最后将aTxtMsg对象中的成员变量的Version值赋给模板里的version,测试系统下一步将对模板中的值与预先定义的校验规则进行比较,验证是否通过。如图7所示。
5 测试系统调试分析
系统开发完成后针对少量监测接收机进行了抽样调试分析,发现不同厂家对协议的理解还存在一些差异,例如数据包的合并和拆分问题,协议中并没有规定数据包是否可以合并发送,但有的厂家为了减少发送的I/O次数,提高效率,将数据量较小的包合并在一起发送,也有将较大的数据包拆分成多个包进行发送。这就造成在控制中心得到的数据包有的是分开的,有的是合并的,得到的数据并不是一致的,影响系统的互联互通。
参考文献
[1]国家无线电监测中心.无线电监测网传输协议(RMTP)V1.01,2008.7
[2]董宏成.TTCN-3在RRC协议一致性测试中的应用.电子技术应用,2013.7
[3]曹丽君.浅谈我国无线电监测工作的现状与发展前景.数字化用户,2014.8