【正文】 在不完善和待修改之處，為方便協(xié)議規(guī)劃的修改與后期新定義的增加，設(shè)計了系統(tǒng)配置模塊，主要用于測試集/組/例的增、刪、改。 筆者根據(jù)命名規(guī)則，自頂向下逐步確定各分支以及分支下的葉節(jié)點（測試例）的層層規(guī)劃，將測試數(shù)據(jù)采用樹型結(jié)構(gòu)來顯示。具體規(guī)則如下：(1) 協(xié)議（Protocol）：包含IPvICMP、OSPF、BGP、SNMP、MPLS和IPsec協(xié)議等。是一級樹深。命名規(guī)則舉例：BGP邊界網(wǎng)關(guān)協(xié)議。(2) 測試集（Test Suit）：按路由器不同測試性質(zhì)的測試需要，一般將測試集可分為：一致性測試集、性能測試集、互操作性測試集、魯棒性測試集等。對測試例的動態(tài)選擇技術(shù)的研究對協(xié)議進行快速測試或完整性測試等規(guī)劃，作為后期研究。是二級樹深。命名規(guī)則舉例：C一致性測試。(3) 測試組（Test Group）：對應(yīng)于協(xié)議集標準協(xié)議規(guī)范對協(xié)議的描述，如IPSec體系結(jié)構(gòu)（RFC2401）、AH協(xié)議（RFC2402）、ESP協(xié)議（RFC2406）、IKE協(xié)議（RFC2409）等。是三級樹深。命名規(guī)則舉例：G1 AH基本報文格式測試。(4) 測試子組（Test Subgroup）：對應(yīng)于一個標準協(xié)議的某一項功能描述，包含一個或多個對該項功能進行多項測試的測試組。是四級樹深。命名規(guī)則舉例：GS1檢查ipv6版本號。(5) 測試例（Test Case）：完成一個測試組可能需要多個測試例。比如測試RFC2402中關(guān)于AH頭格式中下一頭字段的描述，需要對AH頭中該字段的值進行考慮，因此可設(shè)計多個字段值進行測試，這就需要測試子組中包括多個測試例。是五級樹深，也是最大樹深。命名規(guī)則舉例：BV001測試Next Header為4（IPinIP）時IUT是否進行AH處理。 如圖43所示：圖43 系統(tǒng)配置界面 ▲ 系統(tǒng)配置舉例： BGP協(xié)議是邊界網(wǎng)關(guān)協(xié)議，實驗室項目組編寫B(tài)GP協(xié)議的同學(xué)將協(xié)議的劃分為一致性測試集、性能測試集及互通性測試集。一致性測試集規(guī)劃為四個測試組：狀態(tài)機測試組、路由更新測試組、錯誤處理測試組以及BGP擴展測試組。測試子組下對于每個字段取值的測試將按照字段取值有效值和無效值（或錯誤值）來劃分測試例。如下表41(a)和41(b)所示：表41(a) BGP協(xié)議測試組舉例序號測試組名稱測試子組測試子組編碼1基本信息處理GBGP4ConBasic間接、直接連接GBGP4ConBasicGS1基本參數(shù)測試GBGP4ConBasicGS2路徑屬性測試GBGP4ConBasicGS3內(nèi)、外部更新GBGP4ConBasicGS4路由選擇測試GBGP4ConBasicGS5…………表41(b) BGP協(xié)議測試例舉例測試子組測試目的測試例編號測試內(nèi)容GS1測試IBGP以及EBGP的之間連接和間接連接BV001測試IBGP直接連接BV002測試IBGP間接連接BV003測試EBGP直接連接BV004測試EBGP間接連接………… 按照此規(guī)則可以將實驗室已有測試例添加到系統(tǒng)數(shù)據(jù)中，并可以隨著需求的不同隨時更新和修改。 用戶配置模塊 該模塊針對于一次具體的測試行為。其中用戶配置模塊又分為兩個子模塊：參數(shù)配置模塊與測試例配置模塊。 在參數(shù)配置模塊中，需要對被測路由器的兩個端口信息進行配置，具體包括：ip地址、端口號、以及根據(jù)測試支撐層的不同可能會用到的MAC地址。 在測試例配置模塊中，包含了被測測試例的具體描述，是測試前期準備工作的重點。測試例配置又分為兩種方式：自動模式和手動模式。 在手動測試模式下，用戶不僅可以選擇某個協(xié)議的測試集，或多個測試集的集合，也可以選擇具體的某個測試例，并且可以對測試例的執(zhí)行順序進行排序與預(yù)先設(shè)計。測試例以樹型結(jié)構(gòu)顯示，葉子節(jié)點為具體的測試例， 在左邊的顯示框中顯示，右邊為添加的測試例list。用戶可以通過“上移”、“下移”、“刪除”來調(diào)整測試例的執(zhí)行順序。點擊“確定”后，將在顯示界面上顯示出用戶自行配置的測試例順序。 值得一提的是這里的命名規(guī)則，統(tǒng)一采用“BV001漢字”的形式來表示。因為在測試執(zhí)行過程中，執(zhí)行是具體到測試例的，所以此處均以細到葉子節(jié)點的測試例來表示。以目前規(guī)定測試例的數(shù)量來看，每個測試組下的測試例數(shù)目小于100，故采用固定長度三位數(shù)字來表示測試例編號。漢字部分是對該測試例的功能描述，在用戶配置選中該測試例時可以在測試例動態(tài)顯示模塊中將測試例名稱和功能同時顯示出來。并且在顯示測試例名稱時，會按照嚴格的測試例命名規(guī)則，從一級樹深表示到最葉子節(jié)點來表示測試例的名稱，進行了統(tǒng)一表示的規(guī)定。規(guī)范化程度很高，方便測試例管理模塊調(diào)用相應(yīng)函數(shù)。 用戶可以將測試例的手動配置以文件的形式保存下來，方便下一次的打開與調(diào)用。 手動模式界面如下圖44所示：圖44 手動配置模式 在自動模式下，也采用類似手動測試方式下的界面，左邊為樹型結(jié)構(gòu)的復(fù)選框，當選擇例如BGP的快速測試集時，在右邊的顯示框中顯示出測試例動態(tài)選擇的函數(shù)集。例如非A即非B的DEMO測試函數(shù)集（用類C語言表示）：printf(“現(xiàn)在開始測試”)。printf(“先對A進行測試”)。R1=testA()。printf(“A測試結(jié)果”，R1)if (R1=ture){Print(“測試B”)。R2=testB()。Printf(“測試B結(jié)果”，R2)。}else{printf（“測試A failed, 忽略B測試”）。R2=R1。}print(“非A即非B測試結(jié)果”，R1 or R2)。return R1 or R2。 右邊顯示框中可以分為“注釋”和“函數(shù)集”兩部分顯示。 當點擊“確定”時，在顯示界面上顯示出被測協(xié)議集的注釋以及函數(shù)集內(nèi)容。如圖45所示：圖45 自動模式界面 執(zhí)行模塊 當測試文件配置好后，點擊執(zhí)行模塊可以對測試過程進行實時的操作與控制。包含開始、暫停、恢復(fù)、終止。 在手動模式下，點擊“開始”后，將按照用戶設(shè)置的配置測試例順序進行執(zhí)行，理想狀態(tài)下將list測試例表中的測試例全部順利執(zhí)行完畢。當有某一個測試例fail時，將會提示用戶是否終止測試。如果此時用戶終止測試，將是按照最簡單的“非A即非B”的原則進行，即測試例fail測試子組fail測試組fail測試集fail協(xié)議測試fail；如果用戶選擇繼續(xù)進行測試，則執(zhí)行模塊會將剩下未進行的測試例全部顯示出，可以供用戶手動進行下一測試例的執(zhí)行，直至測試全部完成。測試過程中，用戶可以手動對當前進行測試例進行暫停和恢復(fù)暫停操作，并且可以終止測試過程的進行。如圖46所示：圖46 手動執(zhí)行界面 在自動模式下，將按照用戶選擇的測試集/組/例在測試例自動化測試的原則下，自動進行測試例的順序執(zhí)行。中途不允許手動干預(yù)，直至測試結(jié)果結(jié)束，生成測試結(jié)果。具體研究將在下一章中進行討論。 測試過程動態(tài)顯示模塊 測試過程動態(tài)顯示模塊主要顯示兩部分數(shù)據(jù)： 一是用戶對測試例進行配置完畢后，將會在此模塊中顯示出一個待執(zhí)行測試例的list，表中分別包含被選擇的測試例名稱以及對應(yīng)的測試功能，或是待測的測試例的函數(shù)集以及其注解。這將涉及到測試管理模塊，將在后面的測試管理模塊中進行詳細講解。 二是執(zhí)行過程中當測試開始執(zhí)行時，將會顯示出執(zhí)行的具體步驟。當選擇“粗略模式”時，將顯示測試例執(zhí)行的三個測試結(jié)果：pass, fail, inconclusive。當某一測試例執(zhí)行失敗時，記錄失敗結(jié)果到日志模塊中；當用戶手動選擇下一測試例時，繼續(xù)動態(tài)顯示測試過程。如圖47所示：圖47 手動選擇下一個要執(zhí)行的測試例 當選擇“詳細模式”時，則按照日志記錄的格式將被測層PDU和測試支撐層PDU顯示在圖形界面上，供用戶進行在線或下線評估。 測試結(jié)果生成與日志記錄模塊 由于測試系統(tǒng)的測試是基于測試集/組/例的，在測試例的規(guī)劃和定義中詳細說明了PDU的格式、大小、內(nèi)容，被測層與支撐層等信息。因此，監(jiān)控功能的實現(xiàn)可以使規(guī)定時間內(nèi)，具體收、發(fā)了哪些包，是否符合要求等信息記錄下來，具體將作為日志的生成與分析模塊詳細進行說明，此處為調(diào)用與顯示作用。正確執(zhí)行時的測試結(jié)果顯示如圖48所示（此時為“粗略模式”顯示）：48 正確測試結(jié)果顯示 功能小結(jié) 用戶接口模塊實現(xiàn)了系統(tǒng)與用戶之間進行交互的直接橋梁的目的，使用戶可以通過該模塊對系統(tǒng)及測試進行配置，并且描述了與其它模塊之間的關(guān)系。由于用戶界面僅在TPT作為單獨的測試器時才發(fā)揮重要作用，因此本章主要是從TPT單獨測試的角度上來講述的。在整個MPCTS中，當TPT收到MPCTM的連接請求并接受時，在TPT用戶界面上僅有一個“斷開連接” 的按鈕可用，斷開連接后繼續(xù)恢復(fù)用戶界面其它功能子模塊的作用。測試管理模塊、日志生成接口模塊及與多端口測試系統(tǒng)之間的接口模塊將在下面章節(jié)中詳細介紹。 第5章 測試管理模塊及測試控制技術(shù)研究 自動化測試管理模塊 在一個現(xiàn)代軟件測試系統(tǒng)中，自動化測試的引入極大地提高了軟件測試的效率和質(zhì)量。對于規(guī)范化的軟件開發(fā)過程，自動化測試也作為一個必要的模塊對于整個工程的效率和質(zhì)量有著重要的影響力。SEI （軟件工程研究所）提出的 CMM （能力成熟度模型）[48]中一共有5個級別，該模型對軟件開發(fā)組織劃分等級，界定軟件開發(fā)過程中工程化管理的水平?；谠撃Ｊ?，現(xiàn)代軟件研究者Jerry Weinberg提出一套軟件組織模型，在該組織模型中增加了一個額外的級別，稱之為0級別。0模式組織中，在開發(fā)人員和用戶之間已經(jīng)沒有差別。在這類組織環(huán)境中，經(jīng)常采用自動化測試方法。因此，把資源用于自動化測試，并且把自動化測試當作一個軟件開發(fā)活動對待，把軟件測試自動化提升到1級別，這是解決測試自動化的核心的方案。我們應(yīng)該像運作其他的開發(fā)項目一樣來運作軟件自動化測試項目。 在路由器雙端口測試系統(tǒng)中，自動化測試管理模塊將各個獨立的測試模塊有機的連接起來，并根據(jù)對應(yīng)的各個模塊特定的測試方法和模型引入自動化測試方法。在這個過程中，筆者研究了如何實現(xiàn)自動化測試方法以及測試模型的評價方法。 從控制論的角度來看，典型的傳統(tǒng)測試方法是一個簡單的輸入輸出系統(tǒng)，測試模塊只是機械的處理輸入并生成輸出。這種模型的優(yōu)點是實現(xiàn)簡單，功能可靠。缺點是效率偏低，并難以實現(xiàn)自動化批量測試。如圖51所示：圖51 傳統(tǒng)測試方法 而自動化測試方法可以理解為是一個包含反饋的復(fù)雜系統(tǒng)。相對于不同的測試邏輯和系統(tǒng)，其可能是一個多輸入、多輸出，具有多個系統(tǒng)函數(shù)的復(fù)雜系統(tǒng)。并且由于軟件測試的特殊性，離散系統(tǒng)將占有很大的比重。我們可以用下圖描述一個典型的簡單自動化測試系統(tǒng)。圖52 簡單自動化測試系統(tǒng) 其中“測試項目”都可能是一個獨立的簡單測試系統(tǒng)，包含有不同的測試數(shù)據(jù)和測試方法。而測試管理模塊將作為中心調(diào)度模塊，根據(jù)測試結(jié)果實時調(diào)整和選擇測試項目并自動生成測試報告。 以上討論的是自動化測試的基本理論。從理論上來說，設(shè)計良好的測試管理模塊將是整個測試系統(tǒng)的中心模塊，總體控制系統(tǒng)測試的進程和方向。而在實際的工程中如何實現(xiàn)軟件的自動化測試也是一個很吸引人的技術(shù)問題。多年來，人們一直關(guān)注如何實現(xiàn)自動化測試，往往卻忽略了自動化測試方案是否符合測試需要，沒有很好地去研究如何評價和設(shè)計一個合理高效的自動化測試控制模塊。 自動化測試方法的討論 在實際的工作中，由于軟件自動化工程師習(xí)慣于把注意力僅僅集中在如何使自動化運轉(zhuǎn)起來，導(dǎo)致測試自動化達不到預(yù)期的效果。而自動化測試是一個長期的過程，為了與各個具體測試模塊的功能和其它相關(guān)修改保持一致，自動化測試需要不停地維護和擴充。所以，在自動化測試設(shè)計中考慮自動化的可擴充性是非常關(guān)鍵的。 在路由器雙端口測試管理模塊中，筆者采用控制函數(shù)說明書的方法，提供相應(yīng)的接口，由各個模塊的設(shè)計人員編寫實際的系統(tǒng)測試函數(shù)。本章亦將討論如何高效合理的設(shè)計測試函數(shù)以及判斷測試函數(shù)的一些探索性方法。 自動化測試的評判參數(shù) 自動化測試在給軟件測試帶來高效率的同時，也帶來了相應(yīng)的風(fēng)險，自動化測試函數(shù)的設(shè)計也成為關(guān)乎項目成敗的關(guān)鍵因素。 失敗的自動化會給整個項目帶來災(zāi)難性的后果，當測試人員構(gòu)建的測試自動化采用了糟糕的設(shè)計方案或者由于后期的修改引入了錯誤，都會導(dǎo)致失敗的自動化測試。根據(jù)經(jīng)驗，失敗的自動化通常是由于沒有關(guān)注自動化測試的性能或者沒有充分的自動化設(shè)計而導(dǎo)致的。 ● 性能 提高代碼的性能往往增加了代碼的復(fù)雜性，因此，會威脅到代碼的可靠性。很少有人關(guān)心如何對自動化本身加以測試。 在項目的實際工作中，通過我們對測試集/組/例性能的分析，很多測試都是花費大量的時間等候模塊的運行。因此，在不提高模塊運行性能的前提下，無法更有效的提高自動化測試執(zhí)行效率。 而相對來說，測試管理模塊的性能在這個項目中已經(jīng)足夠優(yōu)良，對于整個自動化測試的過程不會存在瓶頸。 ● 便于分析 分析執(zhí)行失敗的自動化測試結(jié)果是件困難的事情，需要從多方面著手，具體到測試邏輯的正確性和模塊的正確性都是可能的原因。 有一些方法可以幫助測試執(zhí)行失敗的結(jié)果分析，某些方法可以找到問題所在。通過在測試執(zhí)行之前檢查常見的測試環(huán)境搭建問題，從而提高測試集的可靠性；通過改進錯誤輸出報告，從而提高測試自動化的錯誤輸出的可分析性；此外，還可以改進自動化測試框架中存在的問題。 在路由器雙端口測試系統(tǒng)中，模塊的提供者將負責(zé)具體模塊的設(shè)計和測試工作并提出相應(yīng)的自動化測試邏輯。評價這些測試邏輯的正確性應(yīng)該從兩個方面入手：一是各個模塊的測試特性，這部分將由模塊提供者進行理論和實際的驗證；二是自動化測試函數(shù)的邏輯驗證。具體來說，就是一個測試函數(shù)是否高效，是否會有隱含的邏輯陷阱，是否會將自動化測試系統(tǒng)引入無限的循環(huán)測