【正文】 評價這些測試邏輯的正確性應該從兩個方面入手：一是各個模塊的測試特性，這部分將由模塊提供者進行理論和實際的驗證；二是自動化測試函數(shù)的邏輯驗證。 ● 便于分析 分析執(zhí)行失敗的自動化測試結(jié)果是件困難的事情，需要從多方面著手，具體到測試邏輯的正確性和模塊的正確性都是可能的原因。很少有人關心如何對自動化本身加以測試。 自動化測試的評判參數(shù) 自動化測試在給軟件測試帶來高效率的同時，也帶來了相應的風險，自動化測試函數(shù)的設計也成為關乎項目成敗的關鍵因素。而自動化測試是一個長期的過程，為了與各個具體測試模塊的功能和其它相關修改保持一致，自動化測試需要不停地維護和擴充。從理論上來說，設計良好的測試管理模塊將是整個測試系統(tǒng)的中心模塊，總體控制系統(tǒng)測試的進程和方向。我們可以用下圖描述一個典型的簡單自動化測試系統(tǒng)。缺點是效率偏低，并難以實現(xiàn)自動化批量測試。 在路由器雙端口測試系統(tǒng)中，自動化測試管理模塊將各個獨立的測試模塊有機的連接起來，并根據(jù)對應的各個模塊特定的測試方法和模型引入自動化測試方法。0模式組織中，在開發(fā)人員和用戶之間已經(jīng)沒有差別。 第5章 測試管理模塊及測試控制技術(shù)研究 自動化測試管理模塊 在一個現(xiàn)代軟件測試系統(tǒng)中，自動化測試的引入極大地提高了軟件測試的效率和質(zhì)量。正確執(zhí)行時的測試結(jié)果顯示如圖48所示（此時為“粗略模式”顯示）：48 正確測試結(jié)果顯示 功能小結(jié) 用戶接口模塊實現(xiàn)了系統(tǒng)與用戶之間進行交互的直接橋梁的目的，使用戶可以通過該模塊對系統(tǒng)及測試進行配置，并且描述了與其它模塊之間的關系。當某一測試例執(zhí)行失敗時，記錄失敗結(jié)果到日志模塊中；當用戶手動選擇下一測試例時，繼續(xù)動態(tài)顯示測試過程。 測試過程動態(tài)顯示模塊 測試過程動態(tài)顯示模塊主要顯示兩部分數(shù)據(jù)： 一是用戶對測試例進行配置完畢后，將會在此模塊中顯示出一個待執(zhí)行測試例的list，表中分別包含被選擇的測試例名稱以及對應的測試功能，或是待測的測試例的函數(shù)集以及其注解。測試過程中，用戶可以手動對當前進行測試例進行暫停和恢復暫停操作，并且可以終止測試過程的進行。包含開始、暫停、恢復、終止。return R1 or R2。Printf(“測試B結(jié)果”，R2)。printf(“先對A進行測試”)。規(guī)范化程度很高，方便測試例管理模塊調(diào)用相應函數(shù)。因為在測試執(zhí)行過程中，執(zhí)行是具體到測試例的，所以此處均以細到葉子節(jié)點的測試例來表示。測試例以樹型結(jié)構(gòu)顯示，葉子節(jié)點為具體的測試例， 在左邊的顯示框中顯示，右邊為添加的測試例list。 在參數(shù)配置模塊中，需要對被測路由器的兩個端口信息進行配置，具體包括：ip地址、端口號、以及根據(jù)測試支撐層的不同可能會用到的MAC地址。測試子組下對于每個字段取值的測試將按照字段取值有效值和無效值（或錯誤值）來劃分測試例。是五級樹深，也是最大樹深。是四級樹深。(3) 測試組（Test Group）：對應于協(xié)議集標準協(xié)議規(guī)范對協(xié)議的描述，如IPSec體系結(jié)構(gòu)（RFC2401）、AH協(xié)議（RFC2402）、ESP協(xié)議（RFC2406）、IKE協(xié)議（RFC2409）等。(2) 測試集（Test Suit）：按路由器不同測試性質(zhì)的測試需要，一般將測試集可分為：一致性測試集、性能測試集、互操作性測試集、魯棒性測試集等。 筆者根據(jù)命名規(guī)則，自頂向下逐步確定各分支以及分支下的葉節(jié)點（測試例）的層層規(guī)劃，將測試數(shù)據(jù)采用樹型結(jié)構(gòu)來顯示。 Graphics Panel 圖形面板用圖形的方式動態(tài)地顯示主要測試數(shù)據(jù)地交互過程和測試結(jié)論，方便地監(jiān)視測試執(zhí)行過程。252。252。筆者將用戶接口模塊劃分為以下幾個子模塊： ●系統(tǒng)初始化模塊：包括系統(tǒng)配置模塊和用戶配置模塊，完成系統(tǒng)和參數(shù)的初始化配置；●測試管理接口模塊：即執(zhí)行模塊，控制測試例的動態(tài)執(zhí)行過程；●顯示模塊：動態(tài)顯示用戶的配置信息和測試例執(zhí)行信息；●日志接口模塊：將用戶配置及測試過程、結(jié)果、操作細節(jié)記錄到日志文件中，以備后期的調(diào)用和分析。因此，當雙端口測試器作為獨立的測試系統(tǒng)使用時，用戶界面應該具有完整的測試功能接口，簡單明了、方便操作的界面，供用戶進行與系統(tǒng)的直接交互。具體的實現(xiàn)由下面的章節(jié)進行詳細的講述。兩種方式各有優(yōu)缺點。 被測層PDU數(shù)據(jù)流記錄模塊252。在某些情況下，由于各種原因，部分測試例的結(jié)果可能為“不確定”(inconclusive)，這時可能需要通過對測試結(jié)果進行人工分析，參考對被測PDU數(shù)據(jù)流和支撐層PDU數(shù)據(jù)流的記錄，得出補充結(jié)論或設計新的測試例來進一步證實相關功能的測試結(jié)果。日志文件通過log函數(shù)完成保存，數(shù)據(jù)結(jié)構(gòu)采用鏈表形式list（first，previous，next，content）。在測試過程中，一個測試例中的功能性測試與非功能性測試無法分割時，測試的評估就需要在線進行。前者將根據(jù)TPTTM執(zhí)行過程記錄被測路由器背景信息、配置信息和執(zhí)行的測試集/組/例名稱；在單測試例的執(zhí)行過程中利用單測試例執(zhí)行器（STCE）測試過程中的輸出，記錄在測試器與被測路由器間交換的協(xié)議數(shù)據(jù)單元（PDU）、測試事件（測試時鐘事件、意外事件等）、測試結(jié)果即測試失敗原因等。在粗略模式時，僅顯示出測試例的名稱、執(zhí)行時間和執(zhí)行結(jié)果：pass、fail或是inconclusive；在詳細模式下，對測試過程中的PDU流進行記錄，并將測試結(jié)果顯示在測試過程顯示子模塊中，同時寫入日志模塊，生成測試記錄報告。因此，本模塊的功能就是利用MPCTCMP 實現(xiàn)測試器間的管理與同步。 M Interface Module）來完成。有關動態(tài)測試組/例自動選擇原則也是本課題需要研究的重要內(nèi)容之一，具體見第5章的討論。 TPT測試管理模塊負責對測試進行動態(tài)選擇。 它通過用戶接口模塊與操作員進行交互完成TPT的測試配置。操作員利用此接口提供的操作界面控制和觀察測試過程：根據(jù)測試的需要并針對不同的測試對象，在測試前對測試系統(tǒng)進行參數(shù)配置；根據(jù)測試目的選擇可執(zhí)行測試集；在手動測試模式下，控制單測試例執(zhí)行過程的啟動與結(jié)束，在自動測試模式下，控制一個或多個測試集的執(zhí)行過程的啟動、中止或結(jié)束；在兩種模式下，根據(jù)操作員的需要改變顯示內(nèi)容與方式；測試結(jié)束后，操作員將利用此接口輸出（顯示或打?。y試結(jié)果和測試報告；在測試結(jié)論不確切時或要進行進一步分析時，調(diào)用相關資料進行人工分析或調(diào)用自動測試分析軟件模塊，進行測后分析。通過對測試例執(zhí)行的管理，雙端口測試例系統(tǒng)可以優(yōu)化測試，提高系統(tǒng)工作效率。 MPCTM接口模塊 在MPRCTS中，TPT在一次完整的測試活動中的業(yè)務流程如下圖32所示：圖32 TPT在路由器多端口測試系統(tǒng)業(yè)務流程圖 從圖32中可以看出，雙端口測試系統(tǒng)的測試工作是從多端口并發(fā)測試系統(tǒng)接收測試初始化數(shù)據(jù)和測試命令開始，至所有的測試例執(zhí)行完畢而結(jié)束。當TPT單獨工作時的流程圖如下圖所示： 圖31 雙端口測試器工作流程圖 而在多端口并發(fā)測試系統(tǒng)中，雙端口測試器已不是獨立的測試系統(tǒng)，而成為整個測試系統(tǒng)的基礎部件，它是測試例直接的執(zhí)行者。 當TPT單獨工作時，具有如下功能模塊：◆ 用戶接口模塊◆ 測試管理模塊◆ 日志記錄模塊◆ 測試結(jié)果分析與測試報告生成模塊 在啟動TPT軟件時，首先對系統(tǒng)進行初始化。 在雙端口測試系統(tǒng)中，僅有一個TPT參與工作。此時，并發(fā)執(zhí)行的同級TPT通過TPT和MPCTM之間的接口模塊由MPCTM提供的多種同步機制實現(xiàn)同步，有效地共享資源和協(xié)同工作，實現(xiàn)并發(fā)測試目的。 MPCTCMP接收并解析MPCTM的控制命令，傳遞給TPTTM中的測試管理模塊；根據(jù)同步命令與其它TPT同步；接收MPCTM分配的并發(fā)測試例，傳遞給執(zhí)行單元。當執(zhí)行過程中某一測試例fail時，若按照“非A即非B”的原則，則STCE不再調(diào)用未執(zhí)行的可執(zhí)行測試例，同時生成測試報告，記錄入log中；若按照手動方式，則測試管理模塊將未執(zhí)行的可執(zhí)行測試例羅列出來，供用戶手動選擇下一待執(zhí)行的測試例，一旦測試繼續(xù)開始執(zhí)行，則TPTTM將主動權(quán)交給STCE，直至測試結(jié)果完成，返回測試結(jié)果報告；若采用自動測試控制技術(shù)，則測試管理模塊按照其自動控制理論，可自動選擇下一待執(zhí)行的測試例。此時STCE以單測試例為入口，在測試漫游 (Traverser)程序的控制下，順序執(zhí)行測試例，直至測試過程完成，按照測試集的規(guī)劃判定測試結(jié)果，生成測試報告。 測試管理模塊與相關調(diào)度模塊/工具 TPTTM中的測試管理模塊是負責測試例/組/集執(zhí)行的總體宏觀調(diào)度模塊。它們一方面將被測PDU流編碼成相應支撐層環(huán)境所能識別的支撐層PDU，另一方面將來自支撐層的PDU進行相應的協(xié)議解碼，并配合收發(fā)數(shù)據(jù)包模塊實現(xiàn)可執(zhí)行測試集所描述的測試系統(tǒng)PDU數(shù)據(jù)流，同時也為各項PDU數(shù)據(jù)流記錄、測試結(jié)果分析提供數(shù)據(jù)接口。編解碼器在為測試控制數(shù)據(jù)提供編解碼接口和網(wǎng)絡傳輸接口的同時，完成了對測試支撐層的配置，從而使不同的測試控制數(shù)據(jù)在執(zhí)行時調(diào)用相應的編解碼器即可，不必考慮測試支撐層的配置細節(jié)。 Manager Module)執(zhí)行何測試例的命令后，具體負責驅(qū)動一個測試例中每一個測試步(Test Step)的執(zhí)行。由于MPCTDL作為TTCN3語言的擴展，是一種宏觀描述語言，主要集中于對系統(tǒng)同步、協(xié)調(diào)、管理功能的描述，對于單個或單對端口的測試過程的描述可以分解為若干獨立的測試過程的描述，因而可以充分發(fā)揮TTCN3的優(yōu)勢。本系統(tǒng)編譯器采用的中間語言為“C”語言。TTCN3描述的測試例雖然具有標準性、通用性和不同開發(fā)者定義的測試例可互換等優(yōu)點，但TTCN3描述的測試例尚不能直接在測試系統(tǒng)中運行，必須通過解釋或編譯的方式才可以轉(zhuǎn)換為機器代碼。 本系統(tǒng)首先由通用的形式化測試描述語言TTCN3定義抽象測試控制數(shù)據(jù)。但在具體實現(xiàn)時，考慮到所用高級語言C/C++實現(xiàn)上述網(wǎng)絡功能的特定接口，程序設計中支撐層適配模塊由編解碼程序?qū)崿F(xiàn)，與STCE程序緊密結(jié)合。 (4) 測試支撐層協(xié)議實現(xiàn)部分相當于特定測試例運行時的協(xié)議平臺，也就是該測試例的PDU在哪層協(xié)議之上傳輸。 (3) 測試支撐層適配模塊主要為PDU的編解碼功能提供符合測試環(huán)境的配置。 用戶接口模塊實現(xiàn)用戶的操作界面，初始化系統(tǒng)，以圖形化的形式動態(tài)顯示測試過程；測試管理模塊根據(jù)用戶操作參數(shù)化待運行的測試集并進行相關配置，動態(tài)選擇測試集/組/例，向STCE發(fā)出測試命令，在測試過程中監(jiān)測和記錄測試狀態(tài)；日志記錄和測試結(jié)果處理模塊綜合分析測試結(jié)果，管理測試記錄文件并生成測試報告，記錄入日志文件系統(tǒng)；TPT與MPCTM的接口模塊從MPCTM接收操作員控制命令，并將測試結(jié)果返還給MPCTM，作為MPRCTS的一部分。 TPT具有圖24所示的內(nèi)部功能結(jié)構(gòu)：它由TPT測試執(zhí)行部分和測試集支撐工具（測試控制數(shù)據(jù)描述語言TTCN3編譯器等）左右兩部分組成。TPT作為系統(tǒng)的“服務器端”，接收“客戶端”MPCTM發(fā)出的指令，根據(jù)指令執(zhí)行經(jīng)TTCN3編譯器編譯而成的可執(zhí)行測試例，并將執(zhí)行結(jié)果返回給客戶端，完成對路由器單對端口的測試。單個雙端口測試器可在同一臺PC上實現(xiàn)，在該物理設備上存在三塊網(wǎng)卡：其中兩塊作為雙端口測試系統(tǒng)中的“收”與“發(fā)”（即源IP/MAC地址與目的IP/MAC地址），另一塊網(wǎng)卡經(jīng)交換機可與同等實體上的多個雙端口測試器實現(xiàn)高速互連，并與多端口測試管理器相連。圖的左半部為測試系統(tǒng)的測試執(zhí)行部分，由硬軟件共同組成；右半部為測試控制數(shù)據(jù)的支撐工具，它包括測試控制數(shù)據(jù)描述語言本身和將該語言轉(zhuǎn)換為測試系統(tǒng)可執(zhí)行的機器代碼的工具（MPCTDL轉(zhuǎn)換器、TTCN3編譯器和C/C++編譯器）。因此，一方面具備對路由器的一對端口進行觀測的能力，另一方面又必須具備對路由器多對端口間的并發(fā)測試過程，包括測試控制數(shù)據(jù)的并發(fā)性的協(xié)調(diào)、控制和同步的能力。③ 可執(zhí)行測試例動態(tài)選擇技術(shù)研究 測試例動態(tài)選擇是提高測試效率，避免浪費測試時間的重要手段。具體來說，就是在功能設計上從用戶界面入手，盡可能全面地分析功能需求，全面規(guī)劃TPT的測試操作界面，進行初步的功能框架設計；在程序?qū)崿F(xiàn)上將緊密配合實驗室進行的測試試驗，在試驗過程中逐步完善。n 多端口并發(fā)測試管理器與雙端口測試器之間的接口模塊(TPT amp。 TPT的設計目標是：既能作為獨立的雙端口測試器，也能夠與多端口測試管理器配合做成多端口路由器的并發(fā)測試系統(tǒng)。與Agilent公司的路由器測試系列產(chǎn)品類似，Smartbits也側(cè)重于性能測試，也具有類似的局限性。盡管該系列產(chǎn)品具有一定的互通測試功能，但被動測試設備使之不具備設計主動測試的故障診斷的能力。相關的網(wǎng)絡測試儀除網(wǎng)絡運營商用作網(wǎng)絡監(jiān)測外，著名的第三方網(wǎng)絡測試機構(gòu)Partner Group也使用上述產(chǎn)品作為性能測試手段。這種平臺被稱為“模擬路由器”，其實質(zhì)是在一臺機器上通過多個進程來模擬多個路由器的工作情況來實現(xiàn)對協(xié)議的測試。優(yōu)點是HTML語言的可讀性較好，但存在一個與ISO標準測試語言TTCN描述的測試例的可比性或等價性問題。② 中科院計算技術(shù)研究所[33, 34]該所在國家863項目支持下，研制開發(fā)出一套IPv6協(xié)議一致性測試系統(tǒng)。 清華大學[2330]該系統(tǒng)對多端口的測試采用了所謂“DipIn”[31]測試配置（即測試器對所有的端口同時進行觀測）。該法是曾華燊教授在英國國家物理實驗室(NPL National Physical Laboratory )[2122]工作期間針對回繞測試法的不足提出的；在NPL工作期間他還開發(fā)了第一個使用該測試法的“黃皮書網(wǎng)管”測試系統(tǒng)。MPRCTM和TPT都由測試執(zhí)行部分和測試控制數(shù)據(jù)支撐工具兩部分組成，MPRCTM的測試執(zhí)行部件的主要任務是多端口并發(fā)測試的協(xié)調(diào)管理，測試控制數(shù)據(jù)支撐工具為MPCTDL編譯程序[19]。 要達到模擬網(wǎng)絡中繼設備的真實工作環(huán)境，測試系統(tǒng)必須能夠?qū)υO備的多個端口同時進行觀測，能夠?qū)Χ鄠€端口間的測試進行協(xié)調(diào)和同步，因此需要： 新的并發(fā)測試方法和實現(xiàn)該方法