基于白盒測試的Parlay API接口測試方法設(shè)計

下一代網(wǎng)絡(luò)(NGN)是可以提供語音、數(shù)據(jù)和多媒體等各種業(yè)務(wù)的綜合開放的網(wǎng)絡(luò)架構(gòu)，可以支持快速業(yè)務(wù)部署以及第三方業(yè)務(wù)控制。NGN開放式業(yè)務(wù)提供的是一個分布式系統(tǒng)，為了實現(xiàn)第三方業(yè)務(wù)開發(fā)，業(yè)務(wù)結(jié)構(gòu)應(yīng)采用開放式接口控制技術(shù)，正在研究和開發(fā)的技術(shù)包括移動代理技術(shù)、主動網(wǎng)絡(luò)技術(shù)和應(yīng)用編程接口(API)技術(shù)。目前現(xiàn)實可行的是API技術(shù)。許多組織提出了開放業(yè)務(wù)平臺的API，Parlay是其中最活躍、最有影響力的一個。

在Parlay組織成立后不久，3GPP和ETSI啟動了3G系統(tǒng)UMTS的開放式業(yè)務(wù)架構(gòu)的研究，稱之為OSA。兩者非常類似，最初的OSA標準就是由Parlay 1.2和2.1加上少量的3GPP新增功能組成的。其后，兩個組織決定從Parlay 3.0和OSA R5開始統(tǒng)一發(fā)布接口標準，命名為Parlay/OSA，這奠定了固定和移動NGN業(yè)務(wù)層融合的技術(shù)基礎(chǔ)。兩者的差別在于，Parlay是單純的接口標準，而OSA是一種業(yè)務(wù)結(jié)構(gòu)，不僅包括業(yè)務(wù)接口，還包括體系結(jié)構(gòu)以及Parlay至移動網(wǎng)絡(luò)協(xié)議，如MAP、CAP等的映射。

一、Pariay APl對業(yè)務(wù)的支持

Parlay API是一種基于分布式技術(shù)的、開放的、面向?qū)ο蟮南乱淮鷺I(yè)務(wù)開發(fā)技術(shù)，它通過協(xié)議映射技術(shù)把底層網(wǎng)絡(luò)的通信細節(jié)抽象成標準的API形式供業(yè)務(wù)開發(fā)者開發(fā)業(yè)務(wù)邏輯程序。它帶來的好處是降低了業(yè)務(wù)開發(fā)的技術(shù)門檻，能使業(yè)務(wù)開發(fā)者更快捷地滿足用戶的個性化需要，提供豐富多彩的業(yè)務(wù)，為下一代網(wǎng)絡(luò)的應(yīng)用和發(fā)展提供最有效的驅(qū)動力。

Parlay APl是一個標準的接口，從而能夠使第三方通過此接口利用運營商的基礎(chǔ)網(wǎng)絡(luò)提供豐富多彩的業(yè)務(wù)，例如統(tǒng)一消息業(yè)務(wù)、基于位置的業(yè)務(wù)、呼叫中心業(yè)務(wù)等，這些業(yè)務(wù)的業(yè)務(wù)邏輯都位于應(yīng)用服務(wù)器上。

通過Parlay提供的第三方業(yè)務(wù)主要分為以下幾類：

·通信類業(yè)務(wù)，如點擊撥號、VoIP、點擊傳真、可視通話、會議電話，以及與位置相關(guān)的緊急呼叫業(yè)務(wù)等；

·消息類業(yè)務(wù)，如統(tǒng)一消息、短消息、語音信箱、E-mail、多媒體消息、聊天等；

·信息類業(yè)務(wù)，如新聞、體育、旅游、金融、天氣、黃頁、票務(wù)等各種信息的查詢、訂制、通知，以及基于位置的人員跟蹤、找朋友等；

·娛樂類業(yè)務(wù)，如游戲、博彩、謎語、教育、廣告等。

各類業(yè)務(wù)可以相對獨立，也可以有機地結(jié)合，例如可以在查詢信息時根據(jù)相應(yīng)的信息進行支付類業(yè)務(wù)，而且各種娛樂可以通過不同的消息方式來表現(xiàn)(短消息、E-mail)，將娛樂與消息業(yè)務(wù)相結(jié)合。

框架服務(wù)器接口和業(yè)務(wù)能力接口是Parlay API定義的兩類主要接口。業(yè)務(wù)邏輯程序通過Parlay網(wǎng)關(guān)中框架服務(wù)器接口的鑒權(quán)后，被授權(quán)接入規(guī)定的業(yè)務(wù)，然后使用框架服務(wù)器接口提供的業(yè)務(wù)能力發(fā)現(xiàn)和業(yè)務(wù)能力選擇功能，通過簽訂在線業(yè)務(wù)能力使用協(xié)議，獲得在框架服務(wù)器中注冊的、滿足業(yè)務(wù)需求的業(yè)務(wù)能力管理類接口引用。業(yè)務(wù)邏輯通過獲得業(yè)務(wù)能力管理類接口引用就可以和其對應(yīng)的業(yè)務(wù)能力接口進行通信，實現(xiàn)特定業(yè)務(wù)邏輯的呼叫控制、用戶交互及計贊等功能。

Parlay標準定義的是控制底層網(wǎng)絡(luò)資源的API，并非網(wǎng)絡(luò)協(xié)議。兩者的差別在于：協(xié)議面向具體的網(wǎng)絡(luò)，由嚴格定義的一組消息和通信規(guī)則組成；API面向軟件編程者，由一組抽象的操作或過程組成。在不同的網(wǎng)絡(luò)中完成同樣的功能所用的協(xié)議可能完全不同，但是所用的API則完全相同。這樣，原來對通信網(wǎng)技術(shù)知之甚少的軟件人員也可以利用Parlay接口自如地開發(fā)應(yīng)用業(yè)務(wù)程序。

二、開放式業(yè)務(wù)接口Parlay API的測試

業(yè)務(wù)支撐環(huán)境是業(yè)務(wù)實現(xiàn)的重要環(huán)節(jié)，下一代網(wǎng)絡(luò)的業(yè)務(wù)支撐環(huán)境主要包括應(yīng)用服務(wù)器、業(yè)務(wù)服務(wù)器和業(yè)務(wù)生成環(huán)境，它們互相配合，共同完成向用戶提供多樣靈活的基于下一代網(wǎng)絡(luò)的增值業(yè)務(wù)的任務(wù)。其中應(yīng)用服務(wù)器是支撐環(huán)境的主體，它通過開放的協(xié)議或者API與軟交換設(shè)備之間的交互來間接地利用底層網(wǎng)絡(luò)資源，從而實現(xiàn)了業(yè)務(wù)與呼叫控制的分離，有利于新業(yè)務(wù)的引入。
  應(yīng)用服務(wù)器可分為SIP應(yīng)用服務(wù)器和Parlay應(yīng)用服務(wù)器兩類，前者與軟交換之間采用SIP協(xié)議進行交互，后者將采用Parlay API作為與軟交換之間的接口。通過協(xié)議開發(fā)業(yè)務(wù)的主要特點是：開發(fā)的業(yè)務(wù)與特定的網(wǎng)絡(luò)和協(xié)議有關(guān)，即應(yīng)用與具體的協(xié)議和網(wǎng)絡(luò)相聯(lián)系，這樣開發(fā)的業(yè)務(wù)互通性不好，同時業(yè)務(wù)也不可移植。而采用基于開放API開發(fā)方法的主要特點是：互通性好，具有可編程性，可擴展性好，支持第三方業(yè)務(wù)開發(fā)。Parlay應(yīng)用服務(wù)器的框架如圖1所示。

圖1　Parlay應(yīng)用服務(wù)器的框架

Parlay API主要由兩部分組成：①業(yè)務(wù)接口(service Interface)：這類應(yīng)用編程接口可以訪問Parlay服務(wù)器所提供的一系列基本業(yè)務(wù)能力，比如建立或釋放路由、與用戶交互、發(fā)送用戶消息及設(shè)定QoS級別等。業(yè)務(wù)供應(yīng)商可以按照不同的業(yè)務(wù)邏輯調(diào)用它們以實現(xiàn)不同的業(yè)務(wù)。②框架接口(Frame-work Interface)：它們對客戶端使用業(yè)務(wù)接口提供必需的安全、管理支持�？蚣芊�務(wù)器保證了底層通信網(wǎng)的安全開放和Parlay服務(wù)器的有序運行。業(yè)務(wù)邏輯程序通過Parlay網(wǎng)關(guān)中的框架服務(wù)器接口鑒權(quán)后，被授權(quán)接入規(guī)定的業(yè)務(wù)，然后使用框架服務(wù)器接口提供的業(yè)務(wù)能力發(fā)現(xiàn)和業(yè)務(wù)能力選擇功能，通過簽訂在線業(yè)務(wù)能力使用協(xié)議，獲得在框架服務(wù)器中注冊的、滿足業(yè)務(wù)需求的業(yè)務(wù)能力管理類接口調(diào)用。業(yè)務(wù)邏輯通過獲得業(yè)務(wù)能力管理類接口調(diào)用就可以和其對應(yīng)的業(yè)務(wù)能力接口進行通信，實現(xiàn)特定業(yè)務(wù)邏輯的呼叫控制、用戶交互及計費等功能。

Parlay API實際上定義了一套能使外部網(wǎng)絡(luò)訪問通信網(wǎng)絡(luò)各種資源的標準接口，并屏蔽了底層網(wǎng)絡(luò)以及復雜的信令交互，使得業(yè)務(wù)開發(fā)人員無需掌握太多的通信背景知識，即可編寫出豐富多彩的業(yè)務(wù)應(yīng)用。所以，Parlay應(yīng)用服務(wù)器除了要為Parlay業(yè)務(wù)提供一個安全可靠、高性能、開放的運行環(huán)境外，還要充當業(yè)務(wù)與下層網(wǎng)絡(luò)之間的中間者，實現(xiàn)對與下層網(wǎng)絡(luò)通信的CORBA對象的本地化封裝，向運行其中的業(yè)務(wù)提供本地APl接口，為業(yè)務(wù)開發(fā)者屏蔽復雜的CORBA接口，因此，對Parlay API接口進行測試，以保證與下層網(wǎng)絡(luò)的互通和業(yè)務(wù)的正常運行是必須的。

CORBA作為Parlay API的一種常用的底層通信環(huán)境，實現(xiàn)了功能實體的位置透明性和執(zhí)行狀態(tài)的透明性，使Parlay業(yè)務(wù)具有良好的分布特性。而CORBA復雜的調(diào)用接口參數(shù)配置也給對接口的測試帶來了很大的難度。對于應(yīng)用服務(wù)器所封裝的Parlay API接口進行測試，可以有多種測試方法，業(yè)務(wù)也是復雜多樣，如果想完全模擬全部的業(yè)務(wù)是不可能的，因此需要設(shè)計一套基于自盒測試的模擬測試環(huán)境，仿真整個網(wǎng)絡(luò)的業(yè)務(wù)生成環(huán)境，這樣不但可以節(jié)省購置大量硬件設(shè)備的資金，也可以對業(yè)務(wù)的觸發(fā)進行軟件控制。

白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，主要是列程序模塊進行如下檢查：

·對邏輯模塊的所有獨立的執(zhí)行路徑至少測試一遍；

·對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一遍；

·在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體；

·測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性。

應(yīng)用白盒測試的思想，通過測試用例設(shè)計和腳本的編寫，即可實現(xiàn)對Parlay API接口調(diào)用的業(yè)務(wù)邏輯進行更準確的測試。

三、Pariay APl測試方案的設(shè)計

測試方案可以細化為被測系統(tǒng)、被測實體和服務(wù)SP三個部分，其中，被測系統(tǒng)為Parlay應(yīng)用服務(wù)器；被測實體是Parlay應(yīng)用服務(wù)器的Parlay接口功能；為測試系統(tǒng)和被測系統(tǒng)提供互聯(lián)功能的服務(wù)SP可以是Parlay API所采用的CORBA環(huán)境。首先，可以把Parlay API接口分為業(yè)務(wù)側(cè)和網(wǎng)關(guān)側(cè)，其中網(wǎng)關(guān)側(cè)API實現(xiàn)了對下層網(wǎng)絡(luò)能力的封裝，向上層應(yīng)用提供統(tǒng)一的調(diào)用接口。而業(yè)務(wù)側(cè)API則用來為網(wǎng)關(guān)側(cè)提供回調(diào)的接口，網(wǎng)關(guān)側(cè)通過此接口向上層應(yīng)用上報所有的呼叫事件及業(yè)務(wù)的操作結(jié)果。因此，在整個測試環(huán)境中需要兩個測試器：位于網(wǎng)關(guān)側(cè)的呼叫模擬和位于業(yè)務(wù)側(cè)的業(yè)務(wù)模擬。對于兩側(cè)的測試器，可以設(shè)置兩個觀察窗口，對兩側(cè)API的調(diào)用情況分別進行監(jiān)測。

整個測試系統(tǒng)的主要目的就是對應(yīng)用服務(wù)器所封裝的Parlay API接口進行測試，驗證其是否將Parlay網(wǎng)關(guān)和業(yè)務(wù)之間發(fā)送的Parlay API調(diào)用正確地進行了傳遞，其中包括了函數(shù)名、參數(shù)是否正確以及在傳遞過程中是否正確地維持了方法調(diào)用的邏輯順序，特別是在大話務(wù)量情況下，這種正確性是否仍然能得到保證。因此，對于網(wǎng)關(guān)側(cè)的測試器發(fā)出和處理Parlay API所依據(jù)的規(guī)則并不要求必須是基于動態(tài)呼叫狀態(tài)的，所以，沒有必要在網(wǎng)關(guān)側(cè)實現(xiàn)一個復雜的仿真網(wǎng)絡(luò)環(huán)境。對于Parlay API的發(fā)送、接收和處理所依據(jù)的規(guī)則采用靜態(tài)定義的方法即可，即對所要測試的業(yè)務(wù)控制功能(SCF)，甚至是SCF中定義的某些方法編寫測試用例，由測試用例來控制各方法、參數(shù)和調(diào)用的邏輯順序。

Parlay API的呼叫APl分為一般呼叫控制、多方呼叫控制、多媒體呼叫控制和會議呼叫控制接口。

1．一般呼叫控制

一般呼叫控制服務(wù)是整個呼叫模型的子集。呼叫局限于兩方且不可控制呼叫線路(Call Leg)。由于一般呼叫控制服務(wù)不能處理多媒體連接，所以不可能控制媒體信道。一般呼叫控制由網(wǎng)絡(luò)側(cè)的兩個接口，即IpCallControlManager和IpCall，以及相對應(yīng)的企業(yè)側(cè)的兩個接口，即IpAppCallControlManager和IpAppCall構(gòu)成。

IpCallControlManager提供管理呼叫的方法。該接口的CreateCall()方法可建立新的呼叫對象(即實現(xiàn)IpCall接口的對象)。它也提供請求向客戶應(yīng)用通知呼叫事件的方法。例如，客戶應(yīng)用能夠調(diào)用IpCallControlManager接口請求將送到指定電話號碼或一定范圍電話號碼的呼叫事件通知給客戶應(yīng)用，如果由于某種錯誤呼叫通知不可進行，則不允許客戶應(yīng)用請求呼叫通知。

一旦調(diào)用了呼叫通知請求，就可以通過接口更改或刪除。接口也提供在一系列呼叫上實施的負載控制方法和取消先前設(shè)囂的負載限制的方法。

IpCall接口提供將呼叫路由到目的方或監(jiān)視呼叫狀態(tài)的方法。例如，客戶應(yīng)用能調(diào)用接口的方法，請求當呼叫結(jié)束時，設(shè)置與呼叫相關(guān)的信息(例如計費)。使用lpCall接口，客戶應(yīng)用也能請求監(jiān)視呼叫，即經(jīng)過指定時長后，將呼叫的狀態(tài)報告送到客戶應(yīng)用且將呼叫的控制交給應(yīng)用。這在預(yù)付費應(yīng)用中很有用，以防止當預(yù)付費賬戶為零時，呼叫仍然繼續(xù)。

IpCall接口也提供設(shè)置呼叫計費的操作，IpCall提供的另兩個接口是請求用戶提供更多的雙音多頻(DTMF)輸入和計費建議操作，它通知用戶有關(guān)呼叫計費的信息(即消息被發(fā)送到它的終端，如果終端有能力顯示這一信息)。

IpAppCalIControlManager是IpCallContrdManager企業(yè)側(cè)的對應(yīng)接口。這個接口提供當呼叫事件(通過IpCallControlManager接口請求)到達時被調(diào)用的方法。也提供用以接受底層網(wǎng)絡(luò)呼叫通知狀態(tài)(能或不能)信息和當網(wǎng)絡(luò)遇到呼叫過載時Parlay網(wǎng)關(guān)發(fā)送的通知信息的方法。接口也提供指示網(wǎng)絡(luò)中呼叫終止的方法，當網(wǎng)絡(luò)檢測到呼叫(應(yīng)用感興趣的)終止后，由Parlay網(wǎng)關(guān)調(diào)用。

IpAppCall是IpCall接口企業(yè)側(cè)對應(yīng)的接口。該接口提供用以處理呼叫請求的響應(yīng)和狀態(tài)報告的方法。例如，IpAppCall接口被通知有關(guān)路由請求的狀態(tài)：路由成功和被叫應(yīng)答，或被叫忙等。IpAppCall接口接受所有通過IpCall設(shè)置的請求的狀態(tài)報告。

2.多方呼叫控制

在多方呼叫控制服務(wù)中，有六個重要的接口：IpMultiPartyCallControlManager、IpAppMultiPartyCallCaontrolManager、IpMultiPartyCall、IpAppMultiPartyCall、IpCallLeg和IpAppCallLeg。

接口IpMultiPartyCallControlManager、lpAppMultiPartyCallControlManager和IpAppMultiPartyCall從一般呼叫控制繼承了所有方法目沒有引入新的方法，IpMultiPartyCall接口是IpCall的擴展。它包含顯式接入呼叫Leg的操作。注意在多方呼叫中，一個呼叫能包含兩個以上呼叫Leg。接口也提供一個建立實現(xiàn)IpCallLeg接口對象的方法。

IpCallLeg接口提供將呼叫Leg路由到指定目的方以及合并或分離與入/去呼叫相聯(lián)系的媒體的方法，也提供當呼叫Leg終止時將Leg指定的請求信息發(fā)送到應(yīng)用的方法。雖然能請求詳細的Leg事件報告，但不提供連續(xù)監(jiān)視Leg的方法。將來，通過IpCallLeg接口提供幾個接入功能，例如找回呼叫Leg所屬的ID。注意一個呼叫能有多個Leg，但一個Leg同時僅能是一個呼叫的部分。

IpAppCallLeg接口是]pCalILeg接口企業(yè)側(cè)的對應(yīng)接口。它接受通過IpCallLeg接口設(shè)置的請求的響應(yīng)。

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

·GetCallLeg()，此方法請求與呼叫對象相關(guān)的呼叫Leg對象的標識；

·CreateCallLeg()，此方法請求創(chuàng)建新的呼叫Leg對象；

·CreateAndRouteCallLegReq()，此異步操作請求創(chuàng)建并對新創(chuàng)建的呼叫Leg選路。

接口IpAppMultiPartyCall繼承自IpAppCall，新增方法有：

·CreateAndRouteCallLegErr()，此異步方法指示呼叫路由至目的地的請求不成功。

接口IpCallLeg繼承自IpService，呼叫Leg接口用地址代表與呼叫相關(guān)的邏輯呼叫Leg。

·RouteReq()，此異步方法請求呼叫Leg路由至目的地址指示的一方；

·EventReportReq()，此異步方法設(shè)置、清除或改變Leg對象監(jiān)視的事件標準；

·Release()，此方法請求釋放呼叫Leg，如果成功，呼叫Leg被刪除；

·GetInfoReq()，此異步方法請求在適當?shù)臅r候提供與呼叫Leg相關(guān)的信息；

·GetCall()，此方法請求與呼叫Leg相關(guān)的呼叫：

·AttachMedia()，此方法請求呼叫Leg與它的呼叫對象相連；

·DetachMedia()，此方法使呼叫Leg與它的呼叫相分離；

·GetLastRedirectedAddress()，此方法用來查詢要轉(zhuǎn)向的最后地址；

·ContinueProcessing()，此操作繼續(xù)呼叫Leg的處理，在呼叫Leg處理由于應(yīng)用預(yù)約的事件通知被檢出而中斷后調(diào)用此操作；

·SetChargePlan()，設(shè)定操作員定義呼叫的計費策略。計費策略必須在呼叫Leg路由至目的地前設(shè)定。此方法也可以用來改變目前呼叫的計費策略；

·SetAdviceOfCbarge()，此方法允許AOC信息發(fā)送到可以接收該信息的終端；

·SuperviseReq()，調(diào)用此方法監(jiān)視呼叫Leg；

·Deassign()，此方法請求重新指定應(yīng)用和呼叫Leg以及相關(guān)對象的關(guān)系。

接口IpAppCallLeg繼承自IpInterface，應(yīng)用呼叫Leg接口用來處理與呼叫Leg請求相關(guān)的響應(yīng)和錯誤。

·EventReportRes()，此異步方法報告所要請求報告的事件；

·EvenlReportErr()，此異步方法指示處理呼叫Leg事件報告的請求未成功以及原因；

·GetlnfoRes()，此異步方法報告應(yīng)用所請求的所有必要信息；

·GetInfoErr()，此異步方法報告源端請求錯誤；

·RouteErr()，此方法報告路由錯誤；

·SuperviseRes()，此異步方法報告呼叫Leg監(jiān)視事件給應(yīng)用；

·SuperviseErr()，此異步方法報告呼叫Leg監(jiān)視錯誤；

·CallLegEnded()，此方法指示應(yīng)用網(wǎng)絡(luò)中Leg已結(jié)束。

3.多媒體呼叫控制

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

接口IpMultiMediaCallControlManager繼承了IpMultiPartyCallControlManager提供的所有方法而且通過提供兩個新的方法擴展了它的能力。通過這些方法可以媒體信道通知能力。當激活媒體信道通知能力時，包含兩個標準集。兩個標準集必須在信道報告給客戶應(yīng)用前全部實現(xiàn)。首先，多媒體呼叫必須與呼叫標準匹配(即目的呼叫碼必須在一定范圍內(nèi))，而且媒體信道指示也必須匹配。企業(yè)側(cè)的對應(yīng)接口IpAppMultiMediaCallControlManager繼承了IpAppMultiPartyCallControlManager接口的所有方法，引入了一個新方法，即媒體信道事件通知方法。

為代表網(wǎng)絡(luò)側(cè)的多媒體呼叫，使用一個實現(xiàn)IpMultiMediaCall接口的對象。接口繼承了IpMultiPartyCall接口的操作，引入一個新方法去設(shè)定一個呼叫認可的數(shù)據(jù)流量(以微秒測算)。當給定的數(shù)據(jù)量過期后，企業(yè)側(cè)稱IpAppMultiMediaCall的對應(yīng)接口收到事件的通知。

接口IpMultiMediaCallLeg繼承了IpCallLeg的所有操作，客戶應(yīng)用通過調(diào)用這個接口的方法能夠監(jiān)控和影響媒體信道。該接口提供了三個新的操作，其中一個是能夠監(jiān)控打開和關(guān)閉媒體信道，這又包括兩種監(jiān)控類型：一般監(jiān)控(滿足任何媒體類型)或指定監(jiān)控(僅當使用指定媒體類型的信道才發(fā)送通知)。如果監(jiān)控設(shè)置為中斷模式，為打開這種媒體信道，應(yīng)用必須顯式地允許接入。IpMultiMediaCallLeg接口提供相應(yīng)的方法，其引入的最新方法使得可以接入所有與這個呼叫Leg相關(guān)的已打開的媒體信道列表的方法(注意，一個呼叫Leg可與幾個媒體信道相聯(lián)系)。

在企業(yè)側(cè)必須實現(xiàn)IpAppMuhiMediaCallLeg接口，它繼承了父類IpAppCallLeg的方法。引入一個新的操作，即媒體信道通知，當打開或關(guān)閉滿足請求的檢測標準時，由Parlay網(wǎng)關(guān)調(diào)用。

多媒體呼叫控制包含的最后一個接口是IpMulfiMediaChannel，這個接口表現(xiàn)為與呼叫Leg聯(lián)系的單向數(shù)據(jù)流。只有一個方法可用，即關(guān)閉信道。

4.會議呼叫控制控制

會議呼叫控制是Parlay API定義的最高級的呼叫控制形式。會議呼叫控制服務(wù)用會議和子會議的概念提升了多媒體呼叫控制服務(wù)。會議與多媒體、多方呼叫的不同點是會議資源可提前保留。子會議是會議中全部Legs的子集，只有在同一子會議中的Legs才能相互通信(即只有在同一子會議的Legs間才有媒體通路)。

有兩種會議開始方式：沒有會議資源的優(yōu)先保留和有會議資源的優(yōu)先保留。在會議呼叫控制服務(wù)中，有六個接口最重要：

·IpConfCallControlManager是必須用以生成會議和資源管理的接口。它繼承了父類接口IpMultiMediaCallControlManager，但也增加了重要的新成員。該接口提供建立新會議及檢測會議是否有足夠的資源可用、為會議預(yù)留資源和釋放分配資源的方法。當建立一個新的會議時，應(yīng)用必須指明要用的子會議數(shù)目。它至少為1，會議參加者數(shù)目和預(yù)期的會議時長也在建立會議的請求時提供，網(wǎng)絡(luò)隨后盡力在指定的時間分配必要的資源。如果資源可用，會議開始。當會議時長超出了資源預(yù)留的時間，資源不再保證，但會議可以繼續(xù)。注意，如果需要資源滿足另外的請求，會議可能被網(wǎng)絡(luò)結(jié)束或拒絕。

IpConfCallControlManager接口也提供檢測在給定的預(yù)計時間是否有足夠的資源可用的方法。調(diào)用此方法時，必須輸入指定的開始和結(jié)束日期以及時間(代表搜索間隔)、可選的期望參加者數(shù)目和會議周期。搜索算法返回實際可利用的資源、會議時長和開始時間。注意此方法仍然沒有保留資源。為了保留資源，IpConfCallControlManager接口提供了另一個方法。作為此方法的參數(shù)，必須制定開始的日期和時間，參加者數(shù)目和會議預(yù)期時長，以及會議指定的策略、內(nèi)容、是否允許會議建立以后實體加入等。

IpConfCallControlManager接口提供的最后一個方法專為釋放先前保留的資源，本方法有效地取消了資源預(yù)留。

·IpAppConfCallControlManager提供了當會議因先前的預(yù)約由網(wǎng)絡(luò)建立時，Parlay網(wǎng)關(guān)調(diào)用的方法。它繼承了IpAppMuhiMediaCallManager接口，除了以上描述的方法外，沒有引入新的方法。

·lpConfCall接口繼承了IpMuhiMediaCall接口，用以管理子會議，也可向不需要知道有多個子會議的應(yīng)用隱藏子會議。除了繼承的方法外，該接口提供了請求會議中所有子會議列表的新方法，以建立新子會議和請求監(jiān)控事件。

·IpAppConfCall是相對于lpConfCall接口的企業(yè)側(cè)接口。IpAppConfCall接口接收通過IpConfCall接口調(diào)用的請求的響應(yīng)。它繼承了父接口IpAppMultiMediaCall的方法，且提供了兩個新方法。

首先，通過lpAppConfCall接口，提供當?shù)竭_一個新的實體(和呼叫Leg)時的通知方法。例如可以用于計劃會議(會議資源已經(jīng)預(yù)留)，這里參加者使用資源預(yù)留期間提供的地址可以撥進會議(如果會議策略允許撥入)。

第二個新的操作是通知應(yīng)用實體的離去，當實體離開會議和監(jiān)控實體提前申請離開，應(yīng)由Parlay網(wǎng)關(guān)調(diào)用。

·IpSubConfCall提供管理子會議的操作。子會議又稱為一個會議中所有Legs的子集，所以僅在同一子會議的Legs才能相互通信。它繼承了IpMultiMediaCall，并提供幾個新的方法。其中一個方法是分拆子會議，在這種情況下，子會議中的一些Legs移往新建的子會議。相應(yīng)的，也提供了合并子會議的方法，在這種情況下，該子會議中的所有Legs移往一已經(jīng)存在的子會議，且釋放空子會議。該接口也提供了將呼叫Leg移往另一子會議的方法。通過IpSubConfCall接口，可以改變多媒體(子)會議策略。

·IpAppSubConfCall接口允許通知應(yīng)用關(guān)于子會議的事件。它繼承了IpAppMultiMediaCall接口，并引入了兩個新的操作，都是用來調(diào)用去通知應(yīng)用網(wǎng)絡(luò)所作的請求。一個方法用于提供主席請求，另一個提供坐席請求。

整個測試系統(tǒng)由四部分組成(如圖2所示)：

·模擬Parlay網(wǎng)關(guān)模塊：主要實現(xiàn)Parlay網(wǎng)關(guān)的功能；

·測試用例運行模塊：主要實現(xiàn)對測試用例的加載、運行；

·測試結(jié)果保存模塊：保存測試用例測試的結(jié)果，并可查詢和對比；

·輔助工具模塊：對測試提供輔助工具。

其中，測試用例運行模塊和模擬Parlay網(wǎng)管模塊在測試平臺中起關(guān)鍵作用，可以通過測試用例運行模塊編寫測試用例。此模塊可以設(shè)計成并行執(zhí)行，每次可以加載多個測試用例同時進行。特別是在驗證大話務(wù)量的情況下，應(yīng)用服務(wù)器在Parlay API傳遞中是否能夠保證消息、參數(shù)以及調(diào)用順序上的正確性。

圖2　Parlay API測試方案的整體架構(gòu)

模擬Parlay網(wǎng)關(guān)模塊對外提供兩種接口：一種是基于CORBA的遠程調(diào)用接口，該接口主要用于同Parlay應(yīng)用服務(wù)器進行正常的Parlay API交互；另一種是向測試用例提供的Java本地API接口，測試用例通過使用此接口通知模擬網(wǎng)關(guān)應(yīng)該向應(yīng)用服務(wù)器發(fā)送哪個Parlay API調(diào)用。因此，該接口需要為測試用例提供的功能，包括創(chuàng)建各種IP側(cè)接口實例，設(shè)定Parlay方法的各個參數(shù)，指定應(yīng)該向Parlay應(yīng)用服務(wù)器發(fā)起哪一個方法調(diào)用等。實際上，模擬Parlay網(wǎng)關(guān)模塊的這種本地API接口就是提供給測試用例使用的控制接口，測試用例通過該接口來控制模擬Parlay網(wǎng)關(guān)模塊完成CORBA對象的創(chuàng)建和Parlay方法的封裝及調(diào)用工作，而測試過程中的呼叫狀態(tài)信息主要由測試用例自身保存和更改。

四、基于白盒測試的測試用例的實現(xiàn)

在此測試系統(tǒng)中，每個測試用例應(yīng)分為兩個部分。①網(wǎng)關(guān)側(cè)測試集：主要功能是測試用例運行時，向Parlay應(yīng)用服務(wù)器發(fā)送一個模擬呼叫清求，然后配合業(yè)務(wù)邏輯執(zhí)行測試操作。②業(yè)務(wù)側(cè)測試集：主要是接收由Parlay應(yīng)用服務(wù)器轉(zhuǎn)發(fā)來的網(wǎng)關(guān)側(cè)呼叫請求，然后配合網(wǎng)關(guān)部分執(zhí)行測試操作，并將測試結(jié)果保存到相應(yīng)的文件中。

網(wǎng)關(guān)側(cè)和業(yè)務(wù)側(cè)的測試集分別在測試平臺和Parlay應(yīng)該用服務(wù)器中運行，測試用例需要分別單獨編寫。其中，業(yè)務(wù)側(cè)的測試集作為業(yè)務(wù)的一種，網(wǎng)關(guān)側(cè)的測試集需要調(diào)用測試系統(tǒng)中的ITestInstance接口。測試用例的相關(guān)信息在測試用例腳本文件中提供。這些相關(guān)信息包括：①測試用例的名稱，用來惟一表示測試用例。②網(wǎng)關(guān)側(cè)測試類的類名，每個測試用例都對應(yīng)著一個網(wǎng)關(guān)側(cè)的Java類，測試平臺對測試用例的加載實際上就是創(chuàng)建并加載相應(yīng)的Java類，測試用例的執(zhí)行就是執(zhí)行該Java類的相應(yīng)接口方法。③業(yè)務(wù)側(cè)測試類名。每個測試用例都要有對業(yè)務(wù)的支持，因此需要在腳本文件中為每個測試用例指定相應(yīng)的業(yè)務(wù)名稱。④測試用例所使用的呼叫類型，該呼叫類型指定測試用例所對應(yīng)的上層業(yè)務(wù)是基于何種呼叫類型。

對于Parlay API的測試方案，我們采取白盒測試的方法進行測試。

白盒測試應(yīng)用于本測試系統(tǒng)中，主要是對業(yè)務(wù)邏輯調(diào)用的考察，因此，我們必須制訂好測試的實施步驟：

·測試計劃階段：根據(jù)業(yè)務(wù)說明書，制定測試進度；

·測試設(shè)計階段：依據(jù)業(yè)務(wù)的程序沒計說明書，按照一定規(guī)范化的方法進行軟件結(jié)構(gòu)劃分和測試用例的設(shè)計；

·測試執(zhí)行階段：加載測試用例，得到測試結(jié)果；

·測試總結(jié)階段：對比測試的結(jié)果和代碼的預(yù)期結(jié)果，分析錯誤原因，找到并解決錯誤。

由于本測試操作主要是通過API的調(diào)用情況和調(diào)用順序來體現(xiàn)的，這就要求在每次測試操作中，測試用例需要將業(yè)務(wù)側(cè)對網(wǎng)關(guān)側(cè)以及網(wǎng)側(cè)對業(yè)務(wù)側(cè)的APl調(diào)用信息，API所繼承的類名、方法名等保存到相應(yīng)的測試結(jié)果文件中，最后通過比較相關(guān)的測試結(jié)果文件就能獲知測試用的執(zhí)行結(jié)果是否正確。在整個測試過程中，對Parlay API的調(diào)用情況可以分為兩類：業(yè)務(wù)側(cè)和網(wǎng)絡(luò)側(cè)調(diào)用情況。每種情況又可以分為兩類：主動調(diào)用和被動調(diào)用。這四種情況是對應(yīng)的，業(yè)務(wù)側(cè)的主動調(diào)用和網(wǎng)關(guān)側(cè)的被動調(diào)用情況對應(yīng)，網(wǎng)關(guān)側(cè)的主動調(diào)用情況和業(yè)務(wù)側(cè)的被調(diào)用情況對應(yīng)。

基本操作流程：

第一步：測試系統(tǒng)首先應(yīng)根據(jù)配置文件中所設(shè)置的參數(shù)初始化CORBA環(huán)境，創(chuàng)建Parlay中各網(wǎng)絡(luò)側(cè)Manager接口類的CORBA對象以及測試結(jié)果保存模塊所必須的CORBA對象，并將這些CORBA對象注冊到CORBA命名服務(wù)中，以供應(yīng)服務(wù)器和測試用例使用；

第二步：測試系統(tǒng)從測試用例腳本文件中讀取所有要執(zhí)行的測試用例的相關(guān)信息，包括測試用例的名稱、網(wǎng)管側(cè)測試類名、業(yè)務(wù)側(cè)測試類名以及呼叫類型等，并保存下來；

第三步：加載測試用例到Parlay應(yīng)用服務(wù)器中，然后激活；

第四步：運行測試用例；

第五步：在測試過程中，測試用例的業(yè)務(wù)側(cè)測試類，測試平臺的模擬Parlay網(wǎng)關(guān)模塊把各自對Parlay API的調(diào)用情況，通過測試結(jié)果保存模塊將相應(yīng)的測試結(jié)果保存到結(jié)果文件中去；

第六步：測試用例執(zhí)行結(jié)束后，清除所有進程，去掉前面已經(jīng)加載的測試用例。

第七步：統(tǒng)計、分析測試結(jié)果，用戶可通過各種文本文件比較工具比較測試結(jié)果文件內(nèi)容的異同。

對于Parlay應(yīng)用服務(wù)器接口測試的需求，這種自動化測試平臺具有如下優(yōu)點：

·測試平臺實現(xiàn)比較簡單，本測試平臺只需按照測試用例的要求生成相應(yīng)的Parlay API調(diào)用，無需維護模擬呼叫的狀態(tài)信息；

·測試用例編寫靈活，模擬呼叫的狀態(tài)信息以及各Parlay API方法的參數(shù)均由測試用例提供，只要測試用例的功能足夠，即可支持真實業(yè)務(wù)的功能測試；

·測試操作的自動化。

五、結(jié)語

Parlay應(yīng)用服務(wù)器可以提供不同抽象層次的業(yè)務(wù)開發(fā)接口、以便不同能力不同類型的業(yè)務(wù)開發(fā)者開發(fā)豐富多彩的業(yè)務(wù)，例如，可以提供基于CORBA的Parlay API接口、基于JAIN SPA標準的Java API接口、以及基于Javabeans的接口，基于XML、CPL、VoiceXML的接口等，業(yè)務(wù)開發(fā)者也可以根據(jù)業(yè)務(wù)的需要和自己的能力來選擇合適的開發(fā)接口。

業(yè)務(wù)的多樣性給測試帶來了很大的不便，購買大量設(shè)備建設(shè)模擬環(huán)境的確不是一個理想的測試方案，上述基于白盒的檢測方法大大簡化了模擬環(huán)境的配置，可以通過軟件來模擬網(wǎng)絡(luò)環(huán)境，考察API的調(diào)用情況。