CN103631704A

CN103631704A - 通信设备的自动化测试系统及方法

Info

Publication number: CN103631704A
Application number: CN201210304169.7A
Authority: CN
Inventors: 张鑫; 沈志刚
Original assignee: Shanghai Feixun Data Communication Technology Co Ltd
Current assignee: Song Yixiao
Priority date: 2012-08-23
Filing date: 2012-08-23
Publication date: 2014-03-12
Anticipated expiration: 2032-08-23
Also published as: CN103631704B

Abstract

本发明公开了一种通信设备的自动化测试系统及方法。该自动化测试系统包括一测试主机和一辅助测试装置，其中，该测试主机用于发送命令列表至该辅助测试装置，该命令列表中包括由组件包中的工具命令重新组合封装之后的测试命令；该辅助测试装置用于接收该命令列表并识别该命令列表中的测试命令，以及在该第二操作系统下将该测试命令发送至该通信设备以采用TCL测试脚本完成对该通信设备的测试。本发明充分发挥Tcl语言提供的套接字设施的易于使用和完全免费的特点，实现了对跨平台能力差的工具包的实现平台无关化的应用。

Description

通信设备的自动化测试系统及方法

技术领域

本发明涉及一种通信设备的自动化测试系统及方法，特别是涉及一种测试平台无关化的通信设备的自动化测试系统及方法。

背景技术

随着国内的中国人口红利的逐渐耗尽，国内人力成本正在逐年攀升。然而，人们对于软件产品的质量和可靠性要求确实在逐年提高的，这就意味着，如果要提高测试的质量，但同时有不至于大幅度提高成本，那么自动化测试是个不错的选择。

Tcl（Tool Command Language，工具命令语言）脚本语言是通信设备自动化测试的首选脚本语言，主要是因为，很多通信类软件测试仪器都对其留了API（应用程序编程接口），例如，Spirent Communication Ltd.生产的仪器，就大量使用的这种语言作为API脚本语言。因其快速高效的特质，以及与C、C++语言的良好转换性，特别适合，AST（Automated Software Testing，自动软件测试）的要求——开发周期短，便于修改，并且有良好的跨平台能力，以及对未来的性能提升（即转化为C代码），具备潜在便利条件。

虽然，Tcl脚本语言，通过Tcl解释器的多系统版本，实现了跨平台能力，但是，Tcl是一种持续进化的语言，它的灵活性，在于它的各种模块化的组件包（组件包是第三方组织创建的工具包，这些工具会在测试过程中使用到）。问题就在于，这些组件包，对于不同的操作系统（Opration System，简称OS）平台具有不同的适应性。有的组件包，只在GNU\Linux上有（GNU计划，又称革奴计划，是由Richard Stallman在1983年9月27日公开发起的。它的目标是创建一套完全自由的操作系统；Linux是一种自由和开放源码的类Unix操作系统（UNIX操作系统，是美国AT&T公司于1971年在PDP-11上运行的操作系统。具有多用户、多任务的特点，支持多种处理器架构），别的OS上就看不到它的实现。但是，当我们恰恰需要这个软件包提供的功能，但是又不能更换测试用的OS平台时，如何完成自动化测试是一个问题。

Tcl脚本语言在发展的过程中，积累了很多成功的工具包，遗憾的是，它们并不都是如Tcl解释器“tclsh.exe”一样具有良好的跨平台特性。如何能够将一个不兼容与本OS的工具包用起来，而不必重新开发一个对应于本OS的类似工具包，是我们面临的一个现实问题。

当前解决这个问题的方法，主要是：

1)通过购买某些ActiveTcl（官方发布的免费Tcl开发环境，包含许多有用的扩展包）的收费工具包；

2)自己开发一个功能类似的工具包；

3)寻找其它较相近的工具包，重新设计实现方案。

以上几种方式虽然可以解决这个问题，但是各自也都存在明显的不足：

1)通过购买收费软件包，是需要计入开发成本的；

2)自己开发功能相近的工具包，需要单独立项，耗费大量公司资源，有可能造成ROI(Return On Investment)受损，影响公司收益；

3)重新设计方案，有时候是可行的，但是，同样涉及ROI的问题，有时候，可能还有开发时间不足的问题。

发明内容

本发明要解决的技术问题是为了克服现有技术在通信设备的自动化测试过程中组件包不能跨平台使用的缺陷，提供一种简单有效、无需开发新的组件包的通信设备的自动化测试系统及方法。

本发明是通过下述技术方案来解决上述技术问题的：

一种通信设备的自动化测试系统，其特点在于，其包括设置了一第一操作系统的一测试主机和设置了一第二操作系统的一辅助测试装置，其中，

该测试主机用于在该第一操作系统下采用TCL测试脚本执行对该通信设备的测试，以及用于发送一命令列表至该辅助测试装置，该命令列表中包括由组件包中的工具命令重新组合封装之后的测试命令，其中该组件包为只能在该第二操作系统中应用的TCL工具包；

该辅助测试装置用于接收该命令列表并识别该命令列表中的测试命令，以及在该第二操作系统下将该测试命令发送至该通信设备以采用TCL测试脚本完成对该通信设备的测试。

通过本发明所述的通信设备的自动化测试系统，无需额外购买收费工具包、也免去了在仓促的时间内开发一个功能相似的工具包的烦恼，采用简单的改进即可实现TCL组件包的跨平台使用。

优选地，该通信设备用于将该测试命令的执行结果发送至该辅助测试装置；

该辅助测试装置还用于将该执行结果返回至该测试主机。

优选地，该辅助测试装置还用于将该执行结果以XML格式返回至该测试主机。

优选地，该第一操作系统为MS-Windows操作系统（视窗操作系统（英语：Windows，在中文地区亦常以其英文名称呼）是微软公司推出的一系列操作系统），该第二操作系统为Linux操作系统，和/或，该命令列表为静态列表。

优选地，该通信设备为路由器或者交换机。

本发明还提供一种通信设备的自动化测试方法，其特点在于，其采用如上所述的通信设备的自动化测试系统实现，该通信设备的自动化测试方法包括以下步骤：

步骤S₁、该测试主机发送该命令列表至该辅助测试装置；

步骤S₂、该辅助测试装置接收该命令列表并识别该命令列表中的测试命令；

步骤S₃、该辅助测试装置在该第二操作系统下将该测试命令发送至该通信设备以采用TCL测试脚本完成对该通信设备的测试。

优选地，步骤S₃之后还包括：

步骤S₄、该通信设备将该测试命令的执行结果发送至该辅助测试装置；

步骤S₅、该辅助测试装置将该执行结果返回至该测试主机。

优选地，步骤S₅中该辅助测试装置将该执行结果以XML格式返回至该测试主机。

优选地，该第一操作系统为MS-Windows操作系统，该第二操作系统为Linux操作系统，和/或，该命令列表为静态列表。

优选地，该通信设备为路由器或者交换机。

本发明的积极进步效果在于：本发明所述的通信设备的自动化测试系统及方法综合考虑了技术现实和研发时所不得不面对的财务限制，充分发挥Tcl语言提供的套接字设施的易于使用和完全免费的特点，实现了对跨平台能力差的工具包的实现平台无关化的应用。

附图说明

图1为本发明一实施例的通信设备的自动化测试系统的结构框图。

图2为本发明一实施例的通信设备的自动化测试方法的流程图。

具体实施方式

下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在所述的实施例范围之中。

参考图1，介绍本发明一实施例的通信设备的自动化测试系统，其包括设置了一第一操作系统的一测试主机1和设置了一第二操作系统的一辅助测试装置2，其中，

该测试主机1用于在该第一操作系统下采用TCL测试脚本执行对该通信设备3的测试，以及用于发送一命令列表至该辅助测试装置2，该命令列表中包括由组件包中的工具命令重新组合封装之后的测试命令，其中该组件包为只能在该第二操作系统中应用的TCL工具包；

该辅助测试装置2用于接收该命令列表并识别该命令列表中的测试命令，以及在该第二操作系统下将该测试命令发送至该通信设备3以采用TCL测试脚本完成对该通信设备3的测试。

该通信设备3用于将该测试命令的执行结果发送至该辅助测试装置2；

该辅助测试装置2还用于将该执行结果返回至该测试主机1。在本实施例中，该辅助测试装置2还用于将该执行结果以XML（Extensible MarkupLanguage，可扩展标记语言）格式返回至该测试主机1。

在本实施例中，该第一操作系统为MS-Windows操作系统，该第二操作系统为Linux操作系统，并且，该命令列表为静态列表。

在本实施例中被测试的该通信设备为路由器。

参考图2，介绍本发明一实施例的通信设备的自动化测试方法，其采用如上所述的通信设备的自动化测试系统实现，该通信设备的自动化测试方法包括以下步骤：

步骤S₁、该测试主机1发送该命令列表至该辅助测试装置2；

步骤S₂、该辅助测试装置2接收该命令列表并识别该命令列表中的测试命令；

步骤S₃、该辅助测试装置2在该第二操作系统下将该测试命令发送至该通信设备3以采用TCL测试脚本完成对该通信设备3的测试。

步骤S₄、该通信设备3将该测试命令的执行结果发送至该辅助测试装置2；

步骤S₅、该辅助测试装置2将该执行结果返回至该测试主机1。

具体来说，步骤S₅中该辅助测试装置将该执行结果以XML格式返回至该测试主机。

下面通过一个简单的应用实例，再次说明本发明的技术方案。

在本发明的自动化测试中，假设某个测试脚本，其执行环境是在MS-Windows下，并且需要使用到某个工具包，但是这个工具包不能在Windows下面运行。并且，开发时间是有限的，测试方又不愿意花更多的钱去购买它的第三方收费工具包。除此之外，还需要另一台电脑安装Linux系统，并作为服务器所在。

在本发明中，需要用到一命令服务器（Command Server,CS），即一个TCP Server（Transmission Control Protocol，传输控制协议，服务器）用来提供命令执行服务和命令结果返回服务。其中，命令服务器可以是个应用程序，它安装在安装了Linux系统的PC（个人电脑）上。

在自动化测试过程中，还涉及命令列表（Command List，CL），该命令列表为一张可执行的命令表，可以被CS识别并正确执行的命令，它是一个静态列表。该命令列表是命令服务器运行后载入到其内存中的一个列表，表中每个元素都是一个完整的命令，这些命令是对前述的“组件包”中提供的工具命令，根据测试需要，进行重新组合封装之后的命令，以用于实际执行一项测试动作。该命令列表以表1的形式呈现。其中，每个命令，例如CMD1是一种高层抽象API，它存在的价值是对调用者隐藏对“组件包”中命令调用的细节过程。

表1 CL结构图

Command（命令）	Parameter List（参数列表）
		CMD1	P1,P2,P3
CMD2	P1,P2,P3
		CMD3	P1,P2,P3
CMD4	P1,P2,P3

对于该CS来说，在实际应用过程中，首先装载CL，接着进行初始化、绑定接口和监听的操作，以判断是否收到命令，若是，判断命令是否存在，若存在，则执行命令脚本；若不存在命令，则返回判断是否收到命令的操作。

测试的结果以一XML文本包含结构化的消息结果呈现，即执行报告（Action Report，简称AR），该AR例如以下形式：

该执行结果最终将被回报给命令发送端。

本发明所述的通信设备的自动化测试系统及方法综合考虑了技术现实和研发时所不得不面对的财务限制，充分发挥Tcl语言提供的套接字设施的易于使用和完全免费的特点，实现了对跨平台能力差的工具包的实现平台无关化的应用。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这些仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。

Claims

1.一种通信设备的自动化测试系统，其特征在于，其包括设置了一第一操作系统的一测试主机和设置了一第二操作系统的一辅助测试装置，其中，

2.如权利要求1所述的通信设备的自动化测试系统，其特征在于，该通信设备用于将该测试命令的执行结果发送至该辅助测试装置；

该辅助测试装置还用于将该执行结果返回至该测试主机。

3.如权利要求2所述的通信设备的自动化测试系统，其特征在于，该辅助测试装置还用于将该执行结果以XML格式返回至该测试主机。

4.如权利要求1所述的通信设备的自动化测试系统，其特征在于，该第一操作系统为MS-Windows操作系统，该第二操作系统为Linux操作系统，和/或，该命令列表为静态列表。

5.如权利要求1-4中任意一项所述的通信设备的自动化测试系统，其特征在于，该通信设备为路由器或者交换机。

6.一种通信设备的自动化测试方法，其特征在于，其采用如权利要求1所述的通信设备的自动化测试系统实现，该通信设备的自动化测试方法包括以下步骤：

步骤S₁、该测试主机发送该命令列表至该辅助测试装置；

7.如权利要求6所述的通信设备的自动化测试方法，其特征在于，步骤S₃之后还包括：

步骤S₅、该辅助测试装置将该执行结果返回至该测试主机。

8.如权利要求7所述的通信设备的自动化测试方法，其特征在于，步骤S₅中该辅助测试装置将该执行结果以XML格式返回至该测试主机。

9.如权利要求6所述的通信设备的自动化测试方法，其特征在于，该第一操作系统为MS-Windows操作系统，该第二操作系统为Linux操作系统，和/或，该命令列表为静态列表。

10.如权利要求6-9中任意一项所述的通信设备的自动化测试方法，其特征在于，该通信设备为路由器或者交换机。