基于白盒测试的Parlay_API接口测试方法设计

基于白盒测试的Parlay API接口测试方法设计

下一代网络(NGN)是可以提供语音、数据和多媒体等各种业务的综合开放的网络架构，可以支持快速业务部署以及第三方业务控制。NGN开放式业务提供的是一个分布式系统，为了实现第三方业务开发，业务结构应采用开放式接口控制技术，正在研究和开发的技术包括移动代理技术、主动网络技术和应用编程接口(API)技术。目前现实可行的是API技术。许多组织提出了开放业务平台的API，Parlay是其中最活跃、最有影响力的一个。

在Parlay组织成立后不久，3GPP和ETSI启动了3G系统UMTS的开放式业务架构的研究，称之为OSA。两者非常类似，最初的OSA标准就是由Parlay 1.2和2.1加上少量的3GPP 新增功能组成的。其后，两个组织决定从Parlay 3.0和OSA R5开始统一发布接口标准，命名为Parlay/OSA，这奠定了固定和移动NGN业务层融合的技术基础。两者的差别在于，Parlay 是单纯的接口标准，而OSA是一种业务结构，不仅包括业务接口，还包括体系结构以及Parlay 至移动网络协议，如MAP、CAP等的映射。

一、Pariay APl对业务的支持

Parlay API是一种基于分布式技术的、开放的、面向对象的下一代业务开发技术，它通过协议映射技术把底层网络的通信细节抽象成标准的API形式供业务开发者开发业务逻辑程序。它带来的好处是降低了业务开发的技术门槛，能使业务开发者更快捷地满足用户的个性化需要，提供丰富多彩的业务，为下一代网络的应用和发展提供最有效的驱动力。

Parlay APl是一个标准的接口，从而能够使第三方通过此接口利用运营商的基础网络提供丰富多彩的业务，例如统一消息业务、基于位置的业务、呼叫中心业务等，这些业务的业务逻辑都位于应用服务器上。

通过Parlay提供的第三方业务主要分为以下几类：

·通信类业务，如点击拨号、VoIP、点击传真、可视通话、会议电话，以及与位置相关的紧急呼叫业务等；

·消息类业务，如统一消息、短消息、语音信箱、E-mail、多媒体消息、聊天等；

·信息类业务，如新闻、体育、旅游、金融、天气、黄页、票务等各种信息的查询、订制、通知，以及基于位置的人员跟踪、找朋友等；

·娱乐类业务，如游戏、博彩、谜语、教育、广告等。

各类业务可以相对独立，也可以有机地结合，例如可以在查询信息时根据相应的信息进行支付类业务，而且各种娱乐可以通过不同的消息方式来表现(短消息、E-mail)，将娱乐与消息业务相结合。

框架服务器接口和业务能力接口是Parlay API定义的两类主要接口。业务逻辑程序通过Parlay网关中框架服务器接口的鉴权后，被授权接入规定的业务，然后使用框架服务器接口提供的业务能力发现和业务能力选择功能，通过签订在线业务能力使用协议，获得在框架服务器中注册的、满足业务需求的业务能力管理类接口引用。业务逻辑通过获得业务能力管理类接口引用就可以和其对应的业务能力接口进行通信，实现特定业务逻辑的呼叫控制、用户交互及计赞等功能。

Parlay标准定义的是控制底层网络资源的API，并非网络协议。两者的差别在于：协议面向具体的网络，由严格定义的一组消息和通信规则组成；API面向软件编程者，由一组抽象的操作或过程组成。在不同的网络中完成同样的功能所用的协议可能完全不同，但是所用的API则完全相同。这样，原来对通信网技术知之甚少的软件人员也可以利用Parlay接口自如地开发应用业务程序。

二、开放式业务接口Parlay API的测试

业务支撑环境是业务实现的重要环节，下一代网络的业务支撑环境主要包括应用服务

器、业务服务器和业务生成环境，它们互相配合，共同完成向用户提供多样灵活的基于下一代网络的增值业务的任务。其中应用服务器是支撑环境的主体，它通过开放的协议或者API 与软交换设备之间的交互来间接地利用底层网络资源，从而实现了业务与呼叫控制的分离，有利于新业务的引入。

应用服务器可分为SIP应用服务器和Parlay应用服务器两类，前者与软交换之间采用SIP 协议进行交互，后者将采用Parlay API作为与软交换之间的接口。通过协议开发业务的主要特点是：开发的业务与特定的网络和协议有关，即应用与具体的协议和网络相联系，这样开发的业务互通性不好，同时业务也不可移植。而采用基于开放API开发方法的主要特点是：互通性好，具有可编程性，可扩展性好，支持第三方业务开发。Parlay应用服务器的框架如图1所示。

图1Parlay应用服务器的框架

Parlay API主要由两部分组成：①业务接口(service Interface)：这类应用编程接口可以访问Parlay服务器所提供的一系列基本业务能力，比如建立或释放路由、与用户交互、发送用户消息及设定QoS级别等。业务供应商可以按照不同的业务逻辑调用它们以实现不同的业务。②框架接口(Frame-work Interface)：它们对客户端使用业务接口提供必需的安全、管理支持。框架服务器保证了底层通信网的安全开放和Parlay服务器的有序运行。业务逻辑程序通过Parlay网关中的框架服务器接口鉴权后，被授权接入规定的业务，然后使用框架服务器接口提供的业务能力发现和业务能力选择功能，通过签订在线业务能力使用协议，获得在框架服务器中注册的、满足业务需求的业务能力管理类接口调用。业务逻辑通过获得业务能力管理类接口调用就可以和其对应的业务能力接口进行通信，实现特定业务逻辑的呼叫控制、用户交互及计费等功能。

Parlay API实际上定义了一套能使外部网络访问通信网络各种资源的标准接口，并屏蔽了底层网络以及复杂的信令交互，使得业务开发人员无需掌握太多的通信背景知识，即可编写出丰富多彩的业务应用。所以，Parlay应用服务器除了要为Parlay业务提供一个安全可靠、高性能、开放的运行环境外，还要充当业务与下层网络之间的中间者，实现对与下层网络通信的CORBA对象的本地化封装，向运行其中的业务提供本地APl接口，为业务开发者屏蔽复杂的CORBA接口，因此，对Parlay API接口进行测试，以保证与下层网络的互通和业务的正常运行是必须的。

CORBA作为Parlay API的一种常用的底层通信环境，实现了功能实体的位置透明性和执行状态的透明性，使Parlay业务具有良好的分布特性。而CORBA复杂的调用接口参数配置也给对接口的测试带来了很大的难度。对于应用服务器所封装的Parlay API接口进行测试，可以有多种测试方法，业务也是复杂多样，如果想完全模拟全部的业务是不可能的，因此需

要设计一套基于自盒测试的模拟测试环境，仿真整个网络的业务生成环境，这样不但可以节省购置大量硬件设备的资金，也可以对业务的触发进行软件控制。

白盒测试又称为结构测试或逻辑驱动测试，主要是列程序模块进行如下检查：

·对逻辑模块的所有独立的执行路径至少测试一遍；

·对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一遍；

·在循环的边界和运行的界限内执行循环体；

·测试内部数据结构的有效性。

应用白盒测试的思想，通过测试用例设计和脚本的编写，即可实现对Parlay API接口调用的业务逻辑进行更准确的测试。

三、Pariay APl测试方案的设计

测试方案可以细化为被测系统、被测实体和服务SP三个部分，其中，被测系统为Parlay 应用服务器；被测实体是Parlay应用服务器的Parlay接口功能；为测试系统和被测系统提供互联功能的服务SP可以是Parlay API所采用的CORBA环境。首先，可以把Parlay API接口分为业务侧和网关侧，其中网关侧API实现了对下层网络能力的封装，向上层应用提供统一的调用接口。而业务侧API则用来为网关侧提供回调的接口，网关侧通过此接口向上层应用上报所有的呼叫事件及业务的操作结果。因此，在整个测试环境中需要两个测试器：位于网关侧的呼叫模拟和位于业务侧的业务模拟。对于两侧的测试器，可以设置两个观察窗口，对两侧API的调用情况分别进行监测。

整个测试系统的主要目的就是对应用服务器所封装的Parlay API接口进行测试，验证其是否将Parlay网关和业务之间发送的Parlay API调用正确地进行了传递，其中包括了函数名、参数是否正确以及在传递过程中是否正确地维持了方法调用的逻辑顺序，特别是在大话务量情况下，这种正确性是否仍然能得到保证。因此，对于网关侧的测试器发出和处理Parlay API 所依据的规则并不要求必须是基于动态呼叫状态的，所以，没有必要在网关侧实现一个复杂的仿真网络环境。对于Parlay API的发送、接收和处理所依据的规则采用静态定义的方法即可，即对所要测试的业务控制功能(SCF)，甚至是SCF中定义的某些方法编写测试用例，由测试用例来控制各方法、参数和调用的逻辑顺序。

Parlay API的呼叫APl分为一般呼叫控制、多方呼叫控制、多媒体呼叫控制和会议呼叫控制接口。

1．一般呼叫控制

一般呼叫控制服务是整个呼叫模型的子集。呼叫局限于两方且不可控制呼叫线路(Call Leg)。由于一般呼叫控制服务不能处理多媒体连接，所以不可能控制媒体信道。一般呼叫控制由网络侧的两个接口，即IpCallControlManager和IpCall，以及相对应的企业侧的两个接口，即IpAppCallControlManager和IpAppCall构成。

IpCallControlManager提供管理呼叫的方法。该接口的CreateCall()方法可建立新的呼叫对象(即实现IpCall接口的对象)。它也提供请求向客户应用通知呼叫事件的方法。例如，客户应用能够调用IpCallControlManager接口请求将送到指定电话号码或一定范围电话号码的呼叫事件通知给客户应用，如果由于某种错误呼叫通知不可进行，则不允许客户应用请求呼叫通知。

一旦调用了呼叫通知请求，就可以通过接口更改或删除。接口也提供在一系列呼叫上实施的负载控制方法和取消先前设嚣的负载限制的方法。

IpCall接口提供将呼叫路由到目的方或监视呼叫状态的方法。例如，客户应用能调用接口的方法，请求当呼叫结束时，设置与呼叫相关的信息(例如计费)。使用lpCall接口，客户应用也能请求监视呼叫，即经过指定时长后，将呼叫的状态报告送到客户应用且将呼叫的控制交给应用。这在预付费应用中很有用，以防止当预付费账户为零时，呼叫仍然继续。

IpCall接口也提供设置呼叫计费的操作，IpCall提供的另两个接口是请求用户提供更多的双音多频(DTMF)输入和计费建议操作，它通知用户有关呼叫计费的信息(即消息被发送到它的终端，如果终端有能力显示这一信息)。

IpAppCalIControlManager是IpCallContrdManager企业侧的对应接口。这个接口提供当呼叫事件(通过IpCallControlManager接口请求)到达时被调用的方法。也提供用以接受底层网络呼叫通知状态(能或不能)信息和当网络遇到呼叫过载时Parlay网关发送的通知信息的方法。接口也提供指示网络中呼叫终止的方法，当网络检测到呼叫(应用感兴趣的)终止后，由Parlay 网关调用。

IpAppCall是IpCall接口企业侧对应的接口。该接口提供用以处理呼叫请求的响应和状态报告的方法。例如，IpAppCall接口被通知有关路由请求的状态：路由成功和被叫应答，或被叫忙等。IpAppCall接口接受所有通过IpCall设置的请求的状态报告。

2.多方呼叫控制

在多方呼叫控制服务中，有六个重要的接口：IpMultiPartyCallControlManager、IpAppMultiPartyCallCaontrolManager、IpMultiPartyCall、IpAppMultiPartyCall、IpCallLeg和IpAppCallLeg。

接口IpMultiPartyCallControlManager、lpAppMultiPartyCallControlManager和IpAppMultiPartyCall从一般呼叫控制继承了所有方法目没有引入新的方法，IpMultiPartyCall 接口是IpCall的扩展。它包含显式接入呼叫Leg的操作。注意在多方呼叫中，一个呼叫能包含两个以上呼叫Leg。接口也提供一个建立实现IpCallLeg接口对象的方法。

IpCallLeg接口提供将呼叫Leg路由到指定目的方以及合并或分离与入/去呼叫相联系的媒体的方法，也提供当呼叫Leg终止时将Leg指定的请求信息发送到应用的方法。虽然能请求详细的Leg事件报告，但不提供连续监视Leg的方法。将来，通过IpCallLeg接口提供几个接入功能，例如找回呼叫Leg所属的ID。注意一个呼叫能有多个Leg，但一个Leg同时仅能是一个呼叫的部分。

IpAppCallLeg接口是]pCalILeg接口企业侧的对应接口。它接受通过IpCallLeg接口设置的请求的响应。

接口lpMuhiPartyCall继承自lpCall，新增方法有：

·GetCallLeg()，此方法请求与呼叫对象相关的呼叫Leg对象的标识；

·CreateCallLeg()，此方法请求创建新的呼叫Leg对象；·CreateAndRouteCallLegReq()，此异步操作请求创建并对新创建的呼叫Leg选路。

接口IpAppMultiPartyCall继承自IpAppCall，新增方法有：·CreateAndRouteCallLegErr()，此异步方法指示呼叫路由至目的地的请求不成功。

接口IpCallLeg继承自IpService，呼叫Leg接口用地址代表与呼叫相关的逻辑呼叫Leg。·RouteReq()，此异步方法请求呼叫Leg路由至目的地址指示的一方；

·EventReportReq()，此异步方法设置、清除或改变Leg对象监视的事件标准；

·Release()，此方法请求释放呼叫Leg，如果成功，呼叫Leg被删除；

·GetInfoReq()，此异步方法请求在适当的时候提供与呼叫Leg相关的信息；

·GetCall()，此方法请求与呼叫Leg相关的呼叫：

·AttachMedia()，此方法请求呼叫Leg与它的呼叫对象相连；

·DetachMedia()，此方法使呼叫Leg与它的呼叫相分离；·GetLastRedirectedAddress()，此方法用来查询要转向的最后地址；·ContinueProcessing()，此操作继续呼叫Leg的处理，在呼叫Leg处理由于应用预约的事件通知被检出而中断后调用此操作；

·SetChargePlan()，设定操作员定义呼叫的计费策略。计费策略必须在呼叫Leg路由至目的地

前设定。此方法也可以用来改变目前呼叫的计费策略；

·SetAdviceOfCbarge()，此方法允许AOC信息发送到可以接收该信息的终端；·SuperviseReq()，调用此方法监视呼叫Leg；

·Deassign()，此方法请求重新指定应用和呼叫Leg以及相关对象的关系。

接口IpAppCallLeg继承自IpInterface，应用呼叫Leg接口用来处理与呼叫Leg请求相关的响应和错误。

·EventReportRes()，此异步方法报告所要请求报告的事件；

·EvenlReportErr()，此异步方法指示处理呼叫Leg事件报告的请求未成功以及原因；·GetlnfoRes()，此异步方法报告应用所请求的所有必要信息；

·GetInfoErr()，此异步方法报告源端请求错误；

·RouteErr()，此方法报告路由错误；

·SuperviseRes()，此异步方法报告呼叫Leg监视事件给应用；

·SuperviseErr()，此异步方法报告呼叫Leg监视错误；

·CallLegEnded()，此方法指示应用网络中Leg已结束。

3.多媒体呼叫控制

在多媒体呼叫中，涉及以下七个接口：IpMultiMediaCallControlManager、IpAppMultiMediaCallControlManager、IpMultiMediaCall、IpAppMultiMediaCall、IpMultiMediaCallLeg、IpAppMultiMediaCallLeg以及IpMultiMediaChannel。

接口IpMultiMediaCallControlManager继承了IpMultiPartyCallControlManager提供的所有方法而且通过提供两个新的方法扩展了它的能力。通过这些方法可以媒体信道通知能力。当激活媒体信道通知能力时，包含两个标准集。两个标准集必须在信道报告给客户应用前全部实现。首先，多媒体呼叫必须与呼叫标准匹配(即目的呼叫码必须在一定范围内)，而且媒体信道指示也必须匹配。企业侧的对应接口IpAppMultiMediaCallControlManager继承了IpAppMultiPartyCallControlManager接口的所有方法，引入了一个新方法，即媒体信道事件通知方法。

为代表网络侧的多媒体呼叫，使用一个实现IpMultiMediaCall接口的对象。接口继承了IpMultiPartyCall接口的操作，引入一个新方法去设定一个呼叫认可的数据流量(以微秒测算)。当给定的数据量过期后，企业侧称IpAppMultiMediaCall的对应接口收到事件的通知。

接口IpMultiMediaCallLeg继承了IpCallLeg的所有操作，客户应用通过调用这个接口的方法能够监控和影响媒体信道。该接口提供了三个新的操作，其中一个是能够监控打开和关闭媒体信道，这又包括两种监控类型：一般监控(满足任何媒体类型)或指定监控(仅当使用指定媒体类型的信道才发送通知)。如果监控设置为中断模式，为打开这种媒体信道，应用必须显式地允许接入。IpMultiMediaCallLeg接口提供相应的方法，其引入的最新方法使得可以接入所有与这个呼叫Leg相关的已打开的媒体信道列表的方法(注意，一个呼叫Leg可与几个媒体信道相联系)。

在企业侧必须实现IpAppMuhiMediaCallLeg接口，它继承了父类IpAppCallLeg的方法。引入一个新的操作，即媒体信道通知，当打开或关闭满足请求的检测标准时，由Parlay网关调用。

多媒体呼叫控制包含的最后一个接口是IpMulfiMediaChannel，这个接口表现为与呼叫Leg联系的单向数据流。只有一个方法可用，即关闭信道。

4.会议呼叫控制控制

会议呼叫控制是Parlay API定义的最高级的呼叫控制形式。会议呼叫控制服务用会议和子会议的概念提升了多媒体呼叫控制服务。会议与多媒体、多方呼叫的不同点是会议资源可提前保留。子会议是会议中全部Legs的子集，只有在同一子会议中的Legs才能相互通信(即

只有在同一子会议的Legs间才有媒体通路)。

有两种会议开始方式：没有会议资源的优先保留和有会议资源的优先保留。在会议呼叫控制服务中，有六个接口最重要：

·IpConfCallControlManager是必须用以生成会议和资源管理的接口。它继承了父类接口IpMultiMediaCallControlManager，但也增加了重要的新成员。该接口提供建立新会议及检测会议是否有足够的资源可用、为会议预留资源和释放分配资源的方法。当建立一个新的会议时，应用必须指明要用的子会议数目。它至少为1，会议参加者数目和预期的会议时长也在建立会议的请求时提供，网络随后尽力在指定的时间分配必要的资源。如果资源可用，会议开始。当会议时长超出了资源预留的时间，资源不再保证，但会议可以继续。注意，如果需要资源满足另外的请求，会议可能被网络结束或拒绝。

IpConfCallControlManager接口也提供检测在给定的预计时间是否有足够的资源可用的方法。调用此方法时，必须输入指定的开始和结束日期以及时间(代表搜索间隔)、可选的期望参加者数目和会议周期。搜索算法返回实际可利用的资源、会议时长和开始时间。注意此方法仍然没有保留资源。为了保留资源，IpConfCallControlManager接口提供了另一个方法。作为此方法的参数，必须制定开始的日期和时间，参加者数目和会议预期时长，以及会议指定的策略、内容、是否允许会议建立以后实体加入等。

IpConfCallControlManager接口提供的最后一个方法专为释放先前保留的资源，本方法有效地取消了资源预留。

·IpAppConfCallControlManager提供了当会议因先前的预约由网络建立时，Parlay网关调用的方法。它继承了IpAppMuhiMediaCallManager接口，除了以上描述的方法外，没有引入新的方法。

·lpConfCall接口继承了IpMuhiMediaCall接口，用以管理子会议，也可向不需要知道有多个子会议的应用隐藏子会议。除了继承的方法外，该接口提供了请求会议中所有子会议列表的新方法，以建立新子会议和请求监控事件。

·IpAppConfCall是相对于lpConfCall接口的企业侧接口。IpAppConfCall接口接收通过IpConfCall接口调用的请求的响应。它继承了父接口IpAppMultiMediaCall的方法，且提供了两个新方法。

首先，通过lpAppConfCall接口，提供当到达一个新的实体(和呼叫Leg)时的通知方法。例如可以用于计划会议(会议资源已经预留)，这里参加者使用资源预留期间提供的地址可以拨进会议(如果会议策略允许拨入)。

第二个新的操作是通知应用实体的离去，当实体离开会议和监控实体提前申请离开，应由Parlay网关调用。

·IpSubConfCall提供管理子会议的操作。子会议又称为一个会议中所有Legs的子集，所以仅在同一子会议的Legs才能相互通信。它继承了IpMultiMediaCall，并提供几个新的方法。其中一个方法是分拆子会议，在这种情况下，子会议中的一些Legs移往新建的子会议。相应的，也提供了合并子会议的方法，在这种情况下，该子会议中的所有Legs移往一已经存在的子会议，且释放空子会议。该接口也提供了将呼叫Leg移往另一子会议的方法。通过IpSubConfCall接口，可以改变多媒体(子)会议策略。

·IpAppSubConfCall接口允许通知应用关于子会议的事件。它继承了IpAppMultiMediaCall 接口，并引入了两个新的操作，都是用来调用去通知应用网络所作的请求。一个方法用于提供主席请求，另一个提供坐席请求。

整个测试系统由四部分组成(如图2所示)：

·模拟Parlay网关模块：主要实现Parlay网关的功能；

·测试用例运行模块：主要实现对测试用例的加载、运行；

·测试结果保存模块：保存测试用例测试的结果，并可查询和对比；

·辅助工具模块：对测试提供辅助工具。

其中，测试用例运行模块和模拟Parlay网管模块在测试平台中起关键作用，可以通过测试用例运行模块编写测试用例。此模块可以设计成并行执行，每次可以加载多个测试用例同时进行。特别是在验证大话务量的情况下，应用服务器在Parlay API传递中是否能够保证消息、参数以及调用顺序上的正确性。

(二)基于白盒测试的Parlay API接口测试方法设计

图2Parlay API测试方案的整体架构

模拟Parlay网关模块对外提供两种接口：一种是基于CORBA的远程调用接口，该接口主要用于同Parlay应用服务器进行正常的Parlay API交互；另一种是向测试用例提供的Java 本地API接口，测试用例通过使用此接口通知模拟网关应该向应用服务器发送哪个Parlay API 调用。因此，该接口需要为测试用例提供的功能，包括创建各种IP侧接口实例，设定Parlay 方法的各个参数，指定应该向Parlay应用服务器发起哪一个方法调用等。实际上，模拟Parlay 网关模块的这种本地API接口就是提供给测试用例使用的控制接口，测试用例通过该接口来控制模拟Parlay网关模块完成CORBA对象的创建和Parlay方法的封装及调用工作，而测试过程中的呼叫状态信息主要由测试用例自身保存和更改。

四、基于白盒测试的测试用例的实现

在此测试系统中，每个测试用例应分为两个部分。①网关侧测试集：主要功能是测试用例运行时，向Parlay应用服务器发送一个模拟呼叫清求，然后配合业务逻辑执行测试操作。

②业务侧测试集：主要是接收由Parlay应用服务器转发来的网关侧呼叫请求，然后配合网关部分执行测试操作，并将测试结果保存到相应的文件中。

网关侧和业务侧的测试集分别在测试平台和Parlay应该用服务器中运行，测试用例需要分别单独编写。其中，业务侧的测试集作为业务的一种，网关侧的测试集需要调用测试系统中的ITestInstance接口。测试用例的相关信息在测试用例脚本文件中提供。这些相关信息包括：①测试用例的名称，用来惟一表示测试用例。②网关侧测试类的类名，每个测试用例都对应着一个网关侧的Java类，测试平台对测试用例的加载实际上就是创建并加载相应的Java 类，测试用例的执行就是执行该Java类的相应接口方法。③业务侧测试类名。每个测试用例都要有对业务的支持，因此需要在脚本文件中为每个测试用例指定相应的业务名称。④测试用例所使用的呼叫类型，该呼叫类型指定测试用例所对应的上层业务是基于何种呼叫类型。

对于Parlay API的测试方案，我们采取白盒测试的方法进行测试。

白盒测试应用于本测试系统中，主要是对业务逻辑调用的考察，因此，我们必须制订好测试的实施步骤：

·测试计划阶段：根据业务说明书，制定测试进度；

·测试设计阶段：依据业务的程序没计说明书，按照一定规范化的方法进行软件结构划分和测试用例的设计；

·测试执行阶段：加载测试用例，得到测试结果；

·测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。

由于本测试操作主要是通过API的调用情况和调用顺序来体现的，这就要求在每次测试操作中，测试用例需要将业务侧对网关侧以及网侧对业务侧的APl调用信息，API所继承的类名、方法名等保存到相应的测试结果文件中，最后通过比较相关的测试结果文件就能获知测试用的执行结果是否正确。在整个测试过程中，对Parlay API的调用情况可以分为两类：业务侧和网络侧调用情况。每种情况又可以分为两类：主动调用和被动调用。这四种情况是对应的，业务侧的主动调用和网关侧的被动调用情况对应，网关侧的主动调用情况和业务侧的被调用情况对应。

基本操作流程：

第一步：测试系统首先应根据配置文件中所设置的参数初始化CORBA环境，创建Parlay 中各网络侧Manager接口类的CORBA对象以及测试结果保存模块所必须的CORBA对象，并将这些CORBA对象注册到CORBA命名服务中，以供应服务器和测试用例使用；

第二步：测试系统从测试用例脚本文件中读取所有要执行的测试用例的相关信息，包括测试用例的名称、网管侧测试类名、业务侧测试类名以及呼叫类型等，并保存下来；

第三步：加载测试用例到Parlay应用服务器中，然后激活；

第四步：运行测试用例；

第五步：在测试过程中，测试用例的业务侧测试类，测试平台的模拟Parlay网关模块把各自对Parlay API的调用情况，通过测试结果保存模块将相应的测试结果保存到结果文件中去；

第六步：测试用例执行结束后，清除所有进程，去掉前面已经加载的测试用例。

第七步：统计、分析测试结果，用户可通过各种文本文件比较工具比较测试结果文件内容的异同。

对于Parlay应用服务器接口测试的需求，这种自动化测试平台具有如下优点：

·测试平台实现比较简单，本测试平台只需按照测试用例的要求生成相应的Parlay API调用，无需维护模拟呼叫的状态信息；

·测试用例编写灵活，模拟呼叫的状态信息以及各Parlay API方法的参数均由测试用例提供，只要测试用例的功能足够，即可支持真实业务的功能测试；

·测试操作的自动化。

五、结语

Parlay应用服务器可以提供不同抽象层次的业务开发接口、以便不同能力不同类型的业务开发者开发丰富多彩的业务，例如，可以提供基于CORBA的Parlay API接口、基于JAIN SPA 标准的Java API接口、以及基于Javabeans的接口，基于XML、CPL、VoiceXML的接口等，业务开发者也可以根据业务的需要和自己的能力来选择合适的开发接口。

业务的多样性给测试带来了很大的不便，购买大量设备建设模拟环境的确不是一个理想的测试方案，上述基于白盒的检测方法大大简化了模拟环境的配置，可以通过软件来模拟网络环境，考察API的调用情况。