《电子技术应用》
您所在的位置:首页 > 通信与网络 > 业界动态 > 基于TCL的DHCP协议冒烟测试

基于TCL的DHCP协议冒烟测试

2008-12-17
作者:方 毅, 赵保华

  摘 要: 介绍了基于TCL的协议冒烟测试" title="冒烟测试">冒烟测试系统,对DHCP协议进行形式化分析,生成EFSM图,采用UIO方法生成一致性测试序列,并在该系统上针对提供DHCP服务的各网络设备进行了DHCP协议的冒烟测试,在实际应用中取得了较好的测试效率,缩短了产品研发周期,降低了风险,提高了产品的可靠性。
  关键词: 协议测试" title="协议测试">协议测试; 冒烟测试; 一致性测试

 

  每日构建和冒烟测试是个优秀软件产品的实践过程,在这个过程中,软件产品每天被完全创建并通过一系列的测试以检验它的基本运行情况。冒烟测试可以极大地降低经常遇到的项目进度不清、不成功的整合、质量低劣等风险[1]
  网络协议对确保网络的正常运行起着至关重要的作用。协议测试是检验网络协议实现与协议标准是否一致的重要手段。DHCP是一个草案标准协议,广泛应用于TCP/IP网络上的主机信息自动配置。协议的冒烟测试是网络产品设计过程中的重要环节,可降低系统集成风险,缩短产品开发周期,是保证协议一致性的重要手段。它为依照国际标准化组织所制定的“协议一致性测试的方法和框架”[2]进行一致性的测试做准备。
  本文介绍了基于TCL的协议冒烟测试系统" title="测试系统">测试系统平台、对DHCP协议进行形式化描述、生成EFSM图和UIO测试序列、引出DHCP协议冒烟测试的功能点、结合TCL的高扩展能力,给出基于TCL的DHCP协议冒烟测试系统的具体实现。
1 协议冒烟测试系统
1.1 冒烟测试
  冒烟测试是微软公司[3]首先提出的一个概念,与微软公司一直提倡的每日构建有很密切的联系。冒烟测试指的是开发人员在个人版本的软件上进行一个简单的功能需求测试,确定基本功能都已经被实现,可以进行后续测试工作。其严格定义为:冒烟测试是从抽象层次验证软件的基本功能是否已经实现来确定是否需要更多的测试。若测试失效,软件不再进行其他测试,直接返回给开发人员。具体地说,冒烟测试就是在每日构建建立后对系统的基本功能进行简单的测试,这种测试强调功能的覆盖率,而不对功能的正确性进行验证。从这一点看,与所谓的“接受性(验收)测试(Acceptance Test)”非常相似。不同之处在于冒烟测试所执行的频率和被测的版本不同。
  协议的冒烟测试是对协议实现的基本功能进行测试,确保协议能够正常运行。冒烟测试随着系统的扩充而扩充,最初的冒烟测试可能非常简单,随着开发的进展,系统功能的扩充,冒烟测试也越来越充分[1]。所以冒烟测试本质上属于协议一致性测试,因此,协议一致性测试的方法适用于冒烟测试。冒烟测试作为一个优秀有益的实践过程,有别于通常的协议一致性测试的地方在于测试的频率和范围。
  由于协议软件比一般软件更加复杂,完整测试的代价也更高,因此更加需要进行冒烟测试。当冒烟测试成为软件开发生命周期的一部分时,产品的质量将得到很大的提升。冒烟测试首先要开发一系列的测试例,这些测试例将在每次编译构建后运行,用来测试系统的主要功能完成情况。将这些测试例脚本串行自动化执行,向用户返回一个哪些协议功能已经基本实现(通过冒烟测试)的列表,这个自动化的冒烟测试过程是针对被测实现IUT(Implement Under Test)在路由器开发过程中被定期执行。目前常用的脚本语言有TCL、Perl、Python、Windows Scripting及批处理等。其中,TCL脚本已逐渐成为业界普遍采用的实用工具。
1.2 系统实现
  本测试利用TCL的可扩展性,通过将C++实现的协议测试基本库封装在动态链接库,无缝集成到TCL平台,同时对TCL命令集进行扩展,实现了一个基于TCL的DHCP协议冒烟测试系统。图1是该系统的系统架构。DHCP协议冒烟测试即是在该系统架构下实现的。

 


  该系统由底层支持模块、测试套编辑模块、测试套执行和管理模块、GUI界面模块构成。
底层支持模块:在TCL自身命令的基础上,增加C++实现的协议测试基本库及TCL扩展命令,提供从链路层及以上各层协议的收发和编解码等命令。
  测试套编辑模块:采用TCL为测试套的编写语言,包括测试例描述、测试脚本、测试配置文件。
  测试套执行和管理模块:由于底层支撑命令采用的是已编译过的二进制代码,故虽然测试套采用TCL编写,但是测试执行是简单高效的。测试套执行后,自动生成测试结果报告。
  GUI界面模块:目前采用VC实现,以后将考虑用TK实现,以提高系统的可移值性。
2 基于TCL的DHCP协议冒烟测试的测试套实现
2.1 DHCP协议及其形式化

  DHCP是一个草案标准协议。动态主机配置协议DHCP(Dynamic Host Configuration Protocol)RFC2131、DHCP RFC2132选项和BOOTP软件商扩展(DHCP Options and BOOTP Vendor Extensions),系统地描述了当前DHCP规范。
  DHCP提供了一个把配置信息传递到TCP/IP网络上的主机的框架[4]。DHCP基于BOOTP协议[5],增加了自动分配可重用网络地址的能力和额外的配置选项[6]。有关BOOTP的规范可参考文献[7]。
  DHCP消息使用UDP的67端口(BOOTP服务器公用)和68端口(BOOTP客户公用端口)。DHCP参与者可以与BOOTP参与者互操作[8]
  DHCP采用客户/服务器模式,由两部分组成:
  (1)把特定主机的配置参数从一个DHCP服务器发送到主机的协议。
  (2) 把网络地址(临时或永久)分配给主机的机制。
  DHCP消息分为DHCPDISCOVER、DHCPOFFER、DHCP-
  REQUEST、DHCPACK、DHCPNACK、DHCPDECLINE、DHC-
  PRELEASE、DHCPINFORM等八种类型。图2为DHCP客户/服务器交互过程时序图,显示了其典型客户/服务器交互的时序关系及各消息类型间的关系。

 


  DHCP服务器端接收来自DHCP客户端" title="客户端">客户端的DHCPDISCOVER、DHCPREQUEST、DHCPDECLINE、DHCPRELEASE、DHCPINFORM等DHCP消息,而DHCP客户端则接收来自DHCP服务器端的DHCPOFFER、DHCPACK、DHCPNAK等DHCP消息。通过DHCP客户/服务器交互过程完成整个DHCP机制,其DHCP消息类型是DHCP机制成功实施的基础和关键。
  DHCP冒烟测试的功能点包括:客户端初始化并通过DHCP Relay Agent向DHCP Server获取网络地址(DHCP Relay)、客户端初始化向DHCP Server获取网络地址;客户端初始化向DHCP Server申请重新使用以前分配的网络地址;外部赋予客户端配置参数,客户端与DHCP Server通信进行初始化(DHCP Server)。
  本文以DHCP Server功能为例,首先将DHCP的非形式化描述转化成用EFSM[9]协议形式化描述技术来进行描述,然后基于EFSM的测试序列生成方法UIO(Unique Input/Ouput Sequence)[10]生成DHCP协议的测试序列,最后实现测试序列的脚本,即完成其冒烟测试。
  DHCP Server功能主要实现动态IP地址分配,其EFSM图如图3所示。

 

  图3中,a表示DHCPDiscover,b表示DHCPRequest, c表示DHCPInform,d表示DHCPDecline,x表示DHCPOffer,y表示DHCPAck, z表示DHCPNak。
  在图3所示的EFSM图的基础上,采用UIO方法生成一致性测试序列:
  (1)为每个状态确定一个不同的输入输出序列:
  UIO(S1)={a/x},UIO(S2)={b/y},UIO(S3)={c/y},是满足上述要求的三个输入输出序列。
  (2)测试EFSM 中的每个状态Si。测试序列由三部分组成:①引导序列。②状态Si的UIO 序列(带下划线标记)。③同步序列ri/null。
  

  (3)测试EFSM 中的每个状态转换(Si, Sj,i/o)。输入序列由四部分组成:(a)引导序列。(b)待测转换i/o(带下划线标记)。(c)状态sj 的UIO 序列。(d)同步序列ri/null。
  

2.2  测试例实现
  测试套是测试例的集合,测试例由测试例描述、测试脚本、测试例配置文件三部分构成,而测试例配置文件又分测试前配置文件、去配置文件,以保持干净的测试环境" title="测试环境">测试环境,各测试例在测试套自动执行时,前一测试例不影响后面的测试例。同时,测试例的描述与测试环境密切相关,测试例在编写时将测试脚本和测试配置分开,以适应不同的测试环境。
  图4为DHCP Server功能点的冒烟测试环境。利用TCL的可扩展性,实现了基于数据链路层的数据收发及编解码支撑命令、PCO(Point of Control and Observation)支持命令、DHCP协议的接口支持函数和编解码函数。部分命令如表1所示。

 


  测试例的框架如下:
  #首先开发DHCP的TCL扩展命令,封装其各种报文的收发、编码和解码等。
  #加载TCL/Tk扩展命令,以及测试环境配置参数。
  #通过telnet设置IUT测试环境:
  set result [TELNET::TelExecFile $s $cmdfilename]
  #测试过程
  #建立Socket连接并发送报文
  set udp_sock [UDP::Init $s_adpter $s_mac $broadMac  
   $s_addr $s_port $broadIp $d_port]
  set udp_bcast_rsock [UDP::Init $s_adpter $broadMac
    $d_mac  $broadIp $s_port $d_addr $d_port]
  UDP::Send $udp_sock $dhcpData
  …
  set dhcp_offer [UDP::ReceiveFrom $udp_bcast_rsock
     $timeout '' '' '']
  #对收到的报文解码分析。
2.3 测试结果
  协议冒烟测试实现的是对基本功能的测试,不关注细节,其目的是确保系统稳定运行,能进行进一步的测试。DHCP冒烟测试例在协议冒烟测试系统中以测试套的形式自动执行,向用户返回测试例的执行结果。本例中,对DHCP的四个功能点实现其测试例,并且每个测试例以UIO测试序列来对协议实现情况进行测试和评判。其测试结果如表2所示。

 


  表2显示了DHCP Server、 Relay测试例均已通过,说明该协议的冒烟测试已经完成,该IUT支持DHCP。测试环境中的RUT是一台成熟的路由器产品,该路由器支持DHCP,测试结果与预期的结果是一致的。说明本文提出的基于TCL的协议冒烟测试系统在实际应用中是可行、高效的。
  本文基于TCL/Tk协议测试系统实现了DHCP的冒烟测试,将冒烟测试引入协议产品的开发中,提高了项目的可视性和产品的质量,降低了产品上市时间延迟的风险。本文对提高协议测试的覆盖率和测试效率,实现测试序列的自动生成,具有一定的参考价值。


参考文献
[1] (美)迈克康奈尔(Ma C S)著[M].快速软件开发——有效控制与完成进度计划.席相霖,等译.北京:电子工业出版社,2002.
[2]  IS29646.ISO. Conformance testing methodology and framework[S]. 1991.
[3]  CONNELL M C S. Software project survival Guide[M].  Microsoft Press, 1998:290-330.
[4]  RFC2131.Dynamic host configuration protocol[S]. 1997.
[5]  CROFT B, GILMORE J. Bootstrap protocol (BOOTP). RFC951 Stanford and SUN Microsystems[S], September 1985.
[6]  SCHILLER J, ROSENSTEIN M. A protocol for the dynamic assignment of IP addresses for use on an ethernet.(Available from the Athena Project, MIT)[Z], 1989.
[7]   RFC951. Bootstrap Protocol[S]. 1985.

[8]  DROMS D. Interoperation between DHCP and BOOTP.  RFC 1534[S], Bucknell University, October 1993.
[9]  DUALE A Y, FECKO M A, UYAR M U. Generating executable tests for timed and untimed EFSM models.
 Proc. IIS/IEEE World Multiconference on Systemics,Cybernetics and Informatics[J], Orlando, FL, 2001,(2):
 109-113.
[10] 余萍,顾冠群.基于UIO流方法的协议一致性测试及应用[J]. 数据通信,1996,(1):8-15.

本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306118;邮箱:aet@chinaaet.com。