1 / 191

第三章 树表描述语言

OSI/ITU 组织颁布的协议一致性测试基本框架和方法标准 (ISO/IEC 9646 (ITU X.290 series) 由五大部分构成，树表描述语言 (Tree Tabular Combine Notation or Testing and Test Control Notation) 是其中的第三部分，即 ISO/IEC 9646-3 。. 第三章 树表描述语言. TCP. UT. PDUs. LT. IUT. PCO. PCO. ASPs. UnderLying Service. 图 3.1 一致性测试体系结构 CTMF. 3.1 协议一致性测试框架.

silver
Download Presentation

第三章 树表描述语言

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OSI/ITU组织颁布的协议一致性测试基本框架和方法标准(ISO/IEC 9646 (ITU X.290 series)由五大部分构成，树表描述语言(Tree Tabular Combine Notation or Testing and Test Control Notation)是其中的第三部分，即ISO/IEC 9646-3。 第三章 树表描述语言

  2. TCP UT PDUs LT IUT PCO PCO ASPs UnderLying Service 图 3.1一致性测试体系结构CTMF 3.1 协议一致性测试框架

  3. IUT： 在一致性测试中一个被测试部分（Implement Under Test简称IUT）是一个OSI协议实体。 SUT： IUT所在的系统称为被测试系统（System Under Test简称SUT）。 UT和LT： IUT有一个上层测试（Upper Test）接口和下层测试(Low Test)接口。

  4. PCO： 控制观察点（Points of Control and Observation简称PCOs），UT和LT通过控制观察点对系统进行测试。通常LT是远程可访问接口，因此IUT定义一个远端的PCO，即底层接口被设置在远端 。 输入输出队列： 通信被认为是异步通信，所以在每一个PCO都对应两个队列（FIFO），一个是输入，另一个是输出。

  5. ASPs： IUT和UT之间通过抽象服务元语（Abstract Service Primitives简称ASPs）进行通信。 PDUs： 从概念角度，IUT和LT通过协议数据单元（Protocol Data Units简称PDUs）交换数据； 两者的联系： 从实际角度，PDUs 采用ASPs 对基本服务动作进行编码，即PDUs不是直接进行交互，而是CTMF 允许根据PDUs的编码进行交互，即在一个抽象的测试中使用PDUs进行交换，所以ASPs与PDUs不再加以区分。

  6. TCP： 测试协调过程（Test Coordination Procedures 简称TCP）来协调LT和UT的动作，这在LT和UT是两个独立的过程时十分必要 。 测试方法分类： 在CTMF中测试方法可分为局部的、分布的、协调的和远程的测试几种 。它们的主要不同是对LT和UT的协调以及对它们的控制与观察程度不同。

  7. Stable state Test state End state (Test Body) End State (Verification) postamble preamble Verification Test Body 图3-2 测试例方案 执行过程状态机

  8. 图3.2是一个基于CTMF的测试过程。一个IUT首先由测试例的触发条件激活，并从稳定状态进入被测试状态；经过测试用例在测试体中运行，进入结束状态；如果执行的结果不唯一，则需要经检查步分析结果中存在的问题，从而进入End State（Verification）状态；根据检查结果提出反馈，进入下一次的测试阶段。在上面的测试过程中，如果测试例的结束状态相同，则直接进入到下一次测试过程。 执行过程描述

  9. 结合CTMF的X-协议执行脚本如下： MTC（Master Tester Component）首先通过产生PTCs(Parallel Tester Components)对测试系统进行初始化。对于X-协议产生一个低端PTC(LT)和一个高端PTC(UT)。 通过IUT，低端PTC建立一个与高端PTC的一个X-连接。出于简单考虑，我们假定一个N网络连接已经建立，即不会出现一个X_CONNECTrequest被拒绝（该假定是为了解释TTCN特性）； 3.1.2 X-协议一致性测试

  10. 低端PTC发送一个数据包，该数据包将通过IUT在高端PTC返回，这个数据包将在一个指定的时间间隔内返回，该过程重复多次；低端PTC发送一个数据包，该数据包将通过IUT在高端PTC返回，这个数据包将在一个指定的时间间隔内返回，该过程重复多次； 在完成数据传递后，低端PTC断开，并发送它的最初结果给MTC后，计算最终结论并终止测试。

  11. 配置和相关描述： LT将用N-SERVICE元语和N-PDUs加以说明，分别用N_DATArequest和CR_PDU等进行说明；// UT将用X-SERVICE元语加以说明，使用X_CONNECTrequest等进行说明；//

  12. TTCN提供了一个最小的功能集合 提供能够通过测试系统发送和/或接收ASPs的能力； 提供嵌在ASPs中PDUs的描述能力； 说明ASPs在PCOs被发送和/或被接收的次序；

  13. TTCN采用以下方法提供上述功能： 声明ASP和PDU的类型； 声明PCOs 说明实际的ASPs和PDUs 说明行为实例 本测试例的使用有两种意义 ： IUT在限定的时间内通过X-协议，接收并返回指定数量的数据包。

  14. 测试例与测试套： 为了测试IUT，我们需要建立一个仿真测试事件集合或交互行动序列。这个用于描述测试任务的事件或行动的序列称为测试例（test case），一个特定协议的测试例集合称为测试套。 TTCN说明： TTCN就是一种用于说明测试例的符号集，它可以建立一个实际被测系统的抽象模型，并说明测试例的执行过程。抽象的测试例包括所有的IUT所支持的被测目标。 3.2 测试系统行为描述

  15. TTCN表现形式： 在ISO/IEC 9646-3中定义了两种TTCN的图表，一种是图形符号，另一种是语义符号。图形符号采用表格的形式描述测试例的内容。这种表现形式比较直观，所以称为TTCN-GR，它适合于测试例的分析与设计。语义符号采用巴氏克斯范式Backus-Naur Form简称BNF)形式说明TTCN测试例，所以它更适合于计算机处理，所以把这种形式的表示称为TTCN-MP(TTCN-machine processable)。在本教材中主要采用TTCN-GR来描述测试用例。

  16. 定义： 一致性测试框架下的测试只关心控制与观察点上的交互，所以系统行为用一颗树来表示比较自然，这棵树就称之为行为树。 行为树语义： 在行为树中，每一个树枝表示两个协议状态之间可能发生交互。在TTCN中，为了与表格形式一致，把行为树的分支随着时间逐层横向缩排，并写在一个表框内。 3.2.1 行为树

  17. Tree J B C A D I E F G H H B C F D G E J I A Time Time 图3-3 TTCN行为树

  18. 行为表： 在TTCN中，所有的行为用动态行为表来说明。 行为表类型： 测试例动态行为表 测试步动态行为表 缺省动态行为表 3.2.2 TTCN行为描述

  19. 动态行为表构成： 行号、标签、行为描述、约束条件、结论、注释 声明行与声明： 在一个动态行为表中，声明行在行为描述栏中定义，它用于说明事件发生顺序 。在声明行中描述测试系统的行为，如发送和接受ASPs等等

  20. 声明分成三个不同的类型 事件 行动 条件 事件 一个声明的发生称为事件。声明成立也称为事件匹配。

  21. 两类事件： 输入事件（input events）：是一个到达指定PCO的ASP，或者是指定CP（协同点coordination points简称CP)的消息。 时间事件(timer events)：是一个协议时间结束时刻。 事件包括： RECEIVE OTHERWISE TIMEOUT

  22. 行动 （活动）： 有时声明总是成立的，也就是说它是可执行的，我们把这种声明称之为活动 。 行动类型： SEND IMPLICIT_SEND //内部交互，如Keep alive包 ASSIGNMENT_LIST TIMER_OPERATION GOTO

  23. 条件 声明行也可以包括条件声明，即布尔表达式，把这个声明行称为条件声明行。如果没有事件匹配，也就没有行动被执行，除非声明行中的条件的值为True。如果一个声明行不包括条件，则为非条件声明行。 一个TTCN条件就是布尔表达式： BOOLEAN_EXPRESSION 例如： L! N_DATArequest [B=1]

  24. 替换： 在同一缩排的声明行的集合中，有相同父节点的节点称为可替换声明行，简称替换。 例如： 在图1-1中 (A,B), (C, D, E), (F, G), (I, J) 和 (H)是所有的替换。 说明规则： 由于一个替换集合中不同替换的前后次序是十分重要的，所以必须把所有事件和条件在一个没有激活的行动之前声明。 3.2.2.2 执行与匹配

  25. 行为树的执行 行为树的执行从树根开始。首先第一个替换集合被循环执行，每一个替换均以他们在集合中出现的先后次序被赋值。如果一个替换不成功，则执行下一个替换；如果替换成功，则执行该替换的下一级替换集。在执行到叶结点后，该替换集合的循环停止，这时将得出结论。

  26. 例子 首先被执行的是替换集合（A,B）。如果A成功，则下一个替换集合（C,D,E）被激活；如果A不成功，B成功，则执行终止。现在假定C和D不成功，而E成功，则下一个替换集合是（I,J）。 注意：如果在任意一个替换集合中没有声明是成功的，则执行将“死锁”。

  27. 数据类型的含义： TTCN所包含的数据类型用来说明行为描述中所涉及到的数据，如在ASPs中数据类型说明等等。 数据类型种类： 简单类型定义表 构造类型定义表（一个类型定义使用一个表） 3.3 TTCN数据类型和取值

  28. TTCN的数据类型如下： HEX STRING//16进制位串，如`0F'H BOOLEN INTEGER BIT STRING//位串，如`1001'B OCTET STRING/ASN.1 16进制串，如`0F'O Character String//IA5String ENUMERATED//枚举类型 OBJECT IDENTIFIER//对象标识符，由标准化组织定义的整数序列，如ttcn-standard OBJECT IDENTIFIER ::= { iso (1) standard (0) 9646 3 } REAL//用科学计数法表示的实数，如10*2-2 NULL//空 其它ASN.1类型 3.3.1 预定义数据类型

  29. 取值： TTCN预定义数据类型的值与ASN.1数据类型的值具有相同的取值范围，参见ASN.1。 简单用户定义类型 简单用户类型的定义，通常是对预定义数据类型或前面已经定义的用户定义类型的进一步说明，这些说明往往是施加一些约束。 TTCN的简单用户定义类型采用简单类型定义表对数据类型进行描述，并可以在测试套中的任何地方使用 。

  30. TTCN有专用的表来定义构造类型数据。构造数据如同简单数据类型一样可以在测试例的任何一个地方使用。但他们主要在ASPs和PDUs的子构造中使用。具体细节参见ASPs 、PDUs和CM取值。 3.3.4 构造类型

  31. TTCN支持异步通信模型，在测试组件和被测软件之间的通信是通过控制和观察点（PCOs）实现的，而不同测试组件之间是通过测试协作点（Coordination Points简称CPs）进行交互。 3.4 PCOs和CPs

  32. 队列模型： 在通信模型中，我们将使用队列模型描述PCOs和CPs。每一个PCO/CP有两个先进先出的队列，与程序中的队列不同，这里的队列没有边界。 队列构成： 一个队列用于存放发送（SEND）ASP的对列 另一个用于存放接收（RECEIVE）ASP信息 两个队列在一个PCO或CP进行连接 一个用于PCO/CP的输入，另一个用于PCO/CP的输出。 3.4.1 通信模型

  33. 发送一个ASP，是通过SEND行作把一个ASP追加到PCO队列中去。PCO的SEND队列是无约束长度的队列，所以它总可以接受来自于LT或UT的消息。发送一个ASP，是通过SEND行作把一个ASP追加到PCO队列中去。PCO的SEND队列是无约束长度的队列，所以它总可以接受来自于LT或UT的消息。 3.4.2 发送一个ASP

  34. 接受的含义： 一个有效的接受从RECEIVE队列中取出ASP，并检查其内容。 一般接受有两个步骤 ： 接收ASP 检查其内容 3.4.3 接受(receipt)一个ASP

  35. 测试套中使用的PCO类型必须在PCO类型声明中进行。测试套中使用的PCO类型必须在PCO类型声明中进行。 每一个PCO类型声明需要下列信息： PCO类型名 与PCO通信的对象LT或UT 3.4.4 声明PCO类型

  36. 使用规则： 如果测试套仅使用PCO，则PCO名在TTCN声明中可以省略。如果有多个PCO和CP被使用，则PCO和CP必须在TTCN声明中加以说明。 3.4.5 使用PCOs和CPs

  37. 定义： 在每一次替换循环的最初，从输入队列中取出PCO或CP的当前值称为一个快照。 执行过程： 每一个声明的值取决于这个快照，而不是PCO或CP队列的实际值。这样替换被执行的时间将会冻结，即阻止两个快照之间的事件发生。通过这种方法一个ASP、PDU或CM的到达只有在快照更新后才被登记。 3.4.6 PCO和CP快照

  38. CPs在CP声明表中声明 每一个CP需要下列信息： CP名 CP角色 3.4.7 声明CPs

  39. TTCN行为树中的主要行为之一是通过PCO/CP向IUT发送ASPs或PDUs。下面我们讨论发送(SEND)行为的描述和使用。TTCN行为树中的主要行为之一是通过PCO/CP向IUT发送ASPs或PDUs。下面我们讨论发送(SEND)行为的描述和使用。 3.5 发送语句

  40. 发送行为声明允许一个测试套说明一个通过PCO发送的ASP类型。发送行为声明允许一个测试套说明一个通过PCO发送的ASP类型。 发送语句格式如下： PCO_Identifier ! ASP_Identifier SEND3[QUALIFIER]1 [ASSIGNMENT_LIST]2 [TIMER_OPERATION]4 3.5.1 发送ASP

  41. 执行过程： 如果一个条件QUALIFIER是FALSE，则过程停止，并且发送语句为假；如果QUALIFIER是TRUE，则ASSIGNMENT_LIST被执行。最后TIMER_OPERATION 被执行。 3.5.2 执行发送语句

  42. 例子： 例如：L! N_DATArequest //送网络数据请求服务原语给名为L的PCO L! N_DATArequest [B=1] //如果B=1，则执行SEND L! N_DATArequest [B=1] (X:=3) //如果B=1，则把X赋值为3，并且执行SEND

  43. 发送描述： 通常一个PDUs 数据被包含在ASPs中，在声明SEND语句时并不显式说明。然而，并不是所有的协议有服务定义（如X.25），所以TTCN提供了显式声明PDUs的语句格式，而不用ASPs 。 一个发送PDU的语句如下： PCO_Identifier ! PDU_Identifie 该语句中还可以包含其它辅助信息，这些信息与PDU数据一同被处理，他们的说明格式与标准SEND语句相同。 3.5.3 发送一个PDU

  44. 发送语句也可以在CP上发送一条协同信息(Coordination Message简称CM)。格式如下： CP_Identifier ! CM_Identifier 该语句中还可以包含其它辅助信息，这些信息与CM数据一同被处理，他们的说明格式与标准SEND语句相同。 3.5.4 发送协同信息

  45. 接收语句是用于描述一个测试组件从测试系统IUT接收消息事件的基本语句。接收语句是用于描述一个测试组件从测试系统IUT接收消息事件的基本语句。 3.6 接收语句

  46. 接收语句的语法如下： PCO_Identifier ? ASP_Identifier RECEIVE1[QUALIFIER]2 (ASSIGNMENT_LIST)3 [TIMER_OPERATION]4 3.6.1 接收ASP

More Related