CN1400751A

CN1400751A - 通讯协议一致性测试中的虚拟测试系统及方法

Info

Publication number: CN1400751A
Application number: CN01123871A
Authority: CN
Inventors: 田军
Original assignee: Institute of Computing Technology of CAS
Current assignee: Institute of Computing Technology of CAS
Priority date: 2001-08-08
Filing date: 2001-08-08
Publication date: 2003-03-05
Anticipated expiration: 2021-08-08
Also published as: CN1207857C

Abstract

一种通讯协议一致性测试中的虚拟测试方法，包括步骤：被测实现是根据地址判断测试包的来源；用不同的被测协议实现对等层的网络地址实现多台虚拟测试器；使用多台虚拟下测试器搭建逻辑测试结构，实现对被测协议实现软件(或系统)测试。在保证有效性、精确性的前提下，仅使用一台下测试器就可以实现对被测协议实现软件(或系统)的测试。虚拟测试方法避免了各测试器之间复杂的测试协调过程，而且测试结果更可靠、更精确。

Description

通讯协议一致性测试中的虚拟测试系统及方法

技术领域

本发明涉及计算机和电信通讯协议一致性测试，特别涉及通讯协议一致性测试中的虚拟测试系统及方法。

背景技术

协议一致性测试是一种“功能测试”，它依据一个协议的描述对协议的某个实现进行测试，判别一个协议的实现与所对应的协议标准是否相一致。它只根据协议的说明，通过观察协议实现的外部行为来确定协议实现的功能，而不涉及协议实现的内部结构。

为了说明协议一致性测试方法，给出如下基本概念。

1.实体(Entity)：OSI将每一层中活跃的元素称为实体，实体既可以是硬件实体(比如一块芯片)，也可以是软件实体(比如一个进程)。在不同机器上同一层内的实体叫做同层实体或对等层实体。

2.服务访问点SAP(Service Access Point)：分层的网络协议体系结构中，每一层都要为上一层提供一定的服务，并把这些服务是如何实现的细节对上一层加以屏蔽，服务是在服务访问点SAP提供给上层的。

3.控制观察点PCO(Points of Control and Observation)：测试系统和IUT之间的通信点。测试系统通过PCO访问IUT，通过控制观察点，测试系统既可以对通信进行初始化，也可以观察通信结果。控制观察点一般定义在服务访问点SAP上。

4.协议数据单元PDU(Protocol Data Unit)：在协议栈的层与层之间的接口上，n+1层实体通过SAP把一个接口数据单元IDU(InterfaceData Unit)传递给n层实体。IDU由服务数据单元SDU(Service DataUnit)和一些控制信息组成。SDU是将要跨过网络传递给对等实体。然后向上交给n+1层的信息。控制信息用于帮助下一层完成任务，它本身不是数据的一部分。为了传递SDU，n层实体可能将SDU分成几段，每一段加上一个报头作为独立的协议数据单元PDU送出。

5.被测系统SUT(System Under Test)：被测试的系统或者是被测系统的一部分。

6.被测实现IUT(Implementation Under Test)：作为测试目标的系统或者协议实现(Protocol Implementation)，被测实现可以作为被测系统的一部分，嵌入被测系统中。

7.上测试器(Upper Tester)：是一个测试系统或测试系统的一部分，它在被测系统的上层控制PCO。它通过IUT的上侧SAP与IUT进行通信。

8.下测试器(Lower Tester)：是一个测试系统或测试系统的一部分，它在被测系统的低层控制PCO。它通过IUT的下侧SAP与IUT进行通信。下测试器同时负责给出测试判定。

9.测试协作过程(Test Coordination Procedure)：包含合作规则的集合。例如，上测试器和下测试器之间的同步，不同下测试器之间的同步。

10.服务提供者(Service Provider)：是测试结构的一部分，假设被测系统位于网络体系结构的第N层，服务提供者为它提供N-1层的功能。服务提供者为IUT和下测试器之间提供通信环境。

协议一致性测试使用在特定点PCO(Point of Control and Observation)对被测实现的层间服务原语和协议数据单元进行控制和观察的原理。根据PCO的不同，在ISO9646(协议一致性测试方法和框架)中已被标准化的抽象测试方法有本地测试法和外部测试法。本地测试法适合于在产品内部测试；外部测试法适合于远程的第三方测试，又可分为分布式、协调式和远程式测试。本地测试法的一个基本前提是在IUT的上下边界都存在暴露的服务访问接口，上下测试器控制这些访问接口来激励IUT，并观察IUT的输出响应。分布式测试法的下测试器位于测试系统中，上测试器位于被测系统IUT中，下测试器和IUT是对等实体，它们之间通过提供N-1层服务的底层协议实现来连接，上测试器与IUT在同一个系统中，IUT必须有暴露的上边界服务访问接口。协调测试法的下测试器和IUT是对等实体，它们之间通过提供N-1层服务的底层协议实现来连接，上测试器与IUT在同一个系统中，IUT不一定有暴露的上边界服务访问接口，上测试器要用标准的测试管理协议(testing management protocol)与下测试器来协调完成测试实现。远程测试法不定义上测试器，也不需要显式的测试协调过程

在实际测试中，第三方测试一般使用远程式测试法或分布式测试法，并采用多台下测试器的测试结构。如美国New hampshire大学的IOL(Interoperability Lab)提供ATM，ADSL，MPLS，IPv6，Routing，VoIP，Wireless等协议的一致性测试，日本的TAHI工程从1998年10月1日，进行IPv6的一致性测试，美国国家标准技术局NIST的信息技术实验室ITL对ATM的一致性测试和互操作性测试等。各大学和研究机构对通讯协议的测试，特别是在对路由协议的测试中，一般要采用多台下测试器对被测实现进行测试。其测试结构框图如图1所示。

假如有这样一个测试序列，如图2所示。在这个测试序列中需要三个下测试器TN1、TN2、TN3，这三个下测试器可能是主机也可能是路由器。被测节点NUT可能是主机也可能是路由器。图3是此测试序列的测试过程流程框图。测试过程由TN1发起，测试结果判断也由TN1做出。整个流程解释如下：步骤S1，三个下测试器做好准备，开始测试；步骤S2，TN1发送测试数据包TP1给NUT，并通知TN2，TN3准备接收；步骤S3，NUT产生响应，其响应数据包RP1是发给TN2的；步骤S4，TN2判断收到NUT的响应数据包RP1是否与预期值相同；

步骤S5，若TN2收到RP1与预期值不同，则通知TN1；步骤S6，TN1做出判断，测试失败或不确定；

步骤S7，若TN2收到RP1与预期值相同，则发送测试数据包TP2给NUT，并通知TN1，TN3准备接收；步骤S8，NUT产生响应，其响应数据包RP2发给TN3；

步骤S9，TN3判断收到NUT的响应数据包RP2是否与预期值相同；

步骤S10，若TN3收到RP2与预期值不同，则通知TN1；步骤S11，TN1做出判断，测试失败或不确定；步骤S12，若TN3收到RP2与预期值相同则发送测试数据包TP3给NUT，并通知TN1，TN2准备接收；步骤S13，NUT产生响应，其响应数据包RP3发给TN1；步骤S14，TN1判断收到NUT的响应数据包RP3是否与预期值相同；

步骤S15，若TN1收到RP3与预期值不同则做出判断，测试失败或不确定；

步骤S16，若TN1收到RP3与预期值相同，则做出测试成功的判断。

采用多台下测试器对被测实现进行测试的缺点是：多台下测试器在物理上是分离的，因此对同一测试事件的观察在时间上存在差异。多台下测试器存在于不同的系统中，它们之间必须有良好的同步和控制协调过程，使测试过程复杂化。如上测试序列中TN1发送测试数据包TP1后，需要通知TN2，TN3准备接收；TN2在收到NUT的响应数据包RP1，发现不等于预期值时，需要通知TN1做出判断。对于多台下测试器之间的测试协调，有多种方法。如TAHI在对IPv6协议测试中，是采用串行线实现各测试器之间的协调。还有利用被测实现的同层参考实现构成的辅助通道来完成各测试器之间的协调。

发明内容

为了更有效地实现对通讯协议的一致性测试，本发明的目的是提出一种虚拟测试系统及方法。

为实现上述目的，通讯协议一致性测试中的虚拟测试方法包括步骤：

被测实现是根据地址判断测试包的来源；

用不同的被测协议实现对等层的网络地址实现多台虚拟测试器；

使用多台虚拟下测试器搭建逻辑测试结构，实现对被测协议实现软件(或系统)测试。

在保证有效性、精确性的前提下，仅使用一台下测试器就可以实现对被测协议实现软件(或系统)的测试。虚拟测试方法避免了各测试器之间复杂的测试协调过程，而且测试结果更可靠、更精确。

附图说明

图1示出多台下测试器的远程测试结构；

图2示出三个测试器的测试序列图；

图3是三个测试器的测试过程流程框图；

图4示出单台下测试器的虚拟测试结构；

图5示出单台测试器的测试序列图；

图6是单台测试器的测试过程流程框图；

图7是IPv6协议测试的物理拓扑；

图8示出Ipv6协议一个实例的逻辑测试结构；

图9是在链/离链测试例的测试序列图。

具体实施方式

在实际的协议测试中，被测实现是根据地址来判断测试包是从哪一个测试器来的。如当对链路层的协议进行测试时，被测链路层协议实现是根据链路层地址来判断测试包是从哪一个测试器发送来的；当对网络层的协议进行测试时，被测网络层协议实现是根据网络层地址来判断测试包是从哪一个测试器发送来的；当对传输层的协议进行测试时，被测传输层协议实现是根据传输层端口地址来判断测试包是从哪一个测试器发送来的。在实际的协议测试中本发明提出用一台物理测试器、不同的被测实现对等层的网络地址来实现多个下测试器的测试结构。

图4是用单台下测试器实现的对n层被测协议实现进行一致性测试的虚拟测试结构。其中VT1、VT2、VT3是由同一台测试器实现的多台虚拟测试器。对图2的三个测试器的测试序列，用虚拟测试法，可以用一台测试器实现。图5是对应图2的单台测试器的测试序列图。图6是此测试序列的测试过程流程框图。整个流程解释如下：

步骤S1，测试器做好准备，开始测试；步骤S2，TN发送测试数据包TP1给NUT；(TP1的目的地址是NUT的地址，源地址是VT1的地址)步骤S3，TN收到NUT产生的响应数据包RP1；(RP1的目的地址是VT2的地址，源地址是NUT的地址)步骤S4，TN判断收到NUT的响应数据包RP1是否与预期值相同；步骤S5，若TN收到RP1与预期值不同，则做出判断，测试失败或不确定；

步骤S6，若TN收到RP1与预期值相同，则发送测试数据包TP2给NUT；(TP2的目的地址是NUT的地址，源地址是VT2的地址)

步骤S7，TN收到NUT产生的响应数据包RP2；(RP2的目的地址是VT3的地址，源地址是NUT的地址)步骤S8，TN判断收到NUT的响应数据包RP2是否与预期值相同；

步骤S9，若TN收到RP2与预期值不同，则做出判断，测试失败或不确定；

步骤S10，若TN收到RP2与预期值相同，则发送测试数据包TP3给NUT；(TP3的目的地址是NUT的地址，源地址是VT3的地址)

步骤S11，TN收到NUT产生的响应数据包RP3；(RP3的目的地址是VT1的地址，源地址是NUT的地址)步骤S12，TN判断收到NUT的响应数据包RP3是否与预期值相同；

步骤S13，若TN收到RP3与预期值不同，则做出判断，测试失败或不确定；

步骤S14，若TN收到RP3与预期值相同，则做出判断，测试成功。

图4单台下测试器的虚拟测试结构与图1多台下测试器的远程测试结构具有相同的测试能力。而且，由图6的测试流程可以看出，虚拟测试法省去了图3中的测试器之间的测试协调过程。如在图3中的步骤S7，当TN2发送测试数据包TP2时必须通知TN1，TN3准备接收；在步骤S5必须通知TN1做出测试判断等。

虚拟测试法的优点可以概括如下：

使用虚拟测试法搭建的虚拟测试环境与同拓扑的实际测试环境(由多个物理测试器组成的测试环境)具有相同的测试能力，其优点在于：不需要搭建复杂的物理测试环境；不用考虑各测试器之间的同步问题，便于各测试器之间的协调和测试实现的控制；

消除了测试器非同步造成的错误，使测试更可靠；

由于各虚拟测试器的定时器都以同一系统时钟为基准，使与时间有关的测试序列更加精确。

以第三层协议IPv6为例来说明虚拟测试法的具体应用。在IPv6协议一致性测试中，可以用一台物理测试器，不同的IPv6地址来实现多个虚拟测试器。

下面用IPv6信息包的格式来说明如何实现虚拟测试器。IPv6的基本报头格式如下所示：

0 7 8 15 16 23 24 31

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| Traffic Class | Flow Label |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload Length | Next Header | Hop Limit |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

. Source Address(128 bits) .

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

. Destination Address(128 bits) .

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

任何IPv6数据包都必须包含这个基本报头，其中的Source Address字段是128位的源地址，表示发送这个数据包的结点的地址。因此，可以利用一台测试机器来发送测试数据包，通过数据包中基本报头的SourceAddress字段不同的地址值，使接受数据包的被测结点认为这些数据包是从不同的测试结点发出的，从而可以实现多台虚拟测试器对被测实现进行测试的效果。另外，对虚拟测试路由器还需要用特殊方法处理才能实现。在邻居发现协议中定义了一种ICMPv6的信息消息，叫做邻居宣告消息(Neighbor Advertisement)，节点在收到邻居请求消息或者其链路层地址改变时，应发送邻居宣告消息告知自己的链路层地址。在邻居宣告消息的格式中，有一个R字段，用以区分发送此消息的结点是主机还是路由器，若R字段为1，则说明此消息是路由器发出的；否则，说明此消息是由一台主机发出的。

邻居宣告消息格式如下所示：

0 7 8 15 16 23 24 31

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

| Type | Code | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

|R|S|O| Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

| |

. Target Address(128 bits) .

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

| Options |

+-+-+-+-+-+-+-+-+-+-+-+-+-

另外，在邻居发现协议中还专门定义了一个路由器宣告消息(RouterAdvertisement)，用以标识路由器发出的消息。路由器周期性地发送路由器宣告消息，用来宣告其可用性，以及用于配置链路和因特网参数，包含网络地址前缀、建议的跳限值及本地链路最大传输单元(MTU)，也包括指明节点应使用的自动配置类型的标志等。另外，路由器收到一个路由器请求消息以后应立即发送一个路由器宣告消息。

通过邻居宣告消息的R字段和路由器宣告消息可以使被测协议实现或系统辨识测试器是一台主机还是路由器。

如图8是IPv6某一测试例的逻辑拓扑结构。其实际物理测试拓扑就是图7所示的一个下测试器和一个被测实现通过底层服务连接起来的结构。被测实现(Implementation Under Test，IUT)是IPv6协议在被测结点(Node Under Test，NUT)上的一个具体的实现。被测结点可能是一台主机(Host Under Test，HUT)也可能是一台路由器(Router Under Test，RUT)。测试结点(Test Node，TN)是一台激发测试执行的设备，它可以是一台主机(Test Host，TH)也可以是一台路由器(Test Router，TR)。在实际的测试过程中，有这样一个事实：对IPv6协议的测试是在网络层进行的，被测实现仅仅根据数据包的网络层地址，即IPv6地址来确定包的来源和去处，根本不考虑数据包的链路层地址是什么。换句话说，在测试过程中，一个不同的IPv6地址代表一个不同的结点，一个被测结点收到的各个数据包，如果包的源IPv6地址不同，被测结点就会认为这些包是不同的源结点发出的，尽管这些包的源链路层地址可能是相同的。逻辑测试结构的实质就是用一台主机来模拟所有的测试结点，包括测试主机和测试路由器(如图8中的TH-1，TH-2，TH-3，TR-1，TR-2)。图8中所有的测试结点都被称作虚拟测试器，所有虚拟测试器的链路层地址都是相同的，但是它们都有不同网络层地址既IPv6地址，也就是说，在用同一台物理测试器发送测试包时，在测试包的IP层填入不同的源地址，接收到这些包的目的结点就会认为这些包是由不同的结点发出的。另外，通过邻居宣告消息的R字段和路由器宣告消息可以使被测协议实现或系统辨识测试器是一台主机还是路由器。站在被测实现HUT/RUT的角度来看，它把图8的拓扑当作它的实际网络环境。从而实现了用一台测试机器模拟多台测试机器(包括测试主机和测试路由器)的效果。

在邻居发现协议的测试中，有一个测试例是验证节点能否正确确定一个目的地址是在链还是离链。为了便于理解这个测试例，先把这个测试例的测试目的解释一下：邻居发现协议的标准文本RFC2461中规定，对于一个给定的目的地址来说，一个节点应该这样确定这个目的地址是在链的还是离链的，如果这个目的地址是一个链路本地地址，则节点认为这个目的地址是在链的(on-link)；如果这个目的地址是一个全球地址，且节点前缀列表中有一个前缀与这个全球地址相匹配，则认为这个地址是在链的(on-link)；如果这个目的地址是一个全球地址，节点前缀列表中没有前缀与这个全球地址相匹配且节点的默认路由器列表中至少有一个路由器，则节点认为这个目的地址是离链的(off-link)；若节点前缀列表中既无前缀与之匹配，路有器列表中也无路由器，则节点认为该目的地址是在链的(on-link)。节点如何确定一个目的地址在链还是离链可以用表1来表示：

表1：目的地址在链/离链条件

地址类型	有无前缀与之匹配	路由器列表是否为空	结论：在链/离链
地址类型	有无前缀与之匹配	路由器列表是否为空	结论：在链/离链	链路本地地址	◎	◎	在链
全球地址	有	◎	在链	链路本地地址	◎	◎	在链
全球地址	有	◎	在链	全球地址	无	有	离链
全球地址	无	空	在链	全球地址	无	有	离链
全球地址	无	空	在链	注：表中填为◎的项意味着可为任意情况

这个测试例的目的就是测试具体的实现是否与这样的规定相一致。

此测试例用到了三个虚拟测试器(图8中的两个虚拟测试主机TH1，TH2，一个虚拟测试路由器TR1)。在该测试例中，虚拟测试法得到应用。其测试过程可以由图9的测试序列图来说明。

测试过程1：

测试步1：TH-1发送数据包TP1(Echo request)给NUT，用本身的链路本地地址(fe80∷0210：5aff：fe63：af14)作为包的源IPv6地址。

测试步2：TH-1接受NUT的响应数据包RP1。

测试步3：TH-1比较检查收到的数据包，如果NUT返回的是请求TH-1链路层地址的邻居请求包，则可以确定NUT认为TH-1是在链的(on-link)。

测试过程2：

测试步1：TR-1发送数据包TP2(Router_Advertisement)给所有的节点(包括NUT)，用本身的链路本地地址(fe80∷0210：5aff：fe63：af15)作为包的源IPv6地址，这个路由器宣告消息包带有一个前缀选项。

测试步2：TH-2发送数据包TP3(Echo request)给NUT，数据包TP3的源IPv6地址是一个全球地址，这个全球地址与数据包TP2(Router-Advertisement)中的前缀相匹配。

测试步3：TH-2接受NUT的响应数据包RP2。

测试步4：TH-2比较检查收到的数据包RP2，如果NUT返回的是请求TH-2链路层地址的邻居请求包，则可以确定NUT认为TH-2是在链的(on-link)。

测试过程3：

测试步1：TR-1发送数据包TP4(Router_Advertisement)给所有的节点，用本身的链路本地地址(fe80∷0210：5aff：fe63：af15)作为包的源IPv6地址，这个路由器宣告消息包不带有前缀选项。

测试步2：TH-2发送数据包TP5给NUT，数据包TP5的源IPv6地址是一个全球地址。

测试步3：TR-1接受NUT的响应数据包RP3。

测试步4：TR-1比较检查收到的数据包RP3，如果NUT返回的是请求TR-1链路层地址的邻居请求包，则可以确定NUT认为TH-2是离链的(off-link)。

如果上述三个测试过程都按照预定的流程执行完毕，则可以认为协议的这一功能的实现是与标准文本相一致的，否则就认为该实现的这一部分有问题，与标准文本不一致。

从上测试例可以看到，用一个测试器TN成功地实现了三个虚拟测试器(两个虚拟测试主机TH1，TH2，一个虚拟测试路由器TR1)，用虚拟测试法实现了对被测主机或路由器(HUT/RUT)的测试。

Claims

1.一种通讯协议一致性测试中的虚拟测试方法，包括步骤：

被测实现是根据地址判断测试包的来源；

2.按权利要求1所述的方法，其特征在于所有虚拟测试器的链路层地址相同，网络层地址不同。

3.按权利要求1所述的方法，其特征在于所有测试节点都是虚拟测试器。

4.按权利要求1所述的方法，其特征在于还包括测试数据包报头的其它特征字段。

5.按权利要求4所述的方法，其特征在于由测试数据包报头的其它特征字段确定主机或路由器。

6.一种通讯协议一致性测试中的虚拟测试系统，包括N-1层服务提供者和N层被测协议实现，其特征在于测试器包括多台虚拟测试器。

7.按权利要求6所述的系统，其特征在于所述的虚拟测试器由一台物理测试器构成。