RTP協(xié)議多用戶組管理測試

趙利民

(天水師范學(xué)院 物信學(xué)院，甘肅 天水 741001)

0 引言

流媒體指在Internet/Intranet 中使用流式傳輸技術(shù)的連續(xù)時基媒體，如音頻、視頻或多媒體文件。 流媒體的核心部分是傳輸協(xié)議和文件格式。支持流媒體傳輸?shù)膮f(xié)議主要有實(shí)時傳輸協(xié)議RTP(Real-Time Transport Protocol)、實(shí)時傳輸控制協(xié)議RTCP (Real-Time Transport Control Protocol)和實(shí)時流協(xié)議RTSP (Real-Time Streaming Protocol)等[1]。 RTP 協(xié)議主要提供時間信息和實(shí)現(xiàn)流同步；RTCP 用來控制實(shí)時數(shù)據(jù)的發(fā)送和參與者的管理。 組管理的穩(wěn)定性決定協(xié)議傳輸?shù)慕研?，對于分布式協(xié)議實(shí)現(xiàn)，基于Estelle、Lotos 及SDL 的形式化描述和測試并不具有優(yōu)勢，在協(xié)議實(shí)現(xiàn)和遠(yuǎn)程IUT 之間缺乏有效的聯(lián)系管理手段。以抽象狀態(tài)機(jī)和接口自動機(jī)為理論基礎(chǔ)的抽象狀態(tài)機(jī)語言 (ASML，Abstract State Machine Language)[2]及其環(huán)境，屬于灰盒測試方式，結(jié)合Windows 系統(tǒng)下可視化編程環(huán)境， 可廣泛用于內(nèi)部單元測試，集成測試，協(xié)議測試。本文詳細(xì)論述了基于抽象狀態(tài)機(jī)模型的RTP 協(xié)議多用戶組管理的形式化描述、分布式測試及協(xié)議一致性測試結(jié)果分析。

1 測試過程的形式化描述

1.1 抽象狀態(tài)機(jī)形式化描述方法

ASML 通過Spec Explorer 環(huán)境來描述具體的應(yīng)用，其內(nèi)部的形式化描述基于接口自動機(jī)模型并按照抽象狀態(tài)機(jī)的描述方式賦予接口自動機(jī)更嚴(yán)格和精確的語意。接口自動機(jī)可以定義為以下七元組形式[3]：

M=（S，Sinit，Ac，Ao，Γc，Γo，δ），其中

S 是狀態(tài)集合，Sinit?S 是初始狀態(tài)集合；Ac和Ao是非交的可控方法(controllable actions)和可被觀察方法(observable actions)的集合，而總方法集合 A=Ac∪Ao；Γc：S→P（Ac）和 Γo：S→P（Ao）分別表示在某一狀態(tài)滿足條件可執(zhí)行的可控函數(shù)和可被觀察函數(shù)的集合，而Γ（s）表示在狀態(tài)s 集合A 中滿足條件能執(zhí)行的所有方法的并集，即Γ（s）=Γc（s）∪Γo（s）；δ：S×A→S 是一個轉(zhuǎn)換函數(shù)，映射由狀態(tài) s、方法 a（a∈Γ（s））經(jīng)由狀態(tài)函數(shù) δ 轉(zhuǎn)換到下一個狀態(tài) δ（s，α）；滿足 Γ（s）=φ的狀態(tài) s 稱為終態(tài)；而滿足 Γo（s）=φ的非終態(tài) s 稱為活動狀態(tài)，否則稱為被動狀態(tài)。

1.2 測試執(zhí)行

一致性測試就是驗(yàn)證由IUT 對應(yīng)的接口自動機(jī)是否和由模型生成的接口自動機(jī)相一致。假設(shè)是模型語言描述生成的接口自動機(jī)δN）表示由被測協(xié)議實(shí)現(xiàn)對應(yīng)的接口自動機(jī)。 定義 M 到 N 的二元關(guān)系 ρ∈SM×SN。 對所有的 s∈SM和 t∈SN，滿足（s，t）∈ρ，以下兩條件成立：

對應(yīng)有以下簡化關(guān)系：

以上關(guān)系可以描述為：在任意狀態(tài)，模型描述的可控方法(Controllable Action)能夠執(zhí)行，則對應(yīng)的IUT 中的對應(yīng)可控方法也必須能夠執(zhí)行；如果IUT 中的可觀察方法 (Observable Action)能夠執(zhí)行，則對應(yīng)的模型接口自動機(jī)里的可觀察方法也必須能夠執(zhí)行。 如果不能一一對應(yīng)，則會出現(xiàn)不一致錯誤。

在本測試環(huán)境中，協(xié)議測試的執(zhí)行，前提是所有的模型內(nèi)的方法必須和IUT 內(nèi)對應(yīng)的方法綁定，這一步驟保證了函數(shù)體、輸入?yún)?shù)類型和個數(shù)的一致性。 而接口自動機(jī)M 和N 的一致性則體現(xiàn)在返回結(jié)果的一致性上。 對任意非終態(tài)s∈SM，可控方法可表示為 α=m（υ）/wM，其中 υ 是輸入?yún)?shù)，wM是結(jié)果變量，m 是 α 對應(yīng)的實(shí)際方法。在狀態(tài)s 如果前提條件Pr eM（v）成立，則同時執(zhí)行模型和IUT 中的m 方法， 并比較各自的結(jié)果變量 wM和 wN；如果前提條件 Pr eM（v）不滿足或是wM≠wN，則返回一致性失敗錯誤。 而可觀察方法則是先執(zhí)行IUT 中m 方法，并緩存結(jié)果wN，然后在前提Pr eM（v）成立的條件下，執(zhí)行對應(yīng)m方法，如果前提Pr eM（v）條件不滿足或是wN≠wM，也返回一致性失敗錯誤。

1.3 基于狀態(tài)模型的協(xié)議一致性測試結(jié)構(gòu)

基于抽象狀態(tài)機(jī)的協(xié)議一致性測試流程如圖 1 所示[4]。 協(xié)議模型描述采用 ASML 或是Spec#描述。 測試集是基于協(xié)議ASML 形式化描述生成的FSM（Finite State Machine）自動生成的。由協(xié)議狀態(tài)圖生成的測試集保證測試?yán)倪\(yùn)行與狀態(tài)轉(zhuǎn)換過程完全一致。

圖1 一致性測試流程

2 基于抽象狀態(tài)機(jī)的協(xié)議一致性測試模型

對于測試系統(tǒng)中被測對象IUT 而言，根據(jù)測試系統(tǒng)所控制的PCO 的位置不同， 可分為以下四種基本測試方法[5]：本地測試法；分布式測試法；協(xié)同測試法；遠(yuǎn)程測試法。基于抽象狀態(tài)機(jī)的協(xié)議一致性測試模型，根據(jù)以上分類，可以衍生出三種典型測試結(jié)構(gòu)[6]，對于RTP 組用戶管理屬于多用戶分布式行為測試，采用分布式測試模型二。模型語言描述的自動機(jī)方法和對應(yīng)的中間包裝程序的樁函數(shù)進(jìn)行綁定，再由樁函數(shù)通過遠(yuǎn)程通道實(shí)現(xiàn)和IUT 對象通訊。 通過樁函數(shù)的包裝，能使得協(xié)議接口自動機(jī)和IUT 之間傳遞測試參數(shù)， 并檢查返回值wM，wN是否相等來驗(yàn)證一致性。 協(xié)議實(shí)現(xiàn)可以采用任何語言，測試過程不關(guān)心測試實(shí)現(xiàn)內(nèi)部的結(jié)構(gòu)，但是為了能調(diào)用被測實(shí)現(xiàn)內(nèi)部函數(shù)，要求被測實(shí)現(xiàn)在測試以前必須實(shí)現(xiàn)兩個條件：

（1） 以定義接口方式申明被測實(shí)現(xiàn)的被測方法函數(shù)格式；

（2）在測試開始以前，定義并啟動建立遠(yuǎn)程通道的函數(shù)。

圖2 協(xié)議一致性測試的基本模型

測試方在知道被測實(shí)現(xiàn)遠(yuǎn)程URL 和協(xié)議實(shí)現(xiàn)功能（即被測實(shí)現(xiàn)定義接口）情況下，就可以通過這種間接方式對遠(yuǎn)程方法引用，實(shí)現(xiàn)對IUT 的測試，如圖2 所示。 其中測試器部分為抽象狀態(tài)機(jī)描述并生成的被測協(xié)議狀態(tài)轉(zhuǎn)換圖；Wrapper部分為和狀態(tài)轉(zhuǎn)換方法一一對應(yīng)的樁函數(shù)，實(shí)際的具體測試數(shù)據(jù)封裝、發(fā)送和被測實(shí)現(xiàn)返回的數(shù)據(jù)解析由具體的樁函數(shù)完成，并和狀態(tài)圖設(shè)置的狀態(tài)值相比對， 看是否一致；IUT 部分為部署在遠(yuǎn)程的協(xié)議實(shí)現(xiàn)。被測協(xié)議實(shí)現(xiàn)和Wrapper 包裝函數(shù)的聯(lián)系是采用微軟的remoting[7]調(diào)用方式，建立一個TCP/Http 邏輯通道， 測試方和遠(yuǎn)程被測協(xié)議實(shí)現(xiàn)通過這個通道把執(zhí)行參數(shù)和測試響應(yīng)結(jié)果進(jìn)行交互。 采用這個方式，使得被測協(xié)議實(shí)現(xiàn)可以在遠(yuǎn)程部署和進(jìn)行； 大大縮短測試周期；有利于分布式協(xié)議和組播或廣播類的協(xié)議測試，如 RTP 協(xié)議。

3 RTP 協(xié)議一致性測試

實(shí)時傳輸協(xié)議（Real-time Transport Protocol，PRT）[8]是在Internet 上處理多媒體數(shù)據(jù)流的一種網(wǎng)絡(luò)協(xié)議，利用它能夠在一對一（unicast，單播）或者一對多（multicast，多播）的網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)流媒體數(shù)據(jù)的實(shí)時傳輸。采用形式化方法抽象狀態(tài)機(jī)語言描述流媒體傳輸協(xié)議的最基本的會話創(chuàng)建和其他會話者加入、離去、發(fā)送數(shù)據(jù)包的有限狀態(tài)機(jī)。 并在此基礎(chǔ)上，結(jié)合遠(yuǎn)程測試要求實(shí)現(xiàn)流媒體傳輸協(xié)議的遠(yuǎn)程分布式測試。

對于RTP 傳輸?shù)慕ⅲ?首先要有一方建立會話，每一個會話者有獨(dú)立的會話名標(biāo)識，協(xié)議實(shí)現(xiàn)會根據(jù)會話名生成成員信息表，其他會話者會根據(jù)收到的SDES 數(shù)據(jù)包中的信息，各自維護(hù)一個參與者的信息表。測試只是根據(jù)協(xié)議原語來執(zhí)行加入會話。

會話建立以后， 如果有其他會話者加入，則可以進(jìn)行數(shù)據(jù)的傳輸，如果沒有，則超時會話結(jié)束。 會話發(fā)起者也可以通過離開，來結(jié)束整個會話過程。 會話發(fā)起者離開以后，其他會話者列表清空，會話回到空閑狀態(tài)。

當(dāng)會話建立成功以后，其他參與者加入，會話發(fā)起者可以開始發(fā)送數(shù)據(jù)幀給其他所有用戶，因?yàn)槭怯蓞f(xié)議實(shí)現(xiàn)來組發(fā)， 所以發(fā)送只是單個操作，由協(xié)議保證發(fā)給所有會話的參與者。

其他參與者作為一個Agent 來加入到會話，對于會話創(chuàng)建者來說，其他會話者的行為屬于被動的，但是可以觀察行為，如果觀察到其他會話者加入，則將該會話者信息加入到partners 會話者列表。但這個過程要求被加入者的名字不能和會話者列表中已有的沖突。

加入到傳輸會話中的用戶，隨時可以選擇離開，如果收到Bye 數(shù)據(jù)包，或是檢查到超時，都會產(chǎn)生離開會話動作。離開也是屬于可觀察的被動行為，如果觀察到某一個會話者離開，則將其從會話列表中去除。

當(dāng)然對于加入到會話中的任何一個參與者，它可以發(fā)送或是接收數(shù)據(jù)，對于被測協(xié)議實(shí)現(xiàn)，控制它的發(fā)送，觀察它的接收行為。 而對于協(xié)議測試協(xié)同工作的其他代理(Agent)，測試中根據(jù)狀態(tài)圖描述， 主要控制Agent 的加入會話是在被測協(xié)議實(shí)現(xiàn)建立會話以后，Agent 就處于工作狀態(tài)，如果接收到會話建立者發(fā)送的數(shù)據(jù)包，它會相應(yīng)的發(fā)送一個數(shù)據(jù)包。 并在隨機(jī)一段時間延時后自己退出會話。 下面是會話發(fā)送數(shù)據(jù)幀的描述：

以上抽象狀態(tài)機(jī)語言描述， 在SPEC EXPLORER 環(huán)境下可編譯生成以下狀態(tài)轉(zhuǎn)換圖：

圖3 單Agent 時的狀態(tài)轉(zhuǎn)換圖

圖4 兩個Agent 時的狀態(tài)轉(zhuǎn)換圖

以上狀態(tài)控制過程，結(jié)合Agent 來模擬其他用戶的行為，每一個Agent 模擬RTP 會話參與者的基本行為：加入會話，離開會話，接收來自會話發(fā)送者的數(shù)據(jù)并發(fā)送回復(fù)數(shù)據(jù)。 如圖5 所示，除了第一個RTP 協(xié)議實(shí)體是由Spec Explorer 遠(yuǎn)程控制其測試的執(zhí)行， 其他Agents 都是在會話建立以后由Wrapper 控制其開始運(yùn)行，其內(nèi)部行為包括加入一個Session，交換信息，離開Session。當(dāng)然遠(yuǎn)程測試方法具有的優(yōu)點(diǎn)就是可以把所有Agent 按照第一個被測RPE 的形式設(shè)置成可控制的遠(yuǎn)程RTP 協(xié)議實(shí)體，為了簡化描述，在這里只對實(shí)際被測IUT 進(jìn)行遠(yuǎn)程控制和測試， 其他Agent 按照啟動后由定時器按照隨機(jī)時間來激發(fā)起基本內(nèi)部行為的方式運(yùn)行來模擬實(shí)際的RTP運(yùn)行環(huán)境。

圖5 流媒體傳輸協(xié)議測試結(jié)構(gòu)

4 結(jié)論

分別對存在 1，2，3，4，5 個 Agent 時 RTP 協(xié)議實(shí)現(xiàn)進(jìn)行了一致性測試，表1 是遠(yuǎn)程測試執(zhí)行后獲得的覆蓋率。

表1 RTP 一致性測試覆蓋率表

覆蓋率就是有限狀態(tài)機(jī)對應(yīng)的被執(zhí)行的測試步和所有測試步的比率， 當(dāng)然在測試過程中，如果任何一步有不一致， 測試將報錯并停止執(zhí)行，這種情況下測試覆蓋率將會很低。 在當(dāng)前的最大重試次數(shù)達(dá)到時，對于多個Agent 的情況還有可能有些測試步?jīng)]有執(zhí)行，因?yàn)殡S著Agent 數(shù)目的增多，測試集以指數(shù)形式增加，對應(yīng)的測試覆蓋率將會達(dá)不到100%。 實(shí)現(xiàn)和被測協(xié)議的形式化描述有任何不一致的地方，測試將立即發(fā)現(xiàn)并停止。 但即使測試過程中沒有發(fā)現(xiàn)不一致，只要測試覆蓋率沒有達(dá)到100%， 則只能說明覆蓋到的測試步?jīng)]有問題。

以上測試覆蓋率說明，被測的流媒體傳輸協(xié)議實(shí)現(xiàn)， 在一個和兩個會話者參與的情況下，其實(shí)現(xiàn)和協(xié)議規(guī)范定義相一致；而在三個及其以上用戶參與時，在目前的測試范圍內(nèi)沒有發(fā)現(xiàn)協(xié)議不一致問題。但是覆蓋率隨著狀態(tài)數(shù)的增加在快速下降， 而這與狀態(tài)空間的猛增具有必然的聯(lián)系。

[1]陳爽文.流媒體技術(shù)綜述[J].北京廣播學(xué)院學(xué)報(自然科學(xué)版)，2003.1.

[2]Asml， the website[DB/OL]. http：//research.microsoft.com/fse/asml/.

[3]L.de Alfaro and T.A.Henzinger.Interface automata[M].in Proceedings of the 8th European Software Engineering Conference and the 9th ACM SIGSOFT symposium on the Foundations of Software Engineering， ACM Press， 2001，pp.109-120.

[4]Egon Borger. The origins and development of the ASM method for high level system design and analysis[J]. Journal of Universal Computer Science，2002，8(1)：2-74.

[5]古天龍，蔡國慶.網(wǎng)絡(luò)協(xié)議的形式化分析與設(shè)計(jì)[M].北京：電子工業(yè)出版社，2003，6.

[6]趙利民，尚稱平.基于ASM 模型的協(xié)議一致性測試研究[J].自動化與儀器儀表，2011.1：P12-14.

[7]Mike Barnett，Wolfram Schulte. Runtime verification of.NET contracts[DB/OL].

[8]H Schulzrinne，S Casner， et al. RTP： A Transport Protocol for Real-time Applications[S].RFC 1889，January 1996.