CN101212362A - 一种融合多类型测试工具的自动化测试装置及方法 - Google Patents

Abstract

本发明公开了融合多类型测试工具的自动化测试装置及方法，用场景用例绑定场景描述文件及场景设置脚本，用测试用例绑定执行脚本和测试脚本，运行场景用例，将场景设置脚本将场景描述文件下载到测试主机进行测试场景自动化配置，利用执行脚本获取测试脚本的运行参数，根据参数加载对应的测试执行工具，由执行工具调用测试脚本根据由场景描述文件解析获得的参数以及构成测试脚本的基本函数命令，对被测设备进行测试，测试中记录测试结果到日志文件中，如有未执行场景用例或测试用例，重复上述步骤直到测试结束，记录最终总的测试结果，并将其更新至测试用例服务器。

Description

一种融合多类型测试工具的自动化测试装置及方法

技术领域

本发明涉及***自动化测试技术，尤其涉及一种用于通讯设备的自动化测试装置及方法。

背景技术

通讯设备的***测试，其典型测试过程是在多种组网环境下对DUT(Device Under Test，被测设备)进行业务配置，业务配置成功之后进行业务测试，接入真实用户或者借助测试仪器模拟真实用户，验证业务是否正确以及业务性能是否合乎要求。

在业务配置方面，通讯设备通常有两种维护方式：

网管通过GUI(Graphical User Interface，图形用户接口)接口对设备进行维护；通过CLI(Command Line Interface，命令行接口)超级终端对设备进行维护。因此，在进行设备配置自动化测试时，通常会根据需要使用上述两方面的测试手段。在GUI方式下，经常会使用类似于Robot等测试工具，对于被测设备DUT的网管配置，采用图形化命令接口配置测试自动化。在CLI方式下，经常会使用Tcl(Tool Command Language，工具命令语言)测试脚本，对被测设备DUT的字符命令，采用人机命令接口配置测试自动化。

在业务测试方面，往往会引入第三方功能和性能测试工具，如模拟呼叫器、网络测试仪等辅助测试仪器，这些仪器同样会提供相应的软件平台进行基于GUI方式或者CLI方式下的业务模拟操作。

现有技术的问题，主要体现在以下几个方面：

(1)对于多种组网环境下的自动化测试，一般的实现方式是根据当前测试组网，设置测试脚本所需的测试参数，当更换测试组网时，需要实时修改测试参数；

(2)在测试过程中，如果使用了多种测试工具，由于针对不同工具的测试脚本各有其控制和运行平台，在变更测试脚本时，需要手工做各个测试工具之间的应用切换；

(3)基于上述限制，一个完整的自动化测试过程只能支持一种测试场景一种测试工具的自动批量测试。

因此，现有技术方案下的自动化测试过程中，具有较多需要人工干预的环节，导致从整体上看测试效率并没有得到明显的提高。

发明内容

本发明所要解决的技术问题在于，提供一种融合多类型测试工具的自动化测试装置及方法，解决现有自动化测试过程因无法融合不同测试工具而需要过多人工干预、以及无法实现测试场景多样化的问题。

本发明提供一种融合多类型测试工具的自动化测试装置，包括：测试场景设置模块、工具驱动模块、测试数据解析模块、测试命令字子集模块、测试脚本集模块、日志模块，其中，

所述测试场景设置模块，位于测试用例服务器上，用于存储若干与场景描述文件及场景设置脚本所绑定的场景用例集合；

所述工具驱动模块，位于测试用例服务器及测试主机上，用于存储与测试用例绑定的执行脚本集合；

所述测试数据解析模块，位于测试主机上，用于对测试场景设置模块提供的场景描述文件按一定的规则进行解析，提取代表被测设备的被测功能的测试参数，供测试脚本运行使用；

所述测试命令字子集模块，位于测试用例服务器及测试主机上，由若干个测试库文件组成，用于提供测试脚本所需的基本命令函数；

所述测试脚本集模块，位于测试用例服务器及测试主机上，用于存储构建于所述测试命令字子集模块提供的命令函数基础之上的与测试用例绑定的测试脚本，该测试脚本使用由所述测试数据解析模块解析出的测试输入参数，在所述工具驱动模块的运行支持下，对被测设备的面向功能和业务的应用层进行自动化测试；

所述日志模块，位于测试用例服务器及测试主机上，使用文本文件记录所述测试脚本集模块中的测试脚本运行过程详细信息及最终的测试结果。

进一步地，所述测试用例服务器、测试主机、被测设备位于一个可建立连接的网络中，所述测试主机与所述测试用例服务器相连，所述测试主机与被测设备相连。

进一步地，所述测试场景配置模块中的所述场景用例，包括：

场景描述文件，用于定义保存某测试场景下被测设备的物理配置结构及与具体测试内容相关的若干测试参数；

场景设置脚本，用于在运行场景用例时，自动将对应的场景描述文件从所述测试用例服务器下载到测试主机本地，并以测试主机本地的场景描述文件名更新保存于测试主机作为测试场景。

进一步地，所述工具驱动模块内的执行脚本是VBScript脚本、或Perl脚本、或C语言脚本，该执行脚本运行时，控制所述工具驱动模块根据传入的参数格式，调用支持该参数格式的测试执行工具及测试用例绑定对应的测试脚本。

进一步地，所述工具驱动模块根据传入参数不同，调用与此参数相匹配的测试工具，执行测试用例绑定的测试脚本，其中所述测试工具是图形用户接口GUI方式下的Robot测试工具，或命令行接口CLI方式下的工具命令语言Tcl工具，或基于GUI或CLI方式的第三方功能和性能测试工具。

进一步地，所述测试脚本集模块内的测试脚本集根据测试内容可进行扩充或删减，其中所述测试脚本是Robot测试脚本、或是工具命令语言Tcl测试脚本；所述测试场景设置模块存储的场景用例集合，根据测试需要可进行场景用例的扩充或删减。

本发明还提供一种基于所述自动化测试装置的融合多类型测试工具的自动化测试方法，利用测试用例服务器和测试主机对被测设备进行自动化测试，包括如下步骤：

(1)判断是否需要运行场景用例，如果是，则与场景用例绑定的场景设置脚本下载对应的场景描述文件到测试主机本地作为被测场景，如果否，采用本地现有场景描述文件作为被测场景；

(2)测试数据解析模块对测试主机上当前的场景描述文件按一定的规则进行解析，提取代表被测设备被测功能的测试参数，供测试脚本运行使用；

(3)工具驱动模块运行与测试用例绑定的执行脚本，由执行脚本读取测试脚本运行参数，自动加载与测试脚本运行参数对应的测试工具执行程序，调用对应的测试脚本；

(4)测试脚本集模块中与测试用例绑定的测试脚本，被调用之后，根据所述测试数据解析模块提取的测试输入参数以及所述测试命令字子集模块的基本函数进行运行，对被测设备进行测试；

(5)测试脚本运行过程中，记录测试脚本运行过程信息，生成测试执行日志文件；

(6)判断是否还有待运行的场景用例或测试用例，如果有，重复上述步骤1-5，继续进行测试；

(7)测试脚本运行结束，所述日志模块根据日志文件获得测试脚本最终执行结果，并将该最终结果更新到测试用例服务器。

步骤(3)中所述由执行脚本读取的测试脚本运行参数，包括测试脚本类型和测试脚本名称，其中所述测试脚本类型包括Robot测试脚本、或工具命令语言Tcl测试脚本。

步骤(3)中所述测试工具是图形用户接口GUI方式下的Robot测试工具，或命令行接口CLI方式下的工具命令语言Tcl工具，或基于GUI或CLI方式的第三方功能和性能测试工具。

本发明提供的方法及其装置具有工具驱动模块，各测试工具执行方式的差异被该模块所屏蔽，运行参数可灵活修改，适应了自动加载多测试工具的要求，因此，具有良好的扩展性。此外，对于多测试场景的测试，通过场景用例和测试用例的有机组合，使得测试过程中无需再手工进行测试场景切换，明显提高了测试效率。

附图说明

图1是本发明提供的多测试场景实现原理图；

图2是本发明提供的工具驱动实现原理图；

图3是本发明提供的具体实施例的自动化测试装置结构图；

图4是本发明提供的具体实施例的自动化批量测试运行流程图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

针对现有测试技术的不足，本发明提出了一种通讯设备自动化测试中集成应用GUI(Graphical User Interface，图形用户接口)和CLI(Command LineInterface，命令行接口)测试执行工具并自动部署测试场景的自动化测试方法及其装置。在通讯设备自动化测试领域，解决如何能够将GUI和CLI组合起来运用的问题，以及如何解决测试场景多样化的问题。利用本发明所述方法及装置，实现多种测试工具及测试脚本的集成化应用，以及多测试场景的自动切换，满足对被测设备DUT全流程自动化测试的需求。。

本发明的核心思想是提供一种可融合多类型测试工具的自动化测试应用，这在通讯设备测试中尤其显得重要和有用。为达到本发明的目的，在本发明的技术方案中，融合多类型测试执行工具的自动化测试方法的主要思路为：

(1)设计场景用例，使用场景用例绑定场景描述文件和场景设置脚本，进行多场景的自动化部署；

(2)设计测试用例，使用测试用例绑定测试脚本和执行脚本，由执行脚本屏蔽不同类型测试执行工具在执行方式上的差异，实现面向多工具平台的测试脚本的自动运行。

通过上述场景用例和测试用例的组合运用，就能够实现对被测设备DUT多测试场景、多测试工具的集成化、批量化的自动测试。

所述“场景用例”，是被测设备DUT在某种组网环境下应用的抽象表述，其可以用一定的规则对DUT的诸多特征进行定义，从而构成为“场景描述文件”。

所述“测试用例”，是本技术领域所通常认知的针对被测设备DUT进行测试行为的逻辑描述。

所述场景用例和测试用例，均可被存储于测试用例服务器之中。测试主机与测试用例服务器、测试主机与被测设备DUT都在一个可建立连接的网络内，其中，测试主机通过和测试用例服务器相连接，获得场景用例和测试用例信息，通过组合若干场景用例和测试用例并按所得到的两者组合运行，就可对与之连接正常的被测设备DUT执行批量化的自动化测试。

参照图1，每一个“场景用例”都由一个特定的“场景描述文件”以及关联场景用例的VBScript“场景设置脚本”所组成。其中：

场景描述文件，定义了被测设备DUT的物理配置结构以及与具体测试内容相关的若干测试参数；

场景设置脚本，用于实现文件下载及复制操作，将所述场景描述文件从测试用例服务器下载至测试主机本地。

场景用例保存于测试用例服务器上，与每个场景用例绑定的每个场景描述文件，测试时被下载到测试主机本地，进行同名替换，在同一时刻，测试主机本地只有一个场景描述文件，存储于测试主机本地的场景描述文件都保持为同一文件名。执行时，后运行的场景用例会替换掉之前的场景用例，进行同名替换，这样就做到了多测试场景的批量运行。

参考图1，通过在测试主机上运行场景用例，其所绑定的场景设置脚本就可自动将对应的场景描述文件下载到测试主机本地，实现测试场景的自动更新。例如，假定场景用例11在测试主机上运行时，绑定的场景设置脚本S11将对应的场景描述文件F11，下载到测试主机本地，并保存为共用名称“场景描述文件”。在更换测试场景时，只需依次将场景用例12或13的场景描述文件F12或F13下载测试主机本地，也都保存为共用名称“场景描述文件”，即实现了测试场景的自动化布置。

如图1所示，测试脚本在运行中要到场景描述文件中提取测试数据，也就是说场景描述文件保存了所有测试运行中需要的测试数据。通过这样的方式，做到了实时数据和测试脚本分离，测试脚本不受测试数据变化影响，保证了测试脚本有很好的维护性。

参考图2，每个测试用例都绑定两个脚本文件：一个为执行脚本，一个为对应于实际测试类型的测试脚本。执行脚本可为任何一种形式的脚本，如Vbscript、Perl甚至是C，本领域的技术人员应该可以理解。

由于测试脚本类型不同，比如GUI的或者是CLI的，它们的运行方式是相互不兼容的，因此，通过设计工具执行引擎来屏蔽掉不同工具不同的运行方式。在图2中，工具执行引擎和执行脚本是画在一起的，可以认为工具执行引擎是一个逻辑上的实体，执行脚本实质上才是工具执行引擎的真实载体，在执行脚本中定义了不同测试工具执行测试脚本的运行参数，通过所传入运行参数的不同，就可以将不同类型的测试脚本调用起来，实现了多类型测试工具的综合测试。

由“工具执行引擎”运行执行脚本，通过所传递的运行参数不同，调用测试工具及测试用例所对应的测试脚本，完成一个运行环境下不同测试工具测试脚本的自动集成运行。当测试脚本为Robot测试脚本时，传入参数格式为Robot支持的运行格式；当测试脚本为Tcl测试脚本时，传入参数格式为Tcl支持的运行格式。

运行场景用例，就是通过场景设置脚本将场景描述文件下载到本地，供后续的测试脚本运行试用。而运行实际的测试用例，则是通过工具执行引擎运行执行脚本，执行脚本可以获取到不同测试脚本执行需要的不同运行参数，从而实现对测试脚本的调用。

下面这段代码是执行脚本(工具驱动是执行脚本的逻辑表述，它是由一系列执行脚本所组合而成的)中如何识别不同类型的运行参数示例：Case″Robot″，Case″Tcl″实际上就是代表不同测试工具类型的不同分支，传入的参数为测试类型和测试脚本名称，通过这两个参数就可确定实际执行时具体执行哪一个分支。

这两个参数是测试用例本身就具备的属性，也就是说测试用例通过测试脚本名称和测试类型才能真正绑定到一个测试脚本，因此在执行测试用例时，自然也就将这两个参数传入给执行脚本了。

下面给出工具驱动的部分伪代码示例：

    Select Case strTool

           Case″Robot″

               StrRunPara1＝″C:\rtrobo.exe″

        StrRunPara2＝strScriptName&″/user admin/project D:\RobotTest.rsp

/play/close″

        XTools.run StrRunPara1，strRunPara2，-1

          Case″Tcl″

                 Set objShell＝CreateObject(″Wscript.Shell″)

                strRunPara＝″D:\TclTest\″&strScriptName

                objShell.Run″％comspec％/c |tclsh.exe″&strRunPara，1，

TRUE

    Case″...″

    ...............

    End Select

进一步地，对所述“工具执行引擎”进行说明如下：

所述工具执行引擎运行VBScript执行脚本的实现原理，是通过将VBScript脚本源解释器封装于其中，用户无需关心VBScript脚本是如何被执行的，只要设计各个执行工具对应的驱动代码即可。上述代码中的“XTools”是工具执行引擎提供的调用接口类。

从上面这个示例可见，按本发明提供的思路，所支持调用的测试工具并不限于示例中的这两种工具(GUI或CLI方式的工具)，只要按上述代码的格式，补充相对应的驱动代码，就可实现多类型测试工具的集成化应用。

在以上所述方法的基础上，进一步可以构建融合多类型测试执行工具的自动化测试装置。

参考图3，该自动化测试装置包括如下功能模块：测试场景设置模块301、工具驱动模块302、测试数据解析模块303、测试命令字子集模块304、测试脚本集模块305、日志模块306。具体而言，各模块功能如下：

所述测试场景设置模块301，为场景用例的具体实现，由场景描述文件以及与该文件所关联的场景设置脚本所组成。其中，场景描述文件，是表现DUT特征的静态结构配置及动态业务数据的逻辑组合；场景设置脚本，完成场景描述文件下载及复制操作；运行场景用例，与场景用例所绑定的场景设置脚本自动将场景描述文件从测试用例服务器下载到测试主机本地。

所述工具驱动模块302，是这样的一个脚本逻辑组合，所述这些脚本是与测试用例所绑定的执行脚本，由它们对不同的测试工具提供统一的调用接口，用不同的运行参数来统一各测试工具执行方式的差异，实现在一个运行环境下多种测试工具的自动调用。

所述测试数据解析模块303，用于对所述测试场景设置模块提供的场景描述文件按一定的规则进行解析，提取出代表被测设备DUT被测功能的测试参数，以供测试脚本运行使用。

所述测试命令字子集模块304，由若干个测试库文件所组成，它们是一系列与DUT直接相关的被“原子化”的测试命令函数集合，所谓的“原子化”表示的是：对用户而言这样的命令不再有被分割的理由，即不可在分割，是基本的功能函数集。通过这些库文件，使得上层测试脚本可以不必关心命令本身实现的细节，将具体命令的实现逻辑和整体的测试逻辑较好地分离开来。

所述测试脚本集模块305，为测试用例的具体实现，构建于所述测试命令字子集模块所提供的命令基础之上，是直接和测试用例相对应的测试脚本集合，它们使用由所述测试数据解析模块解析出的测试输入参数，在所述工具驱动模块的运行支持下，实现对DUT的面向功能和业务的应用层的自动化测试。

所述日志模块306，为使用文本文件来记录所述测试脚本集模块中的测试脚本运行过程详细信息及最终的测试结果。

本发明主要是融合多类型测试工具，提供多测试场景自动部署的自动化测试应用方法及其装置。下面结合附图3对该自动化测试装置的具体实施方式作进一步的详细阐述。

参考图3所示的具体实施例中，该自动化测试装置分布位于测试用例管理服务器和测试主机之上，采用分布式部署，测试用例被集中管理，相应地测试脚本资源也可以被更好地分享。测试用例管理服务器和测试主机在一个局域网中，测试用例管理服务器对测试用例集以及测试结果进行存储管理，测试主机对DUT执行具体的测试行为。

参见图3，在测试用例管理服务器上部署组成本装置的若干模块包括：测试场景设置模块301，工具驱动模块302，测试命令字子集模块304，测试脚本集模块305以及日志模块306。

参见图3，在测试主机上部署组成本装置的若干模块，包括：

工具驱动模块302，测试数据解析模块303，测试命令字子集模块304，测试脚本集模块305以及日志模块306。

所述测试场景设置模块301，是由与场景用例所绑定的场景描述文件和场景设置脚本的集合所组成，在测试用例管理服务器上部署该模块，测试主机和测试用例管理服务器连接，在测试主机上运行场景用例，通过该模块就可自动将场景用例所绑定的场景描述文件下载到测试主机本地，实现本地测试场景的自动更新。

考虑到排除测试主机和测试用例管理服务器之间交互对测试脚本执行效率的影响，在测试主机本地也部署了测试脚本集模块305和测试命令字子集模块304。其中，测试脚本集模块305中的测试脚本是测试用例测试逻辑的自动化实现，测试脚本集可以根据测试内容自由地进行扩充，测试脚本并不受限于特定的测试执行工具，在本实施例中它既可以是Robot测试脚本，也可以是Tcl测试脚本，它们在本发明所述的融合多类型测试工具方法基础之上被很好地融合到一个自动化运行环境之中。

所述测试命令字子集模块304，是从测试脚本可重用的角度而对测试脚本进行分层的一种具体实现，熟悉本领域测试的技术人员都会知道，一个具体的测试用例，一般包含多个对设备或者相关仪器的操作命令，不同的测试用例中，往往也会有许多测试命令是交叉的。因此，将对设备或者相关仪器的操作命令封装为函数，将众多的函数集合构建为该模块。这样实现的好处是：当设备的某个操作命令发生变化时，只需要修改所对应的一个函数实现，而对测试脚本集模块305中与其相关联的若干个测试脚本没有影响，保证了测试脚本良好的可维护性。

由场景用例和测试用例所组合，参考图4，进一步说明本发明具体实施例中的批量自动化测试运行流程，主要包括如下步骤：

(1)首先，要判断是否需要运行场景用例；

如果在一个批量测试运行中，存在场景用例，则通过所述测试场景设置模块301中的场景设置脚本自动下载场景描述文件到测试主机本地，更新场景描述文件，如果不存在，则使用已存在于测试主机之上的当前场景描述文件作为被测场景；

(2)通过所述工具驱动模块302，运行执行脚本读取测试脚本的运行参数，自动加载所对应的测试工具执行程序；

(3)所述测试脚本集模块305中的测试脚本，在所述测试数据解析模块303以及所述测试命令字子集模块304的支持下，按提取出的测试输入参数进行运行；

(4)测试脚本运行中，由所述日志模块306记录测试脚本运行过程信息，生成测试执行日志文件；

(5)判断在该批量运行中，是否还有待运行的用例，如果有，继续执行后续的用例，重复上述步骤1-4；

步骤(5)中的用例要通过判断是否是场景用例，因为场景用例的执行和实际测试用例执行是不一样的，也就是如果不是场景用例，那么就继续在当前的场景描述所定义的测试场景下运行测试用例，如果是场景用例，则需要更新测试场景，这时测试主机本地的场景描述文件被替换掉了。这样就实现了多场景的自动切换。

在组织具体测试时，通过组合使用场景用例和测试用例，至于如何区分场景用例和测试用例，则是由场景用例和测试用例执行方式不同所决定的。场景用例执行的是所绑定的场景设置脚本，而测试用例执行的是所绑定的执行脚本和测试脚本，进一步的，场景设置脚本和执行脚本才是最终执行的载体，通过场景设置脚本将测试场景进行更新，通过执行脚本将相应的测试脚本调用起来。实际批量测试运行时，不管用例组合是怎么样的，最终都是运行用例所绑定的脚本，因此就可识别出是在执行场景用例，还是在执行测试用例。

(6)当测试脚本运行结束之后，由所述日志模块306根据运行日志文件得到测试脚本的最终执行结果，并将该结果更新到测试用例服务器之中。

Claims (9)

1.一种融合多类型测试工具的自动化测试装置，其特征在于，包括：测试场景设置模块、工具驱动模块、测试数据解析模块、测试命令字子集模块、测试脚本集模块、日志模块，其中，

所述测试场景设置模块，位于测试用例服务器上，用于存储若干与场景描述文件及场景设置脚本所绑定的场景用例集合；

所述工具驱动模块，位于测试用例服务器及测试主机上，用于存储与测试用例绑定的执行脚本集合；

所述测试数据解析模块，位于测试主机上，用于对测试场景设置模块提供的场景描述文件按一定的规则进行解析，提取代表被测设备的被测功能的测试参数，供测试脚本运行使用；

所述测试命令字子集模块，位于测试用例服务器及测试主机上，由若干个测试库文件组成，用于提供测试脚本所需的基本命令函数；

所述测试脚本集模块，位于测试用例服务器及测试主机上，用于存储构建于所述测试命令字子集模块提供的命令函数基础之上的与测试用例绑定的测试脚本，该测试脚本使用由所述测试数据解析模块解析出的测试输入参数，在所述工具驱动模块的运行支持下，对被测设备的面向功能和业务的应用层进行自动化测试；

所述日志模块，位于测试用例服务器及测试主机上，使用文本文件记录所述测试脚本集模块中的测试脚本运行过程详细信息及最终的测试结果。

2.如权利要求1所述的自动化测试装置，其特征在于，所述测试用例服务器、测试主机、被测设备位于一个可建立连接的网络中，所述测试主机与所述测试用例服务器相连，所述测试主机与被测设备相连。

3.如权利要求1所述的自动化测试装置，其特征在于，所述测试场景配置模块中的所述场景用例，包括：

场景描述文件，用于定义保存某测试场景下被测设备的物理配置结构及与具体测试内容相关的若干测试参数；

场景设置脚本，用于在运行场景用例时，自动将对应的场景描述文件从所述测试用例服务器下载到测试主机本地，并以测试主机本地的场景描述文件名更新保存于测试主机作为测试场景。

4.如权利要求1所述的自动化测试装置，其特征在于，所述工具驱动模块内的执行脚本是VBScript脚本、或Perl脚本、或C语言脚本，该执行脚本运行时，控制所述工具驱动模块根据传入的参数格式，调用支持该参数格式的测试执行工具及测试用例绑定对应的测试脚本。

5.如权利要求1所述的自动化测试装置，其特征在于，所述工具驱动模块根据传入参数不同，调用与此参数相匹配的测试工具，执行测试用例绑定的测试脚本，其中所述测试工具是图形用户接口GUI方式下的Robot测试工具，或命令行接口CLI方式下的工具命令语言Tcl工具，或基于GUI或CLI方式的第三方功能和性能测试工具。

6.如权利要求1所述的自动化测试装置，其特征在于：

所述测试脚本集模块内的测试脚本集根据测试内容可进行扩充或删减，其中所述测试脚本是Robot测试脚本、或是工具命令语言Tcl测试脚本；

所述测试场景设置模块存储的场景用例集合，根据测试需要可进行场景用例的扩充或删减。

7.一种基于权利要求1所述自动化测试装置的融合多类型测试工具的自动化测试方法，利用测试用例服务器和测试主机对被测设备进行自动化测试，其特征在于，包括如下步骤：

(1)判断是否需要运行场景用例，如果是，则与场景用例绑定的场景设置脚本下载对应的场景描述文件到测试主机本地作为被测场景，如果否，采用本地现有场景描述文件作为被测场景；

(2)测试数据解析模块对测试主机上当前的场景描述文件按一定的规则进行解析，提取代表被测设备被测功能的测试参数，供测试脚本运行使用；

(3)工具驱动模块运行与测试用例绑定的执行脚本，由执行脚本读取测试脚本运行参数，自动加载与测试脚本运行参数对应的测试工具执行程序，调用对应的测试脚本；

(4)测试脚本集模块中与测试用例绑定的测试脚本，被调用之后，根据所述测试数据解析模块提取的测试输入参数以及所述测试命令字子集模块的基本函数进行运行，对被测设备进行测试；

(5)测试脚本运行过程中，记录测试脚本运行过程信息，生成测试执行日志文件；

(6)判断是否还有待运行的场景用例或测试用例，如果有，重复上述步骤1-5，继续进行测试；

(7)测试脚本运行结束，所述日志模块根据日志文件获得测试脚本最终执行结果，并将该最终结果更新到测试用例服务器。

8.如权利要求7所述的自动化测试方法，其特征在于，步骤(3)中所述由执行脚本读取的测试脚本运行参数，包括测试脚本类型和测试脚本名称，其中所述测试脚本类型包括Robot测试脚本、或工具命令语言Tcl测试脚本。

9.如权利要求7所述的自动化测试方法，其特征在于，步骤(3)中所述测试工具是图形用户接口GUI方式下的Robot测试工具，或命令行接口CLI方式下的工具命令语言Tcl工具，或基于GUI或CLI方式的第三方功能和性能测试工具。

Images