IPv6路由器的測試集規(guī)劃技術的研究

1、IPv6路由器測試集規(guī)劃技術的研究 劉 霞 曾 淼 徐 娟 (西南交通大學計算機與通信工程學院 成都 610031)摘 要: 本文以四川省網絡通信技術重點實驗室進行的IPv6路由器的并發(fā)多端口測試技術研究和系統(tǒng)開發(fā)為背景，討論了測試集的規(guī)劃技術，其中的重點是通用測試集的規(guī)劃。根據IP協(xié)議集的特點，本文分別針對單狀態(tài)協(xié)議和多狀態(tài)協(xié)議通用測試集規(guī)劃的一般方法進行了詳細的討論。關鍵詞：通用測試集 (GTS Generic Test Suite) 規(guī)劃 6 / 6文檔可自由編輯打印1 引 言在從IPv4向IPv6網絡過渡期間，對新一代的IPv6網絡產品，特別是路由器產品進行測試變得越來越重要。但是，迄

2、今為止國、內外對路由器進行測試所采用的技術，仍然沿襲ISO規(guī)定的兩種測試中繼系統(tǒng)的方法：回繞測試(Loop-back Test)和穿越測試(Transverse Test)法1。由于這兩種方法只能對路由器單個或一對端口進行測試，難以對未來的多端口路由器進行完整的測試，四川省網絡通信技術重點實驗室對“并發(fā)多端口測試技術”進行了研究并正在開發(fā)相關的測試系統(tǒng)。由于并發(fā)多端口測試可以對多個端口同時進行控制和觀測，完成各對端口測試過程的協(xié)調與同步，因而能夠在模擬路由器的正常與極端工作環(huán)境下進行測試。因此，并發(fā)多端口測試能夠進行全面三類不同性質的測試，即：是否符合相關協(xié)議標準的測試(Conformance

3、 Test)、性能測試(Performance Test)和互通測試(Interoperability Test)。網絡協(xié)議測試系統(tǒng)通過執(zhí)行事先定義的測試控制數據來達到測試目的。ISO 96461 將測試控制數據定義為層次結構，其頂層為測試集(Test Suite)，下面各層次分別為測試組(Test Group)、測試子組(Test Subgroup)、測試例(Test Case)和測試步(Test Step)等。盡管在20世紀8090年代，許多人對自動生成測試控制數據進行了大量的研究，但在Internet相關的協(xié)議測試中，仍然以人工描述技術為主，ISO 9646-3中制訂的半形式化測試控制數

4、據TTCN(Tree and Table Combined Notation)仍然是廣為采用的語言。以測試集為例，測試控制數據從規(guī)劃到轉變?yōu)闇y試系統(tǒng)可執(zhí)行的機器代碼可呈現為3種形式：通用測試集（GTS - Generic Test Suite）、抽象測試集(ATS - Abstract Test Suite)和可執(zhí)行測試集(ETS - Executable Test Suite)。GTS是對測試目的、測試覆蓋范圍和測試內容的宏觀描述，詳細地界定測試組、子組和測試例，是后續(xù)的抽象測試集的描述和具體化的基礎。根據GTS和采用的測試方法，再采用某種描述語言(如TTCN)對測試例和測試步驟進行詳細的描

5、述，然后再組合成ATS。測試系統(tǒng)測試支撐工具（編譯器或解釋器）將ATS變?yōu)樘囟y試系統(tǒng)可執(zhí)行的機器代碼，直接用于控制測試過程。鑒于ATS的重要性，而對GTS又缺少標準化的規(guī)劃與描述工具，加上Internet協(xié)議種類繁多，需要對相關的技術進行研究。出于實驗室的研究工作的需要，筆者在相關的工作中對路由器的IPv6協(xié)議集GTS的規(guī)劃技術進行了研究，并在規(guī)劃IPv6協(xié)議GTS的實踐基礎上提出了單狀態(tài)協(xié)議和多狀態(tài)協(xié)議GTS規(guī)劃的一般方法。2 GTS規(guī)劃原則與測試命名編碼規(guī)則2.1 測試集規(guī)劃原則盡管IP路由器的用戶平面較為簡單，僅涉及網絡層的IP協(xié)議；但其信令控制與管理平面卻涉及包括應用層在內的多個協(xié)議

6、6。如網絡層的協(xié)議除IP之外，在IP之上的子層中，有ICMP、RSVP、IPSec等；而在IP之下的子層中，有ARP、IARP和RARP等。因此，GTS的規(guī)劃必須充分考慮其復雜性，以便將單個GTS的規(guī)劃控制在可管理的范圍內。由于對路由器的測試按性質可分為：一致性測試(Conformance Test)、性能測試(Performance Test)、互通測試(Interoperability Test)、仲裁測試(Arbitration Test)等，在進行并發(fā)多端口測試時可能還包括多個協(xié)議間的多協(xié)議配合測試(Multi-protocol Coordinated Test)等，因此，GTS的規(guī)劃

7、還必須考慮適應各類測試的能力。按照ISO規(guī)定的路由器的測試方法，可分為單端口回繞測試和一對端口的穿越測試，當涉及多端口并發(fā)測試時，兩種測試方法的組合可能出現更復雜的情況。因此，GTS的規(guī)劃必須考慮上述種種因素和需要。在筆者的實踐中，探索出以下幾項GTS規(guī)劃原則： 測試集的可管理原則 單個GTS的規(guī)模不宜太大，所涉及協(xié)議宜盡量少。在筆者的IP路由器通用測試集的規(guī)劃實踐中采用了以單個協(xié)議為基礎規(guī)劃GTS的方法，以避免單個測試集過大，向下細分層次過多。 向上匯聚原則在ISO的測試集之上，我們引入了超級測試類(STC - Super Test Class)的概念，將多個測試集向上匯聚為超級測試類(ST

8、C)，相應地可派生出通用超級測試類(GSTC)和抽象超級測試類(ASTC)。由于我實驗室正進行路由器的并發(fā)多端口測試和傳統(tǒng)單個端口或一對端口的測試，筆者目前定義了兩類超級測試類：并發(fā)多端口超級測試類(MSTC - Concurrent Multi-port Super Test Class)和單個/單對端口超級測試類(SSTC-Single port/pair Super Test Class)。超級測試類可以根據需要增加。采用上述匯聚法的目的還在于能夠與其他研究單位關于單端口/單對端口測試使用的GTS具有可比性。 測試集劃分原則為了適應不同測試性質的測試需要，測試集可分為：一致性測試集、性能

9、測試集、互通測試集等。 測試組劃分原則針對不同的測試集，劃分原則也有所不同。一致性測試主要根據測試需求以協(xié)議標準為單位來劃分測試組（如鄰居發(fā)現協(xié)議測試組、RIP協(xié)議測試組等）；而性能測試主要按性能指標實現測試組的劃分（如端口流量測試組等）。測試組可根據需要進一步增加。由于一致性測試是各類測試的基礎，因此下文主要討論一致性測試集的規(guī)劃，對于其它測試集的規(guī)劃有待進一步研究。 測試子組劃分原則為了適應一致性測試的需要，每個測試組可以進一步劃分為測試子組(Subgroup)。對測試子組的劃分，主要針對被測協(xié)議的特點（如單狀態(tài)、多狀態(tài)、有連接等）采用了下面的規(guī)劃原則： 對于無連接的單狀態(tài)協(xié)議（如IPv6

10、協(xié)議）按報文格式的字段以及協(xié)議各項功能來劃分測試子組。 對于多狀態(tài)協(xié)議，無連接（如RIPng協(xié)議）或有連接協(xié)議（如OSPF協(xié)議、TCP協(xié)議）基于協(xié)議的有限狀態(tài)機并結合非狀態(tài)描述按各狀態(tài)來劃分測試子組。 通用測試例的規(guī)劃原則通用測試例是測試子組下的細化，獨立于測試方法，因此對它的規(guī)劃可采用以下原則： 按報文格式的字段劃分測試子組，其測試例的規(guī)劃主要按各字段的有效取值和無效取值劃分。 按協(xié)議功能劃分測試子組，其測試例的劃分有幾種情況：一是按功能的有效情況和無效情況劃分測試例；二是繼續(xù)劃分子功能，將之作為測試例。 基于狀態(tài)劃分的主要按各輸入事件、輸出事件、狀態(tài)變遷、狀態(tài)處理等劃分相應的測試例。值得一

11、提的是，前面討論的6項原則既適用于通用測試集(GTS)的規(guī)劃，也適用于抽象測試集(ATS)的規(guī)劃。由于ATS與測試方法有關，因此根據GTS的規(guī)劃加上具體的測試方法和測試步驟，就可以得到相應的由抽象測試例（ATC,Abstract Test Case）組成的ATS。2.2 測試數據命名與編碼規(guī)則為了使測試名稱的定義既符合2.1節(jié)中討論的規(guī)劃原則和層次性分組原則，又能夠兼顧可讀性和機器易識別性，必須對測試數據的命名和編碼做明確的規(guī)定。在相關的工作中我們對GTS和ATS分別規(guī)定了下述命名格式與編碼規(guī)則：注：表中的層次結構連接符為英文中的著重線（_），以避免與名稱中的英文連字符（-）。表2 ASTC、

12、ATS、ATM、ATG、ATSG、ATC和ATSP命名格式ASTC Name_ATS Name_Test Method Name_ATG Name_ATSG Name_ATC NameASTC Name: 抽象超級測試類名稱（字符串，最多10個字符），如路由器并發(fā)多端口超級測試類（A-MSTC-IPv6、A-MSTC-IPv4等）和缺省路由器超級測試類（A-Rdef-IPv6、A-Rdef-IPv4等）。根據需要超級測試類可以增加。ATS Name: 抽象測試集名稱（字符串，最多10個字符），如Conformance、Performance、Interoperable、Arbitration等

13、。Abstract Test Method Name: 測試方法名稱（字符串，最多10個字符），如Loop-back、Transverse等。ATG Name: 抽象測試組名稱（字符串，最多15個字符），如A-IPv4、A-IPv6、A-RSVP、A-BGP-4、A-SNMP-2等。ATSG Name: 抽象測試子組名稱（字符串，最多10個字符），如IPv6協(xié)議中版本字段的測試為Version等。ATC Name: 抽象測試例名稱(字符串，最多10個字符)，如版本字段有效取值Version-6,無效取值 Version-5、Version-4等。ATSP Name: 抽象測試步名稱（字符串，最

14、多10個子符），如發(fā)送為send,receive等。表1 GSTC、GTS、GTG、GTSG和GTC命名格式GSTC Name_GTS Name_GTG Name_GTSG Name_GTC NameGSTC Name: 通用超級測試類名稱（字符串，最多10個字符），如路由器并發(fā)多端口超級測試類（G-MSTC-IPv6、G- MSTC-IPv4等）和缺省路由器超級測試類（G-Rdef-IPv6、G-Rdef-IPv4等）。根據需要超級測試類可以增加。GTS Name: 通用測試集名稱（字符串，最多10個字符），如Conformance、 Performance、 Interoperable、

15、Arbitration等。GTG Name: 通用測試組名稱（字符串，最多15個字符），如G-IPv4、G-IPv6、G-RSVP、G-BGP-4、G-SNMP-2等。GTSG Name: 通用測試子組名稱，字符串（最多10個字符），如IPv6協(xié)議中通信流類型字段的測試為TrafficClass等。GTC Name: 通用測試例名稱(字符串，最多10個字符)，如版本字段有效取值Version-6,無效取值 Version-5、Version-4等。對比表1和2可以看出：抽象測試例（ATC）和測試步（ATSP）與測試方法有關，需要命名格式，而通用測試例（GTC,Generic Test Case

16、）的命名規(guī)則只需要到測試例為止。事實上，GTC解決測什么的問題，而ATC要根據各GTC解決怎樣測的問題（即采用一定的測試方法來實現具體的測試過程）。從人工閱讀容易的角度出發(fā)，采用表1和表2中的全稱命名方式較直觀，但書寫起來較為繁瑣，為此在機器閱讀格式中可以采用縮寫方式，即符號加序號的方式, 在兩種命名格式間需要進行映射。一個測試集（GTS或ATS）的層次結構中，允許在特定測試組中不再劃分測試子組，此時，測試子組的編碼為缺省編碼（連續(xù)5個“E” - Empty, 表示為空，或GTSG/ATSG縮寫命名為序號為“0”）。在對ATS進行編譯或解釋時即可直接將測試例隸屬于相應的測試組。3 IPv6協(xié)議

17、集測試集舉例有了規(guī)劃原則和系統(tǒng)的測試集命名規(guī)則，就可以針對不同的協(xié)議進行相應的規(guī)劃設計。下面筆者將以超級測試類IPv6協(xié)議集為例詳細討論其規(guī)劃過程。明確測試工作的對象和內容，才可有效地開展測試工作，因此首先要做好協(xié)議測試的需求分析。通過對IPv6 RFC文本及相關資料的研究，筆者針對IPv6協(xié)議集的特點對ISO1建議的測試集結構進行了相應的改進，并根據2.1節(jié)中討論的測試集的規(guī)劃原則設計了自頂向下的IPv6協(xié)議集的樹狀測試集結構(如圖1)，該結構從上到下分為以下6層： （1） 超級測試類：指路由器的IPv6協(xié)議集單個/單對端口的測試，即多個協(xié)議測試集的向上匯聚。（2） 測試集：按測試性質劃分，

18、本研究主要進行協(xié)議的一致性測試，當然還可進行性能測試等。（3） 測試組：對應于協(xié)議集一標準協(xié)議規(guī)范。如IPv6基本描述協(xié)議（RFC2460）、ICMPv6協(xié)議（RFC2463）、路由協(xié)議RIPng（RFC2080）等。（4） 測試子組：對應于一個標準協(xié)議的某一項功能描述，包含一個或多個對該項功能進行多項測試的測試例，如RFC2460中關于下一報頭的描述、HBH選項頭在擴展頭中位置的描述等。（5） 測試例：完成一個測試組可能需要多個測試例。比如為了測試RFC2460中關于HBH(Hop by Hop)選項頭在擴展頭中位置的描述，需要對HBH在擴展頭中位置的前后進行考慮，因此可設計多種順序組合，這

19、就需要測試子組中包括多個測試例。（6） 測試步：一個測試例的完成需要進行初始化、發(fā)包和收包、比較以及處理結果等等，每一個動作就是一個測試步。需說明的是，前5層可用于GTS和ATS，但測試步與測試方法有關，因此只用于ATS。圖1 IPv6協(xié)議集的樹狀測試集結構test step:test subgroup:test group:test case:BI001:HBH Behind DOH HeaderBI002Initialize,send,receive etcIPv6 Single port/pair Super Test ClassG15:RFC2080G1:RFC2460SG 8:HBH

20、 positiontest suite:P:PerformanceC:Conformace為了便于機器閱讀，筆者根據表1的命名格式設計了IPv6協(xié)議GTS縮寫的命名規(guī)則：G-SSTC-IPv6表IPv6協(xié)議集單個/單對端口超級測試類；C表一致性測試集； Gn(n為整數)表示測試組；SGn表示測試子組；BV（Valid Behavior）和BI（Invalid Behavior）加上編號表示有效行為測試例和無效行為測試例。有了測試集結構和命名規(guī)則，就可根據測試需求，選擇適當的規(guī)劃技術確定相應的測試目的。下面筆者以實踐工作中對IPv6基本描述協(xié)議2、ICMPv6協(xié)議3和RIPng協(xié)議4規(guī)劃的測試集

21、為例，詳細討論單狀態(tài)協(xié)議、多狀態(tài)協(xié)議通用測試集的規(guī)劃設計。4 單狀態(tài)協(xié)議通用測試集的規(guī)劃設計 IPv6和ICMPv6協(xié)議無狀態(tài)變遷，因此采用單狀態(tài)協(xié)議測試，筆者主要針對它們協(xié)議描述中的數據報合法性問題和協(xié)議功能實現問題來進行相應的規(guī)劃。4.1 報文格式的測試對于報文格式的測試 主要采用對數據報各字段取正常值、非正常值或者對幾個字段進行聯(lián)合取有效或無效值以達到對報文格式的一致性測試。 以 IPv6基本描述協(xié)議中基本報頭的測試規(guī)劃為例，如圖2所示，IPv6基本報頭報文格式中包括了6個字段和兩個地址字段，因此規(guī)劃時可按字段劃分測試子組，根據各字段具體要求按其有效取值和無效取值就可設計各測試子組下的測

22、試例。版本(Version)通信流類型 (TrafficClass)流標簽(Flow Label)有效負載長度 (Payload Length)下一個報頭NextHeader跳數限制(HopLimited)源地址(Source Address)（128位）目的地址(Destination Address)（128位）圖2 IPv6基本報頭格式以IPv6基本報頭版本（Version）字段測試為例，首先將該字段的測試作為第一測試子組SG1；接著根據協(xié)議文本對該字段的描述（其值必須為6），按照字段值是否有效，分別設計了有效值為6，無效值為5和4的三個測試例。設置4是想看一下被測路由器（RUT）對版本

23、號字段值為4的IPv6包是按IPv4包處理還是將之作為無效的包處理。綜合上述測試需求就得到了GS1的三個測試例，即有效行BV001（ IPv6 Version_6），無效行為BI001（IPv6 Version_5）和BI002（ IPv6 Version_4）?；緢箢^其它字段（通信流類型、流標簽等）測試目的的確定如法炮制，只是除了基于協(xié)議文本，還要盡量根據被測路由器的特點以及實踐中可能遇到的問題來設計。4.2 協(xié)議功能的測試對協(xié)議功能進行測試規(guī)劃的一般方法是根據協(xié)議文本，同時結合相關資料和實踐經驗劃分各項功能及其子功能，對應于各功能劃分同時分析出其有效和無效情況就能得到覆蓋較全面的協(xié)議功能

24、測試集。以ICMPv6協(xié)議差錯報文測試目的的定義為例，其差錯報文有四種類型：目的不可達、包過大、超時和參數出錯。每一種類型都有不同的描述和要求，根據這四種類型可將差錯報文規(guī)劃為相應的4個測試子組。對于每個測試子組下測試目的的確定以目的不可達為例進行說明。目的不可達有4種情況：沒有路由到目的、同目的的通訊由于管理被禁止、地址不可達和端口不可達。根據這四種功能設計了相應的四個測試例。因此對協(xié)議功能的測試主要在于如何對功能進行合理準確的劃分。 4.3 單狀態(tài)協(xié)議通用測試集規(guī)劃的一般方法總的來講，單狀態(tài)協(xié)議測試目的定義充分利用了軟件測試的方法等價類劃分5。就是按照協(xié)議文本將諸多情況分為有效情況和無效情

25、況。在每種情況內使用特殊代表一般的原則，使等價類采用特殊測試例來覆蓋。有效或無效情況可以更詳細的進一步劃分為各等價類，直到不能再分為止。然后每種不可再分的等價類使用特殊的測試例來覆蓋測試。事實上，就是按測試集的樹形結構，自頂向下逐步確定各分支以（測試子組）及分支下的葉節(jié)點（測試例）來實現GTS的層層規(guī)劃。 5 多狀態(tài)協(xié)議通用測試集的規(guī)劃設計多狀態(tài)協(xié)議由于具有狀態(tài)變遷因而比單狀態(tài)協(xié)議在GTS的規(guī)劃上更為復雜。本文將以IPv6的路徑信息協(xié)議RIP，即RIPng（RIP next generation）GTS的規(guī)劃為例來說明多狀態(tài)協(xié)議的規(guī)劃方法。對于RIPng這類多狀態(tài)協(xié)議，筆者結合了基于協(xié)議狀態(tài)變

26、遷和基于協(xié)議文本非狀態(tài)描述這兩種規(guī)劃技術的優(yōu)點，采用以狀態(tài)變遷為主、非狀態(tài)描述為輔來實現對多狀態(tài)協(xié)議GTS的規(guī)劃。這樣既可兼顧協(xié)議的各種狀態(tài)，又可對非狀態(tài)描述進行覆蓋，較好的保證了測試的完備性?；赗IPng協(xié)議GTS規(guī)劃的實踐，筆者提出了多狀態(tài)協(xié)議測試目的定義的一般步驟：圖3 RIPng狀態(tài)變遷圖（1） 確定協(xié)議各狀態(tài)及狀態(tài)的輸入事件和輸出事件等。較好的方法是通過狀態(tài)變遷圖來實現。筆者設計了RIPng狀態(tài)變遷圖（圖3），圓圈表狀態(tài)；弧線表狀態(tài)變遷，弧線上的標注表觸發(fā)狀態(tài)變遷的事件。 （2） 從多個狀態(tài)變遷中，篩選出對測試有意義的狀態(tài)變遷進行測試目的的確定。（3） 按照協(xié)議文本將各狀態(tài)或狀態(tài)變

27、遷某些規(guī)劃原則（如按功能）進行等價的分類，每一個分類作為一個大的測試子組，如RIPng中請求處理狀態(tài)可作為一個大的測試子組。（4） 接著進一步分為：非狀態(tài)測試（如路由條目RTE的有效性檢查，若需要非狀態(tài)測試）和狀態(tài)測試（包括對所處狀態(tài)處理的測試等），由此得出大測試子組下的小測試子組（如GS12是作為請求處理狀態(tài)這個大測試子組下對請求報文處理的小測試子組）。（5） 根據狀態(tài)的不同輸入產生的不同處理來規(guī)劃每個小測試子組下的測試例。如RIPng請求報文的處理主要以接收三種不同的請求報文（來自1000端口，源地址是全局地址；來自521端口，源地址是鏈路地址并且無RTE；請求全部路由表）為依據來進行測試例的規(guī)劃。表3 RIPng協(xié)議通用測試集的規(guī)劃基于狀態(tài)的測試目標測試子組測試例路由器剛啟動GS11周期更新處理GS32周期更新計時器處理GS41超時計時器處理GS51垃圾計時器處理GS61垃圾計時器運行處理GS71觸發(fā)更新處理GS81輸入請求處理GS9GS1310輸入響應處理GS2,GS14GS2221根