【文章內(nèi)容簡介】 個測試過程，執(zhí)行并發(fā)測試定義語言MPCTDL描述的測試控制數(shù)據(jù)，根據(jù)測試執(zhí)行情況選擇測試?yán)?，最終生成測試報告。TPT作為系統(tǒng)的“服務(wù)器端”，接收“客戶端”MPCTM發(fā)出的指令，根據(jù)指令執(zhí)行經(jīng)TTCN3編譯器編譯而成的可執(zhí)行測試?yán)?，并將?zhí)行結(jié)果返回給客戶端，完成對路由器單對端口的測試。而此時，雙端口測試器中的兩個端口已作為一個抽象概念，并不一定需要是同一物理測試設(shè)備中的兩個端口作為一個收與發(fā)的“綁定”，而可以是多個雙端口測試器中的任意兩個端口的組合。 TPT的體系結(jié)構(gòu) 雙端口測試器TPT既可以作為MPRCTS的下級測試器與其它TPT一起對路由器進(jìn)行多端口的并發(fā)測試，又可以當(dāng)作獨立的測試儀對路由器進(jìn)行一對端口的測試。當(dāng)進(jìn)行多端口并發(fā)測試時，TPT受MPCTM的協(xié)調(diào)與控制；當(dāng)TPT作獨立的測試器時，由測試操作者通過用戶界面進(jìn)行軟件環(huán)境配置并發(fā)布測試控制命令，由路由器雙端口測試管理器(TPTTM TPT Test Manager) 控制測試過程。 TPT具有圖24所示的內(nèi)部功能結(jié)構(gòu)：它由TPT測試執(zhí)行部分和測試集支撐工具（測試控制數(shù)據(jù)描述語言TTCN3編譯器等）左右兩部分組成。圖24 路由器雙端口測試系統(tǒng) TPT測試執(zhí)行部分 圖24左半邊的測試執(zhí)行部分又由以下幾部分組成：①路由器雙端口測試管理器TPTTM、②單測試?yán)龍?zhí)行器（STCE Single Test Case Executor)、③測試支撐層適配模塊、④測試支撐層協(xié)議實現(xiàn)。 (1) 路由器雙端口測試管理器TPTTM是TPT的宏觀控制部分。它包括用戶接口模塊、測試管理模塊、日志記錄和測試結(jié)果處理模塊、與MPCTM的接口模塊等。 用戶接口模塊實現(xiàn)用戶的操作界面，初始化系統(tǒng)，以圖形化的形式動態(tài)顯示測試過程；測試管理模塊根據(jù)用戶操作參數(shù)化待運行的測試集并進(jìn)行相關(guān)配置，動態(tài)選擇測試集/組/例，向STCE發(fā)出測試命令，在測試過程中監(jiān)測和記錄測試狀態(tài)；日志記錄和測試結(jié)果處理模塊綜合分析測試結(jié)果，管理測試記錄文件并生成測試報告，記錄入日志文件系統(tǒng)；TPT與MPCTM的接口模塊從MPCTM接收操作員控制命令，并將測試結(jié)果返還給MPCTM，作為MPRCTS的一部分。 (2) 單測試?yán)龍?zhí)行器STCE完成TPTTM指定的測試?yán)膱?zhí)行。測試?yán)膱?zhí)行從測試集的入口開始，經(jīng)測試漫游程序(Traverser)在測試集定義的樹型控制結(jié)構(gòu)相應(yīng)測試分支中，根據(jù)測試定義發(fā)送PDU，再根據(jù)被測系統(tǒng)的應(yīng)答選擇性地執(zhí)行下一分支的行為，直到測試集完成，綜合結(jié)果記錄。STCE作為主控程序調(diào)用必需的鏈接庫庫函數(shù)，如TRC庫的類型和函數(shù)、winpcap的庫函數(shù)等[40]。 (3) 測試支撐層適配模塊主要為PDU的編解碼功能提供符合測試環(huán)境的配置。從理論上講，待測PDU可直接裝載于支撐層PDU的凈荷 (Payload)部分。但是，被測協(xié)議支撐層可能因被測路由器不同而異，例如，測試IPv6協(xié)議時，支撐層可能是Ethernet MAC、PPP、ATM Cell、Frame Relay，在采用Encapsulation模式下，還可能為IPv4。為了增強在不同支撐環(huán)境中的配置功能，支撐層適配功能作為邏輯上獨立的模塊成為TPT系統(tǒng)的一部分[41]。 (4) 測試支撐層協(xié)議實現(xiàn)部分相當(dāng)于特定測試?yán)\行時的協(xié)議平臺，也就是該測試?yán)腜DU在哪層協(xié)議之上傳輸。例如，對IPv6協(xié)議實現(xiàn)進(jìn)行測試時，支撐層可能為數(shù)據(jù)鏈路層或者IPv4（被測對象為IPv6 over IPv4）；而測試應(yīng)用層的路徑信息交換協(xié)議時，支撐層則可能是UDP或TCP。在進(jìn)行路徑信息交換與IP路徑選擇功能的配合測試時，可能需要根據(jù)發(fā)送的PDU的所在層次，分別調(diào)用不同的支撐層適配模塊以適應(yīng)各自的支撐層協(xié)議接口。 在邏輯設(shè)計中，STCE、支撐層適配模塊和測試支撐層協(xié)議實現(xiàn)模塊是由上而下層次分明的獨立模塊。但在具體實現(xiàn)時，考慮到所用高級語言C/C++實現(xiàn)上述網(wǎng)絡(luò)功能的特定接口，程序設(shè)計中支撐層適配模塊由編解碼程序?qū)崿F(xiàn)，與STCE程序緊密結(jié)合。 測試集支撐工具 測試集支撐工具的主要功能是將抽象測試控制數(shù)據(jù)(ATCD – Abstract Test Control Data)轉(zhuǎn)換成可執(zhí)行測試控制數(shù)據(jù)(ETCD – Executable Test Control Data)。 測試控制數(shù)據(jù)是以形式化描述技術(shù)規(guī)定某一協(xié)議標(biāo)準(zhǔn)的測試目的、測試內(nèi)容和測試步驟的代碼。它決定了測試的質(zhì)量，是測試操作和測試執(zhí)行的基礎(chǔ)。 本系統(tǒng)首先由通用的形式化測試描述語言TTCN3定義抽象測試控制數(shù)據(jù)。TTCN3是ISO9646定義的半形式化描述語言TTCN(Trees and Tabular Combined Notation)的改進(jìn)版，后來被重新解釋為“Testing and Test Control Notation Version 3”，它在同一測試系統(tǒng)引入了多個并行的測試控制單元和單元間同步的概念。抽象測試控制數(shù)據(jù)不依賴于特定測試系統(tǒng)，而是基于通用測試集（GTS Generic Test Suite）[42]與相關(guān)的協(xié)議規(guī)范，完整地說明了測試過程。TTCN3描述的測試?yán)m然具有標(biāo)準(zhǔn)性、通用性和不同開發(fā)者定義的測試?yán)苫Q等優(yōu)點，但TTCN3描述的測試?yán)胁荒苤苯釉跍y試系統(tǒng)中運行，必須通過解釋或編譯的方式才可以轉(zhuǎn)換為機器代碼。出于對未來高速路由器的多端口并發(fā)測試考慮，對測試?yán)龍?zhí)行效率要求較高，因此在筆者設(shè)計的測試系統(tǒng)開發(fā)中采用了編譯方式[43]。編譯一般分為兩個步驟：第一個步驟是將抽象描述的測試集編譯成某種中間的高級語言，第二步再用該中間語言的編譯程序編譯成最終的可執(zhí)行文件。這樣做的好處一是可以利用現(xiàn)有的高級語言編譯程序，把研究的重點放在描述語言和高級語言的轉(zhuǎn)換上；二是可以利用中間語言的可移植性，將編譯過的程序放入多種平臺上進(jìn)行編譯，從而提高編譯程序的可移植性和測試集對多操作系統(tǒng)平臺的適應(yīng)能力。本系統(tǒng)編譯器采用的中間語言為“C”語言。選用C語言的一個優(yōu)點是 C使用的最為普遍，因此容易將經(jīng)編譯后的 C程序文件，與其他測試部件的C程序聯(lián)合進(jìn)行C編譯或進(jìn)行鏈接。TTCN3描述的抽象測試控制數(shù)據(jù)，通過TTCN3編譯器轉(zhuǎn)換為C/C++程序，然后調(diào)用支撐層接口，經(jīng)C/C++編譯器編譯生成ETCD。 為了適應(yīng)多端口并發(fā)測試，實驗室開發(fā)組還定義了并發(fā)多端口測試描述語言(MPCTDL–MultiPort Concurrent Test Definition Language)。由于MPCTDL作為TTCN3語言的擴展，是一種宏觀描述語言，主要集中于對系統(tǒng)同步、協(xié)調(diào)、管理功能的描述，對于單個或單對端口的測試過程的描述可以分解為若干獨立的測試過程的描述，因而可以充分發(fā)揮TTCN3的優(yōu)勢。這樣，就整個系統(tǒng)來說，測試支撐工具還應(yīng)該包括MPCTDL的編譯器。 可執(zhí)行測試集、編譯器與TTCN3和MPCTDL之間的關(guān)系如下圖25所示：圖25 TTCNMPCTDL與編譯器和可執(zhí)行測試集之間的關(guān)系 在編譯器中還整合了一個功能模塊——單測試?yán)龍?zhí)行器和漫游器(Traverser)。單測試?yán)龍?zhí)行器主要是在收到TPTTM中測試管理模塊(Test Scheduler amp。 Manager Module)執(zhí)行何測試?yán)拿詈?，具體負(fù)責(zé)驅(qū)動一個測試?yán)忻恳粋€測試步(Test Step)的執(zhí)行。 編解碼器與支撐層適配模塊 編解碼器(Encoder/Decoder)連接后臺支撐系統(tǒng)和STCE。抽象測試控制數(shù)據(jù)在被編譯的過程中調(diào)用編解碼接口，最終生成以STCE為核心的測試控制數(shù)據(jù)。編解碼器參與了測試支撐層的配置，不同的測試控制數(shù)據(jù)處于特定的測試環(huán)境中，需要相應(yīng)測試支撐層的配置。編解碼器在為測試控制數(shù)據(jù)提供編解碼接口和網(wǎng)絡(luò)傳輸接口的同時，完成了對測試支撐層的配置，從而使不同的測試控制數(shù)據(jù)在執(zhí)行時調(diào)用相應(yīng)的編解碼器即可，不必考慮測試支撐層的配置細(xì)節(jié)。這樣，支撐層適配模塊就很好地與STCE結(jié)合在一起。 當(dāng)測試系統(tǒng)發(fā)送PDU時，需要調(diào)用PDU編碼器 (Encoder) 將待測PDU裝載于支撐層PDU之中；當(dāng)收到測試支撐層上傳的PDU時，解碼器(Decoder)需要將測試?yán)嘘P(guān)注的PDU字段進(jìn)行解碼，轉(zhuǎn)換為測試數(shù)據(jù)的內(nèi)部格式以便進(jìn)行比較。 編解碼器和支撐層適配模塊是銜接可執(zhí)行測試集、實現(xiàn)被測PDU和支撐層PDU雙向數(shù)據(jù)翻譯轉(zhuǎn)換的工具[44]。它們一方面將被測PDU流編碼成相應(yīng)支撐層環(huán)境所能識別的支撐層PDU，另一方面將來自支撐層的PDU進(jìn)行相應(yīng)的協(xié)議解碼，并配合收發(fā)數(shù)據(jù)包模塊實現(xiàn)可執(zhí)行測試集所描述的測試系統(tǒng)PDU數(shù)據(jù)流，同時也為各項PDU數(shù)據(jù)流記錄、測試結(jié)果分析提供數(shù)據(jù)接口。 這里特別需要說明的是編譯器、編解碼器與支撐層適配模塊，在概念上是獨立的功能模塊，但在系統(tǒng)的實際設(shè)計與開發(fā)中是被聯(lián)合編譯進(jìn)“可執(zhí)行測試?yán)?ETC – Executable Test Case)之中的。在TPTTM看來，每一個測試?yán)及凑找粋€命名規(guī)則編譯成了一個函數(shù)，執(zhí)行一個測試?yán)灰{(diào)用相應(yīng)的函數(shù)即可。而所有的可執(zhí)行測試?yán)鳛橐粋€函數(shù)庫，成為測試系統(tǒng)代碼實現(xiàn)的一部分。 測試管理模塊與相關(guān)調(diào)度模塊/工具 TPTTM中的測試管理模塊是負(fù)責(zé)測試?yán)?組/集執(zhí)行的總體宏觀調(diào)度模塊。TPT從用戶接口模塊接收用戶的配置信息以及測試數(shù)據(jù)后，將根據(jù)用戶的具體要求生成一個待執(zhí)行的測試序列。 若用戶選擇某一個協(xié)議的測試集時，測試管理模塊調(diào)用該測試集對應(yīng)的經(jīng)C編譯器以及TTCN3編譯器生成的、采用TTCN3形式化語言描述的測試控制數(shù)據(jù)的可執(zhí)行程序ETC。此時STCE以單測試?yán)秊槿肟冢跍y試漫游 (Traverser)程序的控制下，順序執(zhí)行測試?yán)?，直至測試過程完成，按照測試集的規(guī)劃判定測試結(jié)果，生成測試報告。發(fā)送PDU時，將按照測試?yán)械囊?guī)定的PDU字段、內(nèi)容及長度，調(diào)用PDU編碼器 (Encoder) 將待測PDU裝載于支撐層PDU之中；當(dāng)收到測試支撐層上傳的PDU時，解碼器(Decoder)需要將測試?yán)嘘P(guān)注的PDU字段進(jìn)行解碼，轉(zhuǎn)換為測試數(shù)據(jù)的內(nèi)部格式以便進(jìn)行比較。 若用戶僅對某特定組合的測試?yán)信d趣，則測試管理模塊在生成待測序列后，調(diào)用STCE。當(dāng)執(zhí)行過程中某一測試?yán)齠ail時，若按照“非A即非B”的原則，則STCE不再調(diào)用未執(zhí)行的可執(zhí)行測試?yán)?，同時生成測試報告，記錄入log中；若按照手動方式，則測試管理模塊將未執(zhí)行的可執(zhí)行測試?yán)_列出來，供用戶手動選擇下一待執(zhí)行的測試?yán)?，一旦測試?yán)^續(xù)開始執(zhí)行，則TPTTM將主動權(quán)交給STCE，直至測試結(jié)果完成，返回測試結(jié)果報告；若采用自動測試控制技術(shù)，則測試管理模塊按照其自動控制理論，可自動選擇下一待執(zhí)行的測試?yán)?TPT與MPCTM的接口 當(dāng)TPT作為MPRCTS的下級測試器對路由器進(jìn)行多端口并發(fā)測試時，它主要通過MPCTCMP (MultiPort Concurrent Testing Coordination amp。 Management Protocol) 協(xié)議來接受多端口并發(fā)測試管理器MPCTM(MultiPort Concurrent Test Manager)的協(xié)調(diào)與控制，通過TPT與MPCTM之間的接口模塊(TPT amp。 MPCTM Interface Module)負(fù)責(zé)與MPCTM進(jìn)行傳輸協(xié)商。 MPCTCMP接收并解析MPCTM的控制命令，傳遞給TPTTM中的測試管理模塊；根據(jù)同步命令與其它TPT同步；接收MPCTM分配的并發(fā)測試?yán)?，傳遞給執(zhí)行單元。測試管理模塊收到命令后根據(jù)不同事件實現(xiàn)協(xié)議狀態(tài)變遷，按系統(tǒng)要求執(zhí)行測試?yán)?組管理調(diào)度可執(zhí)行測試?yán)?。MPCTCMP向MPCTM發(fā)送通信請求或應(yīng)答，并負(fù)責(zé)將測試結(jié)果處理模塊生成的單對端口測試結(jié)果傳遞給MPCTM，形成測試記錄文件 (Logging)。 在進(jìn)行多端口并發(fā)測試時，每個TPT作為整個系統(tǒng)中的一個測試部件和其它TPT協(xié)同工作，將高性能路由器的多個端口包圍起來，以模擬出路由器的實際工作環(huán)境，甚至可以通過數(shù)據(jù)發(fā)生器 (Data Generator) [45]故意制造重負(fù)載環(huán)境和外部攻擊以進(jìn)行性能測試。此時，并發(fā)執(zhí)行的同級TPT通過TPT和MPCTM之間的接口模塊由MPCTM提供的多種同步機制實現(xiàn)同步，有效地共享資源和協(xié)同工作，實現(xiàn)并發(fā)測試目的。第3章 TPT需求分析與功能設(shè)計 需求分析 在上述多端口路由器并發(fā)測試系統(tǒng)的講解中，已經(jīng)提到雙端口測試管理器在多端口路由器并發(fā)測試系統(tǒng)中的作用與地位： 它是雙端口測試管理系統(tǒng)的主管理控制器。 它是在多端口并發(fā)測試過程中，在多端口并發(fā)測試管理器的控制下，具體執(zhí)行指定的雙端口間測試活動的執(zhí)行單元。 雙端口測試器在多端口并發(fā)測試系統(tǒng)中身兼兩職，既可作為MPRCTS的基礎(chǔ)測試模塊，參與并發(fā)測試；也可以作為獨立的測試工具對路由器的一對端口進(jìn)行測試。 在雙端口測試系統(tǒng)中，僅有一個TPT參與工作。作為獨立的測試器對路由器的任意兩個端口進(jìn)行一致性、性能等測試。此時TPT由自己的用戶接口接收數(shù)據(jù)，調(diào)用測試管理等模塊，經(jīng)單測試?yán)龍?zhí)行器STCE根據(jù)測試要求發(fā)送測試數(shù)據(jù)，接收并記錄被測對象的應(yīng)答并做出相應(yīng)的測試結(jié)論，并調(diào)用日志記錄模塊生成日志記錄。此時雙端口測試管理器作為一個獨立的系統(tǒng)，并不需要多端口與雙端口之間的接口模塊，無需與多端口并發(fā)測試系統(tǒng)管理器進(jìn)行通信，因此TPT與多端口并發(fā)測試管理器的接口并不發(fā)揮作用。 當(dāng)TPT單獨工作時，具有如下功能模塊：◆ 用戶接口模塊◆ 測試管理模塊◆ 日志記錄模塊◆ 測試結(jié)果分析與測試報告生成模塊 在啟動TPT軟件時，首先對系統(tǒng)進(jìn)行初始化。操作員通過用戶接口模塊將系統(tǒng)配置信息和測試配置信息傳遞給測試管理模塊，有自動配置和手動配置兩種模式。在測試管理模塊的協(xié)調(diào)和管理下，調(diào)用STCE進(jìn)行測試?yán)膱?zhí)行，并將測試過程動態(tài)的顯示在顯示子模塊中。同時，將測試結(jié)果寫入日志記錄模塊中。當(dāng)TPT單獨工作時的流程圖如下圖所示：