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

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

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

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

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

Parlay APl是一個(gè)標(biāo)準(zhǔn)的接口，從而能夠使第三方通過此接口利用運(yùn)營(yíng)商的基礎(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ù)，如點(diǎn)擊撥號(hào)、VoIP、點(diǎn)擊傳真、可視通話、會(huì)議電話，以及與位置相關(guān)的緊急呼叫業(yè)務(wù)等；

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

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

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

各類業(yè)務(wù)可以相對(duì)獨(dú)立，也可以有機(jī)地結(jié)合，例如可以在查詢信息時(shí)根據(jù)相應(yīng)的信息進(jìn)行支付類業(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ù)器中注冊(cè)的、滿足業(yè)務(wù)需求的業(yè)務(wù)能力管理類接口引用。業(yè)務(wù)邏輯通過獲得業(yè)務(wù)能力管理類接口引用就可以和其對(duì)應(yīng)的業(yè)務(wù)能力接口進(jìn)行通信，實(shí)現(xiàn)特定業(yè)務(wù)邏輯的呼叫控制、用戶交互及計(jì)贊等功能。

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

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

業(yè)務(wù)支撐環(huán)境是業(yè)務(wù)實(shí)現(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ò)資源，從而實(shí)現(xiàn)了業(yè)務(wù)與呼叫控制的分離，有利于新業(yè)務(wù)的引入。
  應(yīng)用服務(wù)器可分為SIP應(yīng)用服務(wù)器和Parlay應(yīng)用服務(wù)器兩類，前者與軟交換之間采用SIP協(xié)議進(jìn)行交互，后者將采用Parlay API作為與軟交換之間的接口。通過協(xié)議開發(fā)業(yè)務(wù)的主要特點(diǎn)是：開發(fā)的業(yè)務(wù)與特定的網(wǎng)絡(luò)和協(xié)議有關(guān)，即應(yīng)用與具體的協(xié)議和網(wǎng)絡(luò)相聯(lián)系，這樣開發(fā)的業(yè)務(wù)互通性不好，同時(shí)業(yè)務(wù)也不可移植。而采用基于開放API開發(fā)方法的主要特點(diǎn)是：互通性好，具有可編程性，可擴(kuò)展性好，支持第三方業(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級(jí)別等。業(yè)務(wù)供應(yīng)商可以按照不同的業(yè)務(wù)邏輯調(diào)用它們以實(shí)現(xiàn)不同的業(yè)務(wù)。②框架接口(Frame-work Interface)：它們對(duì)客戶端使用業(yè)務(wù)接口提供必需的安全、管理支持�？蚣芊�務(wù)器保證了底層通信網(wǎng)的安全開放和Parlay服務(wù)器的有序運(yùn)行。業(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ù)器中注冊(cè)的、滿足業(yè)務(wù)需求的業(yè)務(wù)能力管理類接口調(diào)用。業(yè)務(wù)邏輯通過獲得業(yè)務(wù)能力管理類接口調(diào)用就可以和其對(duì)應(yīng)的業(yè)務(wù)能力接口進(jìn)行通信，實(shí)現(xiàn)特定業(yè)務(wù)邏輯的呼叫控制、用戶交互及計(jì)費(fèi)等功能。

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

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

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

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

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

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

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

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

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

測(cè)試方案可以細(xì)化為被測(cè)系統(tǒng)、被測(cè)實(shí)體和服務(wù)SP三個(gè)部分，其中，被測(cè)系統(tǒng)為Parlay應(yīng)用服務(wù)器；被測(cè)實(shí)體是Parlay應(yīng)用服務(wù)器的Parlay接口功能；為測(cè)試系統(tǒng)和被測(cè)系統(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實(shí)現(xiàn)了對(duì)下層網(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)用上報(bào)所有的呼叫事件及業(yè)務(wù)的操作結(jié)果。因此，在整個(gè)測(cè)試環(huán)境中需要兩個(gè)測(cè)試器：位于網(wǎng)關(guān)側(cè)的呼叫模擬和位于業(yè)務(wù)側(cè)的業(yè)務(wù)模擬。對(duì)于兩側(cè)的測(cè)試器，可以設(shè)置兩個(gè)觀察窗口，對(duì)兩側(cè)API的調(diào)用情況分別進(jìn)行監(jiān)測(cè)。

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

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

1．一般呼叫控制

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

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

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

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

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

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

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

2.多方呼叫控制

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

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

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

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

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

·GetCallLeg()，此方法請(qǐng)求與呼叫對(duì)象相關(guān)的呼叫Leg對(duì)象的標(biāo)識(shí)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·EventReportRes()，此異步方法報(bào)告所要請(qǐng)求報(bào)告的事件；

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

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

·GetInfoErr()，此異步方法報(bào)告源端請(qǐng)求錯(cuò)誤；

·RouteErr()，此方法報(bào)告路由錯(cuò)誤；

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

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

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

3.多媒體呼叫控制

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

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

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

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

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

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

4.會(huì)議呼叫控制控制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·測(cè)試用例運(yùn)行模塊：主要實(shí)現(xiàn)對(duì)測(cè)試用例的加載、運(yùn)行；

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

·輔助工具模塊：對(duì)測(cè)試提供輔助工具。

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

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

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

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

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

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

對(duì)于Parlay API的測(cè)試方案，我們采取白盒測(cè)試的方法進(jìn)行測(cè)試。

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

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

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

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

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

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

基本操作流程：

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

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

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

第四步：運(yùn)行測(cè)試用例；

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

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

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

對(duì)于Parlay應(yīng)用服務(wù)器接口測(cè)試的需求，這種自動(dòng)化測(cè)試平臺(tái)具有如下優(yōu)點(diǎn)：

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

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

·測(cè)試操作的自動(dòng)化。

五、結(jié)語(yǔ)

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

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