（计算机软件与理论专业论文）ttcn测试系统的设计和实现.pdf

摘要 摘要 卸她9 l t t c n ( t e s t i n ga n dt e s tc o n t r o ln o t a t i o n ) 测试方法是国际标准中协议测试框 架的一部分，最新的t t c n 一3 标准已经将这一方法推广到软件测试领域。从实际 应用的角度出发，将标准转化为一个现实可用的系统是一项复杂的工作。 通过研究测试框架标准，分析比较测试系统的理论模型，考察已有实现在应 用方面的不足之处，提出了一种新的测试系统实现，是为t t c n 虚拟机模式。以 这项设计为蓝本，从框架搭建到模块细化，再具体到每个模块的分析和设计实现 过程，研究并实践了“需求”一“设计”一“实现”的软件开发过程：实现中以 面向对象和可复用设计的思想为指导，通过“模式”的应用，提高了测试平台的 开发、维护、移植、扩充等特性。 已实现的t t c n 测试系统，既满足标准要求的执行语义，又根据实际需要，在 测试执行、调试模式等方面有创新特性，贴合用户的需求。最后通过介绍t t c n 测试平台的应用，证实了系统的实用价值。 此外，对执行机核心的调度和管理、内存对象组织、编解码实现、虚拟机框 架模式等几个方面的深入探讨，提出了较有价值的独创思想。 关键字 t t c n 协议测试软件设计设计模式 摘要 a b s t r a c t t t c n - t e s t i n ga n dt e s tc o n t r o ln o t a t i o n - i sap a r to fc o n f o r m a n c et e s t i n g m e t h o d o l o g ya n df r a m e w o r ki ni n t e m a t i o n a ls t a n d a r d s t h eu p - t o d a t et t c n 一3 s t a n d a r di n t r o d u c e st h i sm e t h o di n t o s o f t w a r e t e s t i n gf i e l d i np r a c t i c e ，t h e d e v e l o p m e n to fr e a l i z i n gas t a n d a r di sr e a l l yd i f f i c u l t b ys t u d y i n gt h es t a n d a r d so ft e s t i n gm e t h o d o l o g y , a n a l y z i n gt h et h e o r i e s o f d i f f e r e n tt e s t i n gs y s t e m s f i n d i n gt h ew e a k n e s s e so f r e a li m p l e m e n t a t i o n s ，t h e r ec o m e s an e wi d e a t h ev i r t u nm a c l i i n em e t h o d t or e a l i z et t c nt e s t i n gs y s t e m b a s e do n i t ，l o t so fw o r k sh a v eb e e n d o n eo nb u i l d i n gt h ea r c h i t e c t u r e ，d i v i d i n gi ti n t om o d u l e s ， d e s i g n i n ga n di m p l e m e n t i n ge a c hp a r to fi t i nt h ep r o c e s so f r e q m r e m e ms p e c i f i c ”一 “d e s i g n ”一“i m p l e m e n t a t i o n w e f o l l o wo b j e c t - o r i e n t e dd e s i g nm e t h o da n d c o d e r e u s ep r i n c i p l e s ，a p p l y i n gp a t t e r n st oi m p r o v ep o r t a b i l i t ya n ds c a l a b i l i t yw h i l e d e c r e a s et h ed i f f i c u l t yo fm a i n t e n a n c e t h i st t c nt e s t i n gs y s t e mn o to n l ya f f o r d st h et e s t i n gn o t a t i o n sw h i c ha r e d e f i n e di ns t a n d a r d s ，b u ta l s oi m p l e m e n t sn e wf e a t u r e sf o rt e s t i n ge x e c u t i n ga n d d e b u g g i n gt of i tu s e r b yi n t r o d u c i n gar e a lb l a c k b o x t e s tb a s e do nt h i ss y s t e m ，i t p r o v e sg r e a ta p p l i c a b l ev a l u eo f t h i ss y s t e m i na d d i t i o n ，b ya n a l y z i n gs c h e d u l i n ga n dm a n a g e m e n to ft h ek e r n e lo fe x e c u t o r , o r g a n i z a t i o no fo b j e c t si nm e m o r y , c o d i n g d e c o d i n gi m p l e m e n t a t i o na n dp a t t e r no f v i r t u a l m a c h i n ef r a m e w o r k ，i ta l s o0 f i e r sv a l u a b l ei d e a so nt h o s ef i e l d s k e y w o r d s t t c n p r o t o c o lt e s t i n g s o f t w a r ed e s i g n d e s i g np a t t e r n s 2 - 致谢 致谢 首先感谢我的导师蒋儿教授。他严谨的治学态度和细致的学生工作使我受益 匪浅，蒋老师从工程领域转入高校的研究环境，将工程方法和实践精神，特别是 实实在在做事的热情传给了我和周围的同学们，以此为基础的研究和丌发带来了 本文的诞生。 其次感谢我周围的老师和同学们。中国科学技术大学宽松的氛围，促成了学 术气氛的自由发展。在这样的环境罩，本科指导教师王恒才老师曾对我的学业发 展进行认真的指导；实验室的曾儿平老师、张辉老师、马良老师和胡澄宇、张卫 星、宁华中等师兄都曾与我在学术领域进行深入的探讨；黄浩东、段川以及李贺 禄、高翔等同学常常给我启发性的意见：本文从思想脉络至技术细节都与这些帮 助密不可分。 特别要提出感谢的是项目组的同学们：季向东、王继康、黄传动、刘小勇及 其他所有同学。软件工程叠梁架屋，非一人力所能及；软件开发技术上沟壑重重： 软件开发过程中繁琐细屑之事一言难尽。而项目组的同学们以踏实的作风和 团结的精神应对这一切，方堪战胜一切困难之利器。本文许多思想和实现都是团 结精神的产物，是集体智慧的结晶。 华为技术有限公司的同仁卢伟攀、陈晓波等给我提供了许多有益的技术意 见；中国科技大学华为研究所的叶国华老师、陈强师傅为我创造了良好的论文写 作环境，谨向他们致以真挚的谢意。 还要感谢所有9 5 1 1 和0 0 1 1 研的兄弟姐妹们，他们使我8 年的大学生活充满 乐趣。 对父母家人之感谢非“谢”字所能及。无从言表，只以意会。希望我所做的 一切能令他们开心。 杨敬峰2 0 0 3 0 5 1 9 1 引言 1 引言 1 1 研究背景 形形色色的社会需求带来了技术的演化，技术的演化又将需求向更深的层次 推动。虽然人为因素或主动或随机地影响着这个过程，但从历史的角度看，却无 法阻碍需求和技术螺旋式的前进。 二十世纪后半叶，电子信息技术占据了技术进步的一个高峰。对信息处理和 交换的需求也达到历史上空前的高度，不夸张地说，这个时期对信息处理和交换 的需求超过人们已知的历史上同类需求之和。 软件技术在上述背景下蓬勃发展。随着计算机硬件技术发展，从机器语言到 面向对象式的高级语言；从操作系统到高层应用软件；从网络互联到网络高层应 用，软件技术在处理信息和交换信息的各个方面，起着至关重要的作用。与此同 时，软件的丌发、维护、质量保证f 日益成为社会关注的方向，软件工程因此应 运而生。软件工程包括两个方面：以人为本的组织管理方面和以技术为本的研究 丌发运用方面，二者相互渗透和融合，形成不可分割的整体。 在已经进行的软件工程研究中，人们通常借鉴传统的管理学、市场学、经济 学原理，来解释“人本软件工程”中存在的问题，并借助实践中的成功方法以及 经验教训，设计更理想的组织管理方法并使之规范化! ；“软件工程”的技术方向 则没有知识系统可供借鉴，一方面在实践中摸索出了“需求一设计一( 验证) 一 实现一测试”的生产步骤，另一方面则在软件开发技术上不断采用更为自然和适 于理解的模型，以期能提高开发的可复用性、减少开发的失误、提升开发的效率， 顺序式程序结构一模块式程序结构一对象式程序结构一“模式”和泛型程序结构， 这个发展历程可作为软件工程技术发展一个例证。 1 2 作者研究的内容 作者在攻读硕士研究生学位期间，有幸参与导师蒋凡教授组织的一系列 “t t c n 4 测试平台”研发活动5 。短短的三年时间中，对上述软件工程研究方向做 1 无法以统汁数字证明这一命题。这一命题敬请读者看作是公认的假设。 2 成熟的研究和应用有c m m 等方法。 3 b i a r n es t r o u s t r u p 在c + + p r o g r a m m i n g l a n g u a g e 一书中指出，c 到c + + 发展过程中，程序设计结构经历了 “顺序式程序结构一模块式程序结构一对象式程序结构一泛式程序结构”的过程。 4 t t c n 是国际标准组织制定的用于进行协议测试的系列标准之一部分。 。这些活动包括：t t c n - 2 测试执行平台项目( 编译、编解码部分) ；a s n 1 编译器项且( 主体) ；t t c n 一3 测试执行预研项目( 主体) t t c n 3 测试执行平台项目( t m 管理端、t c i 接口) 都是以软件研究和开发 为目标的项目。 1 引言 一些研究，在理论上得到较大的收获，从实践中获得了不少经验，在软件工程的 技术方面，产生了有一定价值的独创性想法。 l ，通过对“测试系统”的需求分析，找出需求与实现之1 司的主要矛盾，分析 已有模型的不足，对t t c n 测试平台提出了一种新的实现方法： 2 ，通过t t c n 测试平台的设计和实现，从框架搭建到模块细化，再具体到每 个模块的分析和设计实现过程，研究并实践了“需求”一“设计”一“实 现”的迭代( i t e r a t i v e ) 过程： 3 ，通过t t c n 测试平台的实现，参考理论界提出的创建、结构、行为等模式， 探讨“模式”对程序可复用性的影响： 4 ，通过t t c n 测试平台的应用，找到了实现的系统与需求分析及框架设计之 间的差距及其原因，对“应用”与“需求”的迭代过程进行了总结分析。 以上这些内容，构成本文的主体和核心。t t c n 标准作为被实现的对象，其本 身的需求、特点和应用也是研究的主要内容6 。 本文用了必要的篇幅描述t t c n 标准，这是为t t c n 测试系统的实现必须进行 的准备活动，从冗长而无味的标准中萃取其核心部分，是既琐碎又繁重的工作。 然而，如同研究c 编译器要研究c 语言的定义( 甚至需要研究“古怪”的c 语 言程序) 一样，研究软件测试不研究测试语言的国际标准，则难免“取巧”之嫌。 1 3 本文结构 本文在结构上分成三个部分 第一部分，介绍t t c n 标准及其应用，对使用t t c n 标准进行测试平台进行需 求分析，获得系统需求分析与制定实现方案之间的关系，在充分比较已有的系统 实现的优缺点的基础上，提出一种新的t t c n 测试平台的实现模型，。 第二部分，在介绍构建t t c n 测试平台的框架的同时，从t t c n 测试平台实现 的角度探讨了“需求”一“分析”一“实现”的迭代过程，结合创建、结构、行 为等模式的应用，就其中若干具体问题研究了程序的可复用性。 第三部分，介绍t t c n 测试平台的应用，通过一些t t c n 测试平台的实际用例 探讨“应用”一“需求”的迭代过程。 1 4 本文说明 本文正文采用小四号宋体：t t c n 程序采用小五号l u c i d ac o n s o e 字体；数 据结构和算法c + + 语言形式表示，并采用五号t i m e s n e w r o m a n 字体；其它文本 6 t t c n 标准作为协议和软件“测试”标准，本身恰恰构成软件工程的一个研究方向，是本文的一个副产 品。 1 日l 言 ( 如测试同志、m p 文件等) 采用小五号l u c i d ac o n s o l e 字体。请读者在阅读时 注意加以辨别。 文中出现的图示与章节号同序，如第二章第2 节中的图示用“图2 2 1 ”、“图 2 2 2 ”等表示。所有表示类结构的图都由r a t i o n a lr o s e 工具制作：第四章抽象 测试套一节中的图都由t e l e l o g i et a u 工具的t t c n e d i t o r 制作。 对f 文内容必要的解释放在脚注中，所有直接引用( 包括文字和图表) 以参 考文献形式附在文末。 2t t c n 测试撬 2t t c n 测试系统 2 1 引言：定义及编写 本章介绍t t c n 测试系统的概貌。本节将对涉及到协议工程学和标准制定组 织使用的一些最基本的术语 i s 0 9 6 4 6 3 加以介绍，以便于读者阅读。行文中尽 可能使用术语的中文形式，如：协议定义。但对于个别使用方便且好记的英文缩 写，则直接使用其英文形式，如：t t c n 。 协议定义针对特定协议，指出协议需要实现的功能和性能，并不明确要求协 议的实现方式。一般为l 岍、i s o 等标准组织制定。 协议实现针对特定协议定义，以某种方式实现其要求的功能和性能，一般为 达到与相同协议的其它实现互联、互通的目的。 t t c n - 2 t r e e a n dt a b u l a rc o m b i n e dn o t a t i o n ( 在中文文献中有时称为树 表结合表示法) t t c n 一3 t e s t i n ga n dt e s tc o n t r o ln o t a t i o n ( 新出现的标准，未见f 式 译法，可试译为测试和测试控制表示法) a s n 1a b s t r a c ts y n t a xn o t a ti o no n e ( 抽象语法记法) a t sa b s t r a c tt e s ts u i t e ( 抽象测试套) e t se x e c u t a b l et e s ts u i t e ( 可执行测试套) a s p a b s t r a c ts e r v i c ep r i m i t i v e ( 抽象服务原语) p d up r o t o c o l d a t au n i t ( 协议数据单元) t c pt e s tc o o r d i n a t ep r o c e d u r e s ( 测试协调过程) m t cm a s t e rt e s tc o m p o n e n t ( 主测试部件) p t cp a r a ll e lt e s tc o m p o n e n t ( 从测试部分) i u t i m p l e m e n t a t i o nu n d e rt e s t ( 被测实现) s u t s y s t e mu n d e rt e s t ( 被测系统) 2 2 协议测试7 系统 人类构造的规模最大的系统可能是拥有1 0 亿个用户的全球电信网络。当你 从北京打电话到斯德哥尔摩时，这个电话可能经过了2 0 多个系统，包括本地交 换机、国际问交换机、卫星系统和传输系统等。每个这种类型的系统大约要花费 1 0 0 0 人年的成本来开发，而其中大部分是软件开发工作。 令人惊异的是，系统如此复杂，并且涉及到不同的人、公司和国家，为什 么它能够正常工作呢? 主要原因在于整个网络( 即网络体系结构) 的每一个协议 7 本文关心的协议测试局限于致性测试范围内，如无特别说明，下文中多以“协议测试”指代“协议一 致性测试” 2t t c n 涮试统 均由一个唯一的组织i t u ( 国际电信联合会) 进行标准化。i t u 规定了该网络中 各种类型节点i 、日j 的协议以及这些协议的精确语义 j a c l 9 9 9 。 协议测试是针对指定协议的具体软( 硬) 件实现，在一致性、互操作性、性 能等方面，对协议实现进行测试，目的是从黑盒测试”的角度来验证协议实现是 否符合协议定义以及是否安全可靠。协议一致性测试主要针对协议定义的功能部 分( 而很少考虑性能部分) 。通过一致性测试，可以了解一个具体的协议实现是 否以及在多大程度上实现了协议定义要求的功能：对那些协议定义未明确要求的 可选性功能，又做出了怎样的实现。协议一致性测试的研究，是伴随协议实现出 现的，现在一般归入协议工程学范畴。 为了测试一个特定协议实现，一般需要将该实现放置于特定的协议测试系统 中。国际标准组织专门制定了协议测试系统的框架。抽象层次上，协议测试的系 统结构如图2 2 1 i s 0 9 6 4 6 1 所示。 被测试的协议实现位于被测系统中的第n 层，测试系统通过协调上测试部件 ( u t ) 和下测试部件( l t ) 对i u t 进行测试，协调动作由测试协调过程( t c p ) 完成，n 层协议下方有更底层的协议支持l t 与i u t 之间的连接。 图2 2 1 一致性测试系统结构 。黑盒测试是软件测试之一种方法，对被测对象不需要了解其实现机理 2t t c n 测试统 这样的测试系统，有两个问题需要重点解决。第一个问题是l t 与i l t 之间 的通讯，由于r l t 是多样的，需要专门实现一组底层适配软件，它们中的每个负 责与一个il 1 进行通讯。第二个问题是l t 与l t 之间的协调工作，p , p t 【n f 3 实现 t c p 。 针对上述两个问题，在t t c n 标准中提出了四种测试模型：本地测试方法、 分布式测试方法、协调测试方法和远程测试方法。它们的配置结构见图 2 2 2 i s 0 9 6 4 6 1 。 本地测试方法中( 图2 2 2 - a ) ，u t 和l ，r 同处于测试系统中，相互协调易于 实现。这种方法主要针对硬件的测试。 分和式测试方法中( 图2 2 2 - b ) ，l t 和u t 分布于测试系统和被测系统中， 通过t c p 的协调对i l t 进行测试，这种方法可被应用于测试整个协议栈。具体的 测试中，可能需要对协议栈的每一层由底向上分别进行测试。由于t c p 的通讯不 能经过被测协议栈，若要实现t c p ，需要额外开辟一条通讯通路( 比如被测协议 是t c p i p 网络协议，则需要以r s 2 3 2 等其它通路来实现t c p ) ，这种方法实现代 价较大。 图2 2 2 四种测试方法的系统结构图 2t t c n 测试统 协调测试方法( 图2 2 2 - c ) 可以看作是对分御式测试的一种改进。l 1 和0 t 同样分布于系统的异i f , 0 ，t c p 不用显式实现，而是被隐式地通过p d u 传递到l t 一端。这样的测试系统适于测试中日j 层协议( 当上层l t 已经被验证为有效时) ， 而且1 c p 的实现被封装于测试套的p d u 中。 远程测试方法( 图2 2 2 - d ) 忽略t c p 过程。它只能针对不需要u t 的i u t 系统。 几种方法中，除了分布式方法外，t c p 都不难实现。要测试的对象大多为中 间层协议，或是为不需要u t 的i l t 实现，所以测试系统只要支持协调测试方法 和远程测试方法即可。这样便解决了t c p 实现的问题。 l t 与i u t 的通讯，对不同的i u t ，它所处的位置可能不同，一般都需要特定 的适配软件来实现与i u t 的通讯。通过实现一个适配软件框架，将l t 与该框架 的通讯固定下来。这个适配框架则便于每个具体的适配软件嵌入其中，这样，对 新的i u t 系统，只要实现新的适配软件并嵌入框架中即可。对适配软件的详细讨 论在第三章l l 节中进行。 实际测试中，u t 和l t 内部又可能出现若干并发的测试组件，通过创建和协 调这些组件，可以实现更为复杂的测试。测试标准中将这种情况称为多方测试， 如图2 2 3 i s 0 9 6 4 6 2 。这些测试组件的创建、组件之间的相互通讯都给测试 平台的设计和实现带来了更多需要解决的问题。 图2 2 3 多方测试结构 2t t c n 澍试系境 测试过程自动化对测试平台的易用性提出了要求。通常，需要一个集成测试 环境。测试套的收集与测试结果的保存通过数据库来管理。测试者可以通过集成 测试环境远程( 或本地) 控制执行部件，指挥执行部件完成测试操作。执行部件 通过底层适配软件完成与i u t 的交互。在多方测试时，集成测试环境可以控制和 协调多个执行组件，并根据各个执行组件返回的结果形成判决。 测试系统组成如下： 集成开发管理界面 执行部件 底层适配软件 测试套数据库 其中测试套的生成和测试套的组织管理不属于本文研究的范畴，本文的重点 集中在前三项特别是执行部件的研究上。 2 3t t c n 标准的沿革 a s p s 至i 一峰u tr 一”。“p 。1 ： 图2 3 1 测试系统结构 在图2 3 1 所示的测试系统中，测试套的表示和测试执行器的执行方法是其 核心。国际标准组织借鉴软件测试的成熟方法和经验，结合协议测试的具体特点 制定出一系列形式化的标准，即t t c n 表示法”。t t c n 表示法在两个方面对协议测 试进行了界定。首先，测试套必须采用t t c n 表示法，即对任何特定协议的测试， 需要用t t c n 表示法来描述测试套；其二，执行部件要正确理解和执行t t c n 表示 法的语义，即对于任何用t t c n 表示法描述的测试套，执行部件要按照t t c n 定义 的语义执行动作。 早期的t t c n 表示法以树表结合形式( g r ) 为主，机器识别形式( m p ) 为辅。 9 早期t t c n 标准是国际标准化组织1 9 9 1 年开始制定的 ocp 骼 唑 p 一罐 |警h t；毒，_ 一! ；一 e s w 一梦一 钟 竺 p 一盍；丰一 2t t c n 滑试抗 面向用户的测试套和测试用例的书写使用表格及树状形式，这种形式可以被唯一 映射为机器识别的m p 格式。执行部件通过分析m p 格式的文本文件，确定执行的 语义动作。 用一个简单的例子 s c h 2 0 0 0 来晚明g r 格式、m p 格式和执行语义。该测试例 以表格和树状组织相结合的形式，描述了一个具体的测试过程，即：p r o d u c e r 发送一个o f f e r 消息，然后等待接收i n d i c a t i o n 。如果收到的是i n d i c a t i o n ， 则判决为通过( p a s s ) ；如果收到其它报文a d v e r t i s e m e n t ，则回到接收 i n d i c a t i o n 的状态；如果在指定的时问内( 通过定时器设置) 没有收到 i n d i c a t i o n ，则判决为失败( f a i l ) 。 测试套g r ( 部分) t e s lc a s ed y n a m i cb e h a v i o u r 1 n 一：l i c a t k - i i 、；a i d ： ，：一t h e l * , v i s e f a i l d e s c r i p t i o n 。t e s t t h e d f e ra 州m 、t i c a b o r t $ “l u e r k e o fb e h a i c t 1 r n rl a b e lb g h a v i o u ro e s c d p t i o nc o n s t r a i n t sr v r d i c tc 1 m m e n t s 协e a l 、b e l t 脚e e l - , a v i o , , a c t i v a 懈o t h e m i s e f a i l p r e a m b l e o ： l tp r o d s e n d , o f f e rl a g e , ： tp a r t e l s e r , i c e s e t ； a l t j 轴o 1r e c e i v e ( i n d i c a t i o n2 4 h i tp ；j r c e i $ e r y , i t e ，s t o l ：i ： v e r d i c ts e t ( p a s s ； p o s l a m l ) t e t ， 、 nl t p r o d r e c e i v e , i a d v e r t i s e m e n t a n y ) ： g o t oa l l ： 2 5 基于t t c n 方法的测试工具系统 自t t c n 标准的诞生，学术界对标准的研究和软件界对标准的实现没有一天 止步。在t t c n 软件的实现方面，则有t e l e l o g i c 、t e s t t e c h 等公司的表现比较 出众，他们的t a u 、t t r u n 系列软件，被广大协议制造商和运营商所采用。这些 系统的共同特点是，采用了“编译”一“编译”一“执行”的实现方法。 “编译”一“编译”一“执行”( c c e ) 方法的具体做法是，先把m p 格式 或t t c n 一3 格式的文件编译成c 、c + + 、j a v a 等中间语言，再进一步利用中间语 言的编译器，编译成可执行文件或c l a s s 文件，最后在操作系统或j a v a 虚拟机 上运行。这种实现的好处是显而易见的，它通过一次转化将t t c n 语言转成中问 语言，以后的工作都可以利用已有的工具完成。为了应用方便，开发商往往提供 集成环境( i d e ) 给用户以便于操作。前面所举的例子，用t e l e l o g i c 公司提供 的t a u 软件，可以生成如下的c 语言代码( 部分) 。 2 t t c n 潮试系统 n to c l n d i c a t i o n 一1 ( i c e c b + e c b ) 逍! 型j 试f 硼”( ：b n d i c a t i o n 一 ：? 例t 二j 化_ ；7 廷：? i n r c l i n e = ： i n ti c a i l o w s n a p s h o t = f a l s e ； g c i v a l u e + l c c o m p a r g s = n u l l ： i n tl a b e l l l = 2 ： x 、h i l e ( 1 ) j 7 循珥1 t 铋i 【满t ：冬7 皤! 。烩雕崩；、，j 譬f l j v c m k f r a m e ( ) ： s w i t c h ( 1 c l i n e ) c a s el ：g 、弟条- i ；f f _ f , j 厅蝣执 1 ，沌惑l c l 。i n e 娃 j 蟛 化玻i l c o b j e c t = o f f e r _ l a r g e b u i l d ( ) ；构造发送报之 i c s e n d ( g c l tp r o d d ，i c o b j e c t ，1 ，”l t p r o d ”，”o f f e r ”) ；发j l i c s t a r t t i m e r ( g c tp a r c e l s e r v i c e d ，i c t i m e r d e f v a l u e ，1 ， ”t _ p a r c e l s e r v i c e ”，) ；，m 定时器 l c l o g ( g c i l o g m a t c h ”l 6 t t a b ：i n d i c a t i o n 一1 ”) ； l 球 ；，。 i c l i n e + + ； i ：意，波r ! b l e a k ，f 斫以终：f 丈执f j c a s e2 ：第一：籀i f f 1 , j i c o b j e c t = i n d i c a t i o n2 4 h b u i l d ( ) ；，构造娥f t 芟牧报史 i f ( ! ( 1 c r e c e i v e ( g c l tp r o d d ，l c o b j e c t ) ) ) ：牧：娜：他个j 之h , d i c a t k m2 4 h ，l0 奠筑i 条m i ，j l c l o g ( g c i l o g n o m a t c h ，”2 t x t t a b ：i n d i c a t i o n 一1 ”) ； i c l i n e = 3 ； b r e a k ； ) 接收5 ：l j l n d i c a t i o n 一2 4 h ，取消前m l 没的定时器，波西劓弛乃p a s s i c o b j e c t = i c g e t r e c e i v e o b j e c t ( g c l t _ p r o d d ) ； i c c a n c e l t i m e r ( g c t p a r c e l s e r v i c e d ，2 ，”t a r c e l s e r v i c e ”) ； i c r e m o v e o b j e c t (g c l t _ p r o d d ，2 ，l 丁- p r o d ”，”i n d i c a t i o n ”) ： i f ( ! l c s e t v e r d i c t ( i c p a s s ) ) r e t u r ni c t e s t c a s e e r r o r ； e l s e ( 1 c l o g ( g c i l o g v e r d i c t ，”t t t a b ：l n d i c a t i o n _ l ”) ； ( 钥、略) ) 1 3 - 2t t c n 测试* 藐 2 6t t c n 测试平台( 虚拟机) 系统设计 c c e 方法在实际应用中存在易用性低的问题。这是因为，从t t c n 格式文本到 c 文本的转化过程虽然简单，但是经过这个转化过程后，用户需要进行比较多的 编码和配置工作。而这些编码和配置工作都是和被测系统的底层接口相关的，所 以不能在c c e 过程中实现。这样，实际的操作过程如图2 6 1 左边所示，转化过 程中增加了人为的因素。 图2 6 1c c e 方法与v 方法的比较 另一方面，c c e 方法难以支持对t t c n 语言级的调试。转化编译后的可执行文 件直接运行于操作系统上，调试将在该语言一级实现。这给调试一甚至在运行时 动念修改t t c n 变量一带来很大的难度。 根据对系统的分析，在易用性方面要尽可能地满足用户的需求，为了实现系 统的独立性，把底层适配模块以软件的形式独立出来，这样，般的用户便不需 要再去编写或修改代码；为了支持可调试性，需要在软件级实现编译执行功能， 用户可以象操作一般的调试工具那样对t t c n 测试套进行编译、执行、调试等操 作。 具体到t t c n 编译、执行的实现，比较虚拟机( v 、i ) 方法、解释器( ) 方法，以 及自己设计的虚拟机平台( v m p ) 方法。v m p 方法指编译、执行、调试过程集中 于统一平台上( 有别于i d e ，是集中而不是集成) ，编译结果以内存对象方式保 存，执行、调试通过操作这些内存对象完成，平台则提供易用的用户界面。与 v m 方法的显著区别是，不设立中间格式，直接在内存中完成编译一执行的过程。 如图2 6 1 右边所示。 这种方法与v m 、c c e 等方法的比较见下表 方法效率、易用扩充移植可靠状态 c c e低低高 高中 已有 v m p中 高 中中高已有 v m 高 中高高高无 2t i c n 测试系统 从上表的比较结果可以看出，综合而言，v m 方法将是各方面符合实际应用情 况的最理想方法( 如果辅以集成丌发环境更佳) 。从技术上来说，v m 方法需要解 决的是中问格式表示这一问题。v , _ i p 方法和c c e 方法各有千秋，但是从需求的主 要方面来考虑问题，v m p 方法更适合于实际应用。而且，在v m p 方法的基础上， 如果可以把编译的内存对象存为文件，以及把文件“原样”恢复出来，就会过渡 为一种类v m 的状态，或者说具有v m 的特征。解决这个问题，技术上其本质是一 个对象的深层c l o n e 问题。所以，从实际丌发角度来说，实现v m p 方法，既可以 在实现后立刻加以应用，又可以为将来升级改造为v m 方法留有余地，这就是综 合考虑几种方法后，选择v m p 方法作为实现方案的原因。解释器方法已经应用于 t c l 测试中，下节将会对这种方法进行的介绍。 2 7 其它测试方法 由于历史原因，在t t c n 标准丌发完成之前，网络( 不只局限于i n t e r n e t ) 协议的实现已经得到实际应用，这时对协议的测试采用各种非标准化的方法。t c l 因其灵活性和易用性，成为其中一种成功的方法，也因而被称为“业界测试的事 实标准”。 t c l 是一种脚本语言，常用来进行系统集成和自动测试【罗b s c 。t c l 有以下 特点： ( 1 ) 变量无类型。使用t c l 编程，不必事先定义数据结构，变量的数据结构、 含义和用法到运行时才确定：函数调用时，不必关，t l , 参数类型，只需确定参 数数值。编程更简单灵活。 f 2 ) 语句集成度高。t c l 的内部命令集中包含大量测试中常用的组件，这样， 一条t c l 命令可以完成几十行c c + + 语句的功能。使测试程序更简单，开发 时间更短。 ( 3 ) 解释型语言。测试器在测试过程中，经常要修改测试用例的数据，若采 用c c + + 编程，每次修改后，都要重新编译，再进行测试。而使用解释型语 言，可以无须编译，修改完数据后直接测试，使测试工作变得更轻松。解释 型语言的好处还在于所有的t c l 命令通过解释器翻译成不同操作系统可以接 受的指令，因此，t c l 程序与操作系统无关。无论测试器使用p c 机，w i n d o w s 环境，还是使用8 6 0 评估板，v x w o r k s 操作系统，t o r n a d o 开发环境，用t e l 编写的测试程序和测试用例无须修改，都可运行。 ( 4 ) 命令集扩展容易。无论是已有的组件，还是用t c l 编写的测试段，都可 以方便地生成t e l 的扩展命令。由测试段生成的测试命令，可以作为测试前 缀或测试后缀，快速构造新的测试程序。 t c l 语言可以用组合的方式表示所述的t t c n 语义，也就是说，t t c n 描述的 测试例基本上都可以用t c l 描述出来。t c l 测试方法运用t c l 语言进行测试，这 样可以方便地利用已有的t e l 解释器。 2t t c n 测试缆 下面是一个t c l 用于i p v 6 版i c m p 协议的测试脚本例子。 f o r s e tjo ) $ 1 0 1 n c rn s e n d c o n t lh u e ) e 1s e c o n t in u e s e tp r e c l o c kc 1 1 c k s s e tt l m e r0 w h i l et s “m e r s t m a x s e tt m a x $ t i m e ) 1 f $ t i m e s t m in ) s e tt m ins t i m e 1 n c rt o t a l $ t i m e p u t s ”r e p l yf r o ms d e s t ，b y t e s = s b y t e st i m e = $ t i m em s ” 1d v 6 - d e le r e $ p a c k e t i d n c rn r e c v b r e a k 1p v 6 _ d e le t e $ p a c k e t i d s e tt i m e r e x p rs t i m e r + 1 - 1 6 2t 丁c 灞试统 2 8 小结 再回过头考虑不同的方法对系统的影响，人们会发现各种方法的目的是解决 同一问题，不过，它们遵从的哲学思想决定了它们将服务于不同的用户。 c c e 方法实质上是u n i x 哲学的产物。在t & r “设计和实现u n i x 系统及c 语言 的时候，遵从的哲学思想是“小而灵活”。在这一思想的指导下，l n i x 系统中存 在数量繁多而使用灵活的各种工具，从s h e l l 到开发工具、系统工具、应用工具 等等不一而足。当用户要实现特定的应用时，不需要从顶层到底层完整地实现， 只需要利用已有的工具，辅以实现特定的功能即可。这种哲学思想的核心完全体 现了软件复用的精神，今天仍然在u n i x l i n u x 以及g n u 团体中广泛传播。同时 应该注意到，这个层次上的软件复用对使用者提出比较“高”的要求，至少它要 求使用者具有h a c k e r 精神，某种程度上是一种不折不扣的探索精神，熟悉并有 志于掌握和使用各种已有的工具。 v m ( v m p ) 方法“实质上更符合应用哲学，它适应般用户对易用性要求高的 心理，通过自主实现( 而非借助已有工具) 底层虚拟机，在上层尽可能地为用户 提供各种需要的功能。这种层次化设计帮助用户解决底层的实现问题，减少了用 户的负担，同时也增加了用户对虚拟机的依赖性。 解释器方法类似于v m 方法，在底层操作系统平台上提供解释器平台，统一 1 0 t & r ：k e nt o m p s o n ，u n i x 系统的实现者；d e n n i sr i t c h i e ，c 语言的发明者。二人合作开创了u n i x 纪 元。 “j a v a 是虚拟机方法的个典型应用 2t t c n 澍试系抗 运行不同的解释脚本。这种方法比较易于实现，但是其问题在于，解释执行的过 程中难于实现对执行脚本的动态语义检查。这样如果执行脚本存在特定的静念语 义问题，很可能要到执行时才能发现，也就降低了实用价值。换句话说，解释器 方法是牺牲了一定的实用性为代价，达到易于实现的目的。 几种不同的哲学思想之问本无优劣可言，至少作者所处的层次尚不足加以判 断。但是从软件工程的角度，分析一个软件系统究竟采用何种哲学思想，需要对 用户的需求加以仔细地考察，从用户所处的地位着想，选择适当的哲学方法彳能 最大限度地使其得以合理的应用。这也正是软件产品”出现的初衷。 ”u n i x 哲学下的软件更像软件艺术品；应用哲学下的软件更像软件商品都是人类社会所不可或缺的。 3t t c n 一3 测试平台的设计和实现 3 t t c n 一3 测试平台的设计和实现 3 1 引言：协议实现和测试 协议实现和协议测试是协议工程的两个重要内容。形式化的协议标准是协议 实现和协议测试的出发点。根据形式化的协议标准构造抽象测试套( a t s ) ，使 用t t c n 语言描述对该协议各项功能的测试过程。经过某种方式的转化，抽象 测试套成为可执行测试套( e t s ) ，这样可以被测试部件( t e s t e r ) 加载和执行。 同时，根据协议标准实现的协议作为被测实体i u t 被嵌入在被测系统s u t 中， 与t e s t e r 连接形成整个测试系统。t e s t e r 执行e t s 后，由测试判决分辩被测协议 实现是否达到了协议标准的要求。这个过程可以用图3 1 1 形象地表示。 图3 1 1 协议实现和协议测试流程 抽象测试套如何转化为可执行测试套，可执行测试套的形式是什么样的，可 执行测试套又是如何被执行的，协议测试标准将这些问题留给具体的测试实现。 本章将结合t t c n 测试平台，回答这一系列问题。