協(xié)議工程之協(xié)議的一致性測試課件

第八章協(xié)議的一致性測試8．1基本概念計算機(jī)網(wǎng)絡(luò)或通訊系統(tǒng)的測試包括四個方面:(1)一致性測試（conformancetesting）一致性測試旨在檢測所實(shí)現(xiàn)的協(xié)議實(shí)體（或系統(tǒng)）與協(xié)議規(guī)范的符合程度;(2)性能測試（Performcetesting）性能測試旨在檢測協(xié)議實(shí)體或系統(tǒng)的性能指標(biāo)（數(shù)據(jù)傳輸率，聯(lián)接時間，執(zhí)行速度，并發(fā)度，……）;(3)互操作測試（interoperateabilitytesting）互操作測試旨在檢測同一種協(xié)議的不同實(shí)現(xiàn)版本之間，或同一類協(xié)議的不同實(shí)現(xiàn)版本之間互通的能力和互操作能力;(4)堅固性測試（robusunesstesting）。堅固性測試旨在檢測協(xié)議實(shí)體或系統(tǒng)在各種惡劣環(huán)境下運(yùn)行的能力（信道被切斷，通訊結(jié)點(diǎn)掉電，注入干擾報文……）。本章只討論一致性測試問題。第八章協(xié)議的一致性測試8．1基本概念1第八章協(xié)議的一致性測試8.1.1一致性定義在OSI范疇內(nèi)，如果一個實(shí)際系統(tǒng)在它與別的實(shí)際系統(tǒng)通訊中所表現(xiàn)的行為符合OSI協(xié)議規(guī)范的一致性要求，我們就說它呈現(xiàn)了一致性。OSI協(xié)議規(guī)范的一致性要求屬于協(xié)議規(guī)范文本的一部分，它包括:靜態(tài)一致性要求（staticconformancerequirements）和動態(tài)一致性要求（dynamicconformancerequirements）兩個方面。

靜態(tài)一致性：說明協(xié)議實(shí)現(xiàn)者必須實(shí)現(xiàn)的最小子集的內(nèi)容，定義各類協(xié)議或各個子集的內(nèi)容〔即協(xié)議實(shí)現(xiàn)者欲實(shí)現(xiàn)某類協(xié)議所必須包括的內(nèi)容），定義PDU的最大長度，定義各種協(xié)議參數(shù)、變量、定時時鐘的取值范圍等等。

動態(tài)一致性：說明協(xié)議執(zhí)行過程中。協(xié)議在每個狀態(tài)下所允許的行為是什么。例如，發(fā)出“聯(lián)接請求”報文的協(xié)議實(shí)體所期待的回答報文應(yīng)該是“聯(lián)接認(rèn)可”或“聯(lián)接拒絕”或“聯(lián)接釋放”，其它回答報文是不允許的。第八章協(xié)議的一致性測試8.1.1一致性定義2第八章協(xié)議的一致性測試

ISO頒布的一部分ISO協(xié)議已包括一致性要求文本，這些文本稱為協(xié)議實(shí)現(xiàn)一致性說明PICS（ProtocolImplementationConformanceStatements）和協(xié)議實(shí)現(xiàn)測試的附加信息PIXIT（PrococolImplementationeXtraInformationforTesting）。這些要求往往使用表格形式（tabulorproformas）來描述，前者稱作PICSproformas，后者稱作為PIXITproformas。第八章協(xié)議的一致性測試ISO頒布的一部分ISO3第八章協(xié)議的一致性測試8．1．2測試模型協(xié)議一致性測試的基本模型如圖8.1所示。（1）IUT（ImplementationUnderTest）是被測試的協(xié)議實(shí)體系統(tǒng)，（2）UT（UpperTester）高層測試軟件或硬件，（3）LT（LowerTester）是低層測試軟件〔或硬件〕。如果IUT是n層協(xié)議實(shí)體，那么UT屬于（n十1）層，LT屬于n層（LT和IUT為同等層協(xié)議實(shí)體）。UT通過PCO（PointofControlandObservation）和IUT交換（n）ASP（AbstractServicePrimitives），LT通過PCO和IUT交換（n-1）ASP。如果IUT是傳輸層協(xié)議實(shí)體，那么（n）就是TSP（TransportServicePrimitives），（n-1）ASP就是NSP(NetworkServicePrimitives)，上面的PCO就是TSAP，第八章協(xié)議的一致性測試8．1．2測試模型4第八章協(xié)議的一致性測試下面的PCO就是NSAP，圖8.1中，LT和IUT通過(n-1)層服務(wù)交換(n-1)ASP，UT和LT利用(n-1)層提供的另外一條通道交換協(xié)同信息CI(CoordinatedInformation)。為了測試能正常進(jìn)行，UT和LT可能要交換一些協(xié)同信息，解決測試的同步問題和控制問題。測試的主控者可以是UT，也可以是LT。第八章協(xié)議的一致性測試下面的PCO就是NSAP，圖8.1中5第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試6第八章協(xié)議的一致性測試下面的例子說明圖8.1模型的基本工作過程，該例子檢測IUT是否具有正常的聯(lián)接能力（假定UT為測試的主控者）。例8.1：⑴UT向IUT發(fā)聯(lián)接請求服務(wù)原語CONNECT_retuest；⑵UT告訴LT：已啟動聯(lián)接測試；⑶LT從IUT接收聯(lián)接請求報文CONNECTreq；⑷如果CONNECTreq合法，LT向IUT發(fā)接受聯(lián)接請求報文CONNECTaccept；⑸LT告訴UT：正確收到聯(lián)接請求報文，已發(fā)出CONNECTaccept報文；⑹UT從IUT接收聯(lián)接指示服務(wù)原語CONNECT_indication(confirm)，UT分析有關(guān)信息作出IUT是否有正常聯(lián)接能力的判決（verdict）。第八章協(xié)議的一致性測試下面的例子說明圖8.1模型的基本工作7第八章協(xié)議的一致性測試8.1.3測試工作流程協(xié)議一致性測試工作流程如圖8.2所示。協(xié)議規(guī)范（protocolspecification）、服務(wù)規(guī)范（servicespecification）以及根據(jù)兩者制定的協(xié)議一致性說明PICS和協(xié)議測試的附加信息PIXIT都是由標(biāo)準(zhǔn)化組織頒布的。協(xié)議一致性測試者所進(jìn)行的工作分為四步進(jìn)行。(1)第一步是根據(jù)協(xié)議規(guī)范、服務(wù)規(guī)范確定測試目的；(2)第二步是生成并描述測試套具（testsuite）；(3)第三步是按測試套具對IUT進(jìn)行測試（這意味著要建立一個測試執(zhí)行系統(tǒng)）；(4)第四步是根據(jù)測試記錄（testlogging）參照PICS和PIXIT對IUT進(jìn)行評估（assessment），并給出測試報告（testreport）。測試套具的生成（第二步）又包括幾個方面的工作：一是測試序列的生成，二是測試數(shù)據(jù)的生成，三是將測試序列和測試數(shù)據(jù)合起來生成并描述測試套具第八章協(xié)議的一致性測試8.1.3測試工作流程8第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試9第八章協(xié)議的一致性測試IUT的測試序列（testsequence）根據(jù)它的狀態(tài)轉(zhuǎn)換模型FSM（也可以是CCS模型）產(chǎn)生。對于給定測試目的，IUT應(yīng)該執(zhí)行的符合協(xié)議一致性要求的事件序列叫做測試序列。實(shí)際上，測試序列是對IUT進(jìn)行結(jié)構(gòu)測試（structuraltesting）的事件系列。因此，我們在設(shè)計測試序列時，只要考慮IUT的控制結(jié)構(gòu)就可以，無需考慮測試序列中每個事件所攜帶的參數(shù)和數(shù)據(jù)是什么。例如，下面的測試序列的目的是檢查IUT是否有正常聯(lián)接能力的測試序列。第八章協(xié)議的一致性測試IUT的測試序列（tes10第八章協(xié)議的一致性測試?yán)?.2(測試序列)：U!CONreq，L?CP，L!CA，U?CONconf這里，U表示UT，L表示LT，！表示發(fā)送，？表示接收，CONreq為聯(lián)接請求服務(wù)原語，CONconf為聯(lián)接認(rèn)可服務(wù)原語，CP為聯(lián)接請求報文，CA為接受聯(lián)接請求報文。例8.2和例8.1相似。

測試數(shù)據(jù)（testdata）的產(chǎn)生包括一系列工作。首先，我們必須將服務(wù)原語和PDU用確定數(shù)據(jù)結(jié)構(gòu)描述，然后根據(jù)測試目的產(chǎn)生服務(wù)原語和PDU的實(shí)例（instances），這些實(shí)例就是測試數(shù)據(jù)。最后，我們還必須設(shè)計和編程，產(chǎn)生PDU的編碼程序（encoder）和解碼程序（decoder），前者將PDU實(shí)例轉(zhuǎn)變成信道上可傳送的報文，后者將接收的報文轉(zhuǎn)變成PDU。編碼程序和解碼程序由LT調(diào)用。第八章協(xié)議的一致性測試?yán)?.2(測試序列)：11第八章協(xié)議的一致性測試測試套具是用某種測試執(zhí)行系統(tǒng)能夠認(rèn)識的語言描述的.測試套具包括兩大部分，一部分是測試數(shù)據(jù)的描述，另一部分是測試案例（testcases）的描述。對于給定測試目的，UT和LT擬將執(zhí)行的參數(shù)化測試事件的集合（測試事件樹）叫做測試案例。測試序列引導(dǎo)出測試案例，但兩者有較大區(qū)別。對同一個測試序列的事件施加不同的測試數(shù)據(jù)（即測試事件攜帶不同參數(shù)）就產(chǎn)生不同測試案例，因此一個測試序列對應(yīng)多個測試案例。測試案例不同于測試序列的另一個地方在于，它還必須考慮“選擇事件”。所謂“選擇事件”是，當(dāng)UT或LT接收不到IUT的正常響應(yīng)事件時，UT或LT應(yīng)該做什么。例8.3中，事件5和6是UT的選擇事件（otherwise），該事件的具體內(nèi)容由協(xié)議測試者定義。另外，測試案例與測試方法緊密相關(guān)（參見例8.5~8.8）。例8.3為一個非形式化的測試案例，測試目的和例8.1相同。source表示源地址，destination表示目的地址，reason表示拒絕原因。實(shí)際的測試事件要攜帶更多的參數(shù)。第八章協(xié)議的一致性測試測試套具是用某種測試執(zhí)12第八章協(xié)議的一致性測試?yán)?.3第八章協(xié)議的一致性測試?yán)?.313第八章協(xié)議的一致性測試8.1.4測試級別IUT的一致性測試分為四級：(1)基本互聯(lián)測試（basicinterconnectiontest）基本互聯(lián)測試旨在檢查IUT是否具備進(jìn)一步測試的條件，是否有最小的聯(lián)接能力，能否接收和發(fā)送數(shù)據(jù)。(2)能力測試（capabilitytest）能力測試旨在檢測IUT是否符合動態(tài)一致性要求。(3)行為測試（behaviourtest）行為測試旨在測試IUT是否符合動態(tài)一致性要求，它又分為兩級：覆蓋性測試（comprehensivetesting）和窮盡性測試（exhausivetesting）。覆蓋性測試只要求測試序列歷經(jīng)IUT的所有轉(zhuǎn)換至少一次就可以，而窮盡性測試要求檢查每個轉(zhuǎn)換的前后狀態(tài)。(4)一致性分解測試（conformanceresolutiontest）。一致性分解測試要求測試執(zhí)行系統(tǒng)對一致性要求逐項(xiàng)地給出yes/no的肯定回答（例如，IUT實(shí)現(xiàn)了第二類協(xié)議嗎等等）。測試總是由低級向高級逐級進(jìn)行。下面的例子是行為測試要包括的一部分內(nèi)容。第八章協(xié)議的一致性測試8.1.4測試級別14第八章協(xié)議的一致性測試IUT的行為測試分成B、C、D三大組，每個大組包括許多小組，每個小組的測試目的可能要由多個測試序列來實(shí)現(xiàn)。B．IUT對合法行為的響應(yīng)測試序列以及測試數(shù)據(jù)根據(jù)協(xié)議規(guī)范是合法的。B1聯(lián)接建立階段B1.1注重于向IUT發(fā)送什么B1.1.1每個狀態(tài)下改變測試事件B1.1.2改變定時時鐘之值B1.1.3改變PDU編碼之值B1.1.4改變單個協(xié)議參數(shù)值B1.1.5多個參數(shù)值的組合改變B1.2注重于從IUT接收什么（類同于B1.1）B1.3注重于與IUT的交互（類同于B1.1）B2數(shù)據(jù)傳輸階段（類同于B1）B3聯(lián)接釋放階段（類同于B1）第八章協(xié)議的一致性測試IUT的行為測試分成B、15第八章協(xié)議的一致性測試C．IUT對語法上不合法行為的響應(yīng)測試序列根據(jù)協(xié)議規(guī)范是合法的，但測試數(shù)據(jù)是不合法的。C1聯(lián)接建立階段C1.1注重于向IUT發(fā)送什么C1.1.1每個狀態(tài)下改變測試事件C1.1.2改變PDU編碼之值C1.1.3改變單個協(xié)議參數(shù)值C1.1.4多個協(xié)議參數(shù)值的組合改變C1.2注重于請求IUT發(fā)送什么C1.2.1單個不合法參數(shù)值C1.2.2多個不合法參數(shù)值的組合C1.3注重于與IUT的交互（類同于C1.1）C2數(shù)據(jù)傳輸階段（類同于C1）C3聯(lián)接釋放階段（類同于C1）第八章協(xié)議的一致性測試C．IUT對語法上不合法行為的響應(yīng)16第八章協(xié)議的一致性測試D．IUT對不合適事件（inopportuneevents）的響應(yīng)不合適事件為異常事件，對協(xié)議規(guī)范來說，它是不合法的。D1聯(lián)接建立階段D1.1注重于向IUT發(fā)送什么D1.1.1每個狀態(tài)下改變測試事件D1.1.2改變定時時鐘之值D1.1.3改變PDU編碼之值D1.1.4改變單個協(xié)議參數(shù)值D1.1.5多個參數(shù)值的組合改變D1.2注重于從IUT接收什么（類同于D1.1）D1.3注重于與IUT的交互（類同于D1.1） D2數(shù)據(jù)傳輸階段（類同于D1）D3聯(lián)接釋放階段（類同于D1）第八章協(xié)議的一致性測試D．IUT對不合適事件（inoppo17第八章協(xié)議的一致性測試8.1.5要考慮的問題協(xié)議一致性測試不但在理論上而且在工程上還有許多問題需要進(jìn)一步研究，這包括：·測試覆蓋率怎樣度量？各級測試包括多少測試就足夠了？·怎樣選取最小的測試序列去檢測最多的協(xié)議錯誤？·如果協(xié)議規(guī)范本身有錯誤，不完整，存在二義性，這將給協(xié)議一致性測試帶來什么問題，怎樣處理？·怎樣描述測試？測試描述至少有二種途徑：用測試案例，用一組程序，用參考協(xié)議實(shí)體。哪種方法最好？·怎樣產(chǎn)生測試數(shù)據(jù)？·怎樣產(chǎn)生測試序列？·UT和LT怎樣協(xié)同工作？·怎樣進(jìn)行多層協(xié)議測試？·怎樣評估測試結(jié)果？……本章只討論三個問題：下節(jié)討論測試方法，第三節(jié)討論測試套具的描述語言TTCN,第四節(jié)討論測試序列的生成方法。第八章協(xié)議的一致性測試8.1.5要考慮的問題18第八章協(xié)議的一致性測試8.2測試方法測試方法不同，產(chǎn)生和描述測試套具的方法也不同，測試執(zhí)行系統(tǒng)的結(jié)構(gòu)也不同。目前，人們已提出多種測試方法，這些方法的區(qū)別表現(xiàn)在下述幾個方面：·本地測試還是外地測試？即IUT和測試執(zhí)行系統(tǒng)的主體部分（LT）是否在同一個機(jī)器之中?！螌訁f(xié)議測試還是多層協(xié)議測試？IUT包括多層協(xié)議實(shí)體的測試為多層協(xié)議測試．·有無UT？如果有UT,UT的作用是什么？·測試的協(xié)同工作怎樣實(shí)現(xiàn)？·是否在線（on-line）測試？IUT處于正常運(yùn)行的測試為在線測試?！な欠裼袑?shí)際的低層通訊支持？·LT和IUT的接口PCO在何處？第八章協(xié)議的一致性測試8.2測試方法19第八章協(xié)議的一致性測試1．本地方法（localMethod）圖8.3為本地方法示意圖。在這種方法中，UT,LT,IUT同處于一臺機(jī)器中，測試不需要低層通訊系統(tǒng)的支持。IUT和LT的接口設(shè)在IUT的底部，UT和IUT的接口設(shè)在IUT的項(xiàng)部（即為IUT的服務(wù)訪問點(diǎn)）。由于UT和LT可以擬合在一個程序中，UT和LT的測試協(xié)同過程TCP(TestCoordinateProcedures)容易實(shí)現(xiàn)。測試案例用UT執(zhí)行的服務(wù)原語和LT執(zhí)行的服務(wù)原語來描述，此時LT扮演的角色是低層服務(wù)提供者。第八章協(xié)議的一致性測試1．本地方法（localMeth20第八章協(xié)議的一致性測試?yán)?.4:LocalMethod:1.U!CONreq2.L?(n-1)DATAreq[CP]3.L！(n-1)DATAind[CA]4.U?CONconf5.U?otherwise6.L?otherwise第八章協(xié)議的一致性測試?yán)?.4:LocalMet21第八章協(xié)議的一致性測試2.分布方法（DistributedMethod）圖8.4為分布方法示意圖。在這種方法中，IUT和UT處于同一個機(jī)器中。LT分布在其它機(jī)器中。LT和IUT借助于（n-1）層服務(wù)交換報文（可以實(shí)行在線測試），它們之間的接口PCO從IUT轉(zhuǎn)移到LT中，LT扮演的角色是（n-1）層服務(wù)的使用者。UT和LT的測試協(xié)同過程TCP隱含在測試案例中，測試同步問題由UT和LT的操作者來實(shí)現(xiàn)．適用于本地方法的測試案例必須改寫才能用于分布測試，請注意例8.5和例8.4的差別（第二行和第三行）.（n-1）DATAreq表示（n-1）層服務(wù)原語，數(shù)據(jù)發(fā)送請求．第八章協(xié)議的一致性測試2.分布方法（Distributed22第八章協(xié)議的一致性測試?yán)?.5:DistributedMethod:1.U!CONreq2.L?(n-1)DATAind[CP]3.L!(n-1)DATAreq[CA]4.U?CONconf5.U?otherwise6.L?otherwise第八章協(xié)議的一致性測試?yán)?.5:Distributed23第八章協(xié)議的一致性測試3．協(xié)同方法（CoordinatedMethod）圖8.5為協(xié)同方法示意圖．協(xié)同方法和分布方法的根本區(qū)別在于，協(xié)同方法引入測試管理協(xié)議TMP(TestManagementProtocol),UT和LT通過交換TM—PDU實(shí)行測試協(xié)同過程．TM_PDU的交換有兩個途徑，一是TM_PDU作為（n)ASP的用戶數(shù)據(jù)傳送給IUT,IUT將之傳送給LT(in-hand方式）；二是TM_PDU直接利用(n-1)層服務(wù)傳送(out_band方式）．圖8.5為in_band方式．第八章協(xié)議的一致性測試3．協(xié)同方法（Coordinate24第八章協(xié)議的一致性測試分布方法的測試案例不能用于協(xié)同方法，請注意例8.6和例8.5的差別：例8.6的第一行表示：LT向（n-1)層協(xié)議發(fā)DATAreq請求,數(shù)據(jù)是TM_PDU,TM_PDU的內(nèi)容是：UT向IUT發(fā)CONreq請求．第八章協(xié)議的一致性測試分布方法的測試案例不能25第八章協(xié)議的一致性測試?yán)?.6CoordinatedMethod:1.L!(n-1)DATAreq[TM_PDU[U!CONreq]]2.L?(n-1)DATAind[CP]3.L!(n-1)DATAreq[CA]4.L!(n-1)DATAreq[TM_PDU[U?CONcnf，othersise]]5.L?otherwise第八章協(xié)議的一致性測試?yán)?.6CoordinatedM26第八章協(xié)議的一致性測試4.遠(yuǎn)程方法（RemoteMethod）圖8.6為遠(yuǎn)程方法示意圖。該方法的最大特點(diǎn)是沒有UT，因此也不存在UT和LT的協(xié)同問題。測試案例完全用(n-1)ASP描述。遠(yuǎn)程方法適用于被動式協(xié)議實(shí)體或服務(wù)型協(xié)議實(shí)體的測試．例8.7是檢驗(yàn)lUT是否能正常接受聯(lián)接請求的測試案例，<IUT!CA＞為隱含事件．例8.7RemoteMethod:1.L!(n-1)DATAreq[CP]2.<IUT!CA>3.L?(n-1)DATAind[CA]4.L?otherwise第八章協(xié)議的一致性測試4.遠(yuǎn)程方法（RemoteMet27第八章協(xié)議的一致性測試5.渡船方法（FerryMethod)圖8.7和圖8.8為渡船方法示意圖。.它與協(xié)同方法的不同之處是，渡船方法將UT從被測系統(tǒng)中移到LT所在系統(tǒng)UT和LT可擬合在一個程序中，因此有本地方法的優(yōu)點(diǎn)。然而，在被測系統(tǒng)中取代UT的，還必須有一個渡船軟件，UT發(fā)給IUT的(n)ASP和UT從IUT獲取的(n)ASP通過渡船軟件進(jìn)行。例如，UT執(zhí)行測試事件的U!CONreq的傳遞過程是：UT通過LT，再通過IUT傳遞給Ferry(in_band方式），或UT通過(n-1)層服務(wù)直接傳遞給Ferry(out_band方式）．圖8.7為in_band方式，圖8.8為out_band方式。第八章協(xié)議的一致性測試5.渡船方法（FerryMetho28第八章協(xié)議的一致性測試渡船方法由我國學(xué)者曾華桑提出，受到國際學(xué)術(shù)界很大的重視[41]．該方法的最大優(yōu)點(diǎn)是，由于UT和LT處于同一個機(jī)器中，測試協(xié)同過程像本地方法一樣容易實(shí)現(xiàn)，被測系統(tǒng)中只要增加簡單的渡船軟件就可以了。前面四種方法都已納入ISO/DIS9646協(xié)議測試標(biāo)準(zhǔn)中，但渡船方法還未納入該標(biāo)中，原因是，有的學(xué)者認(rèn)為渡船方法只是協(xié)同方法的一種變種，是協(xié)同方法在實(shí)現(xiàn)技術(shù)上一種改進(jìn)，它們之間沒有根本區(qū)別。第八章協(xié)議的一致性測試渡船方法由我國學(xué)者曾華29第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試30第八章協(xié)議的一致性測試6.多層協(xié)議的測試方法IUT包含多層協(xié)議實(shí)體的測試稱為多層協(xié)議的測試。多層協(xié)議測試分兩種情況，一是對IUT的所有各層協(xié)議進(jìn)行測試，二是對IUT某一層協(xié)議進(jìn)行測試，后者稱為嵌入?yún)f(xié)議測試（embeddedTesting)。無論是那種情況,測試總是由低層到高層逐層進(jìn)行，只有低層協(xié)議已測試完之后（或者假定低層協(xié)議已符合標(biāo)準(zhǔn)之后），高一層協(xié)議的測試才能進(jìn)行．假定圖8.9的IUT包括i，j,k三層協(xié)議實(shí)體，那么檢查整個IUT是否有正常聯(lián)接能力的測試案例如例8.8所示（案例中省去了（i-1）ASP，直接引用(i)PDU）。j層的聯(lián)接請求報文cp(j)借助于i層的數(shù)據(jù)報文DATA傳送，K層的聯(lián)接請求報文cp(k)借助j層的數(shù)據(jù)報文DATA傳送，這樣，只有當(dāng)i層聯(lián)接已成功情況下才能進(jìn)行j層聯(lián)接，只有當(dāng)j層聯(lián)接已成功情況下才能進(jìn)行k層聯(lián)接．多層協(xié)議的測試案例比單層協(xié)議案例復(fù)雜得多。前面五種測試方法都可以應(yīng)用于多層協(xié)議的測試。第八章協(xié)議的一致性測試6.多層協(xié)議的測試方法31第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試32第八章協(xié)議的一致性測試?yán)?.8Multi-layerTestCase:1.L!CP(i)2.L?CA(i)*layeriok3.L!DATA[CP(j)]4.L?DATA[CP(j)]*layerjok5.L!DATA[DATA[CP(k)]]6.L?DATA[DATA[CA(k)]]*layerkok7.L?otherwise*layerkerr8.L?otherwise*layerjerr9.L?otherwise*layerIerr

第八章協(xié)議的一致性測試?yán)?.8Multi-layer33第八章協(xié)議的一致性測試7.中繼系統(tǒng)的測試方法上述討論的方法只適用于端系統(tǒng)（endsystem）中IUT的測試，對于中繼系統(tǒng)（relaysystem）的IUT的測試可采用圖8.10和圖8.11所示的方法（RS表示中繼系統(tǒng)）。圖8。10為閉環(huán)測試方法（Loop_backTestMethod）,圖8.11為橫斷測試方法（TransverseTestmethod）和遠(yuǎn)程測試一樣，中斷系統(tǒng)的測試也不需要UT。第八章協(xié)議的一致性測試7.中繼系統(tǒng)的測試方法34第八章協(xié)議的一致性測試LTPC0PCORSSubnet-1Subnet-2LT-1RSLT-2Subnet-1Subnet-2圖8.10閉環(huán)測試法圖8.11橫斷測試法第八章協(xié)議的一致性測試LTRSSubnet-1Subnet35第八章協(xié)議的一致性測試8.3測試描述語言TTCN

TTCN(TreeandtabularcombindNotation)是ISO為描述OSI協(xié)議一致性測試而頒布的一種語言。TTCN有兩種形式：圖形形式（TTCN.GR）和機(jī)器可以處理的形式（TTCN.MP）。TTCN.GR是用表格形式（tabularProformas）定義的，TTCN.MP的語法是用巴科斯范式BNF描述的。(1)TTCN.GR直觀易懂，適合于人工閱讀，適合于屏幕編輯。表格欄中的詞為TTCN中的關(guān)鍵詞，它描述表格欄目內(nèi)包含信息的類型。(2)TTCN.MP有嚴(yán)格的語法，適合于機(jī)器處理。TTCN.GR中的關(guān)鍵詞在TTCN.MP中全部冠以$符號，這些關(guān)鍵詞分為三類：(1)第一類關(guān)鍵詞定義一個完整的表格的起點(diǎn)和終點(diǎn)，形式為$BEGIN_KEYWORD………$END_KEYWORD(2)第二類關(guān)鍵詞定義表個中一行的起點(diǎn)和終點(diǎn)，形式為$BEGKEYWORD………$END_KEYWORD(3)第三類關(guān)鍵詞定義一個欄目或欄目中的一個字段，形式為$KEYWORD………第八章協(xié)議的一致性測試8.3測試描述語言TTCN36第八章協(xié)議的一致性測試?yán)?.9為Testcase的表格形式和BNF描述。在表格形式中，關(guān)鍵詞“TestCaseDynamicbehavior”說明表格類型為TestCase，在BNF描述中，TestCase是用$Begin_TestCase………$End_TestCase來表示的/在表格形式中，“refernce”，“Identifeier”等都表示一個字段，“BehaviourDescription”,“Label”等表示一個欄目，在BNF中，他們都屬于第三類關(guān)鍵詞。BNF描述增加表格行的定義，$Behaviour………$End_Behaiour對應(yīng)于表格中的一行，它由多個相關(guān)欄目組成。例8.10為例8.9的一個實(shí)例（instance），分別用TTCN.GR和TTCN.MP描述一個具體的測試案例。例8.9：TestCaseProforma:第八章協(xié)議的一致性測試?yán)?.9為Testcase的37第八章協(xié)議的一致性測試TestCaseDynamicBehaviourReferenceIdentifierPurposeDefaultBehaviourDescriptionLabelContraintReferenceVerdictCommentsTestCasedescriptioninBNF:TestCase::=$Begin_TestCaseTestCaseRefTestCaseIdTestPurpose[DefaultRef]Behaviourdescription[Extcomments]$End_TestCase…...BehaviourDescription::=$BehaviourDescription{BehaviourLine}+$End_BehaviourDescriptionBehaviourLine::=$BehaviourLineLine[LabelId][Cref][VerdictId][Comment]$End_BehaviourLineLine::=$linestatementline第八章協(xié)議的一致性測試TestCaseDynamic38第八章協(xié)議的一致性測試?yán)?.10：TestCaseInstanceinTTCN.GRform:TestCaseDynamicBehaviorReference:TTCN_EXAMPLE/TREE_EXAMPLE_1Identifier:TREE_EX_1Purpose:toillustratetheuseoftreeDefault:BehaviourDescriptionLabelContraitRefernceVerdictcommentsL!CONNECTreqL?CONNECTconfL!DATAreqL?DATAind[X<5]→LOOPL!DISCreqL?DISCindL?DISCindLOOPCR1CC1DTR1DTI1DSR1DSCI1DSCI1passinconcfailRequest..confimSenddataRev.daarepeat第八章協(xié)議的一致性測試?yán)?.10：TestCaseIn39第八章協(xié)議的一致性測試TestCaseInstanceinTTCN.MPfor.$Begin_TestCase$TestCaseRefTTCN_EXAMPLE/TREE_EXAMPLE_1$TestCaseIdTREE_EX_1$TestPurposetoillustratetheuseoftree$BehaviourDescription$BehaviourLine$Line[1]L!CONNECTreq$crefCR1$commentcontextrequest$End_BehaviourLine$BehaviourLine$Line[2]L?CONNECTconf$CerfCC1$commentconnectconfirm$End_BehaviorLine$BehaviourLine$Line[3]L!DATAreq$Labelloop$CrefDTR1$commentsenddata$EndBehaviourLine$BehavioutLine$Line[5][X<5]→loop$commentrepeatsendingdatauntilx=5$End_BehaviourLine$BehaviourLine$Line[5]L!DISCreq$CrefDSCR1$Verdictspass$commentdisconnectrequest$End_Behaviourline$BehaviourLine$Line[4]l?DISCind$CrefDSCI1$Verdictinconc$End_BehaviourLine$BehaviourLine$Line[3]L?dISCind$CrefDSCI1$Verdictfail$End_BehaviourLine$End_BehaviourDescription$End_TestCase第八章協(xié)議的一致性測試TestCaseInstance40第八章協(xié)議的一致性測試一個測試套具的TTCN的描述包含四個部分：套具概況（suiteoverview）、說明部分（declarationpart）限制部分（contraintpart）和動態(tài)部分（dynamicpart）.下面分別討論各個部分。1.測試套具概況測試套具概況提供足夠信息以便使測試套據(jù)的使用者更好的測試套具，方便地使用測試套具。這些信息包括：測試套具名稱；測試套具所參照的協(xié)議標(biāo)準(zhǔn)；測試套具所參照的PICS和PIXIT;說明PICS和PIXIT的各條款映射到測試套具的哪些部分；說明測試套具適用于哪些測試方法；說明測試案例（測試序列）的產(chǎn)生方法；列出testcase、teststep以及各變量、參數(shù)等符號的索引。第八章協(xié)議的一致性測試一個測試套具的TTCN41第八章協(xié)議的一致性測試2說明部分限制部分和動態(tài)部分要訪問的所有符號都必須在說明部分給出定義和描述。這些符號包括：用戶定義的類型和操作；測試套具的參數(shù)、變量和常量；PCO的定義；定時時鐘的說明；縮寫符號定義、ASP各參數(shù)定義、ASP參數(shù)組合說明；PDU類型定義、PDU字段（域）定義、PDU字段組合說明。例8.11為ISO傳輸層協(xié)議測試套具中PCO定義，它的PCO實(shí)際是TSAP和NSAP,TSAP是UT和IUT的接口，NSAP是LT和IUT的接口。例8.12為ISO傳輸層協(xié)議定義中的CONreq服務(wù)原語的定義。CONreq的名稱、類型和三個參數(shù)的名稱和類型都在定義中說明，CONreq的類型為TSAP(TSAP已在例8.11定義)，而CONreq的三個參數(shù)的類型CDA.CGA,QOS在說明部分給出（本章未給出定義）第八章協(xié)議的一致性測試2說明部分42第八章協(xié)議的一致性測試?yán)?.11：PCOtypeinTTCN.GRform:PCOTypeDescriptionNameTypeRoleCommentsLNSAPLTNSAPasLTUTSAPUTTSAPasUTPCOtypeinTTCN.GRform:$Begin_PCO$PCOdcl$PCOid$PCOroleLT$End_PCOdcl$PCOdcl$PCOidU$PCOtypeidTSAP$PCOropeUT$End_PCOdcl%End_PCO第八章協(xié)議的一致性測試?yán)?.11：PCOtypein43第八章協(xié)議的一致性測試?yán)?.12：ASPtypeinTTCNform:ASPTypeinTTCNformASPName:CONreqPCOType:TSAPcommentsServiceParameterInformationParameterNameCda(CalledAddress)Cga(CallingAdress)QoS(QualityofService)TypeCDACGAQOSCommentsAddressofLTAdderssofUTClass0isusedASPtypeinTTCN.MPform:$Begin_ASPdcl$ASPidCONreq$PCOtypeidTSAP$SPI{T_CONNECTrequest}$ASP_PARdcl$ASP_PARtypeCDA$commentAddressofLT$End_ASP_PARdcl$ASP_PARdcl$ASP_PARidCga(CallingAddress)$ASP_PARtypeCGA$commentAddressofUT$End_ASP_PARdcl$ASP_PARdcl$ASP_PARidQoS(ServiceofQuaLity)$ASP_parTypeQOS$commentClass0isused$End_ASP_PARdcl$End_ASPdcl第八章協(xié)議的一致性測試?yán)?.12：ASPtypein44第八章協(xié)議的一致性測試3.限制部分所謂限制是指對ASP的參數(shù)和PDU字段的值進(jìn)行的限制，測試數(shù)據(jù)通過限制定義來實(shí)現(xiàn)。對發(fā)送和接受來說，限制的意義不同，當(dāng)UT或IUT發(fā)送ASP或PDU時，“限制”的含義是：ASP參數(shù)值和PDU字段等于限制值；當(dāng)UT或LT從IUT接收ASP或PDU時，“限制”的含義是：所接收的ASP參數(shù)或PDU字段值必須符合限制值。限制用兩種方法表示：第一種方法是利用說明部分定義的參數(shù)和常數(shù)，第二種方法是說明部分定義的變量作為參數(shù)傳遞給限制定義。除此之外，限制定義還使用三個特殊符號，以說明特殊限制條件：“—“表示省略ASP參數(shù)或PDU字段；“？”表示接收時，該參數(shù)或字段可以為任意值，但類型必須相同；“*”表示“—”和“？”中任意一種情況。第八章協(xié)議的一致性測試3.限制部分45第八章協(xié)議的一致性測試?yán)?.13為ISO傳輸層協(xié)議的聯(lián)接請求報文的一個限制（它對應(yīng)于一個測試數(shù)據(jù)），PDU的字段域的限制直接用數(shù)值表示。例8.14為同一個PDU的另外一個限制，字段Source和Destination用說明部分定義的常數(shù)TS_PARI和TS_PAR2表示，而字段T_class通過參數(shù)class表示，任意變量之值可以通過class參數(shù)作為字段T_class限制值。第八章協(xié)議的一致性測試?yán)?.13為ISO傳輸層協(xié)議的聯(lián)接請46第八章協(xié)議的一致性測試?yán)?.13：PDUCommentsinTTCN.GRform”PDUContraintDeclarationPDUName:TCONNCT_ContraintName:TCON_1FieldNameValueSource‘000’BDestinationT_ClassUserdata?0?第八章協(xié)議的一致性測試?yán)?.13：PDUComments47第八章協(xié)議的一致性測試?yán)?.14：PDUContrantsinTTCN.GRformPDUContrantDeclarationPDUName:T_CONNECT1ContraintName;TCON_1(CLASS:INTEGER)FieldNameValueSourceDestinationT_ClassUserdataTS_PAR1TS_PAR2Class?第八章協(xié)議的一致性測試?yán)?.14：PDUContrant48第八章協(xié)議的一致性測試4.動態(tài)部分動態(tài)部分是測試套具的主體部分，它由多個測試案例，測試步（teststeps）和缺省步（defaultsteps）組成。測試案例，測試步和缺省步的表格形式和BNF描述是基本相同的，不同的是表格關(guān)鍵詞不同。例8.9為Testcase的表格形式，個個關(guān)鍵詞的含義如下：Testcase表格關(guān)鍵詞；Reference測試案例名稱，第三類關(guān)鍵詞；Identifier測試案例標(biāo)識，第三類關(guān)鍵詞。測試套具的其他部分在引用測試案例時可用Refernce也可以用Identiher;Purpose:說明測試案例的目的，第三類關(guān)鍵詞；Defauit指出本案例所引用的省卻步的名稱或標(biāo)識，第三類關(guān)鍵詞；BehaviourDescription:測試事件的米描述，第二類關(guān)鍵詞；Label:測試事件的標(biāo)號，用于GOTO語句；COontraintsReperence:指明發(fā)送或接收的ASP或PDU的限制的名稱，第三類關(guān)鍵詞；Verdict::測試結(jié)果的裁決（pass,fail,inconc）,第三類關(guān)鍵詞。Inconc表示未包括（即該事件不在協(xié)議規(guī)范所包括范圍在之中）；Comment:注釋。第三類關(guān)鍵詞。第八章協(xié)議的一致性測試4.動態(tài)部分49第八章協(xié)議的一致性測試?yán)?.10為例8.9的一個實(shí)例，該案例旨在檢查IUT是否有基本的聯(lián)接能力和數(shù)據(jù)接收能力。標(biāo)號LOOP為GOTO(→)語句引用，第5行：[x<5]→LOOP表示，當(dāng)變量X之值小于5時，測試轉(zhuǎn)移到LOOP行。一個測試案例可能很長，為了精簡測試案例，我們可以重復(fù)出現(xiàn)的一組測試事件抽取出來定義為測試步或省缺步、并將它們放人測試步庫(teststeplibrary)和省峽庫(defaultLibrary）。例8.15為測試步應(yīng)用例子，例8.16為省缺步應(yīng)用例子?！?”表示attach語句。省缺步和測試步的引用有兩點(diǎn)重要差別：第一，省缺步的應(yīng)用不使用+語句；第二，省缺步相當(dāng)在原測試案例的每一個測試事件上附加一個選擇事件。第八章協(xié)議的一致性測試?yán)?.10為例8.9的一個實(shí)例，該案50第八章協(xié)議的一致性測試?yán)?.15：Teststeps第八章協(xié)議的一致性測試?yán)?.15：Teststeps51第八章協(xié)議的一致性測試?yán)?.16：Defaultsteps第八章協(xié)議的一致性測試?yán)?.16：Defaultstep52第八章協(xié)議的一致性測試8.4測試序列生成方法

測試序列是一集根據(jù)協(xié)議規(guī)范所產(chǎn)生的輸入、輸出事件序列，協(xié)議一致性測試時，測試執(zhí)行系統(tǒng)向IUT施加輸人事件序列，接收校驗(yàn)輸出事件序列。檢查狀態(tài)轉(zhuǎn)換，根據(jù)輸出事件和狀態(tài)的轉(zhuǎn)移，判定IUT的行為是否符合協(xié)議規(guī)范的描述。測試序列說明IUT所應(yīng)該表現(xiàn)的邏輯行為，因此它可以從協(xié)議模型中推導(dǎo)出來（FSM模型，CCS模型等）。目前，大部分協(xié)議測試序列的生成算法基于FSM模型。本章所使用的FSM模型如圖8.12和圖8.13所示。圖8.13的a,b,c等孤表示一次轉(zhuǎn)換a/b(a表示輸入事件，b表示輸出事件)，是圖8.12的孤的簡寫形式。這里，我們假定IUT（即它的FSM模型)有如下四個基本特性：（1）IUT的狀態(tài)數(shù)，所能接收的輸入事件數(shù)，所產(chǎn)生的輸出事件數(shù)都是有限的，確定的。這個特征保證本章所描述的算法都是收斂的。第八章協(xié)議的一致性測試8.4測試序列生成方法53第八章協(xié)議的一致性測試（2）IUT有完整性，即它在每個狀態(tài)下都能接收所有協(xié)議規(guī)范描述的輸入事件。一般情況下。IUT在某個狀態(tài)下只對一部分輸入事件產(chǎn)生響應(yīng)（或產(chǎn)生輸出事件，或改變狀態(tài)，或產(chǎn)生輸出事件的同時改變狀態(tài))。這些輸入事件稱作核心事件（coreevent)，其它輸入事件稱作非核心事件。本章所有FSM圖只畫出核心事件所引起的轉(zhuǎn)換，所描述的算法只關(guān)心核心事件。非核心事件的測試留待測試案例生成時擴(kuò)充(8.1節(jié)討論行為測試時曾提到IUT對不合法行為的響應(yīng)問題，非核心事件是不合法事件的一部分)。（3）對于每個輸入事件，如果IUT產(chǎn)生輸出事件，那么該輸出事件在給定有限時間內(nèi)產(chǎn)生。根據(jù)這個特性，IUT的超時事件是可判定的，它是否產(chǎn)生輸出事件也是可判定的。（4）IUT的每個狀態(tài)是可達(dá)的，它的FSM圖是連通圖，這是本章所有算法能夠執(zhí)行的基本前題。第八章協(xié)議的一致性測試（2）IUT有完整性，即它在每個狀態(tài)54第八章協(xié)議的一致性測試8.4.1測試序列生成的基本算法假定IUT能接收并且執(zhí)行三種特殊的輸入事件：（1）復(fù)位命令(RESET)IUT接收RESET命令之后，無論它處于何種狀態(tài)，都復(fù)位到初始狀態(tài)，不產(chǎn)生輸出事件。（2）置位命令(SET)IUT接收SET(i)命令之后將其狀態(tài)置成狀態(tài)i，不產(chǎn)生輸出事件。（3）取狀態(tài)命令(STATUS)IUT接收STATUS命令之后產(chǎn)生輸出事件，報告它所處狀態(tài)，但不改變狀態(tài)。第八章協(xié)議的一致性測試8.4.1測試序列生成的基本算法55第八章協(xié)議的一致性測試算法8.1：exhausivetestsequence對狀態(tài)i∈Q執(zhí)行1.利用reset命令將IUT置成初始狀態(tài)。2.利用SET(i)命令將IUT置成狀態(tài)i。3.向IUT施加輸入事件j(j∈M(i),M(i)表示狀態(tài)i所有核心事件的集合)，接收并校對IUT的輸出事件是否與協(xié)議規(guī)范所描述的匹配。4.利用STATUS命令檢查IUT是否轉(zhuǎn)換到協(xié)議規(guī)范所描述的狀態(tài)。5.重復(fù)1～4，直到狀態(tài)i的所有核心輸入事件測試完畢。對于圖8.12所示的IUT（狀態(tài)1為初始狀態(tài)，a/1表示輸入為a，輸出為1的轉(zhuǎn)換），按照算法8.1產(chǎn)生的測試序列是：RESET，SET(1),a/1，STATUS；RESET，SET(1),b/1，STATUS；RESET，SET(2),a/0，STATUS；RESET，SET(2),b/1，STATUS；RESET，SET(3),a/0，STATUS；RESET，SET(3),b/1，STATUS。第八章協(xié)議的一致性測試算法8.1：exhausivete56第八章協(xié)議的一致性測試實(shí)際上，上述算法中的RESET和SET命令可以省去，如果我們能找到一條轉(zhuǎn)換序列，使測試能遍歷每次轉(zhuǎn)換至少一次，那么測試效果就會和算法8.l相同。第八章協(xié)議的一致性測試實(shí)際上，上述算法中的RESET和SE57第八章協(xié)議的一致性測試算法8.2：transitiontourwithoutSET設(shè)M(i)為狀態(tài)i的核心事件集合，變量i為IUT當(dāng)前狀態(tài)。1.利用RESET命令將IUT置成初始狀態(tài)，i=初始狀態(tài)。2.向IUT施加任意未被測試事件j(j∈M(i))，接收并校對輸出事件是否與協(xié)議規(guī)范所描述的輸出事件相同，標(biāo)記j已被測試。3.利用STATUS命令檢查IUT是否轉(zhuǎn)換到指定狀態(tài)k,i=k。4.重復(fù)2～3，直至所有轉(zhuǎn)換都被測試一次。對于圖8.12所示IUT，算法8.2產(chǎn)生的測試序列可以是：RESET；a/1，STATUS；b/1，STATUS；b/1，STATUS；b/1，STATUS；a/0，STATUS；a/0，STATUS。算法8.2僅僅顯示縮短測試序列的一種途徑，它的許多地方需要改進(jìn)。第八章協(xié)議的一致性測試算法8.2：transitiont58第八章協(xié)議的一致性測試8.4.2測試序列生成的修正算法算法8.1和8.2要求IUT接收執(zhí)行三個特殊命令：SET，RESET，STATUS，這種給IUT提出的特殊要求使得這兩種算法變得不實(shí)用。下面我們討論能否取消這些命令，如果不能取消，那么用什么代替這些命令。1.RESET命令沒有RESET命令，算法8.1無法執(zhí)行，但是算法8.2可執(zhí)行。RESET命令可以用HOME序列代替，HOME(i)序列是一集輸出、輸出事件序列，它將IUT狀態(tài)的i變成初始狀態(tài)。很顯然，測試進(jìn)行之前，我們必須找到并先測試每個狀態(tài)的HOME序列，這又提出一個新問題。實(shí)際上，絕大部分IUT有RESET功能和CLEAR功能，因此下面的算法都假定IUT可執(zhí)行RESET命令。第八章協(xié)議的一致性測試8.4.2測試序列生成的修正算法59第八章協(xié)議的一致性測試2.SET命令沒有SFT命令，算法8.l不能執(zhí)行，但算法8.2可執(zhí)行。SET命令可以用路徑序列(PathSequence}替代，PS(i)為一集輸人、輸出事件序列，它將IUT的狀態(tài)從初始狀態(tài)變成i。我們無需在測試之前找出并測試IUT的所有PS(這意味著整個IUT已被此時)，而是測試進(jìn)行過程中利用已測試的轉(zhuǎn)換逐步地找到各個狀態(tài)的PS。第八章協(xié)議的一致性測試2.SET命令60第八章協(xié)議的一致性測試3.STATUS命令沒STATUS命令，算法8.1和8.2都無法執(zhí)行(如果沒有這個命令，窮盡性測試退變?yōu)閺?fù)蓋性行為測試。請參見8.l節(jié)的測試級別的討論)。STATUS命令可以用特征序列(CharacterizingSequence)替代，CS(i)為一集從狀態(tài)i開始的輸人，輸出事件序列，CS(i)的行為唯一地標(biāo)識狀態(tài)i（就是說，各個狀態(tài)的CS的行為是不相同的)。測試之前，我們必須找出所有狀態(tài)的CS，但不必預(yù)先測試它。例如，我們要測試狀態(tài)i到j(luò)的轉(zhuǎn)換t，測試序列為SET(i)，t，CS(j)。如果測試不成功，錯誤可能是t，也可能是CS(j)，無論是哪個錯誤，都可認(rèn)為是t的錯誤.下面利用PS和CS修正算法8.1和8.2。第八章協(xié)議的一致性測試3.STATUS命令61第八章協(xié)議的一致性測試算法8.3：exhausivetestsequencewithPSandCS1.利用RESET命令將IUT置成初始狀態(tài)。2.向IUT施加PS(i)將IUT置成狀態(tài)i。3.向IUT施加輸人事件j(j∈M(i)，M(i)為狀態(tài)i的核心事件集合)，接收并核對IUT的輸出事件。4.如果輸入事件j將IUT轉(zhuǎn)變成狀態(tài)k，那么向IUT施加CS(k)，核對CS(k)是否成功執(zhí)行。5.重復(fù)1～4，直至M(i)的所有輸入事件都已測試為止。對于圖8.12所示IUT，我們可以直觀地找到PS(2)=a/1，PS(3)=b/1。按UIO方法(將在8.4.4討論)，我們可以直觀地找到CS(1)=a/1，CS(2)={a/0，a/1}，CS(3)={a/0，a/0}。根據(jù)算法8.3，我們得到測試序列為：REST，a/1，CS(2)={a/0，a/1}；REST，b/1，CS(3)={a/0，a/0}；REST，PS(2)=a/1，a/0，CS(1)=a/1；REST，PS(2)=a/1，b/1，CS(3)={a/0，a/0}；REST，PS(3)=b/1，a/0，CS(2)={a/0，a/1}；REST，PS(3)=b/1，b/1，CS(1)=a/1；第八章協(xié)議的一致性測試算法8.3：exhausivete62第八章協(xié)議的一致性測試算法8.4transitionstourwithCS設(shè)M(i)為狀態(tài)i的核心事件集合，狀態(tài)變量i為IUT當(dāng)前狀態(tài)。1.利用RESET命令將IUT置成初始狀態(tài)，i=初始狀態(tài)。2.如果M(i)的事件都已測試，向IUT輸人事件j(j∈M(i))，如果事件j將IUT變成狀態(tài)k，i=k，算法回到2。如果M(i)的事件未被測試，向IUT施加未被測試事件j(j∈M(i)，接收并校對IUT的輸入事件，標(biāo)記事件j已被測試。3.如果事件j將IUT變成狀態(tài)k，那么向IUT施加CS(k)，核對CS(k)是否正確執(zhí)行，i=TCS(k)。TCS(k)表示IUT執(zhí)行CS(k)之后的最終狀態(tài)。4.重復(fù)2～3,直至所有M(i)的事件都己測試完畢。算法8.4是可執(zhí)行的算法，但是由它產(chǎn)生的測試序列可能不是最短測試序列。對于圖8.1所示的IUT,利用算法8.4所產(chǎn)生的測試序列可能是：RESET；a/1，CS(2)={a/0，a/1}；b/1，CS(3)={a/0，a/0}；b/1，CS(3)={a/0，a/0}；a/1；a/0，CS(1)=a/1；b/1；a/0，CS(2)={a/0，a/1}；b/1；b/1，CS(1)=a/1。第八章協(xié)議的一致性測試算法8.4transitions63第八章協(xié)議的一致性測試8.4.3最短轉(zhuǎn)換游程算法8.2和8.4為轉(zhuǎn)換游程算法，但不是最短轉(zhuǎn)換游程算法。這個問題可以利用圖論中關(guān)于中國鄉(xiāng)村郵路和歐拉游程(EulerTour)的經(jīng)典算法得到圓滿解決。每個結(jié)點(diǎn)的輸入孤(inputedges)和輸出孤(outputedges)的數(shù)目相等的有向連通圖稱作對稱有向圖(如圖8.13)。在對稱有向圖中，存在從某個結(jié)點(diǎn)出發(fā)經(jīng)歷每條孤僅僅一次而回到起始結(jié)點(diǎn)的閉鏈。這種閉鏈稱作歐拉游程。對于非對稱有向圖（如圖8.14），我們可以增添若干冗余弧，使之變成對稱有向圖，怎樣添加最少冗余弧使非對稱有向圖變成對稱有向圖，實(shí)際上就是中國鄉(xiāng)村郵路問題。這樣，最短轉(zhuǎn)換游程可以分兩步求得：第一步將非對稱圖變成對稱有向圖；第二步從對稱有向圖中求出歐拉鏈第八章協(xié)議的一致性測試8.4.3最短轉(zhuǎn)換游程64第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試65第八章協(xié)議的一致性測試算法8.5:symmetricgraphaugmentation設(shè)有向連通圖G的結(jié)點(diǎn)集合為V。對于每個結(jié)點(diǎn)，設(shè)變量c(i)=(thenumberofinputedges)-(thenumberofoutputedges).任選一對結(jié)點(diǎn)i和j，利用Dijsketra算法找到結(jié)點(diǎn)i到就的最短路徑，添加冗余弧，。重復(fù)第二步算法，直至所有。算法8.6：derivingEulerTour設(shè)對稱有向圖G的結(jié)點(diǎn)集合為V，變量i為當(dāng)前結(jié)點(diǎn)，M（i）為i的核心事件集合，結(jié)點(diǎn)為起始結(jié)點(diǎn)，以r為起始點(diǎn)的歐拉游程為ET。將r放入ET中，i=r。從M（i）中任選一條未包括在ET中的事件j，將j放入ET中，如果事件j（輸出?。┲赶蚪Y(jié)點(diǎn)k，將k放入ET中，i=k。重復(fù)第二步，直至IUT的所有弧都已放入ET為止。如果某些弧未包括在ET中，清除ET，重復(fù)算法。對于圖8.14所示的非對稱圖，。如果我們首先選擇結(jié)點(diǎn)1和4，那么要添加冗余弧g=a,i=d,結(jié)點(diǎn)1和4的計數(shù)分別減1和加1。之后，我們選擇結(jié)點(diǎn)2和3，添加j=c,h=a，2和3的計數(shù)值分別減1和加1。增添這四條冗余弧之后，圖8.14就變成圖8.13。圖8.15示出變換過程。如果我們?nèi)〗Y(jié)點(diǎn)3為起始結(jié)點(diǎn)，圖8.13的歐拉游程可以為：第八章協(xié)議的一致性測試算法8.5:symmetricg66第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試67第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試68第八章協(xié)議的一致性測試8．1基本概念計算機(jī)網(wǎng)絡(luò)或通訊系統(tǒng)的測試包括四個方面:(1)一致性測試（conformancetesting）一致性測試旨在檢測所實(shí)現(xiàn)的協(xié)議實(shí)體（或系統(tǒng)）與協(xié)議規(guī)范的符合程度;(2)性能測試（Performcetesting）性能測試旨在檢測協(xié)議實(shí)體或系統(tǒng)的性能指標(biāo)（數(shù)據(jù)傳輸率，聯(lián)接時間，執(zhí)行速度，并發(fā)度，……）;(3)互操作測試（interoperateabilitytesting）互操作測試旨在檢測同一種協(xié)議的不同實(shí)現(xiàn)版本之間，或同一類協(xié)議的不同實(shí)現(xiàn)版本之間互通的能力和互操作能力;(4)堅固性測試（robusunesstesting）。堅固性測試旨在檢測協(xié)議實(shí)體或系統(tǒng)在各種惡劣環(huán)境下運(yùn)行的能力（信道被切斷，通訊結(jié)點(diǎn)掉電，注入干擾報文……）。本章只討論一致性測試問題。第八章協(xié)議的一致性測試8．1基本概念69第八章協(xié)議的一致性測試8.1.1一致性定義在OSI范疇內(nèi)，如果一個實(shí)際系統(tǒng)在它與別的實(shí)際系統(tǒng)通訊中所表現(xiàn)的行為符合OSI協(xié)議規(guī)范的一致性要求，我們就說它呈現(xiàn)了一致性。OSI協(xié)議規(guī)范的一致性要求屬于協(xié)議規(guī)范文本的一部分，它包括:靜態(tài)一致性要求（staticconformancerequirements）和動態(tài)一致性要求（dynamicconformancerequirements）兩個方面。

靜態(tài)一致性：說明協(xié)議實(shí)現(xiàn)者必須實(shí)現(xiàn)的最小子集的內(nèi)容，定義各類協(xié)議或各個子集的內(nèi)容〔即協(xié)議實(shí)現(xiàn)者欲實(shí)現(xiàn)某類協(xié)議所必須包括的內(nèi)容），定義PDU的最大長度，定義各種協(xié)議參數(shù)、變量、定時時鐘的取值范圍等等。

動態(tài)一致性：說明協(xié)議執(zhí)行過程中。協(xié)議在每個狀態(tài)下所允許的行為是什么。例如，發(fā)出“聯(lián)接請求”報文的協(xié)議實(shí)體所期待的回答報文應(yīng)該是“聯(lián)接認(rèn)可”或“聯(lián)接拒絕”或“聯(lián)接釋放”，其它回答報文是不允許的。第八章協(xié)議的一致性測試8.1.1一致性定義70第八章協(xié)議的一致性測試

ISO頒布的一部分ISO協(xié)議已包括一致性要求文本，這些文本稱為協(xié)議實(shí)現(xiàn)一致性說明PICS（ProtocolImplementationConformanceStatements）和協(xié)議實(shí)現(xiàn)測試的附加信息PIXIT（PrococolImplementationeXtraInformationforTesting）。這些要求往往使用表格形式（tabulorproformas）來描述，前者稱作PICSproformas，后者稱作為PIXITproformas。第八章協(xié)議的一致性測試ISO頒布的一部分ISO71第八章協(xié)議的一致性測試8．1．2測試模型協(xié)議一致性測試的基本模型如圖8.1所示。（1）IUT（ImplementationUnderTest）是被測試的協(xié)議實(shí)體系統(tǒng)，（2）UT（UpperTester）高層測試軟件或硬件，（3）LT（LowerTester）是低層測試軟件〔或硬件〕。如果IUT是n層協(xié)議實(shí)體，那么UT屬于（n十1）層，LT屬于n層（LT和IUT為同等層協(xié)議實(shí)體）。UT通過PCO（PointofControlandObservation）和IUT交換（n）ASP（AbstractServicePrimitives），LT通過PCO和IUT交換（n-1）ASP。如果IUT是傳輸層協(xié)議實(shí)體，那么（n）就是TSP（TransportServicePrimitives），（n-1）ASP就是NSP(NetworkServicePrimitives)，上面的PCO就是TSAP，第八章協(xié)議的一致性測試8．1．2測試模型72第八章協(xié)議的一致性測試下面的PCO就是NSAP，圖8.1中，LT和IUT通過(n-1)層服務(wù)交換(n-1)ASP，UT和LT利用(n-1)層提供的另外一條通道交換協(xié)同信息CI(CoordinatedInformation)。為了測試能正常進(jìn)行，UT和LT可能要交換一些協(xié)同信息，解決測試的同步問題和控制問題。測試的主控者可以是UT，也可以是LT。第八章協(xié)議的一致性測試下面的PCO就是NSAP，圖8.1中73第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試74第八章協(xié)議的一致性測試下面的例子說明圖8.1模型的基本工作過程，該例子檢測IUT是否具有正常的聯(lián)接能力（假定UT為測試的主控者）。例8.1：⑴UT向IUT發(fā)聯(lián)接請求服務(wù)原語CONNECT_retuest；⑵UT告訴LT：已啟動聯(lián)接測試；⑶LT從IUT接收聯(lián)接請求報文CONNECTreq；⑷如果CONNECTreq合法，LT向IUT發(fā)接受聯(lián)接請求報文CONNECTaccept；⑸LT告訴UT：正確收到聯(lián)接請求報文，已發(fā)出CONNECTaccept報文；⑹UT從IUT接收聯(lián)接指示服務(wù)原語CONNECT_indication(confirm)，UT分析有關(guān)信息作出IUT是否有正常聯(lián)接能力的判決（verdict）。第八章協(xié)議的一致性測試下面的例子說明圖8.1模型的基本工作75第八章協(xié)議的一致性測試8.1.3測試工作流程協(xié)議一致性測試工作流程如圖8.2所示。協(xié)議規(guī)范（protocolspecification）、服務(wù)規(guī)范（servicespecification）以及根據(jù)兩者制定的協(xié)議一致性說明PICS和協(xié)議測試的附加信息PIXIT都是由標(biāo)準(zhǔn)化組織頒布的。協(xié)議一致性測試者所進(jìn)行的工作分為四步進(jìn)行。(1)第一步是根據(jù)協(xié)議規(guī)范、服務(wù)規(guī)范確定測試目的；(2)第二步是生成并描述測試套具（testsuite）；(3)第三步是按測試套具對IUT進(jìn)行測試（這意味著要建立一個測試執(zhí)行系統(tǒng)）；(4)第四步是根據(jù)測試記錄（testlogging）參照PICS和PIXIT對IUT進(jìn)行評估（assessment），并給出測試報告（testreport）。測試套具的生成（第二步）又包括幾個方面的工作：一是測試序列的生成，二是測試數(shù)據(jù)的生成，三是將測試序列和測試數(shù)據(jù)合起來生成并描述測試套具第八章協(xié)議的一致性測試8.1.3測試工作流程76第八章協(xié)議的一致性測試第八章協(xié)議的一致性測試77第八章協(xié)議的一致性測試IUT的測試序列（testsequence）根據(jù)它的狀態(tài)轉(zhuǎn)換模型FSM（也可以是CCS模型）產(chǎn)生。對于給定測試目的，IUT應(yīng)該執(zhí)行的符合協(xié)議一致性要求的事件序列叫做測試序列。實(shí)際上，測試序列是對IUT進(jìn)行結(jié)構(gòu)測試（structuraltesting）的事件系列。因此，我們在設(shè)計測試序列時，只要考慮IUT的控制結(jié)構(gòu)就可以，無需考慮測試序列中每個事件所攜帶的參數(shù)和數(shù)據(jù)是什么。例如，下面的測試序列的目的是檢查IUT是否有正常聯(lián)接能力的測試序列。第八章協(xié)議的一致性測試IUT的測試序列（tes78第八章協(xié)議的一致性測試?yán)?.2(測試序列)：U!CONreq，L?CP，L!CA，U?CONconf這里，U表示UT，L表示LT，！表示發(fā)送，？表示接收，CONreq為聯(lián)接請求服務(wù)原語，CONconf為聯(lián)接認(rèn)可服務(wù)原語，CP為聯(lián)接請求報文，CA為接受聯(lián)接請求報文。例8.2和例8.1相似。

測試數(shù)據(jù)（testdata）的產(chǎn)生包括一系列工作。首先，我們必須將服務(wù)原語和PDU用確定數(shù)據(jù)結(jié)構(gòu)描述，然后根據(jù)測試目的產(chǎn)生服務(wù)原語和PDU的實(shí)例（instances），這些實(shí)例就是測試數(shù)據(jù)。最后，我們還必須設(shè)計和編程，產(chǎn)生PDU的編碼程序（encoder）和解碼程序（decoder），前者將PDU實(shí)例轉(zhuǎn)變成信道上可傳送的報文，后者將接收的報文轉(zhuǎn)變成PDU。編碼程序和解碼程序由LT調(diào)用。第八章協(xié)議的一致性測試?yán)?.2(測試序列)：79第八章協(xié)議的一致性測試測試套具是用某種測試執(zhí)行系統(tǒng)能夠認(rèn)識的語言描述的.測試套具包括兩大部分，一部分是測試數(shù)據(jù)的描述，另一部分是測試案例（testcases）的描述。對于給定測試目的，UT和LT擬將執(zhí)行的參數(shù)化測試事件的集合（測試事件樹）叫做測試案例。測試序列引導(dǎo)出測試案例，但兩者有較大區(qū)別。對同一個測試序列的事件施加不同的測試數(shù)據(jù)（即測試事件攜帶不同參數(shù)）就產(chǎn)生不同測試案例，因此一個測試序列對應(yīng)多個測試案例。測試案例不同于測試序列的另一個地方在于，它還必須考慮“選擇事件”。所謂“選擇事件”是，當(dāng)UT或LT接收不到IUT的正常響應(yīng)事件時，UT或LT應(yīng)該做什么。例8.3中，事件5和6是UT的選擇事件（otherwise），該事件的具體內(nèi)容由協(xié)議測試者定義。另外，測試案例與測試方法緊密相關(guān)（參見例8.5~8.8）。例8.3為一個非形式化的測試案例，測試目的和例8.1相同。source表示源地址，destination表示目的地址，reason表示拒絕原因。實(shí)際的測試事件要攜帶更多的參數(shù)。第八章協(xié)議的一致性測試測試套具是用某種測試執(zhí)80第八章協(xié)議的一致性測試?yán)?.3第八章協(xié)議的一致性測試?yán)?.381第八章協(xié)議的一致性測試8.1.4測試級別IUT的一致性測試分為四級：(1)基本互聯(lián)測試（basicinterconnectiontest）基本互聯(lián)測試旨在檢查IUT是否具備進(jìn)一步測試的條件，是否有最小的聯(lián)接能力，能否接收和發(fā)送數(shù)據(jù)。(2)能力測試（capabilitytest）能力測試旨在檢測IUT是否符合動態(tài)一致性要求。(3)行為測試（behaviourtest）行為測試旨在測試IUT是否符合動態(tài)一致性要求，它又分為兩級：覆蓋性測試（comprehensivetesting）和窮