协议工程之协议的一致性测试课件

第八章协议的一致性测试8．1基本概念计算机网络或通讯系统的测试包括四个方面:(1)一致性测试（conformancetesting）一致性测试旨在检测所实现的协议实体（或系统）与协议规范的符合程度;(2)性能测试（Performcetesting）性能测试旨在检测协议实体或系统的性能指标（数据传输率，联接时间，执行速度，并发度，……）;(3)互操作测试（interoperateabilitytesting）互操作测试旨在检测同一种协议的不同实现版本之间，或同一类协议的不同实现版本之间互通的能力和互操作能力;(4)坚固性测试（robusunesstesting）。坚固性测试旨在检测协议实体或系统在各种恶劣环境下运行的能力（信道被切断，通讯结点掉电，注入干扰报文……）。本章只讨论一致性测试问题。第八章协议的一致性测试8．1基本概念1第八章协议的一致性测试8.1.1一致性定义在OSI范畴内，如果一个实际系统在它与别的实际系统通讯中所表现的行为符合OSI协议规范的一致性要求，我们就说它呈现了一致性。OSI协议规范的一致性要求属于协议规范文本的一部分，它包括:静态一致性要求（staticconformancerequirements）和动态一致性要求（dynamicconformancerequirements）两个方面。

静态一致性：说明协议实现者必须实现的最小子集的内容，定义各类协议或各个子集的内容〔即协议实现者欲实现某类协议所必须包括的内容），定义PDU的最大长度，定义各种协议参数、变量、定时时钟的取值范围等等。

动态一致性：说明协议执行过程中。协议在每个状态下所允许的行为是什么。例如，发出“联接请求”报文的协议实体所期待的回答报文应该是“联接认可”或“联接拒绝”或“联接释放”，其它回答报文是不允许的。第八章协议的一致性测试8.1.1一致性定义2第八章协议的一致性测试

ISO颁布的一部分ISO协议已包括一致性要求文本，这些文本称为协议实现一致性说明PICS（ProtocolImplementationConformanceStatements）和协议实现测试的附加信息PIXIT（PrococolImplementationeXtraInformationforTesting）。这些要求往往使用表格形式（tabulorproformas）来描述，前者称作PICSproformas，后者称作为PIXITproformas。第八章协议的一致性测试ISO颁布的一部分ISO3第八章协议的一致性测试8．1．2测试模型协议一致性测试的基本模型如图8.1所示。（1）IUT（ImplementationUnderTest）是被测试的协议实体系统，（2）UT（UpperTester）高层测试软件或硬件，（3）LT（LowerTester）是低层测试软件〔或硬件〕。如果IUT是n层协议实体，那么UT属于（n十1）层，LT属于n层（LT和IUT为同等层协议实体）。UT通过PCO（PointofControlandObservation）和IUT交换（n）ASP（AbstractServicePrimitives），LT通过PCO和IUT交换（n-1）ASP。如果IUT是传输层协议实体，那么（n）就是TSP（TransportServicePrimitives），（n-1）ASP就是NSP(NetworkServicePrimitives)，上面的PCO就是TSAP，第八章协议的一致性测试8．1．2测试模型4第八章协议的一致性测试下面的PCO就是NSAP，图8.1中，LT和IUT通过(n-1)层服务交换(n-1)ASP，UT和LT利用(n-1)层提供的另外一条通道交换协同信息CI(CoordinatedInformation)。为了测试能正常进行，UT和LT可能要交换一些协同信息，解决测试的同步问题和控制问题。测试的主控者可以是UT，也可以是LT。第八章协议的一致性测试下面的PCO就是NSAP，图8.1中5第八章协议的一致性测试第八章协议的一致性测试6第八章协议的一致性测试下面的例子说明图8.1模型的基本工作过程，该例子检测IUT是否具有正常的联接能力（假定UT为测试的主控者）。例8.1：⑴UT向IUT发联接请求服务原语CONNECT_retuest；⑵UT告诉LT：已启动联接测试；⑶LT从IUT接收联接请求报文CONNECTreq；⑷如果CONNECTreq合法，LT向IUT发接受联接请求报文CONNECTaccept；⑸LT告诉UT：正确收到联接请求报文，已发出CONNECTaccept报文；⑹UT从IUT接收联接指示服务原语CONNECT_indication(confirm)，UT分析有关信息作出IUT是否有正常联接能力的判决（verdict）。第八章协议的一致性测试下面的例子说明图8.1模型的基本工作7第八章协议的一致性测试8.1.3测试工作流程协议一致性测试工作流程如图8.2所示。协议规范（protocolspecification）、服务规范（servicespecification）以及根据两者制定的协议一致性说明PICS和协议测试的附加信息PIXIT都是由标准化组织颁布的。协议一致性测试者所进行的工作分为四步进行。(1)第一步是根据协议规范、服务规范确定测试目的；(2)第二步是生成并描述测试套具（testsuite）；(3)第三步是按测试套具对IUT进行测试（这意味着要建立一个测试执行系统）；(4)第四步是根据测试记录（testlogging）参照PICS和PIXIT对IUT进行评估（assessment），并给出测试报告（testreport）。测试套具的生成（第二步）又包括几个方面的工作：一是测试序列的生成，二是测试数据的生成，三是将测试序列和测试数据合起来生成并描述测试套具第八章协议的一致性测试8.1.3测试工作流程8第八章协议的一致性测试第八章协议的一致性测试9第八章协议的一致性测试IUT的测试序列（testsequence）根据它的状态转换模型FSM（也可以是CCS模型）产生。对于给定测试目的，IUT应该执行的符合协议一致性要求的事件序列叫做测试序列。实际上，测试序列是对IUT进行结构测试（structuraltesting）的事件系列。因此，我们在设计测试序列时，只要考虑IUT的控制结构就可以，无需考虑测试序列中每个事件所携带的参数和数据是什么。例如，下面的测试序列的目的是检查IUT是否有正常联接能力的测试序列。第八章协议的一致性测试IUT的测试序列（tes10第八章协议的一致性测试例8.2(测试序列)：U!CONreq，L?CP，L!CA，U?CONconf这里，U表示UT，L表示LT，！表示发送，？表示接收，CONreq为联接请求服务原语，CONconf为联接认可服务原语，CP为联接请求报文，CA为接受联接请求报文。例8.2和例8.1相似。

测试数据（testdata）的产生包括一系列工作。首先，我们必须将服务原语和PDU用确定数据结构描述，然后根据测试目的产生服务原语和PDU的实例（instances），这些实例就是测试数据。最后，我们还必须设计和编程，产生PDU的编码程序（encoder）和解码程序（decoder），前者将PDU实例转变成信道上可传送的报文，后者将接收的报文转变成PDU。编码程序和解码程序由LT调用。第八章协议的一致性测试例8.2(测试序列)：11第八章协议的一致性测试测试套具是用某种测试执行系统能够认识的语言描述的.测试套具包括两大部分，一部分是测试数据的描述，另一部分是测试案例（testcases）的描述。对于给定测试目的，UT和LT拟将执行的参数化测试事件的集合（测试事件树）叫做测试案例。测试序列引导出测试案例，但两者有较大区别。对同一个测试序列的事件施加不同的测试数据（即测试事件携带不同参数）就产生不同测试案例，因此一个测试序列对应多个测试案例。测试案例不同于测试序列的另一个地方在于，它还必须考虑“选择事件”。所谓“选择事件”是，当UT或LT接收不到IUT的正常响应事件时，UT或LT应该做什么。例8.3中，事件5和6是UT的选择事件（otherwise），该事件的具体内容由协议测试者定义。另外，测试案例与测试方法紧密相关（参见例8.5~8.8）。例8.3为一个非形式化的测试案例，测试目的和例8.1相同。source表示源地址，destination表示目的地址，reason表示拒绝原因。实际的测试事件要携带更多的参数。第八章协议的一致性测试测试套具是用某种测试执12第八章协议的一致性测试例8.3第八章协议的一致性测试例8.313第八章协议的一致性测试8.1.4测试级别IUT的一致性测试分为四级：(1)基本互联测试（basicinterconnectiontest）基本互联测试旨在检查IUT是否具备进一步测试的条件，是否有最小的联接能力，能否接收和发送数据。(2)能力测试（capabilitytest）能力测试旨在检测IUT是否符合动态一致性要求。(3)行为测试（behaviourtest）行为测试旨在测试IUT是否符合动态一致性要求，它又分为两级：覆盖性测试（comprehensivetesting）和穷尽性测试（exhausivetesting）。覆盖性测试只要求测试序列历经IUT的所有转换至少一次就可以，而穷尽性测试要求检查每个转换的前后状态。(4)一致性分解测试（conformanceresolutiontest）。一致性分解测试要求测试执行系统对一致性要求逐项地给出yes/no的肯定回答（例如，IUT实现了第二类协议吗等等）。测试总是由低级向高级逐级进行。下面的例子是行为测试要包括的一部分内容。第八章协议的一致性测试8.1.4测试级别14第八章协议的一致性测试IUT的行为测试分成B、C、D三大组，每个大组包括许多小组，每个小组的测试目的可能要由多个测试序列来实现。B．IUT对合法行为的响应测试序列以及测试数据根据协议规范是合法的。B1联接建立阶段B1.1注重于向IUT发送什么B1.1.1每个状态下改变测试事件B1.1.2改变定时时钟之值B1.1.3改变PDU编码之值B1.1.4改变单个协议参数值B1.1.5多个参数值的组合改变B1.2注重于从IUT接收什么（类同于B1.1）B1.3注重于与IUT的交互（类同于B1.1）B2数据传输阶段（类同于B1）B3联接释放阶段（类同于B1）第八章协议的一致性测试IUT的行为测试分成B、15第八章协议的一致性测试C．IUT对语法上不合法行为的响应测试序列根据协议规范是合法的，但测试数据是不合法的。C1联接建立阶段C1.1注重于向IUT发送什么C1.1.1每个状态下改变测试事件C1.1.2改变PDU编码之值C1.1.3改变单个协议参数值C1.1.4多个协议参数值的组合改变C1.2注重于请求IUT发送什么C1.2.1单个不合法参数值C1.2.2多个不合法参数值的组合C1.3注重于与IUT的交互（类同于C1.1）C2数据传输阶段（类同于C1）C3联接释放阶段（类同于C1）第八章协议的一致性测试C．IUT对语法上不合法行为的响应16第八章协议的一致性测试D．IUT对不合适事件（inopportuneevents）的响应不合适事件为异常事件，对协议规范来说，它是不合法的。D1联接建立阶段D1.1注重于向IUT发送什么D1.1.1每个状态下改变测试事件D1.1.2改变定时时钟之值D1.1.3改变PDU编码之值D1.1.4改变单个协议参数值D1.1.5多个参数值的组合改变D1.2注重于从IUT接收什么（类同于D1.1）D1.3注重于与IUT的交互（类同于D1.1） D2数据传输阶段（类同于D1）D3联接释放阶段（类同于D1）第八章协议的一致性测试D．IUT对不合适事件（inoppo17第八章协议的一致性测试8.1.5要考虑的问题协议一致性测试不但在理论上而且在工程上还有许多问题需要进一步研究，这包括：·测试覆盖率怎样度量？各级测试包括多少测试就足够了？·怎样选取最小的测试序列去检测最多的协议错误？·如果协议规范本身有错误，不完整，存在二义性，这将给协议一致性测试带来什么问题，怎样处理？·怎样描述测试？测试描述至少有二种途径：用测试案例，用一组程序，用参考协议实体。哪种方法最好？·怎样产生测试数据？·怎样产生测试序列？·UT和LT怎样协同工作？·怎样进行多层协议测试？·怎样评估测试结果？……本章只讨论三个问题：下节讨论测试方法，第三节讨论测试套具的描述语言TTCN,第四节讨论测试序列的生成方法。第八章协议的一致性测试8.1.5要考虑的问题18第八章协议的一致性测试8.2测试方法测试方法不同，产生和描述测试套具的方法也不同，测试执行系统的结构也不同。目前，人们已提出多种测试方法，这些方法的区别表现在下述几个方面：·本地测试还是外地测试？即IUT和测试执行系统的主体部分（LT）是否在同一个机器之中。·单层协议测试还是多层协议测试？IUT包括多层协议实体的测试为多层协议测试．·有无UT？如果有UT,UT的作用是什么？·测试的协同工作怎样实现？·是否在线（on-line）测试？IUT处于正常运行的测试为在线测试。·是否有实际的低层通讯支持？·LT和IUT的接口PCO在何处？第八章协议的一致性测试8.2测试方法19第八章协议的一致性测试1．本地方法（localMethod）图8.3为本地方法示意图。在这种方法中，UT,LT,IUT同处于一台机器中，测试不需要低层通讯系统的支持。IUT和LT的接口设在IUT的底部，UT和IUT的接口设在IUT的项部（即为IUT的服务访问点）。由于UT和LT可以拟合在一个程序中，UT和LT的测试协同过程TCP(TestCoordinateProcedures)容易实现。测试案例用UT执行的服务原语和LT执行的服务原语来描述，此时LT扮演的角色是低层服务提供者。第八章协议的一致性测试1．本地方法（localMeth20第八章协议的一致性测试例8.4:LocalMethod:1.U!CONreq2.L?(n-1)DATAreq[CP]3.L！(n-1)DATAind[CA]4.U?CONconf5.U?otherwise6.L?otherwise第八章协议的一致性测试例8.4:LocalMet21第八章协议的一致性测试2.分布方法（DistributedMethod）图8.4为分布方法示意图。在这种方法中，IUT和UT处于同一个机器中。LT分布在其它机器中。LT和IUT借助于（n-1）层服务交换报文（可以实行在线测试），它们之间的接口PCO从IUT转移到LT中，LT扮演的角色是（n-1）层服务的使用者。UT和LT的测试协同过程TCP隐含在测试案例中，测试同步问题由UT和LT的操作者来实现．适用于本地方法的测试案例必须改写才能用于分布测试，请注意例8.5和例8.4的差别（第二行和第三行）.（n-1）DATAreq表示（n-1）层服务原语，数据发送请求．第八章协议的一致性测试2.分布方法（Distributed22第八章协议的一致性测试例8.5:DistributedMethod:1.U!CONreq2.L?(n-1)DATAind[CP]3.L!(n-1)DATAreq[CA]4.U?CONconf5.U?otherwise6.L?otherwise第八章协议的一致性测试例8.5:Distributed23第八章协议的一致性测试3．协同方法（CoordinatedMethod）图8.5为协同方法示意图．协同方法和分布方法的根本区别在于，协同方法引入测试管理协议TMP(TestManagementProtocol),UT和LT通过交换TM—PDU实行测试协同过程．TM_PDU的交换有两个途径，一是TM_PDU作为（n)ASP的用户数据传送给IUT,IUT将之传送给LT(in-hand方式）；二是TM_PDU直接利用(n-1)层服务传送(out_band方式）．图8.5为in_band方式．第八章协议的一致性测试3．协同方法（Coordinate24第八章协议的一致性测试分布方法的测试案例不能用于协同方法，请注意例8.6和例8.5的差别：例8.6的第一行表示：LT向（n-1)层协议发DATAreq请求,数据是TM_PDU,TM_PDU的内容是：UT向IUT发CONreq请求．第八章协议的一致性测试分布方法的测试案例不能25第八章协议的一致性测试例8.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第八章协议的一致性测试例8.6CoordinatedM26第八章协议的一致性测试4.远程方法（RemoteMethod）图8.6为远程方法示意图。该方法的最大特点是没有UT，因此也不存在UT和LT的协同问题。测试案例完全用(n-1)ASP描述。远程方法适用于被动式协议实体或服务型协议实体的测试．例8.7是检验lUT是否能正常接受联接请求的测试案例，<IUT!CA＞为隐含事件．例8.7RemoteMethod:1.L!(n-1)DATAreq[CP]2.<IUT!CA>3.L?(n-1)DATAind[CA]4.L?otherwise第八章协议的一致性测试4.远程方法（RemoteMet27第八章协议的一致性测试5.渡船方法（FerryMethod)图8.7和图8.8为渡船方法示意图。.它与协同方法的不同之处是，渡船方法将UT从被测系统中移到LT所在系统UT和LT可拟合在一个程序中，因此有本地方法的优点。然而，在被测系统中取代UT的，还必须有一个渡船软件，UT发给IUT的(n)ASP和UT从IUT获取的(n)ASP通过渡船软件进行。例如，UT执行测试事件的U!CONreq的传递过程是：UT通过LT，再通过IUT传递给Ferry(in_band方式），或UT通过(n-1)层服务直接传递给Ferry(out_band方式）．图8.7为in_band方式，图8.8为out_band方式。第八章协议的一致性测试5.渡船方法（FerryMetho28第八章协议的一致性测试渡船方法由我国学者曾华桑提出，受到国际学术界很大的重视[41]．该方法的最大优点是，由于UT和LT处于同一个机器中，测试协同过程像本地方法一样容易实现，被测系统中只要增加简单的渡船软件就可以了。前面四种方法都已纳入ISO/DIS9646协议测试标准中，但渡船方法还未纳入该标中，原因是，有的学者认为渡船方法只是协同方法的一种变种，是协同方法在实现技术上一种改进，它们之间没有根本区别。第八章协议的一致性测试渡船方法由我国学者曾华29第八章协议的一致性测试第八章协议的一致性测试30第八章协议的一致性测试6.多层协议的测试方法IUT包含多层协议实体的测试称为多层协议的测试。多层协议测试分两种情况，一是对IUT的所有各层协议进行测试，二是对IUT某一层协议进行测试，后者称为嵌入协议测试（embeddedTesting)。无论是那种情况,测试总是由低层到高层逐层进行，只有低层协议已测试完之后（或者假定低层协议已符合标准之后），高一层协议的测试才能进行．假定图8.9的IUT包括i，j,k三层协议实体，那么检查整个IUT是否有正常联接能力的测试案例如例8.8所示（案例中省去了（i-1）ASP，直接引用(i)PDU）。j层的联接请求报文cp(j)借助于i层的数据报文DATA传送，K层的联接请求报文cp(k)借助j层的数据报文DATA传送，这样，只有当i层联接已成功情况下才能进行j层联接，只有当j层联接已成功情况下才能进行k层联接．多层协议的测试案例比单层协议案例复杂得多。前面五种测试方法都可以应用于多层协议的测试。第八章协议的一致性测试6.多层协议的测试方法31第八章协议的一致性测试第八章协议的一致性测试32第八章协议的一致性测试例8.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

第八章协议的一致性测试例8.8Multi-layer33第八章协议的一致性测试7.中继系统的测试方法上述讨论的方法只适用于端系统（endsystem）中IUT的测试，对于中继系统（relaysystem）的IUT的测试可采用图8.10和图8.11所示的方法（RS表示中继系统）。图8。10为闭环测试方法（Loop_backTestMethod）,图8.11为横断测试方法（TransverseTestmethod）和远程测试一样，中断系统的测试也不需要UT。第八章协议的一致性测试7.中继系统的测试方法34第八章协议的一致性测试LTPC0PCORSSubnet-1Subnet-2LT-1RSLT-2Subnet-1Subnet-2图8.10闭环测试法图8.11横断测试法第八章协议的一致性测试LTRSSubnet-1Subnet35第八章协议的一致性测试8.3测试描述语言TTCN

TTCN(TreeandtabularcombindNotation)是ISO为描述OSI协议一致性测试而颁布的一种语言。TTCN有两种形式：图形形式（TTCN.GR）和机器可以处理的形式（TTCN.MP）。TTCN.GR是用表格形式（tabularProformas）定义的，TTCN.MP的语法是用巴科斯范式BNF描述的。(1)TTCN.GR直观易懂，适合于人工阅读，适合于屏幕编辑。表格栏中的词为TTCN中的关键词，它描述表格栏目内包含信息的类型。(2)TTCN.MP有严格的语法，适合于机器处理。TTCN.GR中的关键词在TTCN.MP中全部冠以$符号，这些关键词分为三类：(1)第一类关键词定义一个完整的表格的起点和终点，形式为$BEGIN_KEYWORD………$END_KEYWORD(2)第二类关键词定义表个中一行的起点和终点，形式为$BEGKEYWORD………$END_KEYWORD(3)第三类关键词定义一个栏目或栏目中的一个字段，形式为$KEYWORD………第八章协议的一致性测试8.3测试描述语言TTCN36第八章协议的一致性测试例8.9为Testcase的表格形式和BNF描述。在表格形式中，关键词“TestCaseDynamicbehavior”说明表格类型为TestCase，在BNF描述中，TestCase是用$Begin_TestCase………$End_TestCase来表示的/在表格形式中，“refernce”，“Identifeier”等都表示一个字段，“BehaviourDescription”,“Label”等表示一个栏目，在BNF中，他们都属于第三类关键词。BNF描述增加表格行的定义，$Behaviour………$End_Behaiour对应于表格中的一行，它由多个相关栏目组成。例8.10为例8.9的一个实例（instance），分别用TTCN.GR和TTCN.MP描述一个具体的测试案例。例8.9：TestCaseProforma:第八章协议的一致性测试例8.9为Testcase的37第八章协议的一致性测试TestCaseDynamicBehaviourReferenceIdentifierPurposeDefaultBehaviourDescriptionLabelContraintReferenceVerdictCommentsTestCasedescriptioninBNF:TestCase::=$Begin_TestCaseTestCaseRefTestCaseIdTestPurpose[DefaultRef]Behaviourdescription[Extcomments]$End_TestCase…...BehaviourDescription::=$BehaviourDescription{BehaviourLine}+$End_BehaviourDescriptionBehaviourLine::=$BehaviourLineLine[LabelId][Cref][VerdictId][Comment]$End_BehaviourLineLine::=$linestatementline第八章协议的一致性测试TestCaseDynamic38第八章协议的一致性测试例8.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第八章协议的一致性测试例8.10：TestCaseIn39第八章协议的一致性测试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第八章协议的一致性测试TestCaseInstance40第八章协议的一致性测试一个测试套具的TTCN的描述包含四个部分：套具概况（suiteoverview）、说明部分（declarationpart）限制部分（contraintpart）和动态部分（dynamicpart）.下面分别讨论各个部分。1.测试套具概况测试套具概况提供足够信息以便使测试套据的使用者更好的测试套具，方便地使用测试套具。这些信息包括：测试套具名称；测试套具所参照的协议标准；测试套具所参照的PICS和PIXIT;说明PICS和PIXIT的各条款映射到测试套具的哪些部分；说明测试套具适用于哪些测试方法；说明测试案例（测试序列）的产生方法；列出testcase、teststep以及各变量、参数等符号的索引。第八章协议的一致性测试一个测试套具的TTCN41第八章协议的一致性测试2说明部分限制部分和动态部分要访问的所有符号都必须在说明部分给出定义和描述。这些符号包括：用户定义的类型和操作；测试套具的参数、变量和常量；PCO的定义；定时时钟的说明；缩写符号定义、ASP各参数定义、ASP参数组合说明；PDU类型定义、PDU字段（域）定义、PDU字段组合说明。例8.11为ISO传输层协议测试套具中PCO定义，它的PCO实际是TSAP和NSAP,TSAP是UT和IUT的接口，NSAP是LT和IUT的接口。例8.12为ISO传输层协议定义中的CONreq服务原语的定义。CONreq的名称、类型和三个参数的名称和类型都在定义中说明，CONreq的类型为TSAP(TSAP已在例8.11定义)，而CONreq的三个参数的类型CDA.CGA,QOS在说明部分给出（本章未给出定义）第八章协议的一致性测试2说明部分42第八章协议的一致性测试例8.11：PCOtypeinTTCN.GRform:PCOTypeDescriptionNameTypeRoleCommentsLNSAPLTNSAPasLTUTSAPUTTSAPasUTPCOtypeinTTCN.GRform:$Begin_PCO$PCOdcl$PCOid$PCOroleLT$End_PCOdcl$PCOdcl$PCOidU$PCOtypeidTSAP$PCOropeUT$End_PCOdcl%End_PCO第八章协议的一致性测试例8.11：PCOtypein43第八章协议的一致性测试例8.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第八章协议的一致性测试例8.12：ASPtypein44第八章协议的一致性测试3.限制部分所谓限制是指对ASP的参数和PDU字段的值进行的限制，测试数据通过限制定义来实现。对发送和接受来说，限制的意义不同，当UT或IUT发送ASP或PDU时，“限制”的含义是：ASP参数值和PDU字段等于限制值；当UT或LT从IUT接收ASP或PDU时，“限制”的含义是：所接收的ASP参数或PDU字段值必须符合限制值。限制用两种方法表示：第一种方法是利用说明部分定义的参数和常数，第二种方法是说明部分定义的变量作为参数传递给限制定义。除此之外，限制定义还使用三个特殊符号，以说明特殊限制条件：“—“表示省略ASP参数或PDU字段；“？”表示接收时，该参数或字段可以为任意值，但类型必须相同；“*”表示“—”和“？”中任意一种情况。第八章协议的一致性测试3.限制部分45第八章协议的一致性测试例8.13为ISO传输层协议的联接请求报文的一个限制（它对应于一个测试数据），PDU的字段域的限制直接用数值表示。例8.14为同一个PDU的另外一个限制，字段Source和Destination用说明部分定义的常数TS_PARI和TS_PAR2表示，而字段T_class通过参数class表示，任意变量之值可以通过class参数作为字段T_class限制值。第八章协议的一致性测试例8.13为ISO传输层协议的联接请46第八章协议的一致性测试例8.13：PDUCommentsinTTCN.GRform”PDUContraintDeclarationPDUName:TCONNCT_ContraintName:TCON_1FieldNameValueSource‘000’BDestinationT_ClassUserdata?0?第八章协议的一致性测试例8.13：PDUComments47第八章协议的一致性测试例8.14：PDUContrantsinTTCN.GRformPDUContrantDeclarationPDUName:T_CONNECT1ContraintName;TCON_1(CLASS:INTEGER)FieldNameValueSourceDestinationT_ClassUserdataTS_PAR1TS_PAR2Class?第八章协议的一致性测试例8.14：PDUContrant48第八章协议的一致性测试4.动态部分动态部分是测试套具的主体部分，它由多个测试案例，测试步（teststeps）和缺省步（defaultsteps）组成。测试案例，测试步和缺省步的表格形式和BNF描述是基本相同的，不同的是表格关键词不同。例8.9为Testcase的表格形式，个个关键词的含义如下：Testcase表格关键词；Reference测试案例名称，第三类关键词；Identifier测试案例标识，第三类关键词。测试套具的其他部分在引用测试案例时可用Refernce也可以用Identiher;Purpose:说明测试案例的目的，第三类关键词；Defauit指出本案例所引用的省却步的名称或标识，第三类关键词；BehaviourDescription:测试事件的米描述，第二类关键词；Label:测试事件的标号，用于GOTO语句；COontraintsReperence:指明发送或接收的ASP或PDU的限制的名称，第三类关键词；Verdict::测试结果的裁决（pass,fail,inconc）,第三类关键词。Inconc表示未包括（即该事件不在协议规范所包括范围在之中）；Comment:注释。第三类关键词。第八章协议的一致性测试4.动态部分49第八章协议的一致性测试例8.10为例8.9的一个实例，该案例旨在检查IUT是否有基本的联接能力和数据接收能力。标号LOOP为GOTO(→)语句引用，第5行：[x<5]→LOOP表示，当变量X之值小于5时，测试转移到LOOP行。一个测试案例可能很长，为了精简测试案例，我们可以重复出现的一组测试事件抽取出来定义为测试步或省缺步、并将它们放人测试步库(teststeplibrary)和省峡库(defaultLibrary）。例8.15为测试步应用例子，例8.16为省缺步应用例子。“+”表示attach语句。省缺步和测试步的引用有两点重要差别：第一，省缺步的应用不使用+语句；第二，省缺步相当在原测试案例的每一个测试事件上附加一个选择事件。第八章协议的一致性测试例8.10为例8.9的一个实例，该案50第八章协议的一致性测试例8.15：Teststeps第八章协议的一致性测试例8.15：Teststeps51第八章协议的一致性测试例8.16：Defaultsteps第八章协议的一致性测试例8.16：Defaultstep52第八章协议的一致性测试8.4测试序列生成方法

测试序列是一集根据协议规范所产生的输入、输出事件序列，协议一致性测试时，测试执行系统向IUT施加输人事件序列，接收校验输出事件序列。检查状态转换，根据输出事件和状态的转移，判定IUT的行为是否符合协议规范的描述。测试序列说明IUT所应该表现的逻辑行为，因此它可以从协议模型中推导出来（FSM模型，CCS模型等）。目前，大部分协议测试序列的生成算法基于FSM模型。本章所使用的FSM模型如图8.12和图8.13所示。图8.13的a,b,c等孤表示一次转换a/b(a表示输入事件，b表示输出事件)，是图8.12的孤的简写形式。这里，我们假定IUT（即它的FSM模型)有如下四个基本特性：（1）IUT的状态数，所能接收的输入事件数，所产生的输出事件数都是有限的，确定的。这个特征保证本章所描述的算法都是收敛的。第八章协议的一致性测试8.4测试序列生成方法53第八章协议的一致性测试（2）IUT有完整性，即它在每个状态下都能接收所有协议规范描述的输入事件。一般情况下。IUT在某个状态下只对一部分输入事件产生响应（或产生输出事件，或改变状态，或产生输出事件的同时改变状态)。这些输入事件称作核心事件（coreevent)，其它输入事件称作非核心事件。本章所有FSM图只画出核心事件所引起的转换，所描述的算法只关心核心事件。非核心事件的测试留待测试案例生成时扩充(8.1节讨论行为测试时曾提到IUT对不合法行为的响应问题，非核心事件是不合法事件的一部分)。（3）对于每个输入事件，如果IUT产生输出事件，那么该输出事件在给定有限时间内产生。根据这个特性，IUT的超时事件是可判定的，它是否产生输出事件也是可判定的。（4）IUT的每个状态是可达的，它的FSM图是连通图，这是本章所有算法能够执行的基本前题。第八章协议的一致性测试（2）IUT有完整性，即它在每个状态54第八章协议的一致性测试8.4.1测试序列生成的基本算法假定IUT能接收并且执行三种特殊的输入事件：（1）复位命令(RESET)IUT接收RESET命令之后，无论它处于何种状态，都复位到初始状态，不产生输出事件。（2）置位命令(SET)IUT接收SET(i)命令之后将其状态置成状态i，不产生输出事件。（3）取状态命令(STATUS)IUT接收STATUS命令之后产生输出事件，报告它所处状态，但不改变状态。第八章协议的一致性测试8.4.1测试序列生成的基本算法55第八章协议的一致性测试算法8.1：exhausivetestsequence对状态i∈Q执行1.利用reset命令将IUT置成初始状态。2.利用SET(i)命令将IUT置成状态i。3.向IUT施加输入事件j(j∈M(i),M(i)表示状态i所有核心事件的集合)，接收并校对IUT的输出事件是否与协议规范所描述的匹配。4.利用STATUS命令检查IUT是否转换到协议规范所描述的状态。5.重复1～4，直到状态i的所有核心输入事件测试完毕。对于图8.12所示的IUT（状态1为初始状态，a/1表示输入为a，输出为1的转换），按照算法8.1产生的测试序列是：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。第八章协议的一致性测试算法8.1：exhausivete56第八章协议的一致性测试实际上，上述算法中的RESET和SET命令可以省去，如果我们能找到一条转换序列，使测试能遍历每次转换至少一次，那么测试效果就会和算法8.l相同。第八章协议的一致性测试实际上，上述算法中的RESET和SE57第八章协议的一致性测试算法8.2：transitiontourwithoutSET设M(i)为状态i的核心事件集合，变量i为IUT当前状态。1.利用RESET命令将IUT置成初始状态，i=初始状态。2.向IUT施加任意未被测试事件j(j∈M(i))，接收并校对输出事件是否与协议规范所描述的输出事件相同，标记j已被测试。3.利用STATUS命令检查IUT是否转换到指定状态k,i=k。4.重复2～3，直至所有转换都被测试一次。对于图8.12所示IUT，算法8.2产生的测试序列可以是：RESET；a/1，STATUS；b/1，STATUS；b/1，STATUS；b/1，STATUS；a/0，STATUS；a/0，STATUS。算法8.2仅仅显示缩短测试序列的一种途径，它的许多地方需要改进。第八章协议的一致性测试算法8.2：transitiont58第八章协议的一致性测试8.4.2测试序列生成的修正算法算法8.1和8.2要求IUT接收执行三个特殊命令：SET，RESET，STATUS，这种给IUT提出的特殊要求使得这两种算法变得不实用。下面我们讨论能否取消这些命令，如果不能取消，那么用什么代替这些命令。1.RESET命令没有RESET命令，算法8.1无法执行，但是算法8.2可执行。RESET命令可以用HOME序列代替，HOME(i)序列是一集输出、输出事件序列，它将IUT状态的i变成初始状态。很显然，测试进行之前，我们必须找到并先测试每个状态的HOME序列，这又提出一个新问题。实际上，绝大部分IUT有RESET功能和CLEAR功能，因此下面的算法都假定IUT可执行RESET命令。第八章协议的一致性测试8.4.2测试序列生成的修正算法59第八章协议的一致性测试2.SET命令没有SFT命令，算法8.l不能执行，但算法8.2可执行。SET命令可以用路径序列(PathSequence}替代，PS(i)为一集输人、输出事件序列，它将IUT的状态从初始状态变成i。我们无需在测试之前找出并测试IUT的所有PS(这意味着整个IUT已被此时)，而是测试进行过程中利用已测试的转换逐步地找到各个状态的PS。第八章协议的一致性测试2.SET命令60第八章协议的一致性测试3.STATUS命令没STATUS命令，算法8.1和8.2都无法执行(如果没有这个命令，穷尽性测试退变为复盖性行为测试。请参见8.l节的测试级别的讨论)。STATUS命令可以用特征序列(CharacterizingSequence)替代，CS(i)为一集从状态i开始的输人，输出事件序列，CS(i)的行为唯一地标识状态i（就是说，各个状态的CS的行为是不相同的)。测试之前，我们必须找出所有状态的CS，但不必预先测试它。例如，我们要测试状态i到j的转换t，测试序列为SET(i)，t，CS(j)。如果测试不成功，错误可能是t，也可能是CS(j)，无论是哪个错误，都可认为是t的错误.下面利用PS和CS修正算法8.1和8.2。第八章协议的一致性测试3.STATUS命令61第八章协议的一致性测试算法8.3：exhausivetestsequencewithPSandCS1.利用RESET命令将IUT置成初始状态。2.向IUT施加PS(i)将IUT置成状态i。3.向IUT施加输人事件j(j∈M(i)，M(i)为状态i的核心事件集合)，接收并核对IUT的输出事件。4.如果输入事件j将IUT转变成状态k，那么向IUT施加CS(k)，核对CS(k)是否成功执行。5.重复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}。根据算法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；第八章协议的一致性测试算法8.3：exhausivete62第八章协议的一致性测试算法8.4transitionstourwithCS设M(i)为状态i的核心事件集合，状态变量i为IUT当前状态。1.利用RESET命令将IUT置成初始状态，i=初始状态。2.如果M(i)的事件都已测试，向IUT输人事件j(j∈M(i))，如果事件j将IUT变成状态k，i=k，算法回到2。如果M(i)的事件未被测试，向IUT施加未被测试事件j(j∈M(i)，接收并校对IUT的输入事件，标记事件j已被测试。3.如果事件j将IUT变成状态k，那么向IUT施加CS(k)，核对CS(k)是否正确执行，i=TCS(k)。TCS(k)表示IUT执行CS(k)之后的最终状态。4.重复2～3,直至所有M(i)的事件都己测试完毕。算法8.4是可执行的算法，但是由它产生的测试序列可能不是最短测试序列。对于图8.1所示的IUT,利用算法8.4所产生的测试序列可能是：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。第八章协议的一致性测试算法8.4transitions63第八章协议的一致性测试8.4.3最短转换游程算法8.2和8.4为转换游程算法，但不是最短转换游程算法。这个问题可以利用图论中关于中国乡村邮路和欧拉游程(EulerTour)的经典算法得到圆满解决。每个结点的输入孤(inputedges)和输出孤(outputedges)的数目相等的有向连通图称作对称有向图(如图8.13)。在对称有向图中，存在从某个结点出发经历每条孤仅仅一次而回到起始结点的闭链。这种闭链称作欧拉游程。对于非对称有向图（如图8.14），我们可以增添若干冗余弧，使之变成对称有向图，怎样添加最少冗余弧使非对称有向图变成对称有向图，实际上就是中国乡村邮路问题。这样，最短转换游程可以分两步求得：第一步将非对称图变成对称有向图；第二步从对称有向图中求出欧拉链第八章协议的一致性测试8.4.3最短转换游程64第八章协议的一致性测试第八章协议的一致性测试65第八章协议的一致性测试算法8.5:symmetricgraphaugmentation设有向连通图G的结点集合为V。对于每个结点，设变量c(i)=(thenumberofinputedges)-(thenumberofoutputedges).任选一对结点i和j，利用Dijsketra算法找到结点i到就的最短路径，添加冗余弧，。重复第二步算法，直至所有。算法8.6：derivingEulerTour设对称有向图G的结点集合为V，变量i为当前结点，M（i）为i的核心事件集合，结点为起始结点，以r为起始点的欧拉游程为ET。将r放入ET中，i=r。从M（i）中任选一条未包括在ET中的事件j，将j放入ET中，如果事件j（输出弧）指向结点k，将k放入ET中，i=k。重复第二步，直至IUT的所有弧都已放入ET为止。如果某些弧未包括在ET中，清除ET，重复算法。对于图8.14所示的非对称图，。如果我们首先选择结点1和4，那么要添加冗余弧g=a,i=d,结点1和4的计数分别减1和加1。之后，我们选择结点2和3，添加j=c,h=a，2和3的计数值分别减1和加1。增添这四条冗余弧之后，图8.14就变成图8.13。图8.15示出变换过程。如果我们取结点3为起始结点，图8.13的欧拉游程可以为：第八章协议的一致性测试算法8.5:symmetricg66第八章协议的一致性测试第八章协议的一致性测试67第八章协议的一致性测试第八章协议的一致性测试68第八章协议的一致性测试8．1基本概念计算机网络或通讯系统的测试包括四个方面:(1)一致性测试（conformancetesting）一致性测试旨在检测所实现的协议实体（或系统）与协议规范的符合程度;(2)性能测试（Performcetesting）性能测试旨在检测协议实体或系统的性能指标（数据传输率，联接时间，执行速度，并发度，……）;(3)互操作测试（interoperateabilitytesting）互操作测试旨在检测同一种协议的不同实现版本之间，或同一类协议的不同实现版本之间互通的能力和互操作能力;(4)坚固性测试（robusunesstesting）。坚固性测试旨在检测协议实体或系统在各种恶劣环境下运行的能力（信道被切断，通讯结点掉电，注入干扰报文……）。本章只讨论一致性测试问题。第八章协议的一致性测试8．1基本概念69第八章协议的一致性测试8.1.1一致性定义在OSI范畴内，如果一个实际系统在它与别的实际系统通讯中所表现的行为符合OSI协议规范的一致性要求，我们就说它呈现了一致性。OSI协议规范的一致性要求属于协议规范文本的一部分，它包括:静态一致性要求（staticconformancerequirements）和动态一致性要求（dynamicconformancerequirements）两个方面。

静态一致性：说明协议实现者必须实现的最小子集的内容，定义各类协议或各个子集的内容〔即协议实现者欲实现某类协议所必须包括的内容），定义PDU的最大长度，定义各种协议参数、变量、定时时钟的取值范围等等。

动态一致性：说明协议执行过程中。协议在每个状态下所允许的行为是什么。例如，发出“联接请求”报文的协议实体所期待的回答报文应该是“联接认可”或“联接拒绝”或“联接释放”，其它回答报文是不允许的。第八章协议的一致性测试8.1.1一致性定义70第八章协议的一致性测试

ISO颁布的一部分ISO协议已包括一致性要求文本，这些文本称为协议实现一致性说明PICS（ProtocolImplementationConformanceStatements）和协议实现测试的附加信息PIXIT（PrococolImplementationeXtraInformationforTesting）。这些要求往往使用表格形式（tabulorproformas）来描述，前者称作PICSproformas，后者称作为PIXITproformas。第八章协议的一致性测试ISO颁布的一部分ISO71第八章协议的一致性测试8．1．2测试模型协议一致性测试的基本模型如图8.1所示。（1）IUT（ImplementationUnderTest）是被测试的协议实体系统，（2）UT（UpperTester）高层测试软件或硬件，（3）LT（LowerTester）是低层测试软件〔或硬件〕。如果IUT是n层协议实体，那么UT属于（n十1）层，LT属于n层（LT和IUT为同等层协议实体）。UT通过PCO（PointofControlandObservation）和IUT交换（n）ASP（AbstractServicePrimitives），LT通过PCO和IUT交换（n-1）ASP。如果IUT是传输层协议实体，那么（n）就是TSP（TransportServicePrimitives），（n-1）ASP就是NSP(NetworkServicePrimitives)，上面的PCO就是TSAP，第八章协议的一致性测试8．1．2测试模型72第八章协议的一致性测试下面的PCO就是NSAP，图8.1中，LT和IUT通过(n-1)层服务交换(n-1)ASP，UT和LT利用(n-1)层提供的另外一条通道交换协同信息CI(CoordinatedInformation)。为了测试能正常进行，UT和LT可能要交换一些协同信息，解决测试的同步问题和控制问题。测试的主控者可以是UT，也可以是LT。第八章协议的一致性测试下面的PCO就是NSAP，图8.1中73第八章协议的一致性测试第八章协议的一致性测试74第八章协议的一致性测试下面的例子说明图8.1模型的基本工作过程，该例子检测IUT是否具有正常的联接能力（假定UT为测试的主控者）。例8.1：⑴UT向IUT发联接请求服务原语CONNECT_retuest；⑵UT告诉LT：已启动联接测试；⑶LT从IUT接收联接请求报文CONNECTreq；⑷如果CONNECTreq合法，LT向IUT发接受联接请求报文CONNECTaccept；⑸LT告诉UT：正确收到联接请求报文，已发出CONNECTaccept报文；⑹UT从IUT接收联接指示服务原语CONNECT_indication(confirm)，UT分析有关信息作出IUT是否有正常联接能力的判决（verdict）。第八章协议的一致性测试下面的例子说明图8.1模型的基本工作75第八章协议的一致性测试8.1.3测试工作流程协议一致性测试工作流程如图8.2所示。协议规范（protocolspecification）、服务规范（servicespecification）以及根据两者制定的协议一致性说明PICS和协议测试的附加信息PIXIT都是由标准化组织颁布的。协议一致性测试者所进行的工作分为四步进行。(1)第一步是根据协议规范、服务规范确定测试目的；(2)第二步是生成并描述测试套具（testsuite）；(3)第三步是按测试套具对IUT进行测试（这意味着要建立一个测试执行系统）；(4)第四步是根据测试记录（testlogging）参照PICS和PIXIT对IUT进行评估（assessment），并给出测试报告（testreport）。测试套具的生成（第二步）又包括几个方面的工作：一是测试序列的生成，二是测试数据的生成，三是将测试序列和测试数据合起来生成并描述测试套具第八章协议的一致性测试8.1.3测试工作流程76第八章协议的一致性测试第八章协议的一致性测试77第八章协议的一致性测试IUT的测试序列（testsequence）根据它的状态转换模型FSM（也可以是CCS模型）产生。对于给定测试目的，IUT应该执行的符合协议一致性要求的事件序列叫做测试序列。实际上，测试序列是对IUT进行结构测试（structuraltesting）的事件系列。因此，我们在设计测试序列时，只要考虑IUT的控制结构就可以，无需考虑测试序列中每个事件所携带的参数和数据是什么。例如，下面的测试序列的目的是检查IUT是否有正常联接能力的测试序列。第八章协议的一致性测试IUT的测试序列（tes78第八章协议的一致性测试例8.2(测试序列)：U!CONreq，L?CP，L!CA，U?CONconf这里，U表示UT，L表示LT，！表示发送，？表示接收，CONreq为联接请求服务原语，CONconf为联接认可服务原语，CP为联接请求报文，CA为接受联接请求报文。例8.2和例8.1相似。

测试数据（testdata）的产生包括一系列工作。首先，我们必须将服务原语和PDU用确定数据结构描述，然后根据测试目的产生服务原语和PDU的实例（instances），这些实例就是测试数据。最后，我们还必须设计和编程，产生PDU的编码程序（encoder）和解码程序（decoder），前者将PDU实例转变成信道上可传送的报文，后者将接收的报文转变成PDU。编码程序和解码程序由LT调用。第八章协议的一致性测试例8.2(测试序列)：79第八章协议的一致性测试测试套具是用某种测试执行系统能够认识的语言描述的.测试套具包括两大部分，一部分是测试数据的描述，另一部分是测试案例（testcases）的描述。对于给定测试目的，UT和LT拟将执行的参数化测试事件的集合（测试事件树）叫做测试案例。测试序列引导出测试案例，但两者有较大区别。对同一个测试序列的事件施加不同的测试数据（即测试事件携带不同参数）就产生不同测试案例，因此一个测试序列对应多个测试案例。测试案例不同于测试序列的另一个地方在于，它还必须考虑“选择事件”。所谓“选择事件”是，当UT或LT接收不到IUT的正常响应事件时，UT或LT应该做什么。例8.3中，事件5和6是UT的选择事件（otherwise），该事件的具体内容由协议测试者定义。另外，测试案例与测试方法紧密相关（参见例8.5~8.8）。例8.3为一个非形式化的测试案例，测试目的和例8.1相同。source表示源地址，destination表示目的地址，reason表示拒绝原因。实际的测试事件要携带更多的参数。第八章协议的一致性测试测试套具是用某种测试执80第八章协议的一致性测试例8.3第八章协议的一致性测试例8.381第八章协议的一致性测试8.1.4测试级别IUT的一致性测试分为四级：(1)基本互联测试（basicinterconnectiontest）基本互联测试旨在检查IUT是否具备进一步测试的条件，是否有最小的联接能力，能否接收和发送数据。(2)能力测试（capabilitytest）能力测试旨在检测IUT是否符合动态一致性要求。(3)行为测试（behaviourtest）行为测试旨在测试IUT是否符合动态一致性要求，它又分为两级：覆盖性测试（comprehensivetesting）和穷