专利名称：一种分布式测试组件框架系统及测试组件透传方法
技术领域：
本发明涉及电子或通信领域的测试技术，特别是涉及一种分布式测试组件框架系统以及应用于所述系统的测试组件透传方法。
背景技术：
RPC(Remote Procedure Calling远程过程调用)是一种较为通用的技术，在测试领域中常采用RPC技术以实现测试组件的共享重用。目前，较为成熟的RPC有微软公司的COM/DCOM(Component Object Model组件对象模型/Distributed Component Object Model分布式组件对象模型)、OMG(ObjectManagement Group，国际对象管理组织)的CORBA(Common Object RequestBroker Architecture，通用对象请求代理系统结构)以及XML(Extensible MarkupLanguage可扩展标记语言)-RPC。这三种技术均能实现跨进程函数调用及跨机器远程调用。其中，COM/DCOM与CORBA实现RPC的机制比较接近。
请参阅图1，是COBRA-RPC过程示意图。本地110欲调用远端120实例即对象，首先本地客户通过命名服务等机制引用远端对象；然后，由本地ORB(Object Request Broker，对象请求代理)检测出所述对象存在于远端120，并依据IIOP(Internet Inter-ORB Protocol，因特网ORB间协议)协议向远端0RB发起调用请求；最后，远端120响应调用请求并按照IIOP协议要求返回调用结果。这样，一次完整远程过程调用完成。当然，本地和远端是相对来讲的，也可以实现远端客户对本地对象的调用。
众所周知，COM/DCOM或CORBA调用系统比较庞大，而通信产品的目标机单板受内存、CPU等资源限制，通常不能驻留上述庞大的系统，因此需要根据实际情况自行开发。但是，COM/DCOM或CORBA系统的开发较为繁琐，需要较大的资金和人力资源的投入，因而使得COM/DCOM或CORBA在测试组件共享重用领域的应用受到限制。因此，在实际应用中常采用相对简单的XML-RPC技术方案。
请参阅图2，通常，XML-RPC调用请求包括三类数据被调函数名称、调用参数及类型。本地210采用XML脚本语言表述RPC调用语句，借助于HTTP协议将调用请求发送到远端220；远端220接收、解释并执行调用请求；之后，远端220依照发送请求过程的逆过程将调用结果返回至本地210。虽然XML-RPC系统相对于COM/DCOM或CORBA系统较为简单，但是实现RPC时需要借助于HTTP协议及XML脚本语言的支持，因此其应用范围也受到限制。
请参阅图3，另一种实现RPC的现有技术是由IBM基金支持的共享源码项目STAF(Software Testing Automation Framework，软件测试自动框架)系统。STAF提供了一套易伸缩、支持跨平台、跨系统的框架系统，可方便地管理自动测试用例与测试环境。
STAF系统包括STAF-Daemon进程、服务分发层、对外接口和服务。其中，服务指的是每个可重用的共享件。所述服务又分为内部服务与外部服务。所述内部服务是内嵌于Daemon的内核服务，包括数据管理服务、同步服务等；所述外部服务是由DLL(Dynamic Link Library，动态链接库)接口装入的用C/C++语言扩展的服务，或由代理接口导入的Java服务与Rexx服务。所述STAF系统支持本机调用和跨机调用。
STAF端点启动STAF-Daemon进程，STAF系统的STAF-Daemon进程接收来自外部的服务请求，并由服务分发层完成服务的分类与分发。如果被调用的是内部服务，由STAF-Daemon进程直接完成服务调用，返回调用结果；如果是外部服务，则通过DLL接口或代理接口完成服务调用，并返回调用结果，最后调用API(Application Programming Interface，应用编程接口)以释放内存。
STAF系统在测试领域中，同COM/DCOM和CORBA比较具有下述优势其一，STAF对外接口与测试中常用到的脚本语言(如Java、C/C++、Rexx、Python、TCL、Perl等)融合得较好，可以直接用脚本实现服务扩展，因而易于将服务接入STAF系统中；其二，STAF易于编程并且支持跨平台，是轻量级的解决方案，适合分布式测试；其三，STAF适用于低配置工作环境，因而可用于通讯领域中低配置的目标机单板。
尽管相对于COM/DCOM和CORBA，STAF系统具有诸多优势，但是采用STAF实现RPC仍然不可避免的存在下述缺陷首先，STAF系统仅支持基于线程方式的服务扩展，而不支持基于进程方式的服务扩展。但是在实际应用中，通常纳入共享的测试服务常以复杂的形态出现，常需要跨进程协调，因此导致STAF系统的应用范围受到限制。
其次，STAF系统未针对专门语言做封装，使得远程调用构造参数的过程较为繁琐。而且，执行调用操作后，相关内存资源不能被自动释放，需要调用API来释放，导致STAF系统对外提供的扩展接口复杂、使用不便。
最后，STAF系统中同在本机的服务调用时延较长、效率较低，经测试得知一次完整的服务请求与服务响应的过程耗时2.4秒。单次调用时延过长、调用效率偏低将导致STAF系统难以用于服务调用比较频繁的场合。
发明内容
本发明提供一种分布式测试组件框架系统及测试组件透传方法，以解决现有技术中STAF系统存在的不支持基于进程方式的服务扩展及测试效率低下的问题。
为此，本发明解决技术问题的技术方案是提供一种分布式测试组件框架DTCF系统，包括DTCF软总线以及注册到DTCF软总线上的DTCF节点；所述DTCF节点用于编码或解析服务请求和服务响应，将服务调用本地化，并响应服务请求；所述DTCF软总线用于传送DTCF节点之间的服务请求和服务响应。
所述DTCF节点包括底层通信层、自动路由机制层、过程透传和实体透传协议层以及编程语言适配接口层；所述自动路由机制层用于通过节点标志实现各DTCF节点之间互相访问；所述过程透传与实体透传的透传协议层用于实现编解码和服务调用；所述编程语言适配接口层用于提供本地化的扩展接口。
所述底层通信层具有用于本机DTCF节点之间的共享内存通信方式，和/或用于跨机的DTCF节点之间的跨机通信方式。
所述的分布式测试组件框架系统进一步包括注册于DTCF软总线上的网络节点，用于跨机通信时转发服务请求或服务响应。
所述过程透传和实体透传协议层配置编解码规则，以及服务请求和服务响应的服务协议。
所述自动路由机制层配置自动路由机制，自动发送服务请求以及自动返回服务响应。
所述编程语言适配接口层包括Python、TCL、C、VBA或Delphi语言的适配接口。
提供一种分布式测试组件透传的方法，应用于分布式测试组件框架系统，包括步骤1)第一DTCF节点发送服务请求至DTCF软总线；2)DTCF软总线发送所述服务请求至第二DTCF节点；3)第二DTCF节点解析所述服务请求、将服务调用本地化并进行响应，并发送服务响应至DTCF软总线；4)DTCF软总线将所述服务响应返回至第一DTCF节点。
所述步骤2)中DTCF软总线采用共享内存通信方式发送服务请求；所述步骤4)中DTCF软总线采用共享内存通信方式发送服务响应。
所述步骤2)具体包括DTCF软总线发送服务请求至第一网络节点；第一网络节点通过采用跨机通信方式的DTCF软总线发送服务请求至第二网络节点；第二网络节点通过DTCF软总线发送服务请求至第二DTCF节点。
所述步骤1)中第一DTCF节点依据节点标识方法指定第二DTCF节点。
所述节点标识方法采用“机器别名.节点别名”作为节点标志。
步骤1)中的服务请求包括输入服务、打印服务、异步运行、同步运行、计算表达式、格式化异步调用和格式化同步调用。
所述步骤1)中第一DTCF节点依据编解码规则编码服务请求；所述步骤3)第二DTCF节点依据编解码规则解码服务请求，并编码服务响应。
所述编解码规则支持通用基本数据类型、复合数据类型和扩展数据类型。
所述通用基本数据类型包括nil、int、long、float、string基本数据类型；所述复合数据类型包括tuple、list、dict数据类型；所述扩展数据类型包括Exception object、Pending object。
所述服务请求和服务响应是基于DTCF交互协议的调用服务。
所述调用服务采用未决变量透传规则传递未决变量。
相对于现有技术，本发明的有益效果是其一，由于DTCF(Distributed Test Component Framework，分布式测试组件框架)系统既可以支持进程方式的服务扩展有可以支持线程方式的服务扩展，因而应用范围广。在实际应用中，对于象Win32、Linux、Unix这样的多进程体系平台，DTCF系统能支持共享内存通信方式以及某种对外的通信方式；对于非多进程体系平台，DTCF系统可以提供某种对外的通信方式。
其二，DTCF透传方法便于使用。由于DTCF系统的编程语言适配接口层可包括Python、TCL、C、VBA或Delphi语言等多种语言的适配接口，因而无需将服务调用语句统一到某一种固定语言格式，因此可使得服务调用语句与当前语言环境融为一体，易于使用。
其三，在DTCF系统中服务调用的效率较高。这是由于DTCF是精简的协议，本机采用共享内存通信方式实现跨进程服务调用过程中，DTCF系统固有的时延很低，经测试得知，在Win98 PII机器上所述时延仅在0.1毫秒级别，相比STAF体系，服务调用效率提高20倍。因而使得各测试组件之间不仅可按进程方式实现有效隔离，而且可保证服务调用的高效率。
其四，DTCF系统协议包括编解码规则和服务协议，而所述编解码规则和服务协议容易开发并快速稳定，是轻量级的协议。
其五，基于DTCF系统的调用服务适用于测试领域。由于所述服务可以动态定义，因而在DTCF系统中既可以用各种语言脚本，又可以用格式化带类型的命令来实现服务调用。因此DTCF系统更适于在跨系统、跨语言的环境下使用，DTCF协议也同样可自然地融合于测试脚本系统中。
图1是COBRA-RPC过程示意图；图2是XML-RPC结构示意图；图3是STAF结构示意图；图4是DTCF系统本机调用结构示意图；图5是DTCF系统跨机调用结构示意图；图6是DTCF系统协议分层示意图；图7是DTCF系统编解码过程示意图；图8是DTCF系统本机节点通信示意图。
具体实施例方式
本发明提供一种分布式测试组件框架(DTCF)系统以及用于所述系统中的测试组件透传方法，实现调用服务和共享服务。
请同时参阅图4和图5，DTCF系统包括DTCF软总线和注册于DTCF软总线上的两个或两个以上的DTCF节点。
其中，DTCF节点为应用程序(即进程)，每个应用程序构成一个DTCF节点。所述DTCF节点是DTCF系统中调用服务与共享服务的基本单位。挂接(即注册)在DTCF软总线上的DTCF节点，用以完成下述功能以RPC方式直接调用DTCF软总线上其他任意DTCF节点对外共享的服务，以使自身程序完成特定的测试功能；以及将自身完成的特定测试功能封装为可供其他DTCF节点调用的共享服务。
所述DTCF系统中的多个节点既可以处于同一个机器上(参见图4)，也可以分布在不同机器上(参见图5)。其中DTCF节点之间使用特定的通信方式连接。
所述DTCF软总线为各种通信方式，是DTCF系统的基础。对于处于本机的多个DTCF节点，DTCF软总线为内部进程通信机制，如共享内存通信方式等。对于跨机的多个DTCF节点，DTCF软总线包括本机内部进程通信机制，以及跨机通信方式。
可以理解，DTCF系统中各个DTCF节点是对等接入的，即各DTCF节点在DTCF软总线上所处的位置是对等的，不存在必然的依赖关系与归属关系。换言之，某DTCF节点挂接到DTCF软总线上是否合法，并不依赖于其他某一个或某些DTCF节点是否挂到DTCF软总线上或者是否合法，而仅仅依赖于DTCF软总线存在与否以及正常与否。当然，在实际应用中，上层为了组织业务的需要，可以对某些DTCF节点附加逻辑关系，使其具有互相依赖的关系。例如，某DTCF节点提供通用的数据库服务，另有两个DTCF节点负责测试业务，后两者必须依赖于前者才能完成功能，而前者并不依赖于后者。
图4所示的DTCF系统包括DTCF软总线420以及挂接在其上的处于同一个机器的三个DTCF节点411。DTCF软总线420固定使用内部进程通信机制如共享内存通信方式来实现共享服务和调用服务。
图5所示的DTCF系统包括DTCF软总线以及挂接在其上的DTCF节点。所述DTCF节点包括位于本地510的DTCF节点511和NET节点512，以及位于远端520的DTCF节点521和NET节点522。所述DTCF软总线包括分别位于本地510和远端520的DTCF软总线513和DTCF软总线523，以及本地510和远端520之间的DTCF软总线530。
其中，DTCF软总线513和DTCF软总线523固定使用共享内存通信方式等内部进程通信机制。而本地DTCF节点510和远端DTCF节点520之间不能直接通信，因而DTCF软总线530是由NET节点512和NET节点522以TCP/IP通信方式实现跨机连接。
所述跨机的DTCF节点之间不能直接通信，因而需要通过NET(网络)节点来实现。所述NET节点也是标准DTCF节点，具体指的是在跨机通信时用于消息收发的NET程序。通常，DTCF系统中每台机器上有且仅有一个NET节点，与所述NET节点连接的相邻机器的DTCF节点也必须是NET节点。所述相互连接的NET节点构成DTCF系统中本地和远端之间直接连接的唯一途径。换言之，在一个DTCF透传系统中，任意两个相邻的机器之间只有一种通信方式，并且同一时间只存在一个双向连接。
为支持以上特性，NET节点需要同时支持多个方向的不同类型的通信连接，因而需要抽象各类通信方式，以点对点方式接入。这样，通信的上层与下层具有较好的分离，能支持按插拔方式(即软件的即插即用)新增某项通信方式。
在实际应用中，所述网络通信方式不仅仅局限于TCP/IP通信方式，也可采用串行接口、并行接口通信等方式。
请参阅图6，是图4和图5所描述的DTCF节点具备的分层结构。所述DTCF节点包括底层通信层、自动路由机制层、过程透传和实体透传协议层以及编程语言适配接口层。其中，底层通信层之上叠加自动路由机制，使各DTCF节点之间能通过节点标志互相访问，所述节点标志包括机器别名和节点别名；自动路由机制层之上叠加支持过程透传与实体透传的透传协议，所述过程透传和实体透传协议层之上为编程语言适配接口层，用于为各类编程语言提供本地化的API扩展接口。根据DTCF节点所处位置，底层通信分为共享内存通信以及跨机通信两种方式。编程语言适配接口层包括Python语言适配接口、TCL语言适配接口、C语言适配接口以及其他语言适配接口。
由于所述DTCF节点必须在DTCF软总线上注册后才能正常使用，并且DTCF节点之间需要通过节点别名来相互标识与访问。因此在注册时就需要为各个DTCF节点指定节点别名，DTCF节点之间相互调用服务时，必须根据节点别名来指定被调用的DTCF节点。所述节点别名在一个机器上必须唯一。
DTCF系统中存在源节点(即调用服务节点，或称服务发起者)和目标节点(即被调用服务节点、或称为即服务响应者)。所述源节点和目标节点必须是挂接在同一个DTCF软总线上的DTCF节点。
DTCF系统中用“机器别名.节点别名”标识目标节点。仅当源节点与目标节点同在一个机器上，机器别名方可省略，即“机器别名.节点别名”省略成“节点别名”。
下面以节点别名分别是A与B的目标节点和源节点为例，来说明目标节点的标示方法。
假设目标节点在机器A上，源节点不同在本机(机器A)上，则需以“机器别名.节点别名”来标识目标节点，若在B节点调用A节点的服务，调用语句为machineA.A.iNum＝3machineA.A.function(machineA.A.iNum)若目标节点和源节点在同一个机器上(机器A)，若B节点调用A节点的服务，则省却“机器别名”仅以“节点别名”来标识目标节点，调用语句改为A.iNum＝3A.function(A.iNum)上述机器别名由配置文件(下称DTCF配置文件)指定，DTCF系统中每台机器的DTCF软总线初始化时都读入DTCF配置文件并使之生效。并且，同一DTCF系统中不同机器使用相同的DTCF配置文件，从而使得每台机器上各个DTCF节点都能唯一标识同在一个DTCF系统中的其他机器的节点。
可以理解，同一台机器上的DTCF节点，仅在注册时定义其节点别名，也即DTCF节点别名是在某项服务启动时动态注册的。同一机器的各DTCF节点按顺序注册，而处于不同机器的DTCF节点可在同一时刻被注册。而且，同一台机器上各DTCF节点所注册的别名必须是本地唯一的，若在本机中重复注册相同的节点别名，则导致注册失败。但是，在同一个DTCF系统中不同机器上的DTCF节点别名可以相同。
本发明所述的DTCF自动路由机制在遵循上述目标节点标示方法的基础上，结合预设的通信功能，使服务请求能够自动到达DTCF目标节点，并使服务响应能顺利的返回给DTCF源节点。所述预设的自动路由通信功能具有如下特点每次调用的服务请求与服务响应消息包所经历的路径是确定的，并且服务响应路径是服务请求路径的逆序。
例如machineA上的A节点调用machineB上的B节点，服务请求的路径是machineA.A->machineA.Net->machineB.Net->machineB.B，服务响应的路径是machineB.B->machineB.Net->machineA.Net->machineA.A。
所述自动路由机制，当服务请求与服务响应路径上各DTCF节点无异常时，服务请求及服务响应可以被自动地准确传递。也就是说，每个DTCF节点不仅能发送服务请求与服务接收响应，而且也具备自动转发非起点或终点的消息包的功能。
所述服务请求与服务响应使用预设的通信路由。所谓预设指的是对于本机通信，可固定使用共享内存方式；对于跨机通信虽不限制特定的通信方式，但在一次完整的服务请求与服务响应过程中所使用的通信方式必须是固定的，并且所述通信方式需在服务调用前预设。所述跨机的通信方式由DTCF系统搭建者预先定义，而不可由DTCF系统动态选择。
如图6所示，在DTCF透传协议的上层是各类语言的适配层，在适配层中需将服务调用本地化，也就是服务调用与当前语言风格融为一体。由于DTCF系统的协议要求DTCF节点在提供服务时，能解释执行某种风格的脚本，或调用指定函数，因此要求每种语言的适配接口都包含解释机制，即脚本解释器，只有当该语言支持的DTCF节点不对外提供服务，只调用他人服务的情况时除外。
由于Python、TCL或VBA语言已经是DTCF封装的脚本语言，因而可直接借用所述各语言的解释机制，只需再支持DTCF透传协议即可。但对于C/C++、Delphi等编译语言，需要用户构造脚本解释器以支持服务函数的注册及被解释调用。
需要指出，DTCF透传协议对上层使用何种语言做适配不作限定，但为了实现基本功能，建议本协议的实现者要提供接口以适用Python、TCL、VBA这3类脚本语言以及C++等编译语言。
请参阅图7，图6所示的DTCF透传协议将源节点的服务请求按照特定的编码规则编码为特定流格式，然后通过自动路由机制发送到目标节点，目标节点将特定流格式解码还原成原始服务请求，再根据请求内容完成特定服务，并按相同编码规则将结果编码后按自动路由返回给源节点，由于服务请求帧的格式中已标注到达目的地的选路规则，因而服务响应可按服务请求过程的逆过程原路返回，源节点再将响应解码还原成调用结果值。
所述DTCF透传协议包含两部分内容，其一是编解码规则，其二是服务请求与服务响应的交互协议(下称服务协议)。
本发明提供的DTCF编解码规则支持下述三大类共10种数据类型通用基本数据类型nil、int、long、float、string，这些数据类型可以兼容多种语言(如C/C++、Delphi、Python、TCL等)的基本数据类型。
复合数据类型tuple、list、dict，分别是参数集、列表与字典扩展数据类型Exception Object，Pending Object其中，nil类型表示值为空或无效，与Python语言的none类似；int表示32位带符号整型；long表示64位带符号整型；float是双精度浮点数；string是Pascal风格字串；tuple是参数类型；list是缓冲区类型；dict是字典类型。其中tuple、list与dict这3种类型的含义以及取值范围与Python语言中的对应类型相同。Exception与Pending为支持服务透传运算而扩展的，前者用来表述调用异常的结果描述，后者用于变量远程透传被使用时辅助变量生存周期的自动管理。
DTCF解码实际上是编码的逆向还原，因而所述编码规则实际也就是解码规则，在此统称为编解码规则。各个DTCF透传变量(即上面所述10种数据类型的变量)编码后均由“格式指示”与“内容指示”两大部分组成，格式指示是一个字节的ASCII码，如int类型的格式指示是“i”，其16进制值是0x69，再如string类型的格式指示是“s”，其16进制值是0x73。内容指示部分除了nil类型缺失外，其他类型都具备，其中int类型只有一段，其他类型都有两段。
DTCF支持的10种数据类型中有3种复合数据类型与2种扩展数据类型，这5种数据类型可以包含多个子成员。所述子成员的类型是这10种类型中的任何一种，并可以层层嵌套，例如一个tuple变量中有一个list子成员，该list子成员下又可以包含其他成员。各种数据类型的编码方法见表1表1 数据类型的编码规则
需要指出的是，DTCF协议不涉及底层通信，所以在本发明中，DTCF协议假定底层通信层已提供较可靠的自动路由消息收发功能。
DTCF服务协议是点到点协议，仅描述一次服务调用过程中，服务发起端与服务响应端的相关命令格式及需要完成功能操作。DTCF服务协议详细描述如下DTCF服务协议提供调用服务包括import(输入)服务、打印服务、异步运行、同步运行、计算表达式、格式化异步调用、格式化同步调用，共7项服务。所述7项服务都涉及源节点与目标节点，前者发出服务请求，后者根据请求执行相应操作并响应操作结果。这些请求中，打印服务、异步运行服务，以及格式化异步调用等服务无需目标节点返回结果值，此时，源节点发出服务请求后不等待；而其他服务需要在指定的时间内返回结果，否则被认为服务超时出现异常。
服务请求的命令格式固定为tuple类型数据(request_id，args)，服务响应的格式也固定为tuple数据(rep1y_id，args)。其中request_id与reply_id是int数值，args可以是DTCF支持的各种数据类型变量，当结果返回是多数值时，采用一个tuple数据，各返回数值表达成该数据的子成员。所述7项服务的规格参见表2表2 服务规格
以上服务调用的请求(如表2中命令9的参数args)与响应(如表2中命令5、7、10中的result)，还可以传递未决变量。所谓未决变量即为类实例，其存在于目标节点，无法经过编解码传递到源节点，因此需使用Pending类型来表达。也就是说，由于运行环境的差异，某DTCF节点的类实例变量仅在源节点参与运算，其内容无法传递到其他DTCF节点，因为DTCF编解码规则不支持类实例透传。因此，Pending变量在源节点真实存在，在其他DTCF节点仅作为映射对象存在，是只记录源节点路径，但无实际内容的空壳。
所述Pending变量的传递遵循下面规则每个Pending变量对应一个真实变量，仅在真实变量所在的DTCF节点被创建。已创建的Pending变量可作为DTCF系统中任何DTCF节点而被传递。而且，Pending变量仅在源节点参与运算，在其他节点不能参与运算而仅用于传递。另外，任何Pending变量在一个DTCF系统中具有唯一标识，其标识名称包括两类信息，其一为所对应的真实变量所在的DTCF节点别名，其二为对应真实变量的ID号，通常，所述ID号即为变量的地址值。
所述Pending变量采用引用计次来实现生存周期的自动管理。当有Pending变量存在时，其所对应的真实变量就被锁定，即不能被释放。而且，当Pending变量每新增一个相邻引用，即被源节点(Pending量对应真实变量所在的DTCF节点)相邻的DTCF节点引用，所述Pending量的引用计次就加1；如果引用结束，则引用计次减1。当不存在相邻引用时，所述Pending变量自动被释放。此外，为使Pending量在DTCF节点任意传递时仍保证生存周期的自动管理，在该Pending量新增一个相邻引用时，本地Pending量的引用计次也累加；而结束引用时，则递减；当不被引用时就自动释放并通知源节点，源节点据此减少对该Pending量的引用计次。以上服务请求与响应中可自由选择是否要支持Pending变量传递，不同的DTCF节点可选择支持或不支持。当不支持Pending变量的节点收到Pending量时，首先通知源节点该Pending被拒绝接收，源节点据此校准引用计次，然后引发PendingNotSupport异常(不支持Pending)。
请参阅图8，以Python语言适配接口为例描述本机两个DTCF节点的通信过程，即DTCF系统实现RPC的过程。本机存在两个Python应用程序也即两个DTCF节点dt1与dt2，底层通信层由DTCF软总线提供自动路由与共享内存通信功能，Python语言适配接口对DTCF透传协议做了本地化封装，使得远程调用句式可融合于Python固有语法。
Python适配接口对上层提供的接口包括dtcf.regist(NodeName，ver) #注册本节点别名，版本号dtcf.deregist(NodeName) #去注册节点dtcf.eval(command，PeerNode，WaitTime)#远程调用，让对端运行command脚本CRemote(PeerNode)#把远端DTCF节点映射为本地模块dtl程序(dt1.Py)设计如下from pydtcf.py_remote import dtcf，CRemotedtcf.regist(′dt1′，′1.0′)
deftest(sMsg)print′in test function.′print sMsgreturn′It is OK′dt2程序(dt2.py)设计如下from pydtcf.py_remote import dtcf，CRemotedtcf.regist(′dt2′，′1.0′)R＝CRemote(′dt1′)print dtcf.eval(”test(′remote call example′)”，’dt1’，5)print R.test(′remote call example′)实际调用过程中，先运行dt1程序，再运行dt2程序。
运行dt1程序。该程序启动后通过调用dtcf.regist接口函数将自身应用程序注册到DTCF软总线上，注册别名为dt1；然后定义测试函数test(sMsg)，该函数可被共享以供其他DTCF节点调用。
运行dt2程序。该程序启动后同样通过调用dtcf.regist接口函数注册到DTCF软总线上，注册别名是dt2；然后调用CRemote类定义创建远端模块类实例(如上面语句R＝CRemote(′dt1′))，其参数指明被映射模块为dt1，这样，对端dt1节点就映射到dt2程序中，成为dt2的本地模块R；之后调用模块R的test函数，实际等效于远程调用对端模块的test函数。此步骤也可以直接调用dtcf.eval接口完成相同功能，用参数指明要求对端执行的脚本、对端别名、远程调用等待时长，例如上面语句print dtcf.eval(”test(′remote call example′)”，’dt1’，5)。
可以理解，不处于同一个机器的两个节点的交互过程类似于本实施例所描述的本机两个DTCF节点交互的过程，只是需要搭建好底层通信机制，至于其上的透传协议与适配接口则是相同的。另外，对于多节点之间相互调用，可同理地将各节点注册到DTCF总线上，每次调用时指明对端节点即可。
需要指出的是，本例中DTCF协议经过本地化语言适配具备下述特点首先，使远程调用语句变得异常简单，其调用句式融合于当前编程环境，实施远程调用就象完成本地调用一样方便。其次，本地化语言适配可结合欲适配语言的特点，做不同层度的封装，对外提供的API可以不同，例如本实施例的Python-DTCF接口，CRemote类就是一种较高层次的封装。最后，本实施例中本地化语言适配融合了Python语言固有的实体生存周期自动管理等特性。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
权利要求
1.一种分布式测试组件框架DTCF系统，其特征在于包括DTCF软总线以及注册到DTCF软总线上的DTCF节点；所述DTCF节点用于编码或解析服务请求和服务响应，将服务调用本地化，并响应服务请求；所述DTCF软总线用于传送DTCF节点之间的服务请求和服务响应。
2.根据权利要求1所述的分布式测试组件框架系统，其特征在于，所述DTCF节点包括底层通信层、自动路由机制层、过程透传和实体透传协议层以及编程语言适配接口层；所述自动路由机制层用于通过节点标志实现各DTCF节点之间互相访问；所述过程透传与实体透传的透传协议层用于实现编解码和服务调用；所述编程语言适配接口层用于提供本地化的扩展接口。
3.根据权利要求2所述的分布式测试组件框架系统，其特征在于，所述底层通信层具有用于本机DTCF节点之间的共享内存通信方式，和/或用于跨机的DTCF节点之间的跨机通信方式。
4.根据权利要求1所述的分布式测试组件框架系统，其特征在于，所述的分布式测试组件框架系统进一步包括注册于DTCF软总线上的网络节点，用于跨机通信时转发服务请求或服务响应。
5.根据权利要求2所述的分布式测试组件框架系统，其特征在于，所述过程透传和实体透传协议层配置编解码规则，以及服务请求和服务响应的服务协议。
6.根据权利要求2所述的分布式测试组件框架系统，其特征在于，所述自动路由机制层配置自动路由机制，自动发送服务请求以及自动返回服务响应。
7.根据权利要求2所述的分布式测试组件框架系统，其特征在于，所述编程语言适配接口层包括Python、TCL、C、VBA或Delphi语言的适配接口。
8.一种分布式测试组件透传的方法，应用于分布式测试组件框架系统，其特征在于，包括步骤1)第一DTCF节点发送服务请求至DTCF软总线；2)DTCF软总线发送所述服务请求至第二DTCF节点；3)第二DTCF节点解析所述服务请求、将服务调用本地化并进行响应，并发送服务响应至DTCF软总线；4)DTCF软总线将所述服务响应返回至第一DTCF节点。
9.根据权利要求8所述的分布式测试组件透传的方法，其特征在于所述步骤2)中DTCF软总线采用共享内存通信方式发送服务请求；所述步骤4)中DTCF软总线采用共享内存通信方式发送服务响应。
10.根据权利要求8所述的分布式测试组件透传的方法，其特征在于，所述步骤2)具体包括DTCF软总线发送服务请求至第一网络节点；第一网络节点通过采用跨机通信方式的DTCF软总线发送服务请求至第二网络节点；第二网络节点通过DTCF软总线发送服务请求至第二DTCF节点。
11.根据权利要求8所述的分布式测试组件透传的方法，其特征在于所述步骤1)中第一DTCF节点依据节点标识方法指定第二DTCF节点。
12.根据权利要求11所述的分布式测试组件透传的方法，其特征在于所述节点标识方法采用“机器别名.节点别名”作为节点标志。
13.根据权利要求8所述的分布式测试组件透传的方法，其特征在于，步骤1)中的服务请求包括输入服务、打印服务、异步运行、同步运行、计算表达式、格式化异步调用和格式化同步调用。
14.根据权利要求8所述的分布式测试组件透传的方法，其特征在于，所述步骤1)中第一DTCF节点依据编解码规则编码服务请求；所述步骤3)第二DTCF节点依据编解码规则解码服务请求，并编码服务响应。
15.根据权利要求14所述的分布式测试组件透传的方法，其特征在于，所述编解码规则支持通用基本数据类型、复合数据类型和扩展数据类型。
16.根据权利要求15所述的分布式测试组件透传的方法，其特征在于，所述通用基本数据类型包括nil、int、long、float、string基本数据类型；所述复合数据类型包括tuple、list、dict数据类型；所述扩展数据类型包括Exceptionobject、Pending object。
17.根据权利要求8所述的分布式测试组件透传的方法，其特征在于，所述服务请求和服务响应是基于DTCF交互协议的调用服务。
18.根据权利要求17所述的分布式测试组件透传的方法，其特征在于，所述调用服务采用未决变量透传规则传递未决变量。
全文摘要
本发明公开了一种分布式测试组件框架系统及测试组件透传方法，所述系统包括DTCF软总线以及注册到DTCF软总线上的DTCF节点。所述方法应用于所述分布式测试组件框架系统，包括如下步骤第一DTCF节点发送服务请求至DTCF软总线；DTCF软总线发送所述服务请求至第二DTCF节点；第二DTCF节点解析所述服务请求、将服务调用本地化并进行响应，并发送服务响应至DTCF软总线；DTCF软总线将所述服务响应返回至第一DTCF节点。本发明适用于软件测试领域，能够快速、高效、便捷地实现适应于跨平台运行环境与多语言开发环境中测试组件的共享重用。
文档编号G06F11/36GK1677361SQ20041003070
公开日2005年10月5日 申请日期2004年3月31日 优先权日2004年3月31日
发明者程强 申请人:华为技术有限公司