專利名稱：測試網絡通信中的通信協(xié)議的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種用于測試諸如Internet網絡中使用的通信協(xié)議的方法 和系統(tǒng)。更具體地，本發(fā)明涉及一種用于測試設備的相容性和強健性的測 試方法和系統(tǒng)，該設備使用一特定的信令協(xié)議與使用相同信令協(xié)議的其他 設備進行通信，具體地，例如會話啟動協(xié)議(SIP)。
背景技術：
例如通過因特網(internet)運行的網絡通信，需要一個信令協(xié)議來建立上 線通知(presence)、査找用戶、啟動、修改或終止會話。目前的受歡迎的 一個信令協(xié)議是會話啟動協(xié)議(SIP)。這是用于網絡會議、電話、上線通 知、事件通知和即時發(fā)送消息的協(xié)議。SIP是在IETF MMUSIC (多方多媒 體會話控制)工作組內開發(fā)的，并從那時起迅速成為各種形式的基于IP網 絡的多媒體通信的基本構建模塊。為此，SIP啟動實體(使用SIP作為信令 的設備)必須滿足全IP環(huán)境帶來的新的挑戰(zhàn)和威脅，必須通過及時測試確 保其相容性和強健性。
為了確保SIP實體中的SIP實現(xiàn)符合標準并且沒有缺陷導致系統(tǒng)安全 妥協(xié)和/或不希望的系統(tǒng)癱瘓，應該在配置之前進行全面的測試。目前商業(yè) 上可得到多種測試工具。這些測試器的例子可以從下述網址找到。
www.testingtech.de/products/ttsuite_sip.php;
www.solinet.com/sip_conf tester.htm; www.codenomicon.com/testtools/sip/index.html
可得到的測試方法需要寫復雜腳本命令和程序的技巧和努力，并僅限 于測試兩個SIP實體之間的通信。
因此，需要更簡單和更經濟的方法來在網絡通信上執(zhí)行全面測試，該 通信可能涉及多于兩個實體。

發(fā)明內容
本發(fā)明的一個目的在于提供一種新的方法和系統(tǒng)，用于測試使用一特 定信令協(xié)議(如SIP)的特定網絡的一個實體，該方法和系統(tǒng)能夠測試基于 該協(xié)議及包含連接到該網絡的數(shù)個實體的復雜的網絡通信。本發(fā)明的另一 H的在于提供一個測試架構，該測試架構使用基于模板的測試腳本命令， 該命令的書寫更簡單，不使用復雜的編程結構，該測試架構還提供一種靈 活、可擴展的、可升級的、可定制的、用戶化的并易于使用的測試方法。
本發(fā)明的這個和其他目的是通過提供一個測試架構達到的，該測試架
構(i)使用簡單腳本命令，較好地，基于模板的文本文件腳本命令；(ii) 具有一個稱為"測試指導(TestDirector)"的集中測試控制器；(iii)具有一 個或多個稱作"談判器"的測試客戶。測試指導和談判器都是軟件實現(xiàn)的， 可以運行在單獨的計算機或幾個計算機中。測試指導與所有談判器有連接 關系，以便它可以向談判器發(fā)布命令。所有談判器和受測試系統(tǒng)(此后稱 作SUT)連接到同一網絡，它們根據(jù)諸如TCP或UDP的協(xié)議通信。對于
本發(fā)明的測試架構，SUT可以為使用測試中的信令協(xié)議的任何的實體。例
如，對于SIP測試架構，SUT可以是任何SIP啟動實體，例如SIP代理、 SIP重定向服務器、SIP電話、SIP電視等。
本發(fā)明的各種新穎特征在后附的權利要求中特別指出并構成此公開內 容的一部分。為了更好地理解本發(fā)明、其操作優(yōu)點、使用本發(fā)明獲得的具 體目的，應參考附圖和下面的說明書，其中說明了本發(fā)明的優(yōu)選實施例。


圖1是顯示本發(fā)明的測試架構的基本結構的靜態(tài)視圖2是圖1中的測試架構工作中的視圖3是顯示本發(fā)明的測試架構的高級工作流程的流程圖4是顯示圖3中的流程圖的方塊A5內的細節(jié)的流程圖； 圖5是顯示圖4中的流程圖的方塊A5-4內的細節(jié)的流程圖； 圖6顯示了測試用例的層次結構的例子。
具體實施例方式
本發(fā)明的測試架構的基本結構
參考圖l，這是典型的用于測試SIP實體的測試架構的基本結構。該 基本結構包括SUT 10 (受測試系統(tǒng))、兩個談判器11和12 (分別運行于不 同計算機上)。SUT lO和談判器ll、 12利用連接方式20連接到同一網絡 30，連接方式20基于TCP或者UDP。此外，談判器ll、 12通過任何預定 的控制協(xié)議連接到測試指導(TestDirector)13，該預定的控制協(xié)議可以由本領
域技術人員容易地設計和實施，由此接收來自測試指導13的命令。談判器 和測試指導都是軟件實現(xiàn)的，可以由計算機編程人員使用合適的計算機編
程語言書寫，例如basic、 pascal/delphi、 c/c++、 java、 c弁等等(這里只例舉 了幾種)。雖然談判器和測試指導在圖1中顯示運行在分開的計算機上，它 們可以實施運行在一個計算機上，其中每個談判器和測試指導具有其各自 分配的網絡端口號。無論談判器和測試指導是運行在相同還是不同的計算 機上，他們都可以取回存儲在同一源14中的文件。典型的文件包括但不限 于(1)談判器和測試指導的配置文件，(2)用于定義測試用例的屏幕播 放文件；(3)用于支持屏幕播放文件的消息文件。SUT是測試的主體，對 于此特定SIP測試架構來說，SUT可以是任何SIP實體。當然，該架構可 以容易地被普通技術人員采用來測試其他信令協(xié)議。
圖2顯示了當測試指導正在執(zhí)行典型的測試時發(fā)生的事情。測試指導 檢測何時談判器開始執(zhí)行測試。在測試開始前，必須準備好3種類型的文 件，以便由測試指導和談判器取用配置文件、屏幕播放文件和消息文件。 這些文件將在后面詳述。
配置文件包括測試指導和所有談判器的配置信息(profile)。測試指導 的配置信息包含網絡地址(IP地址和端口號)，通過網絡地址可以聯(lián)絡到測 試指導。談判器的配置信息包括網絡地址和其它用戶定義的特性，在網絡 地址上談判器可以傾聽進入的SIP流量，用戶可以定義的特性的數(shù)量是無 限的。
測試用例的屏幕播放文件包括一些指令，關于談判器應該做什么和它
們以怎樣的順序執(zhí)行測試。文件的句法和格式將在后面部分討論。
消息文件是文本文件，包括SIP消息模板，談判器將要用于發(fā)送SIP
消息以及比較它們實際收到的SIP消息。
當談判器執(zhí)行測試時，它們實際上執(zhí)行設置在屏幕播放文件中的用于
測試的指令。在特定的實施例中，有兩種類型的指令，即"發(fā)送"(SEND) 和"接收"(RECEIVE)。換句話說，談判器或者發(fā)送消息到網絡中的SUT 或其他實體，或者等待從SUT或其他實體接收消息。如果條件允許談判器 執(zhí)行完成其指令，談判器將發(fā)送一個"通過"(PASS)信號到測試指導，告 訴測試指導談判器已經成功地完成了自己的職責。另一方面，如果條件不 允許談判器繼續(xù)執(zhí)行(例如當希望的消息沒有按時到達)，談判器將發(fā)送"失 敗"(FAILURE)信號到測試指導，告訴測試指導實際發(fā)生了什么問題。當 然，需要時，更多類型的指令可以由本領域的技術人員實現(xiàn)。
當執(zhí)行測試時，測試指導整理從各談判器收集的報告。 一旦測試結束， 測試指導告訴所有談判器停止并在屏幕上顯示測試結果。
圖3顯示了本發(fā)明的測試架構的高級工作流程圖。流程圖中每個方塊 的詳細說明如下。
Al:軟件程序測試指導在計算機上由用戶(可以為一個人或者另一軟 件程序)啟動。用戶還要向測試指導指定要執(zhí)行的測試用例集合。測試指 導從公共數(shù)據(jù)源讀取配置信息并從配置信息確定它將在什么網絡地址(典 型地，網絡地址由IP地址和端口號構成)上傾聽談判器，以便聯(lián)絡用于后 面的注冊。然后，測試指導在該網絡地址上傾聽。
A2: —個或多個軟件程序談判器由同一計算機或其它計算機上的用戶 (可以為一個人或者另一軟件程序)啟動。用戶還向談判器指示它將作為 什么角色。例如， 一個談判器作為談判器A;而另一個談判器作為談判器B。 每個談判器從公共數(shù)據(jù)源讀取自己的配置信息、其它談判器的配置信息和 測試指導的配置信息，并確定它將采取什么特性及網絡地址來聯(lián)絡測試指 導。然后，每個談判器將聯(lián)絡測試指導以向其注冊自己。 一旦測試指導接 受它們的注冊， 一個預定的通信通道將在測試指導和每個談判器之間建立。 通信通道，例如可以利用java的RMI (遠程方法調用)技術實現(xiàn)，用于在 執(zhí)行測試期間，測試指導發(fā)布命令到各談判器及用于談判器提交它們的測 試報告或反饋到測試指導。當然通信通道可以由其它方法實現(xiàn)，并且其實 現(xiàn)是在本領域的技術人員的普通技術范圍內。
A3:根據(jù)用戶指定的測試用例集合，測試指導確定下一個要運行的測 試用例(testcase)。例如，如果用戶指定測試用例T01 、 T02和T03需要執(zhí) 行，測試指導就將確定哪個測試用例在第一、第二和第三運行。對于一個 特定實施方案，可以基于字母順序作決定。
A4:如果用戶希望，則測試指導運行由用戶提供的一個腳本命令(例 如，shell命令、bat命令、perl命令或其它可執(zhí)行文件)。腳本命令存儲在 公共數(shù)據(jù)源中。典型地，腳本命令用于開始和停止SUT (受測系統(tǒng))，以便 確保SUT在每個測試用例開始時具有干凈的狀態(tài)。但是從技術角度來說， 腳本命令可以執(zhí)行用戶需要的任何任務。如果用戶已經選擇不運行該腳本 命令，將跳過這一步驟。以下是這樣的腳本命令的例子
"sw^Xcf/.s/z加W TO,,
其中，wZ^"—""/2為腳本名，start禾QTOl為傳給該腳本的變量。T01 為要執(zhí)行的須ij試用例的名稱。
A5:測試指導與談判器協(xié)調來執(zhí)行測試用例。此步驟的詳細內容參見 圖4。
A6:如果用戶希望，則測試指導運行該用戶提供的一個腳本命令(例
如，shell命令、bat命令、perl命令或其它可執(zhí)行文件)。這是類似于A4的 可選步驟。例如可以運行下面的腳本命令來停止SUT: "jwZy'eC—"/.A加/ 7W，
其中subject一ctl.sh為腳本名，stop和T01為傳給該腳本的變量。T01 為己經執(zhí)行的測試用例的名稱。
A7:測試指導確定是否已經執(zhí)行完用戶指定的所有測試用例。如果還
有要執(zhí)行的測試用例，將返回到A3。如果已經執(zhí)行了所有測試用例，將前 進到A8。
A8:測試指導計算匯總測試結果，并顯示給用戶。對于一個特定的實 施方案，該匯總包括執(zhí)行的測試用例的總數(shù)、通過的測試用例的數(shù)量和失 敗的測試用例的數(shù)量。需要時可以考慮該匯總可以包括其它的信息。
"顯示" 一詞是指程序向用戶傳達某些信息的機制。例如可以通過在計 算機屏幕上輸出信息、在紙上打印信息或經揚聲器播發(fā)消息來實現(xiàn)。
A9:測試指導經A2中建立的通信通道發(fā)布"DISMISS"命令到所有 參與的談判器，以便命令它們全部平靜地退出。談判器遵守該命令退出。
然后，測試指導自己也退出。
圖4詳細顯示了圖3中流程圖的方塊A5的內容。圖4中的每個方塊如
下進一步說明。
A5-l:測試指導從屏幕播放文件確定哪些談判器將參與要執(zhí)行的測試
用例。然后它經A2中建立的通信通道發(fā)布"GET READY"命令及測試用 例的唯一標識符(例如測試用例的名稱)到每個參與的談判器，以便命令 它們準備好執(zhí)行測試用例。
A5-2:接收到準備好(GETREADY)命令后，每個參與的談判器將測 試用例的屏幕播放文件及屏幕播放文件中涉及的相應的消息文件裝載到存 儲器中以便實際執(zhí)行期間使用。
A5-3:當所有的參與的談判器都準備好時，測試指導經A2中建立的通 信通道發(fā)布一個"行動(ACTION)"命令到每個談判器，以便命令它們開 始執(zhí)行測試用例。
A5-4:收到ACTION命令后，每個談判器通過執(zhí)行屏幕播放文件中與 其相關的指令并忽略其它的指令來履行它們的職責。
如果一個談判器可以無差錯地執(zhí)行屏幕播放文件中的所有相關指令， 它將經A2中建立的通信通道提交一個"通過(PASS)"報告給測試指導， 告訴測試指導已經完成了預期的任務。
但是，當談判器遭遇意外的情況(例如期望的消息始終未到)時，它 將經A2中建立的通信通道提交一個"失敗(FAIL)"報告給測試指導，告 訴測試指導出了什么錯。要得到此塊中發(fā)生的詳細內容，參見圖5。
A5-5:測試指導等待從參與的談判器收集狀態(tài)報告("通過"或"失敗")。 它整理該報告并以下述方式導出測試用例的最終結果。
一旦從任意談判器收到"失敗"報告后測試指導就得出結論整個測 試用例失敗。
當所有參與的談判器提交了 "通過"報告給測試指導時，整個的測試 例程才被認為是"成功"的。
一旦導出了最終結果，測試指導將發(fā)布"停(CUT)"命令到所有參與 的談判以命令它們停止工作。談判器于是將停止執(zhí)行屏幕播放文件中給出 的指令，釋放不需要的存儲器，關閉所有不需要的連接，忽略再來的信息 包，直到下一測試用例開始。
圖5更詳細地描述圖4中的塊A5-4中發(fā)生的具體內容。此流程圖說明 了每個談判器將以什么順序作出什么動作。為了更好的易讀性，以下的文 字使用"談判器"代替"每個談判器"。
A5-4-l:談判器初始化其自變量i為O。
A5-4-2:談判器將變量增加l。
A5-4-3:談判器從屏幕播放文件取得第一個相關指令。相關指令是該 談判器必須執(zhí)行的指令。所有不相關指令將被談判器忽略掉。例如，談判 器B將忽略掉要由談判器A執(zhí)行的所有指令，而只執(zhí)行要由談判器B執(zhí)行 的那些指令。在一特定實施例中，指令的字段1指定應執(zhí)行該指令的談判 器的名稱。當然，這種指定可以其它合適的方式實現(xiàn)以獲得滿意的結果。
A5-4-4:談判器將根據(jù)指令的動作類型采取不同的動作。對于此特定
的實施方式，有兩種動作類型，即"發(fā)送(SEND)"和"接收(RECEIVE)"。
A5-4-5: SEND類型的指令指定談判器應使用哪個重寫器(Rewriter) 來重寫當前指令的消息文件。在這步中，基于消息文件的內容，談判器裝 入指定的重寫器來產生要發(fā)送的消息。
典型地，重寫器以實際值解析消息文件中預定義的標簽。于是，重寫 器可以被用戶定制化以便由用戶重寫任何形式的消息文件。重寫器如何工 作的更詳細信息，請見"SIP-指導器的核心重寫器和校驗器"部分。
A5-4-6:談判器發(fā)送重寫消息之前，該指令還指定一個延遲周期。在 這步中，談判器等待延遲周期過去然后發(fā)送出重寫消息到指定的目標。指 定的目標實際是SUT，但也可以為任何的網絡地址。
A5-4-7:談判器檢測是否在發(fā)送消息過程中發(fā)生任何錯誤。
A5-4-8:談判器經A2中建立的通信通道提交"失敗"報告給測試指導， 告訴測試指導失敗原因。
A5-4-9: RECEIVE類型的指令指定談判器將使用哪個校驗器來確定談 判器接收到的消息是否正確。在這歩中，談判器將當前指令涉及的消息文 件的內容和屏幕播放文件中的當前指令中指定的超時時間周期的值裝入指 定的校驗器并初始化它。
A5-4-10:談判器等待直到校驗器確定出談判器收到的消息是否正確。 對于給定的情形，不同的校驗器做出不同的決定。典型地，校驗器基于收 到的消息內容和消息到達的時間做出決定。此外，校驗器可以容易地被客 戶定制化以由客戶以完全不同的方式做出決定。校驗器如何工作的更詳細
信息請見"SIP-指導器的核心重寫器和校驗器"部分。
A5-4-ll:談判器基于校驗器給出的結論采取不同行動。結論是肯定的
或否定的?？隙ǖ慕Y論將導致談判器走到塊A5-4-12，而否定的結論將導致 談判器走到塊A5-4-8。
A5-4-12:談判器檢查當前指令是否為屏幕播放文件中的最后一個相關
A5-4-13:談判器經A2中建立的通信通道提交"通過"報告到測試指 導，告訴測試指導從其觀點看完成了期望的任務。
特定實施例的文件的句法和語義 (A)測試指導的配置信息
解釋和語義
(a) 此文件僅包含一行。
(b) 該行由冒號隔開的3個字段構成。
(c) 第一個字段必須讀"測試指導(TestDirector)"。
(d) 第二個字段指定測試指導要在其上運行的機器的IP地址。
(e) 第三個字段指定端口號，測試指導在執(zhí)行測試用例前要在其上傾 聽談判器注冊。
(B)談判器的配置信息
句法
這里〈property entry>為 〈property name>=<property value〉
解釋和語義
(a) 此文件定義關注的談判器的特性。
(b) 此文件由任意數(shù)量的特性項目(property entry)構成。用戶可以 定義他們喜歡的任何特性。只有一個強制的特性用戶必須定義。
(c) 特性項由等號隔開的兩個字段構成，并以回車結束。第一字段稱 作特性名稱，第二字段稱作特性值。
(d) 特性名稱由一個或多個字母數(shù)字字符構成。
(e) 特性值由一個或多個非回車字符構成。
(f) 強制特性的名為"role.location"且其值為一個由冒號隔開的IP地 址和端口號。
(g) 談判器使用強制特性來確定網絡地址(即IP地址和端口號)，在 其上它將傾聽來自SUT和其他實休的進入消息。
(C)屏幕播放文件 句法
這里 〈nstruction〉為
<fieldl>:<field2>:<field3>:<field4>:<filed5>:[<field6>;|
解釋和語義
(a) 此文件包含要由談判器執(zhí)行的指令。
(b) 簡言之， 一個指令定義誰將在何時發(fā)送什么消息或者誰應等到何 時接收什么消息。
(c) 此文件由一個或多個指令構成。
(d) —個指令是由5或6個字段構成的行。這些字段由冒號隔開。此 行由CRLF或CR終止。
(e) 字段1指定將執(zhí)行該指令的談判器的名稱。
(f) 字段2指定談判器要采取的動作?？赡艿闹禐镾END或RECEIVE。
(g) "SEND"指示談判器發(fā)送一個消息。
(h) "RECEIVE"指示談判器等待一個進入的消息。
(0字段3指定談判器要使用的重寫器或校驗器的名稱。詳細內容請 參見"SIP-測試指導的核心重寫器和校驗器"部分。
(j)如果指令的動作類型為"SEND"，重寫器的名稱應予指定。 (k)如果指令的動作類型為"RECEIVE",校驗器的名稱應予指定。 (1)字段4是重寫器或校驗器要使用的消息文件的文件名。 (m)字段5指定毫秒為單位的時間周期。
(n)如果指令的動作類型為"SEND",時間周期將被理解為談判器的 延遲周期。
(o)如果指令的動作類型為"RECEIVE",時間周期將被理解為校驗 器的超時值。
(p)字段6僅在指令的動作類型為RECEIVE時使用。它指定其值為 網絡地址的特性的名稱，談判器將發(fā)送消息到該地址。簡言之，它指定目 的地。
(D)消息文件 消息文件是文本文件不需要句法。 解釋和語義
(a) 此文件包含一個消息模板或標準模板，重寫器或校驗器將處理其 以便發(fā)送或校驗消息。
(b) 此文件將由重寫器或校驗器解釋。因此，用戶可能希望放到此文 件中的文本取決于使用什么重寫器或校驗器及用戶希望得到什么結果。
(c) 典型地，此文件包含帶有專有標簽和標記的類似SIP消息的內容， 以便被專有的重寫器或校驗器使用。
(d) 重寫器和校驗器如何使用消息文件的詳細內容請見"SIP-指導器
的核心重寫器和校驗器"部分。 SIP-指導器的核心重寫器和校驗器
重寫器和校驗器為軟件模塊，它們輔助談判器執(zhí)行屏幕播放文件中的 指令。它們在實施本發(fā)明中起十分重要的作用，因此形成測試架構的核心。
重寫器是一個符合標準接口 (應用編程接口或API)的軟件模塊，并負 責將一給定的消息文件轉換成另一形式。SIP-指導器允許測試工具的用戶提 供自己的重寫器，由此給用戶自由以任何可以想象的方式設計和轉換消息 文件。為了便于說明，下面將在這部分討論一組樣本重寫器。
類似地，校驗器是一個符合標準接口 (應用編程接口或API)的軟件模 塊，并在一個超時限制內負責確定由談判器接收到的一個或多個消息的正 確與否。SIP-指導器允許測試工具的用戶提供自己的校驗器，由此給用戶自 由去定義他們自己的方式來確定接收的消息正確與否。為了便于說明，下 面將在這部分討論一組樣本校驗器。
關于上述的公開內容，很顯然本發(fā)明的測試架構的應用不限于SIP協(xié) 議。本領域的普通技術人員可以根據(jù)上述SIP測試架構的實施例容易地將 本發(fā)明用于測試其它通信協(xié)議。
羞寫器
如前所述，談判器在其發(fā)送出重寫的消息之前，依賴重寫器來重寫消
息文件。因此，當談判器正在執(zhí)行其動作類型為SEND的指令時，談判器
將使用重寫器。
SIP測試架構的用戶可以選擇設計和使用他們自己的重寫器。為了說明 的目的，兩個樣本重寫器將在下面討論(a) NO叩重寫器；(b)標準重寫 器°
No叩重寫器不在消息文件上執(zhí)行任何操作。換句話說，它不改變消息 文件。其結果是，用戶放到消息文件中的任何內容都將在延遲周期過去之 后被談判器原樣發(fā)送出去。
標準重寫器通過以實際值替代預定標簽來重寫消息文件。標簽是符合
預定模式的一段文本。由標準重寫器識別的所有標簽具有下列模式
其中，方括號標記標簽的界限，X是標簽的類別(有4類，即P， H， C和D)， 是分隔符，Desc告訴標準重寫器它應該怎樣替換標簽。 標準重寫器將重寫的標簽的4個類別為
(a) 特性標簽；
(b) 常量標簽； (C)動態(tài)標簽；
(d)歷史標簽。
特性標簽
簡言之，特性標簽要由標準重寫器解析為特性值，特制標簽采用以下 形式
解釋
(a) P代表特性標簽；(b) property一name是特性名稱，此標簽將被解析為特性值；
(c) negotiator—name是談判器的名稱，其配置信息將被使用于査找特性值。 此字段是可選的，當省略時，標準重寫器將使用正執(zhí)行屏幕播放文件中的 當前指令的談判器的配置信息，來重寫消息文件以査找特性值。
(a ) /P swty'ecf. /ocaf/o"/ 上述的特性標簽告訴標準重寫器以正執(zhí)行當前指令的談判器的配置信息中 找到的特性"subject.location"的值替換該標簽。
(b ) /P ~r。/e.鵬'.cfo附a/" B7 上述特性標簽告訴標準重寫器以談判器B的配置信息中找到的特性
"role.uri.domain"的值替換該標簽。
常量標簽
簡言之，常量標簽要被解析為共同的常數(shù)值給所有參與的談判器。在 執(zhí)行每個測試用例之前新的常數(shù)值賦給所有的談判器。常量標簽采用以下 形式
(a) C代表常量標簽；
(b) predefmedJoken為常量名稱，此常量標簽將可能解析為下列可能的值:
(1) Call-ID:解析為可能包括字母、標點符號和數(shù)字的字符串；
(2) BranchCookie:解析為如RFC3261中指定的magic cookie起始的
字符串；
(3) Alphanumeric:解析為包含字母數(shù)字字符的字符串；
(4) Numeric:解析為僅僅包含數(shù)字的字符串。
(c) suffix是一段文本，將附屬到解析值之后。該字段是可選的。省略時， 不附屬額外的文本。
(a) /C C/D/
上述常量標簽告訴標準重寫器(StandardRewriter)用可以包括字母、標點 符號和數(shù)字的字符串替換該標簽。
上述常量標簽告訴標準重寫器用如RFC3261中指定的magic cookie起始的 字符串替換該標簽。
(c) [C Brawc/2G50Aie "6c] 上述常量標簽將被解析為與前一個相同的值，并有額外文本"abc"附屬到 末尾。
動態(tài)標簽
動態(tài)標簽將被解析為一個取決于消息文件的內容的值。動態(tài)標簽采用下列 形式
(a) D代表動態(tài)標簽；
(b) predefined-token告訴標準重寫器它應如何計算該值。對于此示例，僅 有一個可能值(可以根據(jù)需要定義更多的token): content-length。它被解析 為一個數(shù)值，反映消息文件中找到的SIP消息體的字節(jié)數(shù)。
示例
上述的常量標簽告訴標準重寫器以反映消息文件中找到的SIP消息體的字 節(jié)數(shù)的數(shù)值替換該標簽。
歷史標簽
歷史標簽被解析為從先前由談判器發(fā)送或由談判器接收到的SIP消息里抽 取的SIP消息頭。歷史標簽采用下列形式
說明
(a) H代表歷史標簽；
(b) header—name指定要被抽取的SIP消息頭的名稱；對于SIP消息頭名 稱的完整列表，參閱RFC 3261.
(c) scope告訴要被抽取的SIP消息頭有多少行?？赡艿闹凳?br> (1) First:當需要的SIP消息頭的多行出現(xiàn)時，僅抽取第一行。
(2) All:抽取需要的SIP消息頭的所有行。
(d) index告訴標準重寫器哪個先前發(fā)送或先前接收的消息應該用于抽取 SIP消息頭。"歷史" 一詞是指由談判器發(fā)出的所有的SIP消息，或者在執(zhí) 行當前指令之前談判器接收的所有的SIP消息。此字段選擇標準重寫器應 該使用哪個消息?？赡艿闹禐?br> (1) r-<n>: r代表接收的SIP消息；n是歷史索引。例如，r-l指談判 器接收的最后的SIP消息；r-2指談判器接收的倒數(shù)第二的SIP消息。
(2) s-<n>: s代表發(fā)送的SIP消息；n是歷史索引。例如，s-l指談判 器發(fā)出的最后的SIP消息；s-2指談判器發(fā)出的倒數(shù)第二的SIP消息。
示例
上述歷史標簽告訴標準重寫器用談判器收到的最后的SIP消息中找到 的"Contact"消息頭的第一行來替換該標簽。
(b) /7/ 7 6^<92^/-^她 v4t7 ^t-2/ 上述歷史標簽告訴標準重寫器用談判器收到的倒數(shù)第二的SIP消息中
找到的"Record-Route"消息頭的所有行來替換該標簽。
(c) /"http://—Kz's—FzV^i-^y 上述歷史標簽告訴標準重寫器用談判器發(fā)出的倒數(shù)第二的SIP消息中
找到的"Via"消息頭的第一行來替換該標簽。
特性標簽、常量標簽和動態(tài)標簽使得SIP-指導基于運行時間參數(shù)來構 造文本消息(不是必須為SIP消息)。因此本質上是動態(tài)地構造消息。
歷史標簽使得測試工具的用戶能夠構造消息模板，該模板內容取決于 先前發(fā)送/先前接收的消息，由此使此測試架構具有構造適于運行時間場景
的SIP信息的能力。換言之，SIP-指導中SIP消息的構造本質上也是適應性的。
校驗器
如上所述，談判器依賴校驗器來確定由談判器收到的消息正確與否。 因此，當談判器在執(zhí)行其動作類型為"接收"的命令時，談判器將使用一 個校驗器。
校驗器以下述方式工作它初始化(1)當前指令中引用的消息文件和 (2)當前指令中指定的超時周期的值。如果需要，校驗器可以在當前指令 開始執(zhí)行時以該超時值開啟一個計時器。每次談判器收到一個消息，該消 息被傳送到校驗器以便它決定收到的消息是否正確。作為響應，該校驗器 可以(1)發(fā)布一個正的決定結果來表明消息是正確的，或者(2)發(fā)布一 個負的決定結果來表明消息不正確或者不合適，或者(3)靜靜等待下一消 息到來，或者等待超時周期過去并其后發(fā)布一個決定結果。在此時，校驗 器一定要發(fā)布一個決定結果。
SIP-指導的用戶可以選擇設計和使用自己的校驗器。下面的校驗器的特 定實施例僅用作范例，不用于限定。
當"標準"系列的校驗器由消息文件初始化時，校驗器將使用標準重 寫器來重寫該文件的內容。重寫的內容將變成校驗器使用的一組規(guī)則來校 驗談判器收到的消息的有效性。 一旦談判器收到消息，該消息將被傳送到 校驗器，后者將執(zhí)行校驗。校驗結果和消息的到達時間二者對校驗器的最
終決定結果有作用。
下面說明校驗器的一個特定實施例。 "盲(Blind)"系列
(a) 盲校驗器(BlindChecker) —旦談判器收到一個消息它將發(fā)布 一個正的決定結果。決定結果與消息的內容無關。它僅在時間超時時發(fā)布 負的決定結果。
(b) 自閉型盲校驗器(AutisticBlindChecker) 該校驗器內向，不愿 意被打擾。因此一旦談判器收到一個消息它將發(fā)布一個負的決定結果。決 定結果與消息內容無關。僅當超時時，發(fā)布正的決定結果。
"標準"系列
(a) 標準校驗器(StandardChecker) —旦談判器收到第一消息，該 標準校驗器將根據(jù)消息文件中給定的規(guī)則校驗其有效性。如果滿足所有規(guī) 則，該校驗器將發(fā)布正的決定結果，否則將發(fā)布負的決定結果。當超時時 也將發(fā)布負的決定結果。
(b) 耐心標準校驗器(PatientStandardChecker) 它很類似于"標準校 驗器"，但是它不會輕易放棄等待期望的消息。 一旦接收的消息滿足所有規(guī) 則，該校驗器將發(fā)布一個正的決定結果。僅當超時時發(fā)布負的決定結果。
(c) 自閉型標準校驗器(AutisticStandardChecker) 它是"過分"內 向的。 一旦談判器收到滿足所有規(guī)則的消息，它將發(fā)布一個負的決定結果。 當超時或者談判器收到的消息不滿足所有規(guī)則時它發(fā)布正的決定結果。
(d)自閉型耐心標準校驗器(AutisticPatientStandardChecker) 它很
類似于自閉型標準校驗器。區(qū)別僅在于它更有耐心。當超時時它發(fā)布正的 決定結果。它將忽略不滿足所有規(guī)則的接收的消息并耐心等待。當滿足所 有規(guī)則的消息到達時它發(fā)布一個負的決定結果。
"標準"系列中的校驗器都是基于標準校驗器(StandardChecker)。"標 準"系列中的所有的校驗器，在確定接收的消息是否正確方面，都與標準 校驗器以相同方式工作。因此討論將集中在標準校驗器如何確定收到的消 息的正確與否。
根據(jù)RFC3261 (RPC代表請求注解。要看詳細內容請登陸 http:〃www.faqs.org/rfcs/rfc3261 .html) ， SIP消息以請求行或響應行開始，后 面跟隨一些SIP消息頭，還可能跟隨消息體。消息體是可選的。
當校驗實際接收的消息的正確與否時(或有效性)，將考慮消息中的下
列信息
(a) 請求行是否使用了期望的請求方法；
(b) 響應行是否使用了期望的響應碼；
(C)消息是否包含特定消息頭名稱的某些消息頭，其消息頭的值不重
要；
(d) 消息是否包含特定消息頭名稱的某些消息頭，其消息頭的值重要;
(e) 其它可能包含特定情況的問題。
因此，當標準校驗器校驗實際接收的消息的有效性時，它應該查看相
同的信息。是消息文件告訴標準校驗器應該確切地査看接收的SIP消息中
的什么信息。換言之，消息文件形成標準校驗器使用的規(guī)則來校驗接收的 消息。
因此，消息文件必須向標準校驗器表明在接收的消息中期望什么請求 方法，在接收的消息中期望什么響應碼，必須有什么消息頭及必須不出現(xiàn) 什么消息頭等等。消息文件的格式應當使這些規(guī)則可以由用戶容易地表達 且由標準校驗器容易地解釋。很自然地，規(guī)則的表達方式將極其類似常規(guī) 的SIP消息。
當標準校驗器初始化時，它將使用標準重寫器來將所有預定標簽解析 為實際值(如上所述)。重寫過程之后，消息文件的內容看起來將非常象SIP 消息，特殊的前綴在某些SIP消息頭之前出現(xiàn)。
消息文件重寫的內容將由標準校驗器以下列方式解釋
(a) 第一行告訴標準校驗器接收的消息中期望什么請求方法或響應
碼；
(b) 其余行告訴標準校驗器什么SIP消息頭必須出現(xiàn)或什么SIP消息 頭必須不出現(xiàn)。如RFC3261中定義的， 一行定義為以回車換行(CrLf)結 束的一段文本。預定的標志用于表明期望什么和不期望什么。標志將在下 面予以討論。
標準系列中由校驗器識別的標志
消息模板中的每一行代表接收的消息必須滿足的一個獨立的規(guī)則。除 了第一行，所有其它行可以加前綴"標志"來表明期望的特性。下面詳細 說明每一個標志
(a) EHV
此標志代表期望的頭值。當沒有指定標志時它是缺省標志。它告訴校 驗器跟隨此標志的SIP消息頭(頭名稱和頭值)必須存在于接收到的消息 中，以便滿足規(guī)則。
示例
EHV Max-Forwards: 70
上行代表的規(guī)則為帶有值70的"Max-Forwards"消息頭必須存在于 接收到的消息中。
(b) EHN
此標志代表期望的頭名稱。它告訴校驗器帶有與跟隨此標志的相同名 稱的SIP消息頭必須存在于接收到的消息中以便滿足規(guī)則。
示例
E麗 Call-ID: *
上行代表的規(guī)則為至少一個"Call-ID"消息頭必須存在于接收到的 消息中。消息頭的值不重要。
(c) UHV
此標志代表不受歡迎的頭值。它告訴校驗器跟隨此標志的SIP消息頭 (頭名稱和頭值)一定不能出現(xiàn)在接收到的消息中以便滿足規(guī)則。
示例
UHV CSeq: 1 INVITE
上行代表的規(guī)則為帶有值"1INVITE"的"CSeq"消息頭一定不能
出現(xiàn)在接收到的消息中。
(d) UHN
此標志代表不受歡迎的頭名稱。它告訴校驗器帶有與跟隨此標志的相 同名稱的SIP消息頭一定不能存在于接收到的消息中以滿足規(guī)則。
示例
UHN Contact: *
上行代表的規(guī)則為不允許"Contact"頭存在于接收到的消息中，不 管頭值是多少。
當前實施例中提供的各種校驗器使得測試架構工作的用戶可以構思合 適的先進的測試用例來測試他們的SUT。用戶甚至可以設計他們自己的校 驗器來校驗收到的消息的正確與否，由此使得此測試方法延伸測試其它通 信協(xié)議。
在校驗SIP消息頭的有效性，不同類型的標志覆蓋了大多數(shù)(若不是 全部的話)能想象到的情況。能表達復雜的規(guī)則，而不需要用戶書寫復雜 的腳本命令，是本發(fā)明的顯著特征。
測試用例的結構和文檔的自動生成
層級測試用例構造
一個測試用例是應當在談判器和受測試系統(tǒng)之間發(fā)生的消息流的規(guī)范 (specification),以屏幕播放文件和相關的消息文件的形式表示。根據(jù)本發(fā) 明的一個特定實施例，測試用例以層級方式邏輯地構造，由此一個測試用 例可以是測試組的一部分，測試組又可以是更大的組的一個部分，等等。
該特定實施例可以構造的測試用例的分組等級數(shù)沒有限制。圖6顯示了測 試用例的這種層級的例子。
測試用例的分組可以基于用戶認為合適的任何規(guī)則。例如，測試用例 分組可以基于它們的相似性、消息流的共性、測試用例所體現(xiàn)的行為所屬 的RFC的邏輯部分等等。
作為一個特定實施例，屏幕播放文件和相關消息文件(例如文件系統(tǒng)) 的物理構造可以具有與相關測試用例的邏輯構造相同的層級結構。這使得 易于文件的維護。
可以單獨執(zhí)行測試，或者利用腳本命令或者其它合適機制自動成批地 執(zhí)行。但是用戶執(zhí)行測試的更強大和有邏輯性的方式是基于上述的測試用 例層級構造。于是，他或她可以通過指定標明測試用例的層級結構中的一 個特定組的標識符來請求執(zhí)行一組測試。這是更強大的，因為用戶可以容 易地通過簡單地指定標識符來請求執(zhí)行任意大組的測試。這也更具邏輯性， 因為它使得測試用例的構造與執(zhí)行密切對應。 自動的文件生成
在生成一個測試用例時，提供關于測試用例的相關文件與指定消息流
是同等重要的。這樣的文件可以包括測試內容的描述、與測試相關的RFC
中的有關部法、消息流的關鍵特性或測試的概念、消息流的圖解表示，等 等。文件是計劃和管理測試過程的工具，當測試用例的數(shù)量變得很大時可 能是至關重要的。
測試用例的規(guī)范要求書寫文檔源文件。文檔源文件具有定義明確的格 式和關于該測試用例的信息關鍵段的占位符，例如測試名稱、測試說明、 測試前提、參考信息如RFC參考資料、消息流等待。測試用例文檔源文件可以具有與實際測試用例相同的層次結構。它們 貯存在與屏幕播放文件和消息文件的層次(例如文件系統(tǒng))相同的物理位 置。這使得文檔源文件和屏幕播放文件及消息文件一樣易于維護。在特定實施例中，有一個程序工具從文檔源文件產生HTML格式的文 檔。這樣的程序工具可以由本領域的普通技術人員實現(xiàn)。產生的HTML文 檔包括完全的超鏈接，使得易于在測試用例中導航。每當需要產生文檔時 測試架構的用戶可以發(fā)布簡單的命令，可以自動產生測試用例的整個層次 的文檔。此外，測試用例文檔源文件包含標簽，該標簽待由從屏幕播放文件或 消息文件中抽取的某些段信息替換，諸如消息流。提供這樣的標簽消除了 屏幕播放文件和消息文件中找到的信息的反復輸入。雖然已經說明和指出本發(fā)明應用于優(yōu)選實施例的基本特征，將可理解， 在不脫離本發(fā)明精神的情況下本領域的技術人員可以在說明的測試架構和 方法的形式和細節(jié)上進行各種的省略、替換和改變。例如，清楚地要將架 構的那些部件的所有組合和/或以實質上相同的方式執(zhí)行實質上系統(tǒng)功能以 獲得相同結果的方法步驟包含在本發(fā)明的保護范圍之內。本發(fā)明不限定于上述的僅作為示例的實施例，這些示例可以在后附的 權利要求的保護范圍內作出各種修改。在理解所附的權利要求時，如果與說明書中其它部分的說明不一致，
下面給出的定義將具有優(yōu)先性。"測試計算機"是可以執(zhí)行軟件程序和具有網絡接口的任何計算設備。 典型的這種設備包括(還有其它部件)中央計算單元(CPU)、隨機存取 存儲器(RAM)、操作系統(tǒng)(OS)和網卡。"測試指導"是僅僅用于測試或診斷目的的可以與其它測試或診斷計 算機軟件程序交互的任何計算機軟件程序，這些測試或診斷計算機軟件程 序運行在同一測試計算機上或一個或多個不同的測試計算機上。"SUT"是指受測試的系統(tǒng)。"談判器"是僅用于測試或診斷目的的任何計算機軟件程序，可以與 其它的測試或診斷計算機軟件程序交互，這些測試或診斷計算機軟件程序 運行在同一測試計算機上或一個或多個不同的測試計算機上，并且通過與 網絡的連接可以與網絡內的設備通信。"校驗器"是用于通過比較網絡通信中實際接收到的消息的內容和期 望的內容來確定是否發(fā)生錯誤的軟件單元。"重寫器"是用于根據(jù)一組預定規(guī)則將計算機可讀文件即數(shù)字數(shù)據(jù)流 轉換成消息的軟件單元，以便所得到的消息的格式符合網絡通信協(xié)議。"測試用例"、"屏幕播放文件"和"消息文件"是計算機可讀文件或 數(shù)字數(shù)據(jù)流，它們的內容可以通過計算機在計算機屏幕上或硬拷貝打印上為人類可讀。 一個測試用例是SUT和多個談判器之一之間的測試消息的確 定性流。屏幕播放文件指定該消息流，很象拍攝電影時使用的劇本。"靜態(tài)和運行時間信息"是指關于測試用例和執(zhí)行測試后獲得的測 結果的信息，例如可包括測試名稱、測試說明、測試前提、RFC參考信息、 消息流、任何通信錯誤的指示和原因，或者用戶認為有用和適用于文檔的 任何其他信息。當然，可以省略上述特定信息的一個或多個部分。
權利要求
1、一種測試連接到IP網絡的實體的通信信號協(xié)議的相容性或強健性的系統(tǒng)，該系統(tǒng)包括(a)一個或多個測試計算機；(b)一個或多個談判器；及(c)一個測試指導，其中所述的一個或多個談判器和所述的測試指導是軟件程序并安裝在所述的一個或多個測試計算機中；所述的一個或多個談判器與所述的IP網絡具有連接，由此利用所述的通信協(xié)議與所述的實體通信；所述的測試指導與所述的一個或多個談判器具有連接，由此發(fā)送命令到所述的一個或多個談判器以執(zhí)行一項工作，所述工作為以符合所述通信協(xié)議的格式發(fā)送一個消息到所述實體，或者等待從所述實體接收滿足所述通信協(xié)議的格式的另一消息。
2、 根據(jù)權利要求l的系統(tǒng)，還包括一個或多個存儲在計算機可讀介質中的 并可以由所述的測試指導訪問的文件。
3、 根據(jù)權利要求2的系統(tǒng)，其中所述的一個或多個文件也可由所述的一個 或多個談判器訪問。
4、 根據(jù)權利要求3的系統(tǒng)，其中所述的一個或多個文件包括一個測試用例， 具有ID、屏幕播放文件和一個或多個消息文件，所述的屏幕播放文件包括 至少一個指令并在所述測試用例中引用；其中由所述測試指導發(fā)送到所述 一個或多個談判器的所述命令包括所述測試用例的ID，所述工作由所述測 試用例中引用的屏幕播放文件中的指令指定。
5、 根據(jù)權利要求2的系統(tǒng)，其中所述談判器包括第一部分，其用作校檢器，所述校驗器能夠比較執(zhí)行所述工作中接收到的另一消息的內容和一項所述 文件的內容，以確定是否發(fā)生了通信誤差。
6、 根據(jù)權利要求5的系統(tǒng)，其中所述談判器基于所述校驗器進行的確定發(fā) 送一個報告到所述測試指導，所述報告可選地由所述測試指導顯示在屏幕 上或打印出來。
7、 根據(jù)權利要求5的系統(tǒng)，其中所述談判器還包括第二部分，其用作重寫 器，所述重新器能夠將一項所述文件的內容轉換成執(zhí)行所述工作中要使用 的所述消息。
8、 根據(jù)權利要求1的系統(tǒng)，其中所述測試指導安裝在測試計算機上，其中 沒有安裝所述談判器。
9、 根據(jù)權利要求1的系統(tǒng)，其中所述測試指導安裝在測試計算機上，其中 - -個或多個所述談判器也安裝在其上。
10、 根據(jù)權利要求1的系統(tǒng)，其中每個所述的測試指導和一個或多個談判 器安裝在分開的測試計算機上。
11、 根據(jù)權利要求2的系統(tǒng)，其中所述一個或多個文件存儲在測試計算機 內的計算機可讀介質中，其中所述測試指導或談判器之一安裝在該測試計 算機中，或者所述一個或多個文件存儲在一個設備或測試計算機的計算機 可讀介質中，在該設備或測試計算機中沒有安裝所述的測試指導或一個或 多個談判器。
12、 一種測試連接到基于IP的網絡的實體的通信信號協(xié)議的相容性和強健性的方法，該方法包括步驟(a) 根據(jù)預定規(guī)則，準備一個測試用例、 一個屏幕播放文件和一組消息文 件；(b) 將所述測試用例作為輸入來執(zhí)行一個測試指導；(C)執(zhí)行一個或多個談判器，該談判器與所述測試指導進行通信；(d) 由所述測試指導發(fā)送一個命令到所述談判器；(e) 基于從所述測試指導接收的命令由所述談判器發(fā)送一個消息，所述消 息發(fā)送到網絡中的所述受測試實體，所述談判器連接于其網絡上；(f) 等待要被發(fā)送到所述談判器的另一消息直到經過了指定的超時時間， 如果在指定的超時時間內所述另一消息到達，該消息經受所述談判器的檢 查，以確定是否發(fā)生了通信誤差；及(g) 基于所述檢査由所述談判器發(fā)送一個報告到所述測試指導。
13、 根據(jù)權利要求12的方法，其中還包括步驟(h):在屏幕上顯示或在紙 上打印出所述測試指導的報告。
14、 根據(jù)權利要求12的方法，其中還包括步驟(i):其中步驟(a)還包括準備預定格式的測試用例文檔源文件，所述格式包括占位符，和步驟(i)在步驟(a) - (g)期間或之間執(zhí)行，通過收集所述測試步驟(a) - (g)期 間的靜態(tài)和運行時間信息及用所述靜態(tài)和運行時間信息替換所述的占位符 來完成。
15、 根據(jù)權利要求12的方法，其中所述測試指導與所述受測試實體沒有直 接連接。
16、 根據(jù)權利要求12的方法，其中所述歩驟(e)中所述消息是從步驟(a) 中準備的所述消息文件之一轉換來的，使得所述消息的格式符合所述通信 協(xié)議。
17、 根據(jù)權利要求12的方法，其中在步驟(f)中所述談判器進行的確定是 否發(fā)生了通信誤差的檢査是通過比較所述另一消息的內容和步驟(a)中準 備的所述消息文件之一的內容實現(xiàn)的。
18、 根據(jù)權利要求12的方法，其中所述的談判器和測試指導的每一個運行 在分開的測試計算機上。
19、 根據(jù)權利要求12的方法，其中所述測試指導和一個或多個談判器運行 在一個測試計算機上。
20、 根據(jù)權利要求12的方法，其中所述的通信協(xié)議是SIP。
全文摘要
用于測試各實體使用的通信信號協(xié)議的相容性或強健性的架構或系統(tǒng)，該實體連接到一個基于IP的網絡，特別地用于測試SIP啟動實體或設備。在該架構內，多個測試客戶由集中的測試控制器協(xié)調，于是測試進程和結果可以集中的方式被控制和監(jiān)控。該架構使用簡單的基于模板的測試腳本命令，易于書寫，不涉及復雜的編程結構。
文檔編號H04L12/26GK101116287SQ200680001176
公開日2008年1月30日 申請日期2006年5月8日 優(yōu)先權日2005年5月17日
發(fā)明者余兢聰, 周文聰 申請人:香港應用科技研究院有限公司