路由器雙端口測試管理器研究與開發(fā)碩士畢業(yè)論文

研研 究究 生生 學學 位位 論論 文文路由器雙端口測試管理器研究與開發(fā)年 級 二二 級 姓 名 申請學位級別 碩 士 專 業(yè) 計算機應用技術(shù) 指 導 教 師 Classified Index: TP393Southwest Jiaotong UniversityMaster Degree ThesisRESEARCH AND DEVELOP ON TWO-PORT TEST SYSTEM UNDER ROUTER DISTRIBUTED MULTI-PORT SYNCHRONIZED PARALLEL TEST 摘摘 要要本論文的研究背景是路由器測試技術(shù)。多端口、高速性和既支持 IPv6又支持 IPv4 是從 IPv4 向 IPv6 過渡的整個歷史時期的特點。以 ISO9646 為代表的傳統(tǒng)的路由器測試方法為單端口的“回繞測試法” （LTM）和雙端口的“穿越測試法” （TTM） ，難以適應現(xiàn)代路由器多端口的特點；高速路由器的性能測試要求測試方法的高效性和端口間的同步協(xié)調(diào)，在 LTM 和 TTM 中都缺少相應的支持。所有這些就是四川省網(wǎng)絡通信重點實驗室（SC-Netcom Lab）提出“分布式多端口同步并行穿越測試法分布式多端口同步并行穿越測試法” （DMSP-TTM）和開發(fā)“多多端端口路由器分布式并發(fā)測試系統(tǒng)口路由器分布式并發(fā)測試系統(tǒng)”（MPR-DCTS）的直接背景。目前仍處于開發(fā)階段的路由器“分布式多端口并發(fā)測試系統(tǒng)”為兩層結(jié)構(gòu)：上層為路由器多端口測試管理器（RMPTM Router Multi-Port Test Manager） ，下層為路由器雙端口測試器（RTPT Router Two-Port Tester） 。RMPTM 處理與路由器多端口測試相關(guān)問題（為多個 RTPT 配置相關(guān)測試控制數(shù)據(jù)，同步與協(xié)調(diào)多個 RTPT 的工作。RTPT 支持 LTM 和 TTM,既可以通過局域網(wǎng)實現(xiàn)層間系統(tǒng)的互聯(lián)，構(gòu)成分布式的多端口測試系統(tǒng)，也可以作為獨立的測試系統(tǒng)完成雙端口測試。本文所反映的工作重點是關(guān)于 RTPT 的“雙端口測試管理器” （RTPTM）的研究與開發(fā)技術(shù)。RTPTM 作為多端口測試的下層測試器管理器和獨立的雙端口測試管理器具有雙重職責和雙重功能：既是雙端口測試的控制管理部件，又時對外接口與管理部件（作為獨立測試系統(tǒng)時提供與測試操作員交互接口，作為多端口測試器的下級測試器，與多端口測試管理器接口接受其控制） 。本論文的貢獻可以概括為：A、對路由器雙端口測試系統(tǒng)管理器的各功能模塊進行了分析和詳細設(shè)計，完成了對路由器雙端口測試系統(tǒng)用戶界面模塊和測試例執(zhí)行管理模塊的開發(fā)。B、設(shè)計了“測試例選擇規(guī)則表” （Test-case Selection-Rules Table TSRT）以簡化測試選擇管理和提高測試執(zhí)行效率，分別提出了單狀態(tài)協(xié)議和多狀態(tài)協(xié)議測試例管理的一般性方法。C、討論了路由器雙端口測試系統(tǒng)與上層管理器的通信問題，為今后分 布式多端口同步并行測試系統(tǒng)的開發(fā)奠定了初步的基礎(chǔ)。關(guān)鍵詞：多端口分布式同步并行穿越測試法關(guān)鍵詞：多端口分布式同步并行穿越測試法（MDSP-TTM） ；路由器雙端；路由器雙端口測試系統(tǒng)管理器（口測試系統(tǒng)管理器（RTPTMRTPTM） ；測試例選擇管理；測試例選擇管理 AbstractAbstract The background of this dissertation is router testing techniques. The main futures of modern router in the process of migrating from IPv4 to IPv6 are characterized by multi-ports, high-speed, and complication in supporting both IPv4 and IPv6. The orthodox test methods defined in ISO 9646, i.e. LTM (Loop-back Test Method) and TTM (Transverse Test Method) are not catered for such router testing. Performance testing for high-speed routers demands high-efficiency in testing as well as synchronization among multi-ports. All these have spurred the research activities at Sichuan Network Communication Key Laboratory (SC-Netcom Lab), which are represented by the novel test method called DMSP-TTM (Distributed Multi-port Synchronized Parallel TTM) and development of MPR-DCTS (Multi-Port Router Distributed Concurrent Test System). The distributed multi-port concurrent test system under development at SC-Netcom Lab takes a two-layer structure: the upper layer formed of the Router Multi-Port Test Manager (RMPTM) and the lower layer composed of multiple “Router Two-Port Testers (RTPT)”. RTPTM deals with multi-port test issues such as RTPT configuration, test case distribution, and synchronization among multiple RTPTs. RTPT on the other hand, supports both LTM and TTM and acts either as an independent test device or the low-layer device of the MPR-DCTS.The work presented in this dissertation is focused on techniques relevant to RTPTM (Router Two-Port Test Manager). The roles of an RTPTM in the MPR-DCTS are twofold: to act as the control and management entity for an RTPT, and to provide interface functions between RTPT and RTPTM in an MPR-DCTS or between RTPT and test operator when the RTPT works independently.The main contributions of this dissertation can be summarized as:A.Provisioning of a functional framework for RTPTM through detailed analysis and design, and implementation of user interface module and test case selection module.B.To improve test efficiency via dynamic test case selection according to test case execution result, a TSRT (Test-case Selection-Rules Table) is designed and generic test selection methods for single- state and multi-states protocols are provided. C.To provide a basis for future development of MPR-DCTS, communication issues between the RTPTM and the RMPTM are also provided.Keywords: MDSP-TTM (Multi-port Distributed Parallel Transverse Test Method, RTPTM (Router Two-Port Test Manager) Test Case selection 目目 錄錄摘摘 要要.IAbstractAbstract.III目目 錄錄.V第第 1 章章 緒論緒論.11.1 論文的研究背景.11.1.1 分布式多端口同步并行測試的意義.1 1.1.2 分布式多端口同步并行測試系統(tǒng).41.1.3 路由器雙端口測試系統(tǒng).51.2 研究分布式多端口同步并行測試系統(tǒng)下雙端口測試管理器的意義.71.3 論文的組織結(jié)構(gòu).81.4 作者的工作與論文的貢獻.8第第 2 2 章章 IPIP 路由器雙端口測試系統(tǒng)功能模塊簡介路由器雙端口測試系統(tǒng)功能模塊簡介.102.1 路由器雙端口測試系統(tǒng)的簡介.102.2 路由器雙端口測試系統(tǒng)功能模塊簡介.112.2.1 測試支撐工具.112.2.2 編解碼器和支撐層適配模塊.122.2.3 雙端口測試管理器.12第第 3 3 章章 路由器雙端口測試系統(tǒng)管理器設(shè)計路由器雙端口測試系統(tǒng)管理器設(shè)計.143.1 雙端口測試系統(tǒng)管理器的功能模塊組成.143.2 雙端口測試系統(tǒng)管理器的功能模塊設(shè)計.153.2.1 用戶接口模塊.153.2.2 測試管理模塊.173.2.3 測試集/組/例管理模塊.193.2.4 日志記錄模塊.193.2.4 測試結(jié)果分析與測試報告生成模塊.203.2.5 與分布式多端口同步并行測試管理器接口.213.2.6 系統(tǒng)數(shù)據(jù)庫.22第第 4 4 章章 測試例執(zhí)行管理測試例執(zhí)行管理.234.1 雙端口測試器中的測試例執(zhí)行管理.234.1.1 雙端口測試器中測試例執(zhí)行的過程.234.1.2 測試例執(zhí)行管理的策略.244.2 單狀態(tài)協(xié)議測試例的執(zhí)行管理.304.2.1 IPv6 測試例的執(zhí)行管理.314.2.2 單狀態(tài)協(xié)議測試例執(zhí)行管理的方法.344.3 多狀態(tài)協(xié)議測試例的執(zhí)行管理.354.3.1 RIPng 測試例的執(zhí)行管理 .354.3.2 多狀態(tài)協(xié)議測試例執(zhí)行管理的方法.38第第 5 章章 雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)接口的研雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)接口的研究究.40 5.1 雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)接口的作用.405.2 雙端口測試系統(tǒng)與分布式多端口同步并行測試系統(tǒng)接口的設(shè)計.415.2.1 雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)接口的數(shù)據(jù)格式.415.2.2 雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)接口的功能模塊設(shè)計.42第第 6 章章 總結(jié)與展望總結(jié)與展望.446.1 小結(jié).446.2 展望.44致致 謝謝.46參考文獻參考文獻.47Comment ZHX1: 參考文獻請按引用的先后次序標號！ 第第 1 章章 緒論緒論1.1 論文的研究背景論文的研究背景1.1.1 分布式多端口同步并行測試的分布式多端口同步并行測試的研究背景研究背景以 IPv4 為基礎(chǔ)的 Internet 在以文本為主體的應用環(huán)境中推動了計算機網(wǎng)絡技術(shù)的發(fā)展和計算機網(wǎng)絡在全球的廣泛應用，極大的改變了人們的工作、學習、生活。但是，隨著 Internet 的迅猛發(fā)展，用戶數(shù)呈指數(shù)型增長，IPv4逐漸表現(xiàn)出地址匱乏的缺點；隨著多媒體應用日益增加，用戶數(shù)據(jù)更多地呈現(xiàn)面向連接服務的特征，用戶數(shù)據(jù)流的速率不斷提高(從 Kbps 數(shù)量級提高到 Mbps 數(shù)量級)；服務質(zhì)量（QoS）的需求也有了很大的變化，Internet盡其所能的服務面臨著新的挑戰(zhàn)。IPv61將 IPv4 地址長度由 4 字節(jié)擴展為16 字節(jié)，解決了 IP 地址匱乏的問題44；對 IP 報頭的簡化，有利于提高對IP 報文的處理速度45。NGI（Next-Generation Internet）2-3就是在這一背景下產(chǎn)生的。在 Internet 發(fā)展的同時，網(wǎng)絡設(shè)備特別是在網(wǎng)絡通信中發(fā)揮巨大作用的路由器，在技術(shù)、性能等方面都得到了長足發(fā)展。在這種背景下，路由器的測試問題就重新提高到議事日程。目前對路由器的測試主要有 2個問題有待解決，一個是如何盡快把過去對以 IPv4 協(xié)議集的測試轉(zhuǎn)入到對IPv6 協(xié)議集的測試上，另一個問題是如何在測試中更好的模擬路由器的真實工作環(huán)境，以達到對其性能精確的測試。 路由器實質(zhì)上是由包括應用層協(xié)議在內(nèi)的信令控制平面和管理平面的協(xié)議集和只有 3 層結(jié)構(gòu)的用戶數(shù)據(jù)傳輸平面構(gòu)成的，因此相關(guān)的測試也必須包括分別對兩個平面的協(xié)議進行 Conformance 測試。路由器或交換路由器是 Internet 中實現(xiàn)系統(tǒng)互聯(lián)的多端口高速交換設(shè)備，目前主要是采用ISO9646 規(guī)定的兩種抽象測試法，即對單端口的“回繞測試法” （LTM - Loop-back Test Method）或?qū)σ粚Χ丝诘摹按┰綔y試法”(TTM - Transverse Test Method) 4-5。回繞測試法和穿越測試法的示意圖如圖 1-1 和圖 1-2 所示。對單端口的“回繞測試”或?qū)σ粚Χ丝诘摹按┰綔y試”都不能驗證端口間的相互影響，特別是對于性能測試，其測試結(jié)果不能定量地界定路由器的實際工作性能，特別是難以考察系統(tǒng)在并發(fā)數(shù)據(jù)的實際運行環(huán)境中符合協(xié)議的程度和性能指標，因而目前的測試技術(shù)和系統(tǒng)所進行的測試是不完整的。現(xiàn)有的測試描述語言，包括歐洲的擴展描述語言 TTCN-3 在內(nèi)，都沒有提供一個完整的描述這類并發(fā)性的機制。為了解決這兩個問題，筆者所在的四川省網(wǎng)絡通信技術(shù)重點實驗室根據(jù)過去的工作經(jīng)驗和研究基礎(chǔ)，把網(wǎng)絡協(xié)議測試技術(shù)的研究作為實驗室的4 個重點研究方向之一。相關(guān)的研究工作瞄準對路由器的“分布式多端口同步并行測試技術(shù)”的研究。迄今為止，國外尚未見以此為目標的系統(tǒng)出現(xiàn)。僅就 IPv6 協(xié)議本身的測試工作來看，目前國外的現(xiàn)有工作大體可分為兩大類：單項測試系統(tǒng)開發(fā)和在現(xiàn)有 IPv4 網(wǎng)絡環(huán)境上建立 IPv6 的互通性（Inter-operability）測試環(huán)境（即采用在 IPv4 之上利用隧道方式（Tunneling）41進行測試） 。 建立測試環(huán)境（Test bed）的研究活動：主要研究實體有兩類：IETF 和網(wǎng)絡公司（或大型網(wǎng)絡運營者） 。其中以 IETF 的“6 bone Project”6活 測試器測試器 1 1測試器測試器 2被測路由器被測路由器 中繼功能中繼功能圖 11 回繞測試法示意圖 測試器測試器被測路由器被測路由器 中繼功能中繼功能圖 12 穿越測試法示意圖Comment ZHX2: 這是端系統(tǒng)測試的實例，不是路由器測試系統(tǒng)。Comment ZHX3: 這也是端系統(tǒng)測試！ 動與本項工作相關(guān)密切。該專案的基本思想是：以現(xiàn)有的 IPv4 網(wǎng)絡為基礎(chǔ)，對 IPv6 進行“隧道” （Tunneling）測試24。從 6bone 近年的研究題目看，其重點在于盡快進行系統(tǒng)間的互通測試，在于研究如何以 IPv4 網(wǎng)絡平臺進行 IPv6 的實驗；而并未全面開展對涉及 IPv6 的兩類設(shè)備（端系統(tǒng)和中繼系統(tǒng)）和 3 類測試目標（一致性、互通性和性能測試）進行全面的方法研究和測試系統(tǒng)的建設(shè)。 開發(fā)單機測試系統(tǒng)的活動：這類項目把測試系統(tǒng)的開發(fā)作為主要研究對象。開展這類研究的單位包括研究機構(gòu)和測試設(shè)備開發(fā)廠家。前者可以美國 NIST（原 NBS）為代表，該研究所的信息技術(shù)實驗室（ITL）從 70年代末開始從事 OSI 協(xié)議的 conformance test 系統(tǒng)研究，主要采用技術(shù)為機內(nèi)測試法（Local Test Method）和分布式測試法（Distributed Test Method） ，前一種方法測試功能強，但實施困難，只適合作為系統(tǒng)自我調(diào)試；后一種方法測試設(shè)備間的同步問題未得到解決。類似的工作還有 HP 測試儀和Compaq 的測試軟件，根據(jù)相關(guān)資料重點在互通測試與性能測試。從 80 年代中期開始我國主要有下述單位涉足了網(wǎng)絡協(xié)議測試技術(shù)研究和系統(tǒng)開發(fā)：中科院成都計算機應用研究所提出了“Ferry-clip Test Approach”7并以此為基礎(chǔ)開發(fā)了針對 OSI 傳送層協(xié)議的測試系統(tǒng)，并將該測試系統(tǒng)移置到微機之中。在國家 863 項目支持下，中科院計算所研制開發(fā)出一套 IPv6 協(xié)議一致性測試系統(tǒng)8。從所發(fā)表文章來看，中科院項目IPv6CTS 雖然能實現(xiàn)多端口測試，文中并未明確提出新的并行、并發(fā)測試方法。在解決同一測試系統(tǒng)如何實現(xiàn)對多個端口進行觀測的問題上，該系統(tǒng)采用集線器作為接入路由器多端口的手段。集線器的共享特征使多端口測試實時控制較難，該文未討論如何應用于性能測試和解決實時同步問題。從系統(tǒng)開發(fā)目標看，主要是否符合協(xié)議標準的測試（Conformance Test） ，而未涉及另外兩類測試，即性能測試（Performance Test）和互通性測試（Interoperability Test） 。此外，北京郵電大學的 IPv6 研究小組9、蘭州大學 IPv6 試驗床10也涉足建立試驗系統(tǒng)和有關(guān)測試研究，主要采用的是基于IPv4 的測試。國內(nèi)關(guān)于協(xié)議測試技術(shù)的研究，在 80 年代中后期和 90 年代初中期有較多的單位開展。就 IPv6 協(xié)議測試而言，中科院計算機所發(fā)表有就 IPv6中 Neighbor Discovery 協(xié)議及其測試方面的文章11。內(nèi)蒙古大學計算機學院發(fā)表的基于 PC 的 IPv6 網(wǎng)絡平臺及其測試的探討12文章談到用 PC 組建 IPv6 網(wǎng)絡，建立測試環(huán)境用于測試 IPv6 協(xié)議的問題。清華大學從近年發(fā)Comment ZHX4: 前面似乎未提到TTCN-3,如何此處得出“綜上所述”的結(jié)論？Comment ZHX5: 什么問題？為什么有聯(lián)系到 SUPANET? 表的文章看，其工作主要是基于形式化技術(shù)研究13，有關(guān) IPv6 路由器的測試的文章中提到多端口并行測試問題，但對如何解決并發(fā)性問題尚無文章。綜上所述，國內(nèi)外已有的對路由器并行測試的工作主要是基于 TTCN-3的機制，在單機內(nèi)建立測試系統(tǒng)。其局限性在于系統(tǒng)成本較高（需要使用小型機） 、測試系統(tǒng)缺少靈活性和可移動性。為了解決上述問題，四川省網(wǎng)絡通信重點實驗室開展了對 IP 路由器的分布式多端口同步并發(fā)測試系統(tǒng)展開了研究工作和系統(tǒng)開發(fā)工作,同時也是進一步為實驗室研究的“單物理層用戶數(shù)據(jù)傳輸平臺體系結(jié)構(gòu)網(wǎng)絡”(SUPANET Single physical layer User-data transfer Platform Architecture Network) 42交換設(shè)備的測試作準備。1.1.2 分布式多端口同步并行穿越測試法和相關(guān)測試系統(tǒng)分布式多端口同步并行穿越測試法和相關(guān)測試系統(tǒng)在解決上述問題的過程中，四川省網(wǎng)絡通信重點實驗室把主要的工作重心放在分布式多端口同步并發(fā)測試系統(tǒng)的設(shè)計與研發(fā)上，在研發(fā)的過程中，同時對相關(guān)的技術(shù)展開研究。針對現(xiàn)有的多端口路由器測試技術(shù)中存在的問題，筆者所在實驗室提出了“分布式多端口同步并行穿越測試法”(DMSP-TTM - Distributed Multi-port Synchronized Parallel-TTM)，并定義了并發(fā)多端口測試定義語言（CMP-TDLConcurrent Multi-port Test Definition Language）14-15。DMSP-TTM 是基于以下應用需求提出的： 新的方法必須具備在多個端口的測試過程進行同步與協(xié)調(diào)能力，以 1便嚴格控制并行測試的過程。 支持對復雜的并行測試過程分解為并行測試過程的同步與協(xié)調(diào)和單 2個/單對端口的測試過程，以便簡化并行測試的描述和最大限度地利用已有的單個/單對端口的測試集。 物理上能夠?qū)⒉⑿袦y試管理設(shè)備與便攜或可移動的單個/單對端口測 3試器相分離，從而實現(xiàn)用物理上獨立的相對便宜的多個設(shè)備組成測試能力更強的多端口同步并行測試系統(tǒng)。 被測路由器單個/單對端口測試器 1單個/單對端口測試器 i單個/單對端口測試器 n測試數(shù)據(jù)分布式多端口同步并行管理器同步協(xié)調(diào)命令測試數(shù)據(jù)測試數(shù)據(jù)響應響應響應響應同步協(xié)調(diào)命令同步協(xié)調(diào)命令響應單個/單對端口測試系統(tǒng)響應圖 1-3 DMSP-TTM 測試法示意圖圖 1-3 即為 DMSP-TTM 測試法的簡單描述。1.1.3 本論文研究的小背景本論文研究的小背景路由器雙端口測試路由器雙端口測試器器路由器雙端口測試系統(tǒng)(RTPT Router Two-Port Tester)是路由器分布式多端口同步并發(fā)測試系統(tǒng)的基礎(chǔ)測試部件。它既能夠作為分布式路由器的多端口并發(fā)測試系統(tǒng)的底層測試器，也可以作為一個獨立的路由器雙端口測試系統(tǒng)16。圖 1-4 就是路由器雙端口測試系統(tǒng)的簡圖。從圖中可以看出，路由器雙端口測試器主要由路由器雙端口測試管理器、測試支撐工具和測試數(shù)據(jù)組成。其中測試支撐工具包括圖中所示的單測試例執(zhí)行器(Test Case Traverser)、支撐層適配模塊(即 PDU 裝/拆模塊)、測試支撐層協(xié)議實現(xiàn)和編譯器。筆者的工作就是圍繞路由器雙端口測試管理器展開的。 1.2 本論文研究對象本論文研究對象雙端口測試管理器雙端口測試管理器路由器雙端口測試器是路由器分布式多端口同步并行測試系統(tǒng)的基礎(chǔ)測試部件，一方面它是實現(xiàn)分布式多端口同步并行測試的基礎(chǔ)，另一方面它也可以脫離分布式多端口同步并行測試系統(tǒng)對雙端口或單個端口進行測試。所以在進行路由器雙端口測試管理器的設(shè)計時，就要兼顧路由器雙端口測試器的這兩個特點。在路由器雙端口測試管理器中，有一個重要模塊雙端口測試器與分布式多端口同步并行路由器測試系統(tǒng)的接口，該模塊是雙端口測試系統(tǒng) 單測試例執(zhí)行器單測試例執(zhí)行器 2 2（Test Case Traverser）圖 1-4 路由器雙端口測試例系統(tǒng)簡圖 支持層適配模塊支持層適配模塊（裝拆被測層3 3PDU） RTPTM (Router Two-1 1Port Test Manager):路由路由器雙端口測試管理器器雙端口測試管理器A.用戶接口模用戶接口模(User Interface Module): 用戶操作界面圖形化測試過程動態(tài)顯示模塊+系統(tǒng)初始化模塊可執(zhí)行測試集：可執(zhí)行測試集：ETS Executable Test Suite + Encoder/DecoderB.B.測試例測試例/ /組管理模塊：組管理模塊：靜態(tài)與動態(tài)測試例、組選擇）測試集、測試組選擇測試例選擇與測試同步信息、測試例指派與分發(fā)、測試例結(jié)論測試例調(diào)用、已編碼的 PDU融入測試例中的PDU 解碼器中。C.測試結(jié)測試結(jié)果分析與果分析與測試報告測試報告生成模塊生成模塊 測試支持層協(xié)議實現(xiàn)：測試支持層協(xié)議實現(xiàn)： 4 41)測試測試 IPv6：為：為 IPv4 或數(shù)據(jù)或數(shù)據(jù)鏈路層鏈路層2)測試應用層：測試應用層：UDP3)信控平面與用戶平面聯(lián)合測信控平面與用戶平面聯(lián)合測試：都需要試：都需要并發(fā)測試配置命令、同步、測試中間結(jié)果被測被測 PDU流、命令流流、命令流和測試結(jié)論和測試結(jié)論記錄。記錄。支持層支持層 PDU數(shù)據(jù)流記錄數(shù)據(jù)流記錄模塊：模塊：測試后進行分析用。至分布式多端口同步并行測試系統(tǒng)抽象測試集（用 TTCN-3語言描述）1、TTCNC 編譯2、C機器代碼編譯 與路由器分布式多端口同步并行測試系統(tǒng)間通信的橋梁。兩者之間的通信使進行分布式多端口同步并行測試的各個雙端口測試器可以同步協(xié)調(diào)工作，同時也使分布式多端口同步并行測試管理器可以匯總各個雙端口測試器的測試結(jié)果16。避開分布式多端口同步并行測試技術(shù)不談，就雙端口測試器本身來說，目前就這方面的研究與設(shè)計主要是針對某一特定測試任務來進行的22-23，當測試任務改變時往往需要重新設(shè)計、開發(fā)測試系統(tǒng)。這使測試系統(tǒng)缺乏靈活性和通用性。因此在設(shè)計雙端口測試系統(tǒng)時，其設(shè)計目標包括：既能夠作為路由器分布式多端口同步并行測試系統(tǒng)的底層測試器，也可以作為一個獨立的路由器雙端口測試系統(tǒng)；既能夠?qū)β酚善髦械膯蝹€協(xié)議實現(xiàn)進行測試，也能夠在多個協(xié)議的配合下進行聯(lián)合測試；既支持穿越測試法，也支持回繞測試法；既支持按事先確定的測試例執(zhí)行順序進行測試，也具備根據(jù)測試例執(zhí)行結(jié)果，動態(tài)地選擇執(zhí)行測試例，即根據(jù)協(xié)議特點和測試例執(zhí)行結(jié)果跳過不需要再執(zhí)行的測試例。雙端口測試管理器是雙端口測試系統(tǒng)的核心組成部分。它對上實現(xiàn)測試終端（雙端口測試器）和分布式多端口同步并行測試系統(tǒng)的通信；對下完成系統(tǒng)配置、測試例執(zhí)行管理、測試過程監(jiān)視和記錄、測試過程管理控制、初步測試報告的生成；在停止測試的狀況下，進一步為人工分析測試結(jié)果和形成最終的測試報告提供支持。整個測試系統(tǒng)的各模塊在測試管理器的管理下，有序協(xié)調(diào)的進行工作。綜上所述，筆者對雙端口測試管理器的研究與設(shè)計為整個系統(tǒng)的實現(xiàn)打下了良好基礎(chǔ)。1.3 論文的組織結(jié)構(gòu)論文的組織結(jié)構(gòu)本論文的后續(xù)章節(jié)內(nèi)容與組織結(jié)構(gòu)如下：第 2 章針對雙端口測試系統(tǒng)的特點，介紹路由器雙端口測試系統(tǒng)的三大部件：測試支撐工具、編/解碼器與支撐層適配模塊、雙端口測試管理器。第 3 章主要介紹筆者對雙端口測試管理器的各個功能模塊的設(shè)計。這是開發(fā)雙端口測試管理器的基礎(chǔ)。第 4 章探討對測試例執(zhí)行的管理。一方面探討了測試例執(zhí)行管理的一般 性方法；另一方面以 IPv6 基本描述協(xié)議和 RIPng 協(xié)議的測試例執(zhí)行管理為例，分別探討了對單狀態(tài)和多狀態(tài)協(xié)議測試例執(zhí)行的管理方法。第 5 章探討了雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)的接口設(shè)計，提出了兩個測試系統(tǒng)之間通信的辦法。最后，第 6 章在對論文工作進行總結(jié)的基礎(chǔ)上，對后續(xù)研究工作進行了分析和展望。1.4 作者的工作與論文的貢獻作者的工作與論文的貢獻作者在西南交通大學網(wǎng)絡通信技術(shù)省重點實驗室承擔的主要工作是對路由器雙端口測試管理器的研究與開發(fā)并探討了雙端口測試系統(tǒng)與上層分布式多端口同步并行測試系統(tǒng)的通信方法。作者的主要工作包括以下幾個方面：對路由器雙端口測試管理器的各個功能模塊進行了詳細設(shè)計； 1針對測試例執(zhí)行管理設(shè)計了測試例執(zhí)行規(guī)則表（Testcase Executing Rules 2Table TERT） ，提出了測試例執(zhí)行管理的一般性方法；以 IPv6 基本描述協(xié)議和 RIPng 協(xié)議的測試例執(zhí)行管理為例，探討了對單 3狀態(tài)和多狀態(tài)協(xié)議測試例執(zhí)行的管理方法；探討了雙端口測試系統(tǒng)與分布式多端口同步并行路由器測試系統(tǒng)之間通 4信的辦法 第第 2 2 章章 IPIP 路由器雙端口測試系統(tǒng)功能模塊簡介路由器雙端口測試系統(tǒng)功能模塊簡介2.1 路由器雙端口測試系統(tǒng)的簡介路由器雙端口測試系統(tǒng)的簡介路由器雙端口測試系統(tǒng)在分布式多端口同步并行測試系統(tǒng)中身兼兩職。既是分布式多端口同步并行測試系統(tǒng)的基礎(chǔ)測試模塊，也可以作為獨立的測試工具使用。因此在對其進行設(shè)計時，既要考慮到它與上層測試管理器的通信，也要考慮其作為獨立測試系統(tǒng)所應具備的能力。圖 2-1 描述的是路由器雙端口測試系統(tǒng)的業(yè)務流程。從圖中可以看出，測試例執(zhí)行開始從分布式多端口同步并行測試系統(tǒng)接收測試數(shù)據(jù)和測試命令測試管理模塊生成測試例執(zhí)行序列，初始化系統(tǒng)測試管理模塊指示執(zhí)行測試序列中第一個測試例漫游器執(zhí)行測試例，編/解碼器裝配數(shù)據(jù)和支撐層適配模塊收發(fā)數(shù)據(jù)測試管理器將已執(zhí)行測試例脫離執(zhí)行序列，判斷執(zhí)行序列是否為空測試執(zhí)行序列不為空測試結(jié)束測試執(zhí)行序列為空日志記錄模塊記錄被測 PDU 流和支撐層 PDU 流向分布式多端口同步并行測試系統(tǒng)發(fā)送測試數(shù)據(jù)圖 2-1 路由器雙端口測試系統(tǒng)業(yè)務流程圖 雙端口測試系統(tǒng)的測試工作是從分布式多端口同步并行測試系統(tǒng)接收測試初始化數(shù)據(jù)和測試命令開始，至所有的測試例執(zhí)行完畢而結(jié)束。期間，雙端口測試系統(tǒng)還需要完成對測試例執(zhí)行進行管理、記錄測試數(shù)據(jù)、向分布式多端口同步并行測試系統(tǒng)發(fā)送測試數(shù)據(jù)等工作。作為分布式多端口同步并行測試系統(tǒng)中的測試端，雙端口測試系統(tǒng)是整個分布式系統(tǒng)測試的基礎(chǔ)；同時它自己也有用戶界面，因此用戶可以直接使用雙端口測試例系統(tǒng)對路由器的單個或一對端口進行測試。通過執(zhí)行不同測試例，雙端口測試系統(tǒng)可以靈活的進行不同的測試任務。通過對測試例執(zhí)行的管理，雙端口測試例系統(tǒng)可以優(yōu)化測試，提高系統(tǒng)工作效率。2.2 路由器雙端口測試系統(tǒng)功能模塊簡介路由器雙端口測試系統(tǒng)功能模塊簡介2.2.1 測試支撐工具測試支撐工具測試支撐工具由圖 1-4 中的測試定義語言 TTCN-3 的編譯器和 C 編譯器組成。TTCN-3 是 ISO9646 定義的半形式化描述語言 TTCN(Trees and Tabular Combined Notation)的改進版。TTCN-317被重新解釋為“Testing and Test Control Notation Version 3”的縮寫，它在同一測試系統(tǒng)引入了多個并行的測試控制單元和單元間同步的概念。為了適應多端口同步并行測試，實驗室開發(fā)組還定義了并發(fā)多端口測試描述語言（Concurrent Multi-Port Test Definition Language-CMPTDL）49。這樣，就整個分布式系統(tǒng)來說，測試支撐工具還應該包括 CMPTDL 的編譯器18。TTCN-3 描述的測試例雖然具有標準性、通用性和不同開發(fā)者定義的測試例可互換等優(yōu)點，但 TTCN-3 描述的測試例尚不能直接在測試系統(tǒng)中運行，必須通過解釋或編譯的方式才可以轉(zhuǎn)換為機器代碼。出于對未來高速路由器的多端口同步并行測試考慮，對測試例執(zhí)行效率要求較高，因此在筆者涉及的測試系統(tǒng)開發(fā)中采用了編譯方式19。在編譯器中還整合了一個功能模塊單測試例執(zhí)行器(Traverser)。單測試例執(zhí)行器主要是在收到測試管理器執(zhí)行何測試例的命令后，具體負責驅(qū)動一個測試例中每一個測試步的執(zhí)行。 2.2.2 編解碼器和支撐層適配模塊編解碼器和支撐層適配模塊編解碼器和支撐層適配模塊（如圖 1-4 所示）是銜接可執(zhí)行測試集，實現(xiàn)被測 PDU 和支撐層 PDU 雙向數(shù)據(jù)翻譯轉(zhuǎn)換的工具。它們一方面將被測PDU 流編碼成相應支撐層環(huán)境所能識別的支撐層 PDU，另一方面將來自支撐層的 PDU 進行相應的協(xié)議解碼，并配合收發(fā)數(shù)據(jù)包模塊實現(xiàn)可執(zhí)行測試集所描述的測試系統(tǒng) PDU 數(shù)據(jù)流動，同時也為各項 PDU 數(shù)據(jù)流記錄、測試結(jié)果分析提供數(shù)據(jù)接口20。這里特別需要說明的是編譯器、編解碼器與支撐層適配模塊，在概念上是獨立的功能模塊，但在系統(tǒng)的實際設(shè)計與開發(fā)中是被聯(lián)合編譯進“可執(zhí)行測試例”(ETC Executable Test Case)之中的。在雙端口測試例管理器看來，每一個測試例都按照的一個命名規(guī)則編譯成了一個函數(shù)，執(zhí)行一個測試例只要調(diào)用相應的函數(shù)就可以了。而所有的可執(zhí)行測試例作為一個函數(shù)庫，成為測試系統(tǒng)代碼實現(xiàn)的一部分。2.2.3 雙端口測試管理器雙端口測試管理器路由器雙端口測試管理器是測試系統(tǒng)的核心部件，同時也是筆者研究與開發(fā)的對象。它在整個分布式系統(tǒng)中實現(xiàn)測試終端和分布式多端口同步并行測試管理器的通信；獨立出與分布式系統(tǒng)，測試器自身也可以使路由器雙端口測試系統(tǒng)成為一個完整的測試系統(tǒng)。筆者根據(jù)其功能，把雙端口測試管理器劃分為以下功能模塊：用戶接口模塊測試管理模塊測試集/組/例管理模塊日志記錄模塊測試結(jié)果分析與測試報告生成模塊與分布式多端口同步并行測試管理器接口系統(tǒng)數(shù)據(jù)庫本章是關(guān)于雙端口測試系統(tǒng)的介紹，所以雙端口測試管理器各功能模塊的詳細設(shè)計，將留在下一章介紹，這里不再贅述。 第第 3 3 章章 路由器雙端口測試系統(tǒng)管理器設(shè)計路由器雙端口測試系統(tǒng)管理器設(shè)計3.1 雙端口測試系統(tǒng)管理器的功能模塊組成雙端口測試系統(tǒng)管理器的功能模塊組成在路由器雙端口測試系統(tǒng)中，除了雙端口測試管理器外，還有許多其他功能模塊，如何讓各個模塊融合在一起協(xié)調(diào)工作？在大多數(shù)測試活動中，執(zhí)行的測試例遠超過一個，如何對這些測試中執(zhí)行的測試例進行合理管理？這些問題都是路由器雙端口測試系統(tǒng)管理器設(shè)計時，需要考慮的問題。筆者在路由器雙端口測試系統(tǒng)管理器的設(shè)計與開發(fā)中，根據(jù)分布式多端口同步并行測試系統(tǒng)的要求以及路由器雙端口測試系統(tǒng)本身亦可作為獨立測試系統(tǒng)的要求，對雙端口測試系統(tǒng)管理器的功能模塊做了以下劃分：與分布式多端口同步并行測試管理器接口模塊用戶接口模塊測試管理模塊測試集/組/例管理模塊日志記錄模塊測試結(jié)果分析與測試報告生成模塊系統(tǒng)數(shù)據(jù)庫與分布式多端口同步并行測試管理器接口模塊與分布式多端口同步并行測試管理器接口模塊是路由器雙端口測試系統(tǒng)能夠成為分布式測試系統(tǒng)測試基礎(chǔ)模塊的關(guān)鍵。它接收分布式多端口同步并行測試系統(tǒng)的測試命令和測試初始化數(shù)據(jù)，同時也把每個測試例執(zhí)行的結(jié)果以及產(chǎn)生的相關(guān)數(shù)據(jù)傳輸給上層分布式測試系統(tǒng)管理器。因此可以說，如果沒有與分布式多端口同步并行測試管理器接口模塊與分布式多端口同步并行測試管理器接口模塊，整個分布式式系統(tǒng)無法協(xié)調(diào)同步工作。用戶接口模塊用戶接口模塊和系統(tǒng)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫的設(shè)計是基于雙端口測試系統(tǒng)可以作為獨立測試系統(tǒng)的考慮。這是因為，在分布式多端口同步并行測試系統(tǒng)管理器端有分布式系統(tǒng)的用戶接口模塊和整個系統(tǒng)的數(shù)據(jù)庫。如果雙端口測試系統(tǒng)只是作為分布式系統(tǒng)的一個模塊，在其測試器中則無需設(shè)計用戶接口模塊和系統(tǒng)數(shù)據(jù)庫。但是，基于雙端口測試系統(tǒng)脫離分布式系統(tǒng)也可以成為獨 立測試系統(tǒng)的考慮，在雙端口測試系統(tǒng)管理中，也必須加入這兩個模塊。3.2 雙端口測試系統(tǒng)管理器的功能模塊設(shè)計雙端口測試系統(tǒng)管理器的功能模塊設(shè)計3.2.1 用戶接口模塊用戶接口模塊如上節(jié)所述，在雙端口測試系統(tǒng)中設(shè)計用戶接口模塊，主要是基于該測試系統(tǒng)能夠自成獨立系統(tǒng)的考慮，同時它的設(shè)計與開發(fā)，也為上層分布式多端口同步并行測試系統(tǒng)中用戶接口的設(shè)計提供了可借鑒經(jīng)驗。用戶接口模塊的主體功能：生成用戶界面；向測試管理模塊傳送用戶數(shù)據(jù)；顯示測試數(shù)據(jù)。根據(jù)其功能，筆者把該模塊劃分為三個子模塊：用戶界面生成模塊測試數(shù)據(jù)傳輸模塊測試數(shù)據(jù)顯示模塊“用戶界面生成模塊”用于在顯示終端生成完整的用戶界面，以利于用戶輸入信息、控制測試和瀏覽結(jié)果。其中用戶界面包括“測試控制” 、 “顯示” 、 “日志” 、 “幫助”四個下拉菜單。測試控制菜單：包括“新建測試” 、“開始測試” 、 “中止測試”命令。 “新建測試”命令，由向?qū)е敢脩粜陆ㄒ粋€測試項目。 “自動測試”項目只需要用戶選擇進行何種測試和輸入測試用戶接口模塊用戶接口模塊用戶界面生成模塊用戶界面生成模塊測試數(shù)據(jù)傳輸模塊測試數(shù)據(jù)傳輸模塊測試數(shù)據(jù)顯示模塊測試數(shù)據(jù)顯示模塊測試管理模塊測試管理模塊系統(tǒng)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫圖 3-1 用戶接口模塊數(shù)據(jù)流圖 參數(shù)即可由系統(tǒng)自動完成測試；“自定義測試”項目需要用戶自行選擇測試例和輸入測試參數(shù)。 “開始測試”命令用于在測試系統(tǒng)準備就緒后通知系統(tǒng)開始測試。 “中止測試”命令用于測試過程中強行中止測試。顯示菜單：可在通過此菜單選擇顯示或關(guān)閉那些窗口。日志菜單：包括“保存測試日志” 、 “保存測試報告” 、 “載入測試日志” 、 “載入測試報告”命令。用戶使用這些命令可以將測試日志和測試報告保存為文件，也可以從文件中讀出以前保存的測試日志和測試報告。幫助菜單：提供幫助系統(tǒng)和軟件版本號?！皽y試數(shù)據(jù)傳輸模塊”用于在用戶接口模塊內(nèi)部的子模塊間或與其他模塊進行數(shù)據(jù)傳輸。主要的數(shù)據(jù)傳輸流程如圖 3-1 所示：1)將用戶通過用戶界面輸入的測試數(shù)據(jù)，傳送到測試管理模塊2)將用戶輸入的測試系統(tǒng)參數(shù)存入系統(tǒng)數(shù)據(jù)庫。測試系統(tǒng)參數(shù)包括測試對象和測試端口的 IP 地址，如果數(shù)據(jù)鏈路層為以太網(wǎng)，則還包括 MAC 地址的配置等。因為經(jīng)編譯器編譯形成的可執(zhí)行測試例是通用測試例，對于具體的測試環(huán)境并不能預知。所以需要用戶在測試之間輸入測試配置信息，并由測試數(shù)據(jù)傳輸模塊存入系統(tǒng)數(shù)據(jù)庫。當測試例執(zhí)行時，需要相關(guān)的測試配置信息就可以直接從系統(tǒng)數(shù)據(jù)庫中讀取。3)從系統(tǒng)數(shù)據(jù)庫中讀出測試過程中產(chǎn)生的數(shù)據(jù)，并交由測試數(shù)據(jù)顯示模塊顯示。這些測試過程中產(chǎn)生的數(shù)據(jù)包括各測試例執(zhí)行結(jié)果、被測 PDU 數(shù)據(jù)流、支撐層 PDU 數(shù)據(jù)流等“測試數(shù)據(jù)顯示模塊”用于在用戶界面顯示測試過程中產(chǎn)生的數(shù)據(jù)。在測試進行期間動態(tài)顯示每一個測試例執(zhí)行的情況；測試例全部執(zhí)行完畢后，顯示測試報告。所以其數(shù)據(jù)流如圖 3-1 所示，從測試數(shù)據(jù)傳輸模塊接收數(shù)據(jù)，將數(shù)據(jù)處理后，交由用戶界面生成模塊顯示在測試終端的顯示設(shè)備上。3.2.2 測試管理模塊測試管理模塊路由器雙端口測試系統(tǒng)的測試管理器的作用是協(xié)調(diào)管理雙端口測試系統(tǒng)中各模塊的工作，而在測試管理器內(nèi)部，起協(xié)調(diào)管理作用的則是測試管理模塊。測試管理模塊的主體功能是協(xié)調(diào)系統(tǒng)各模塊工作；調(diào)度各測試例按照適當順序執(zhí)行。 測試管理模塊測試管理模塊用戶接口模塊用戶接口模塊測試初始化模塊測試例執(zhí)行管理模塊測試集測試集/組組/例例管理模塊管理模塊漫游器漫游器系統(tǒng)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫測試結(jié)果分析與測試結(jié)果分析與測試報告生成模測試報告生成模塊塊圖 3-2 測試管理模塊數(shù)據(jù)流圖如圖 3-2 所示，測試例管理模塊幾乎與測試管理器的其余模塊都有數(shù)據(jù)通信，可見其在測試管理器中管理協(xié)調(diào)其他模塊的作用。根據(jù)測試例管理模塊的功能，筆者將其劃分為測試初始化模塊和測試例執(zhí)行管理模塊?！皽y試初始化模塊”用于在測試初始化階段從用戶接口模塊接收用戶輸入的測試數(shù)據(jù)；調(diào)用測試集/組/例管理模塊生成測試所需的測試例執(zhí)行序列；根據(jù)用戶需求和測試系統(tǒng)要求完成測試系統(tǒng)的初始化工作?！皽y試例執(zhí)行模塊”用于調(diào)度測試例的執(zhí)行。按照測試例執(zhí)行序列的順序驅(qū)動漫游器逐個執(zhí)行測試例；測試進行過程中，記錄測試例執(zhí)行結(jié)果并寫入系統(tǒng)數(shù)據(jù)庫，調(diào)用測試集/組/例管理模塊對測試例執(zhí)行進行管理；測試例全部執(zhí)行完畢后，驅(qū)動測試結(jié)果分析與測試報告生成模塊進行結(jié)果分析并生成測試報告。 3.2.3 測試集測試集/ /組組/ /例管理模塊例管理模塊測試集/組/例管理模塊的功能是對測試例的執(zhí)行按照一定的規(guī)則進行管理。它的主要工作是在測試例初始化階段，將一個測試項目所有需執(zhí)行的測試例排列成一個測試例執(zhí)行序列，序列中測試例的順序根據(jù)測試例之間關(guān)系確定；在測試進行中，對測試例執(zhí)行序列進行動態(tài)管理。有關(guān)與測試例執(zhí)行管理的具體方法，是雙端口測試管理器中主要需要解決的問題之一，因此有關(guān)于測試例執(zhí)行管理的規(guī)則，筆者在本章之后，將用一個專門的章節(jié)進行討論。這個規(guī)則就是測試集/組/例管理模塊工作的主要依據(jù)。3.2.4 日志記錄模塊日志記錄模塊在測試過程中，雙端口測試管理器需要對每個測試例執(zhí)行時產(chǎn)生的被測PDU 數(shù)據(jù)流和支撐層 PDU 數(shù)據(jù)流進行記錄。在某些情況下，由于各種原因，部分測試例的結(jié)果可能為“不確定”(inconc)，這時可能需要通過對測試結(jié)果進行人工分析，參考對被測 PDU 數(shù)據(jù)流和支撐層 PDU 數(shù)據(jù)流的記錄，得出補充結(jié)論或設(shè)計新的測試例來進一步證實相關(guān)功能的測試結(jié)果。此外，實際測試中可能出現(xiàn)測試結(jié)果的正確與否與支撐層的行為有關(guān)的情況，這就是為什么保存支撐層 PDU 數(shù)據(jù)流的原因。通過分析支撐層 PDU 數(shù)據(jù)流可能有助于進一步確定被測層出現(xiàn)的問題16。筆者根據(jù)日志記錄模塊的功能，該模塊按其所記錄數(shù)據(jù)的類型，直接將日志記錄模塊劃分成：被測 PDU 流記錄模塊支撐層 PDU 流記錄模塊如圖 3-3 所示，日志記錄模塊在編解碼器和支撐層適配模塊和系統(tǒng)數(shù)據(jù)庫之間進行數(shù)據(jù)傳輸。 3.2.4 測試結(jié)果分析與測試報告生成模塊測試結(jié)果分析與測試報告生成模塊簡單說來測試結(jié)果分析與測試報告生成模塊的功能就是分析每個測試例執(zhí)行的結(jié)果，并生成測試報告?！皽y試結(jié)果分析模塊”從系統(tǒng)數(shù)據(jù)庫中讀出每個測試例執(zhí)行結(jié)果的記錄，分析測試結(jié)果，得出測試結(jié)論，交用戶接口模塊，通過用戶界面顯示?！皽y試報告生成模塊”根據(jù)各個測試例執(zhí)行的結(jié)果，生成測試報告，把測試報告交用戶接口模塊，通過用戶界面顯示。測試報告應包括一些統(tǒng)計數(shù)據(jù)，例如本次測試執(zhí)行的測試例總數(shù)，有多少通過，多少失敗，多少不確定。一致性測試的測試報告還應指出被測路由器實現(xiàn)了那些協(xié)議功能，那些協(xié)議功能沒有實現(xiàn)；性能測試的測試報告則列出被測路由器經(jīng)測試得出的吞吐率、延遲、幀/包丟失率、幀/包突發(fā)量等21各項性能指標。圖 3-4 所描述的就是測試結(jié)果分析與測試報告生成模塊的數(shù)據(jù)流圖。在圖中可以清楚地看到，在測試結(jié)束后，測試結(jié)果分析與測試報告生成模塊只需直接從系統(tǒng)數(shù)據(jù)庫中讀取各測試例執(zhí)行的結(jié)果和相關(guān)的測試數(shù)據(jù)就可以得出測試結(jié)果和測試報告。日志記錄模塊日志記錄模塊被測 PDU 流記錄模塊支撐層 PDU 流記錄模塊系統(tǒng)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫編解碼器和支撐編解碼器和支撐層適配模塊層適配模塊圖 3-3 日志記錄模塊數(shù)據(jù)流圖Comment ZHX6: 測試系統(tǒng)中的大量數(shù)據(jù)（Logging Files, Test Suite/Group/Case, Test Report 等）都是以文字文件或程序文件形式出現(xiàn)的，使用數(shù)據(jù)庫管理系統(tǒng)還是文件管理系統(tǒng)需要斟酌。這一段內(nèi)容太空，應有分析并提供基本組成思路或初步框架。 測試結(jié)果分析與測試報告生成測試結(jié)果分析與測試報告生成模塊模塊測試結(jié)果分析模塊測試報告生成模塊系統(tǒng)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫用戶接口模塊用戶接口模塊圖 3-4 測試結(jié)果分析與測試報告生成模塊數(shù)據(jù)流圖3.2.5 與與分布式多端口同步并行測試管理器接口分布式多端口同步并行測試管理器接口與分布式多端口同步并行測試管理器接口主要負責和上層的分布式多端口同步并行測試系統(tǒng)管理器進行通信。當雙端口測試系統(tǒng)作為下層測試端工作時，必須從分布式多端口同步并行測試系統(tǒng)的管理器接收測試命令，分布式系統(tǒng)的雙端口測試系統(tǒng)才能夠同步并行的進行多端口的測試工作。此外，在進行分布式多端口同步并行測試時，用戶在上層的分布式多端口同步并行測試系統(tǒng)的管理器端進行操作，因此測試配置等數(shù)據(jù)是在分布式系統(tǒng)的上層端輸入的，這些測試配置的數(shù)據(jù)也必須通過由上層測試管理器發(fā)出，通過雙端口測試系統(tǒng)與分布式多端口同步并行測試管理器的接口來接收。因此，進行分布式多端口同步并行測試時，雙端口測試系統(tǒng)的用戶接口模塊將蛻化為單一的顯示終端。有關(guān)于在與分布式多端口同步并行測試管理器接口模塊中，兩個測試系統(tǒng)之間具體是如何進行通信的將在后繼的章節(jié)中給予詳細介紹。3.2.6 系統(tǒng)系統(tǒng)數(shù)據(jù)庫數(shù)據(jù)庫在分布式多端口同步并行測試系統(tǒng)中，上層管理器端有一個總系統(tǒng)數(shù)據(jù) 庫，下層的若干個雙端口測試系統(tǒng)都可以共享其中的數(shù)據(jù)。筆者之所以要在雙端口測試系統(tǒng)中也建立其自有數(shù)據(jù)庫主要是基于兩方面的考慮：1)雙端口測試系統(tǒng)是一個獨立的測試系統(tǒng)，所以應當有其自帶的數(shù)據(jù)庫以存儲測試系統(tǒng)參數(shù)、測試數(shù)據(jù)等2)當雙端口測試系統(tǒng)作為分布式測試系統(tǒng)一部分時，有些在測試中經(jīng)常用到的數(shù)據(jù)，不宜頻繁從上層的總系統(tǒng)數(shù)據(jù)庫中讀取，所以雙端口測試系統(tǒng)帶有自己的數(shù)據(jù)庫也是基于整個系統(tǒng)運行高效、穩(wěn)定的考慮。在雙端口測試系統(tǒng)的數(shù)據(jù)庫中有靜態(tài)和動態(tài)兩種數(shù)據(jù)。靜態(tài)數(shù)據(jù)在測試過程中始終不會變化，它就像軟件的代碼一樣，作為測試系統(tǒng)軟件的一部分。這類數(shù)據(jù)主要是測試例執(zhí)行管理的規(guī)則，在后繼章節(jié)將會詳細介紹。動態(tài)數(shù)據(jù)則是上面提到的測試系統(tǒng)參數(shù)、測試例執(zhí)行結(jié)果、被測 PDU 流記錄、支撐層 PDU 流記錄等。這些數(shù)據(jù)在每次測試時都會因為測試系統(tǒng)配置和所執(zhí)行的測試例改變而改變。Comment ZHX7: 一段文字成為“圖”不合適！ 第第 4 4 章章 測試例執(zhí)行管理測試例執(zhí)行管理4.14.1 雙端口測試器中的測試例執(zhí)行管理雙端口測試器中的測試例執(zhí)行管理前面章節(jié)已經(jīng)介紹過，在分布式多端口同步并行路由器測試系統(tǒng)中，測試工作主要是通過執(zhí)行相關(guān)測試例來進行的。在此過程中，測試例可以與被測路由器進行數(shù)據(jù)通信并通過收到的數(shù)據(jù)判定測試例執(zhí)行的結(jié)果。所有測試例的執(zhí)行都是在分布式多端口同步并行測試管理器的協(xié)調(diào)下，由若干雙端口測試器來執(zhí)行的。所以，分布式多端口同步并行路由器測試系統(tǒng)中，對測試例的執(zhí)行管理就顯得格外重要。在測試例的具體執(zhí)行者雙端口測試器中，由雙端口測試系統(tǒng)管理器具體對測試例的執(zhí)行進行管理。當單個雙端口路由器獨立進行測試時，情況也是如此。如果我們在設(shè)計雙端口測試系統(tǒng)管理器時，對測試例管理規(guī)則進行合理有效的設(shè)計，就能提高測試例執(zhí)行的效率，進而提高整個測試系統(tǒng)的性能。4.1.14.1.1 雙端口測試器中測試例執(zhí)行的過程雙端口測試器中測試例執(zhí)行的過程RTPT 實際調(diào)用的測試例是用 TTCN-3 編寫的測試例，首先將經(jīng) TTCN-3/C 編譯器生成 C/C代碼，通過與編解碼器（E/D）和單測試例游歷程序（Test Case Traverser）的 C 代碼聯(lián)合進行 C 編譯后形成的可執(zhí)行程序。按照系統(tǒng)開發(fā)各小組之間的約定，負責編譯器開發(fā)的小組把每個測試例編譯成一個函數(shù)，并以用該測試名作為該函數(shù)的名稱。所有的測試集，以函數(shù)庫的形式存在于系統(tǒng)中，測試管理器可以直接通過調(diào)用對應函數(shù)來達到執(zhí)行測試例的目的。比如進行 IPv6 一致性測試時，我們把 IPv6 測試例中測試 IPv6 版本號字段的一個測試例命名為 G1_GS1_BV001, 因此該測試例進行編譯后，將形成如下函數(shù)：圖 41 中的函數(shù)的值verdict 為一個枚舉類型25，其定義為：verdict G1_GS1_BV001( )圖 41 測試例函數(shù)Comment ZHX8: 這一段應該討論測試例的選擇原則預算法。請考慮建議的表格方式是否合理？此表的目的僅為用于測試例選擇， “測試目標”和“測試結(jié)果”有什么用？Comment ZHX9: 為什么是“通用”測試集或例？RTPT 執(zhí)行的只能是可執(zhí)行測試集、組、例。通用測試集與測試方法無關(guān)，抽象測試例與測試方法有關(guān)，但 RTPT 不能執(zhí)行，只有可執(zhí)行測試例才能為 RTPT 所用。 enum verdict pass, fail, inconclusive該枚舉類型的成員分別代表 TTCN3 中 Verdict 類型三個值：pass、fail、inconc。測試管理器通過判斷函數(shù)返回值，即枚舉類型 verdict的值就可以知道該測試例執(zhí)行的結(jié)果為 pass（通過） 、fail（失?。┻€是inconc（不確定） 。測試管理器就可以根據(jù)測試例執(zhí)行的結(jié)果做出相應操作。在實際的測試過程中，測試管理器根據(jù)用戶的選擇逐個執(zhí)行相關(guān)測試例，應該執(zhí)行那個測試例就調(diào)用那個測試例所對應的函數(shù)。測試例函數(shù)在執(zhí)行中，自動向路由器發(fā)送數(shù)據(jù)，接收反饋數(shù)據(jù)，根據(jù)反饋數(shù)據(jù)得出執(zhí)行結(jié)果，最后把結(jié)果以返回值的形式送測試管理器。測試管理器則根據(jù)測試例函數(shù)的返回值判斷其執(zhí)行結(jié)果、做出相應操作，并決定下一步執(zhí)行那一個測試例。依此類推，直到所有需要執(zhí)行的測試例都執(zhí)行完畢。這就是測試例在雙端口測試器中執(zhí)行的過程。4.1.24.1.2 測試例執(zhí)行管理的測試例執(zhí)行管理的策略策略通過上一小節(jié)的介紹已經(jīng)可以了解一個測試例執(zhí)行的大致過程，但是一次測試往往需要執(zhí)行若干測試例，而測試例執(zhí)行管理也不僅僅是簡單的執(zhí)行每個測試例，再匯集每個測試例執(zhí)行的結(jié)果。在雙端口測試系統(tǒng)管理器中，對測試例執(zhí)行的管理應著重解決以下幾個問題：當需要執(zhí)行的測試例在一個以上時，如何有序組織為數(shù)眾多的測試例當每個測試例執(zhí)行后產(chǎn)生不同結(jié)果，針對不同的執(zhí)行結(jié)果，測試系統(tǒng)應該采取那些應對操作當一個測試例執(zhí)行完畢后，如何根據(jù)其執(zhí)行的結(jié)果確定下一個應當執(zhí)行的測試例在測試系統(tǒng)的實際開發(fā)中，為了解決以上問題，筆者設(shè)計了一個測試例執(zhí)行規(guī)則表（Testcase Executin