ATF自动化工具使用手顺.doc

文档名称 STEP BY STEP 5小时精通ATF文档密级Step by step 5小时精通ATFdd 拟制:胡玉刚日期：2004-04-13审核:日期：yyyy-mm-dd审核:日期：yyyy-mm-dd批准:日期：yyyy-mm-dd目录第1章绪论41.1绪论4第2章ATF介绍52.1什么是ATF52.2关于自动化测试脚本62.2.1自动测试脚本的组成62.2.2测试脚本、逻辑拓扑和测试床之间的联系62.2.3测试脚本、逻辑拓扑和测试床的对应关系72.3ATF的运行环境82.4选择文件列表9第3章自动测试脚本的编写实例113.1自动测试脚本的的编写步骤113.2举一个实例113.3测试用例分析113.3.1设备连接113.3.2测试步骤和预期结果113.4测试床的编写123.4.1打开或生成一个*.tbd文件123.4.2测试床文件正文的编写格式133.5逻辑拓扑的编写143.5.1打开或生成一个*.topo文件143.5.2逻辑拓扑文件的编写格式153.6测试脚本的编写153.6.1打开或生成一个*.tcl文件153.6.2测试脚本头部的编写163.6.3测试脚本的配置、检查动作部分的编写。173.6.4脚本中的配置过程193.6.5脚本中的检查过程213.7测试脚本的编写注意事项22第4章自动化测试脚本的运行234.1测试脚本的运行准备234.1.1指定测试床、测试日志的路径234.1.2启动控制台244.2测试脚本的运行254.2.1脚本执行过程中RTA控制台的显示264.2.2RTA控制台的Debug信息显示274.2.3测试脚本的执行过程及结果输出显示27第5章更进一步295.1一系列脚本的编写295.2测试集脚本的生成示例305.3查看Log文档31第6章结束语34第7章附录357.1相关的学习资料357.2相关的文件35第1章 绪论1.1 绪论由于ATF牵涉的概念比较复杂，规则繁多，使用灵活，对于刚刚接触的初学者来说感到学习困难，看了很多教材还是感觉一时很难上手。本书的目的就是让刚刚接触到ATF的初学者能够快速的使用ATF对TCL进行自动测试脚本编写、调试。本书具有以下几个特点：1 不要求读者具有专门的计算机专业知识的基础，只要学习过一些简单的tcl语言，如果没有学过tcl语言也没关系，你只要用上3个小时左右的时间快速翻阅一下TCL培训教程(全)的前8章就行了。2 本书只在第二章对ATF做一下简单扼要的介绍，然后便开门见山的进行实战操作，如果你非要弄清除ATF是怎么回事，建议你跟着学完后面的章节，等做完一个完整的自动测试脚本之后再去研究它。在本书的末尾会给你推荐几本深入的教材，帮你更进一步的了解ATF。3 在第三章之后，便是实际的操作了，你需要step-by-step跟着做下去，待一个完整的脚本写完，相信你对ATF有一个感性的认识！由于作者水平有限，经验不多，刚刚接触ATF也只是三周时间_，只是为了让读者快速学会ATF，挤出时间匆匆写成本教材，肯定会有不少缺点或错误，祈得到专家和读者的指正，在适当的时间再作修订和补充。第2章 ATF介绍2.1 什么是ATFATF是Auto Test Framework的英文缩写，直译为自动测试框架。是一种用计算机代替手工敲击命令（发向交换机、路由器等设备）、并由计算机做出结果处理和判断（pass或failed）的方法。ATF的运行依赖于北研测试平台VTP2003新版本实际上是一个实现自动化的框架，它的实现方式是在ATF下编写自动化测试脚本这就是我们学习的重点。而自动化测试脚本又可分为测试床、逻辑拓扑、测试脚本三部分。用图2.1可以对ATF有一个直观的概括：图2.1 ATF的层次结构2.2 关于自动化测试脚本自动测试脚本的编写规范不是一种新的语言，而是在TCL脚本语言的基础上，扩展了一些过程和类来实现Action Word。2.2.1 自动测试脚本的组成自动化测试脚本主要有三部分组成：测试床、逻辑拓扑、测试脚本。测试床(TestBed)是用来描述一套独立的测试环境中所有设备的特性、访问方法及他们之间的连接信息的。逻辑拓扑是测试用例运行所必须具备的拓扑环境，其中的设备和接口采用的虚拟的名称，这样可以使测试用例脚本的编写与实际物理环境相独立，从而增加了脚本的可移植性和可读性。测试脚本是数据通信产品的自动测试的过程实现，主要执行对设备进行发送配置命令、结果检查动作。这是ATF的重点部分。 2.2.2 测试脚本、逻辑拓扑和测试床之间的联系自动化测试脚本的三个部分之间是有机的结合在一起的。之所以将测试床和逻辑拓扑从测试脚本中移至出去，其主要原因就是为了使脚本更加灵活。对于几十或上百个脚本文件来说，当物理环境变化时，只需对他们对应的一个或几个测试床和逻辑拓扑文件做一些相应的更改，就可以使脚本进行很方便的移植。他们之间的关系如下图2.2：测试脚本测试床逻辑拓扑（图） 脚本名称 IP_FUN_3.2.2.1_1_1_1.tcl 3 GLOBAL FUNCTION huyugang 2004.03.19 适用于VRP3.1 1.1.1 测试脚本的简单描述 IP_3.2_1.topo #空白部分 #第1步开始 文字说明部分 #配置RTA Config interface ethernet 0/0 ip address 129.1.1.111 255.255.255.0 #检查 description 检查部分的文字说明 type command expect forwarding args display interface #第2步开始 文字说明部分 #配置 #检查#第步开始在空白的部分自动完成映射在头部的说明图2.2 测试脚本、测试床、逻辑拓扑之间联系细节 说明1测试脚本文件 扩展名.tcl2逻辑拓扑文件 扩展名.topo3测试床文件 扩展名.tbd4右边方框中的内容为测 试脚本的主要内容从图2.2中可以看出，在测试脚本中，只需在文件头部中指明用的是哪个逻辑拓扑文件即可。测试床和逻辑拓扑的映射关系是自动建立的，对于初学者来说，最好不要向里面添加手工映射关系。2.2.3 测试脚本、逻辑拓扑和测试床的对应关系在图2.2中主要将测试脚本的内容给展示出来，主要是由于测试脚本的内容相对丰富一些，可以在里面看出一些测试脚本、测试床、逻辑拓扑之间关系。对于测试床、逻辑拓扑文件内容比较简单，主要是用于描述一些物理设备与逻辑设备的之间的关系。并且一个测试床可以对应多个逻辑拓扑，而一个逻辑拓扑可以对应多个测试脚本，如下图2.3所示。测试脚本文件11测试床文件逻辑拓扑（图1）图2.3 测试脚本、测试床、逻辑拓扑之间对应关系测试脚本文件12测试脚本文件1n测试脚本文件21逻辑拓扑（图2）测试脚本文件22测试脚本文件2n2.3 ATF的运行环境打开VTP测试平台后，在全局TCL窗口中进行测试脚本、测试床和逻辑拓扑的编写（图2.4）。在图2.4蓝色圈中快捷键位置选择全局TCL窗口后出现图2.5的界面图2.4准备打开全局TCL窗口图2.5全局TCL窗口2.4 选择文件列表如上图2.5所示，要打开脚本文件不在文件列表区的目录中，需要在左面文件列表区来选择脚本文件，而如果脚本文件没有在文件列表区，则需要设置要打开的脚本所在的目录。如下图2.6所示，选择菜单选项Option，点击选项“Setting Case Dir”，将弹出“Setting test case directory”对话框，见图2.7。 图2.6准备设置文件列表目录图2.7设置文件列表目录选中测试脚本所在的目录即可。这样就可以进行对测试脚本的编辑操作了。第3章 自动测试脚本的编写实例3.1 自动测试脚本的的编写步骤对测试用例进行分析编写测试床编写逻辑拓扑图编写测试脚本3.2 举一个实例在这里我们以ICMP协议的请求和回显应答报文为例，来进行一个实际的自动测试脚本的编写。测试任务（即测试用例）我们用图例来对任务进行描述；图3.1测试用例描述3.3 测试用例分析根据测试用例内容可以归纳为以下三个动作：3.3.1 设备连接设备连接：PC机（HOST）用一根网线与交换机或路由器（DUT）的端口PORT连接此动作应该在测试床与逻辑拓扑中进行，将物理连接通过测试床和逻辑拓扑的映射关系描述成逻辑连接。即编写测试床和逻辑拓扑，由于其映射关系是完全封装好的，因此我们按照特定的规则填写即可。3.3.2 测试步骤和预期结果测试步骤：在PC（HOST）机上构造一个正确的ICMP请求报文，发送给DUT预期结构：DUT返回一个回显报文这两个动作就在测试脚本中进行，第2步即配置：通过脚本配置向设备（PC或DUT）发送命令（发送报文）。第3步即检查：通过脚本检查设备（DUT）是否响应报文。3.4 测试床的编写我们以这个例子来演示一下测试床的编写，根据第2章所述测试床一般对应几十或上百个的测试脚本，一般情况在写好一个测试床后以后就可以通用。测试床文件的扩展名为.tbd，为ACSII文本文件，也可以在记事本中编写。在ATF环境中的全局TCL窗口中编写如下图3.2图3.2测试床的编写环境及格式3.4.1 打开或生成一个*.tbd文件按上图所示，第1步点击VTP中的”TK”按钮，打开全局TCL窗口，第2步打开或新生成一个*.tbd文件，然后在测试床编辑区按上图所示的格式进行编写测试床。3.4.2 测试床文件正文的编写格式注释部分测试床文件中的注释部分用“；”分号表示（这一点与逻辑拓扑和测试脚本不同，后者的注释均是以“”开头）。为了测试床的目的更清除明了，我将测试用例的图描述在文件的顶端，其实测试床可能要对应多个测试图，因此一般在文件顶端写一些文字说明就可以了，或什么都不写。设备描述部分设备描述部分可按照一定的格式进行填写，在“ ”括号中填写设备名RTA，以及PC1，若有其他设备如RTB等一样填写。在设备名后一行中填写设备类型 type = ，路由器或交换机等设备类型可以在参考书中查到，如例子中用的路由器类型为“8011” 端口号 interface = ，即物理连接设备的端口，此例中用的端口RTA为“Ethernet0”，PC为自己的网卡序号，例子中的序号为“0000”（对于有多个网卡的序号有可能为0001等，可以在脚本中有专门的命令得到，在稍后脚本编写中在进行介绍。）访问名称 access-name = ，即设备的访问名称，该项是针对路由器或交换机可起一个好识别的名称。访问连接 access-line = ，即向设备传送命令的连线，设备上的接口，此例用设备的“console”口。访问通道 access-channel = ，即连接设备的终端的接口，此例用pc的com1口和路由器连接“com1”对于测试床可能还对应其他逻辑拓扑，要用到其他设备，但在此例中我们就用到RTA和PC1，因此可以将其他设备前加“！”注释掉，暂时不用，相对于注释号。设备连接部分此处用来描述上述设备的连接方式，开始于标签“Link”，此例用到的连接为“link1, RTA Ethernet0 129.1.1.100/24, PC1 0000 129.1.1.111/24”分别为“连接标号，设备1 端口 IP地址/掩码长度，设备2 端口 IP地址/掩码长度”若不用的连接可用“；”暂时注释掉。 这样一个完整的测试床就编写完毕了。3.5 逻辑拓扑的编写以此例子来演示一下测试床的编写，同样，一个逻辑拓扑可能会对应多个测试脚本，一般情况在写好一个逻辑拓扑后以后就可以通用。逻辑拓扑文件的扩展名为.topo，为ACSII文本文件，也可以在记事本中编写。在ATF环境中的全局TCL窗口中编写如下图3.3图3.3逻辑拓扑的编写环境及格式3.5.1 打开或生成一个*.topo文件按上图所示，第1步点击VTP中的”TK”按钮，打开全局TCL窗口，第2步打开或新生成一个*.topo文件，然后在逻辑拓扑编辑区按上图所示的格式进行编写逻辑拓扑。3.5.2 逻辑拓扑文件的编写格式逻辑拓扑文件中的注释部分用“#”分号表示。如果你已看过其他一些关于ATF的书籍，可能会发现本例所示逻辑拓扑的内容与测试脚本中的头文件中的标签差不多，其实本来逻辑拓扑是可以在脚本中一起完成的，但为了有更好的灵活性，因而将它给移植出来了。它的书写也很简单，在标签“ name”和“ graph”中均是写一些文字说明，为了标识及增加可读性。在“ description”中书写的内容才是和测试床建立映射的部分，即将物理连接映射成逻辑连接，前两行“RTA VrpDevice HOST localhost”是设备的类型描述，若是用其他一些设备可以查阅一下北研数通产品自动测试脚本编写规范中的附录3设备标准名称表。对于最后一行“link1, RTA PORT1, HOST toRTA”即是与测试床的物理连接建立的映射，可以看出“设备名称 端口名称”有所变化，这里所用的名称即为测试脚本中所用的名称。编译器会自动的进行映射。这样一个完整的逻辑拓扑文件便完成了。3.6 测试脚本的编写本节便开始演示测试脚本的编写，这是本书的重点部分。测试脚本的内容很丰富，不过大致可以分为3个部分：脚本头部的描述；配置；检查；然后循环，步骤。其中，步骤的内容是需要测试人员根据测试例的内容进行构思、设计它是测试脚本的核心。我们还是以此例来对它进行剖析，测试脚本文件的扩展名为.tcl，为ASCII文本文件，也可以在记事本中编写。在ATF环境中的全局TCL窗口中编写如下图3.43.6.1 打开或生成一个*.tcl文件与前面步骤相同，打开全局TCL窗口，第2步打开或新生成一个*.tcl文件，然后在测试脚本编辑区按图7所示的格式进行编写测试脚本。测试脚本的编写格式有点类似于HTML的格式，文件内容以“”开始，“”结束。注释部分以符号“”开始。由于测试脚本的内容比较多，我们分步进行编写讨论：下图3.4展示的是一个完整的测试脚本例子。图3.4测试脚本的编写写环境及格式3.6.2 测试脚本头部的编写在测试脚本内容中，文件头部分以“”开始，“”结束。为了描述更清除，我把例子的这部分给单列出来，见图3.5。测试脚本头部编写的格式也比较固定，大部分为描述性语言，如标题“”、索引“”、层次“”、模块“”、类别“”、作者“”、版本“”、测试描述“”，以上部分均可以参照例子进行按需填写，注意填写的内容中最好不要出现空格、及后面不要写注释部分，以免影响脚本的编译。最后部分为拓扑图的源文件“”，此部分内容一定要填写正确，它指明脚本对应的逻辑拓扑文件的位置。一般情况逻辑拓扑文件与测试脚本文件写在同一目录下，因此前面的相对路径可以省略。图3.5测试脚本头部内容在头文件描述部分后面，便是以“”开始，“”结束的设备映射部分，此部分内容一般为空，即表示编译器自动进行映射，如果对ATF比较熟悉，也可以按一定格式填写一些手动映射关系，但对初学者最好不要这样。3.6.3 测试脚本的配置、检查动作部分的编写。说到这为止，我们还没看到tcl方面的语句，是因为ATF已经做好了封装，在接下来的“”部分，我们还是以此例进行介绍，编写时可能自己会用到一些tcl的知识。在图3.4所示后半部分，以“”标签开始，在“”之间的部分即是测试脚本的配置、检查动作部分。为了更清楚看到脚本的编写内容，我将此部分也摘出来，并将此部分进行了一些标识，见图3.6。测试脚本的配置、检查动作内容是根据测试用例的内容要求进行编写的，内容格式相对来说不是很固定的。你可以在一个“”进行完所有的配置、检查，也可以将配置检查写在多个“”。一般来说，在对设备进行重新配置时，最好重新进行用一个“”。在脚本执行过程中，可以看到运行时，编译器会自动将多个“”进行顺序编号。因此你可以在后面的描述部分“”中不必写上第步，但为了使脚本可读性好，建议将每个step前加上注释第步。图3.6测试脚本的配置、检查部分一般来说测试用例中的测试步骤对应于测试脚本中的配置部分进行，而测试用例中的预期结果对应于测试脚本中的检查部分进行。本例的测试步骤为由主机HOST构造一个ICMP请求报文，发送给路由器RTA。RTA开接收到报文后，发送回显报文。配置内容：RTA打开IP调试开关以及ICMP调试开关，HOST构造并发送ICMP报文。检查内容：RTA向HOST发送ICMP回应报文。3.6.4 脚本中的配置过程如何向终端发送命令本例向RTA发送配置命令的语句，如图3.6所示，“RTA Config ”此命令就是计算机如同在RTA终端的命令模式中敲击命令语句一样，在稍后的脚本运行中我们可以看到该例的同步信息。Config的格式为：逻辑设备名称 Config “命令字符串”你只需要在里面添加你所需要向RTA发送的命令即可。其实它也是tcl的封装函数，你可以在ATF的联机帮助中找到详细的内容介绍。这里对配置命令只做一些简单的介绍，其目的使你能简单的编写对设备对象发送配置命令即可，以下列举了一些配置命令：设备对象的使用：n 调用方式：对象名称方法名称方法参数n 常用方法：Send 发送配置命令Config发送配置命令CreateInterface创建接口ConfigAddress配置接口地址GetScreen得到控制台窗口屏幕的内容SetErrorCommandCheck设置错误命令检查SaveConfig保存当前配置Restart重新启动设备最常用的就是Config，另外对于Send，Config的功能基本相同，基本的不同之处是Config自动进入配置模式(032system-view)。报文的构造与发送本例中ICMP报文的构造和发送过程中用到了一些的tcl语言和tcl的扩展命令，这些都可以在ATF联机帮助中可以查阅到的，下面只将用到的这些tcl扩展命令的功能大致列举出来：conicmp构造icmp报文conframe构造以太帧listndis列出本主机的所有NDIS设备selectndis device选择device指明的NDIS设备closendis device关闭device指明的NDIS设备sendpack pack报文pack中的内容发送出去delpack pack删除pack代表的报文注：NDIS是Network Driver Interface Standard的英文缩写，本例所选定ndis为PC的网卡。 还有一个命令listndis是列出本主机的所有NDIS设备的名称。在发送报文之前必须调用这个命令（参照联机帮助文档）。此例中，在构造和发送报文时还用到了：$addr(HOST,toRTA)、$addr(RTA,PORT1)、$intf(HOST,toRTA)，分别代表HOST的IP地址129.1.1.111，RTA的IP地址129.1.1.100，及HOST的网卡接口号0000，细心的读者会发现在测试床和逻辑拓扑中好象有这些数据。我们再次将测试床中和逻辑拓扑中的Link给抽出来，看一下他们之间的关系：逻辑拓扑link1, RTA Ethernet0/0 129.1.1.100/24, PC1 0000 129.1.1.111/24测试床link1, RTA PORT1 , HOST toRTA物理连接图3.7逻辑拓扑、测试床、物理连接之间的映射关系这样我们不难理解，$addr(HOST,toRTA)、$addr(RTA,PORT1)、$intf(HOST,toRTA)的含意了，这也是为什么将测试脚本、逻辑拓扑、测试床分离的原因，当物理环境变化时，测试脚本中引用的地址、端口不需要做任何修改，只需修改逻辑拓扑和测试床即可。这对于几十个或几百个脚本对应几个逻辑拓扑和测试床的情况优势更明显。在这里需要说明一点，在ATF框架下编写自动测试脚本不主张用全局变量，尽可能用ATF框架本身的一些变量，以下便是常用的设备相关变量： 物理接口名称： intf (逻辑设备名称，逻辑接口名称) 接口IP地址： addr (逻辑设备名称，逻辑接口名称) 接口网段地址： net (逻辑设备名称，逻辑接口名称) 接口网络掩码： mask(逻辑设备名称，逻辑接口名称) 接口网络掩码长度： masklen(逻辑设备名称，逻辑接口名称) 接口网络反掩码： wildcard (逻辑设备名称，逻辑接口名称) 接口路由： rtEntry (逻辑设备名称，逻辑接口名称) 接口有类路由： class_rtEntry(逻辑设备名称，逻辑接口名称)这里的设备相关变量实际上是以TCL的数组形式存放，对其取值的方式是在前面加$比如：$intf(DUT1,PORT1)就取得逻辑设备DUT1的PORT1端口对应的物理端口名称。3.6.5 脚本中的检查过程脚本中的检查过程是以“”为开头的部分，如图3.6所示。检查其实也是tcl的封装函数，它的格式也比较规范，下面以本例来介绍一下检查的格式：检查的格式 description 是检查的描述部分，你只需将检查的内容描述清楚即可。 type 是检查的类型指定。本例所举例子的检查过程类型是text。 expect 期望得到的字符串。 args 指定要检查的字符串。本例是将RTA缓冲区中的内容赋给了变量result_string（通过“set result_string RTA GetBuffer”语句得到），然后将该缓冲区中的字符串指定为被检查对象，期望有RTA发给HOST的回显报文（关键字：echo-reply(Type=0, Code=0)）。需要指出一点，expect参数后面可以带如“-negative”等选项，表示期望等到要检查的字符串中没有指定的字符串。 最后一项没有带任何参数，但这才是真正的执行检查过程，而前面只是设置参数。检查的一般格式检查的类型除了text格式，还有command、ping、route和custom。你可以在自动测试框架（ATF）帮助中找到详细的介绍，在此只是做一下简单介绍。v 类型：command, route, ping, custom, textv 结果：pass，failedv 一般格式： description descr type type args args object obj expect ?opt? exp repeat times ?-interval seconds ? whenfailed args v 说明 args和expect指定的参数与检查类型有关 对于command、ping和route检查类型，需要指出对象object，后面的参数为逻辑设备名称。 对于任何类型的检查，expect参数可以带有-negative选项，表示取反 repeat参数设置重复检查，ATF一般只有前一次检查失败时才进行重复；whenfailed参数设置检查失败时的动作。此两项参数设置在简单的脚本中一般不会用到，在这里只做简单了解即可。 最后一个单独的真正的执行检查，前面只是设置参数3.7 测试脚本的编写注意事项1 注意你的编写脚本的风格，以保证脚本具有较好的可读性，可扩展性，可复用性等等，推荐你在编写脚本之前可参阅一下林锐编写的高质量C+/C编程指南2 当测试脚本结束时，一定要清除配置3 清除测试脚本中所定义的变量，因为表面看变量为局部变量，当在测试集执行时，多个脚本执行时，前面的脚本中定义的变量有可能会影响到后面的脚本执行过程。第4章 自动化测试脚本的运行在上一章主要以一个“测试对ICMP请求报文回应”例子来介绍ATF自动化测试脚本的编写的全部过程。为了对测试脚本有更清除的掌握、认识，我们仍以此例，来示范测试脚本是如何进行运行的。测试脚本的运行主要分以下部分：4.1 测试脚本的运行准备测试脚本运行准备包括：打开VTP测试平台，并将设备RTA终端视图打开（此部分内容详见VTP2003中的帮助文件控制台使用说明），以及全局TCL窗口。并按照如下步骤先进行脚本的测试床、测试志的设置。4.1.1 指定测试床、测试日志的路径图4.1对测试床及测试志文件的指定环境图4.2对测试床及测试志文件的指定在前面章节中已经讲过逻辑拓扑文件的指定是在测试脚本的头文件中进行的，而测试床则需要按以上步骤进行选择。另外还可指出测试结果的输出测试日志的放置位置。注意：测试床及测试志文件的路径指定只需在第一次使用时指定即可。测试日志的选项按图4.2的默认选项选择即可。特别指出的是，测试日志的“清除配置”选项中的复选框中的内容均不要选，最好在每个测试脚本中的结尾处自己添加清除配置的命令。4.1.2 启动控制台在脚本运行之前，必须要将RTA控制台启动起来，如下图4.3所示：图4.3启动RTA控制台4.2 测试脚本的运行在一切准备就绪后，点击下图4.4红圈内按钮进行执行脚本。图4.4测试脚本运行我们在运行脚本的执行过程中可以按下图4.5进行对“脚本自动向RTA发送命令”实际过程监视。图4.5脚本执行过程中RTA控制台的显示4.2.1 脚本执行过程中RTA控制台的显示在图4.5的RTA控制台中我们可以看到“!-device-initial-”开始进行设备的初始化，此时已经完成测试床和逻辑拓扑的映射。执行脚本开始执行 中的内容，相对应的RTA如图4.5所示：控制台中脚本向RTA发送配置命令Config自动进入system-view模式quit退到用户视图模式debugging ip packet打开ip packet调试开关debugging ip icmp打开icmp调试开关terminal debugging终端显示调试信息。4.2.2 RTA控制台的Debug信息显示在脚本执行到发送icmp报文时，我们将全局TCL窗口最小化，来监控RTA终端视图的显示过程，在执行完脚本尾段，还有清除配置的命令发送。将图4.6图4.6RTA发送回显报文在Debug信息中的显示4.2.3 测试脚本的执行过程及结果输出显示同时，我们可以在全局TCL窗口中的结果输出区实时看到程序的运行状态，如图4.7所示：图4.7测试脚本的结果输出我们将测试脚本的结果输出区域放大，可以看到在脚本执行过程中，输出结果区域中的显示内容。大体可分为三部分：1 自动测试脚本的物理设备和逻辑设备之间的映射，设备的初始化。2 测试执行过程的信息，此例只有一步检查，即查看是否有RTA发送给HOST一个回应ICMP报文，若有则passed，否则failed。如果脚本中还有“ ”将会有STEP 2：、STEP 3：等等。3 在脚本执行完毕后，会有测试脚本的执行情况的汇总，当所有的步骤均通过时，显示测试结论OK，否则应为NG。第5章 更进一步5.1 一系列脚本的编写到此为止，一个完整的自动测试脚本便完成了。有了第一个脚本的编写基础，以后的脚本编写便变的很轻松了。对于一系列测试用例，诸如： HOST发送测试主机不可达时发送ICMP报文。构造IP报文，设置目的MAC设为被测路由器，目的IP是本网络没有的地址，设备应该返回主机不可达报文。 测试网络不可达时发送IP报文。构造IP报文，设置目的MAC设为被测路由器，目的IP不可达，设备应该返回网络不可达报文。 测试协议不可达时发送ICMP报文。构造IP报文，协议类型是RTA不识别的协议，目的IP是SUT地址，设备应该返回协议不可达报文。 测试TTL超时时发送的的ICMP报文。构造IP报文，TTL设为1或者0，RTA应不转发此报文，并发送一个TTL超时的ICMP报文。 等等，我们可以参考已经编写好的测试脚本，或者直接将测试脚本“save as”，然后将构造报文部分进行稍做修改，例如“构造RTA协议不识别的报文”测试用例：原测试脚本报文构造：set icmppack conicmp -sip $addr(HOST,toRTA) -dip $addr(RTA,PORT1) -type 8 -code 0set frame conframe -seth 00.00.00.00.00.01 -deth $deth_Mac -data $icmppack更改为：set ippack conicmp -sip $addr(HOST,toRTA) -dip $addr(RTA,PORT1) -protocol 213set frame conframe -seth 00.00.00.00.00.01 -deth $deth_Mac -data $ippack其中选项protocol的值为213，RTA不识别。注icmppack和ippack、frame均是自己定义的变量。预期结果将： expect echo-reply(Type=0, Code=0)更改为： expect protocol-unreachable(Type=3, Code=2)其余部分你只需将测试脚本的头部的一些描述部分（如标