本发明涉及自动化测试领域，具体涉及一种自动化测试控制方法、装置及终端。
背景技术：
软件测试是保证软件质量的重要手段，也是软件开发过程中的一个重要环节。图像用户界面GUI(GraphicalUserInterface)作为用户和应用程序交互的接口，是应用程序和用户信息传递的桥梁，它凭借着其灵活性以及易操作性等，为软件开发和应用都带来了极大的方便，但也正是由于其规模的日益增加，使得GUI测试工作变得异常繁重，同时故障成本的不断上涨，使得对每个版本做全面、快速的GUI测试变得十分必要。
由于GUI测试模仿用户的行为对应用程序进行操作，相对其他测试而言，具有其独特性，实行GUI测试自动化可以将测试人员从耗时而又枯燥的手工操作中解放出来，有效提高工作效率。自动化测试是把人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到及时结果与期望结果的比较，在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
在20世纪80年代中期，随着自动捕获/回放工具的出现，测试自动化开始了。第一代自动化测试，即自动化测试思想刚开始诞生时，依靠的是传统的“录制-回放”技术。这种计划与现在的自动化测试工具的“录制-回放”思想不一样，它实际上是对PC操作键盘和鼠标过程的记录和模拟，但这种机制限制颇多，若对环境的依赖性强，对变化性太多于敏感等，因此不可能发展成一种模式。第二代自动化测试，即脚本化的自动化测试，利用脚本进行结构化的自动化测试，此可以应用于CLI与API的自动化测试，主要应用模块化与库思想。第三代自动化测试，开始产生了各种自动化测试思想，其伴随着对象化思想的产生，而随之出现了一系列的自动化测试软件，如基于数据驱动思想和关键字驱动思想的测试工具。从这时候开始，自动化就开始实现了一定的规模，开始运用在各个行业，并且发展趋势越来越快。
目前，常规的自动化测试，对自动化测试工具依赖性高，在自动化测试过程中，都是利用各测试工具自身的顶层实现测试用例的调用、测试用例驱动的调用等，而不同的测试工具的顶层调用控制往往是不同的，因此目前的自动化框架的高效运转必须依赖与自动化框架有关的顶层设计，如果需要更换测试工具，则需要根据更换后的测试工具完全重新进行满足该测试工具需求的顶层设计。可见，目前的自动化测试存在对自动化测试工具的依赖性高，成本高、效率低的问题。
技术实现要素：
本发明要解决的主要技术问题是，提供一种自动化测试控制方法、装置及终端，解决现有自动化测试存在的对自动化测试工具的依赖性高，成本高、效率低的问题。
为解决上述技术问题，本发明提供一种自动化测试控制方法，包括：
设置测试工具的自动测试用例库，该自动测试用例库中包含各种自动测试用例；
获取所述测试工具当前测试工程的测试需求；
根据所述测试需求确定当前测试工程中的被测对象，并从所述自动测试用例库中选择出当前需对所述被测对象进行测试的目标自动测试用例；
获取各目标测试用例对应的各目标驱动；
通过所述各目标驱动将各目标自动测试用例导入所述测试工程对所述被测对象进行自动化测试。
在本发明的一种实施例中，设置测试工具的自动化测试用例库包括：
对应所述测试工具的手动测试用例库中的各手动测试用例分别设置自动测试用例，各自动测试用例所使用的语言为所述测试工具支持的脚本语言。
在本发明的一种实施例中，获取各目标测试用例对应的各目标驱动包括：
获取各目标测试用例对应的驱动参数；
根据各目标测试用例的驱动参数分别对所述测试工具中的通用驱动模板进行设置得到各目标测试用例的目标驱动。
在本发明的一种实施例中，所述测试工具为统一功能测试工具UFT。
在本发明的一种实施例中，设置测试工具的自动化测试用例库包括：
将所述自动化测试用例库中的各自动化测试用例的名称设置为相同，且各自动化测试用例中的入口函数名相同，并将不同的自动化测试用例存储于不同的测试目录下。
在本发明的一种实施例中，获取所述测试工具当前测试工程的测试需求包括：
获取测试人员设定的测试项目，所述测试项目中包含至少一个测试组；
从所述测试项目中获取各测试组，各测试组中包含至少一个被测对象以及各被测对象的测试用例组合；
根据所述测试用例组合从所述自动测试用例库中获取各被测对象对应的目标自动化测试用例。
为了解决上述问题，本发明还提供了一种自动化测试控制装置，包括：
测试用例设置模块，用于设置测试工具的自动测试用例库，该自动测试用例库中包含各种自动测试用例；
需求获取模块，用于获取所述测试工具当前测试工程的测试需求；
处理模块，用于根据所述测试需求确定当前测试工程中的被测对象，并从所述自动测试用例库中选择出当前需对所述被测对象进行测试的目标自动测试用例；
驱动获取模块，用于获取各目标测试用例对应的各目标驱动；
导入模块，用于通过所述各目标驱动将各目标自动测试用例导入所述测试工程对所述被测对象进行自动化测试。
在本发明的一种实施例中，所述测试用例设置模块包括创建子模块，用于对应所述测试工具的手动测试用例库中的各手动测试用例分别创建自动测试用例，各自动测试用例所使用的语言为所述测试工具支持的脚本语言。
在本发明的一种实施例中，所述驱动获取模块包括：
驱动参数获取子模块，用于获取各目标测试用例对应的驱动参数；
驱动设置模块，用于根据各目标测试用例的驱动参数分别对所述测试工具中的通用驱动模板进行设置得到各目标测试用例的目标驱动。
在本发明的一种实施例中，所述测试用例设置模块包括设置子模块和存储子模块；
所述设置子模块用于将所述自动化测试用例库中的各自动化测试用例的名称设置为相同，且将各自动化测试用例中的入口函数名相同；
所述存储子模块用于将不同的自动化测试用例存储于不同的测试目录下。
在本发明的一种实施例中，所述需求获取模块包括：
测试项目获取子模块，用于获取测试人员设定的测试项目，所述测试项目中包含至少一个测试组；
测试组获取子模块，用于从所述测试项目中获取各测试组，各测试组中包含至少一个被测对象以及各被测对象的测试用例组合；
测试用例获取子模块，用于根据所述测试用例组合从所述自动测试用例库中获取各被测对象对应的目标自动化测试用例。
为了解决上述问题，本发明还提供了一种的自动化测试控制终端，包括如上所述的自动化测试控制装置。
本发明的有益效果是：
本发明提供的自动化测试控制方法、装置及终端，先设置测试工具的包含各种自动测试用例的自动测试用例库；然后在自动测试过程中获取测试工具当前测试工程的测试需求；根据测试需求确定当前测试工程中的被测对象，并从自动测试用例库中选择出当前需对被测对象进行测试的目标自动测试用例，进而获取各目标测试用例对应的各目标驱动，然后通过各目标驱动将各目标自动测试用例导入测试工程对被测对象进行自动化测试。可见，本发明在自动化测试过程中，对于测试用例及驱动的调用等都是由独立于测试工具之外的自动化测试控制装置(也即独立于测试工具的顶层)完成，并不依赖于测试工具自身的顶层，因此当更换测试工具时，并不需要额外重新进行顶层的匹配设计，降低了对测试工具的依赖性，且能降低测试成本，提升测试效率。
附图说明
图1为本发明实施例一提供的自动化测试控制方法流程示意图；
图2为本发明实施例一提供的获取测试需求的流程示意图；
图3为本发明实施例一提供的获取目标驱动的流程示意图；
图4为本发明实施例一提供的基于UFT工具的测试流程示意图；
图5为本发明实施例二提供的自动化测试控制装置结构示意图。
具体实施方式
本发明通过设计独立于各测试工具之外的顶层结构(也即自动化测试控制装置)进行测试需求的获取、自动测试用例及驱动的调用，并不依赖各测试工具自身的顶层，因此可以降低对测试工具的依赖性，提升测试效率，降低测试成本。且本发明中的顶层可以通过python脚本编码完成，也可通过其他语言例如java等实现。下面通过具体实施方式结合附图对本发明作进一步详细说明。
实施例一：
本实施例独立于测试工具的顶层，也即自动化测试控制装置进行自动化测试控制的过程请参见图1所示，包括：
步骤101：设置测试工具的自动测试用例库，该自动测试用例库中包含各种自动测试用例；
步骤102：获取测试工具当前测试工程(也即测试任务)的测试需求；
步骤103：根据获取的测试需求确定当前测试工程中的被测对象，并从自动测试用例库中选择出当前需对被测对象进行测试的目标自动测试用例；
步骤104：获取各目标测试用例对应的各目标驱动；
步骤105：通过各目标驱动将各目标自动测试用例导入测试工程对被测对象进行自动化测试。
以上测试过程测试需求的获取、测试用例及驱动的调用过程都不依赖测试工具自身的顶层控制，而全部由独立于测试工具的自动化测试控制装置实现，该自动化测试控制装置对于不同的测试工具都可通过上述过程实现顶层控制，因此可降低自动测试对测试工具的依赖性，提升测试效率并降低测试成本。
上述步骤101中，设置测试工具的自动化测试用例库时，为了便于测试人员的后续验证，对应测试工具的手动测试用例库中的各手动测试用例分别设置自动测试用例，各自动测试用例所使用的语言为所述测试工具支持的脚本语言(例如测试工具为UFT时，采用的脚本语言为vbs)。自动测试用例与各手动测试用例对应设置，这样测试人员即可用一套统一的验证规则进行后续验证。具体的，本实施例中可以要求各自动测试利用与各手动测试用例的编号一一对应。
另外，现有自动化测试过程中，各测试工具的一个测试用例对应一个测试工程，也即在一个测试工程中只能调用一个测试用例，导致测试时需调用的接口以及各种数据繁多、开销大、效率低且易出错。为此，本实施例在设置测试工具的自动化测试用例库时，将自动化测试用例库中的各自动化测试用例的名称设置为相同，例如都设置为tcf.vbs(当然根据不同测试工具的需求该名称可以灵活设置)且将各自动化测试用例中的入口函数名相同，例如testcase，该入口函数为唯一入口函数，然后将不同的自动化测试用例存储于不同的测试目录下，这样就能通过不同的测试目录区分并调用不同的测试用例。而针对不同的测试用例的名称及入口函数相同，因此一个测试工程可以通过一个文件名和一个入口函数实现对不同测试用例的调用。因此不用对应每一个测试用例对应一个测试工程，可大大减少产生的接口及其他数据，降低开销，提升测试效率和准确率。
本实施例中，为了便于测试人员灵活的设置测试需求，可提供三层结构，从上往下依次为测试项目层(TPF)、测试组层(TGF)以及测试用例层(TCF)：
测试项目层供测试人员设计测试项目，一个测试项目中可包含一个或多个测试组，具体包含的测试组的个数以及各测试组之间的关系可以根据当前的实际测试需求灵活设定。例如可以设置为仅包含一个测试组，也可设置多包含两个或两个以上的测试组，且各测试组之间可以相互独立无关联关系，也可以具有一定的关联关系。测试人员在测试项目中列出需要进行的测试组即可；
测试组层用于分析测试项目中的各测试组，一个测试组中可能包含一个或多个组件，此时则这些组件被划分到一个测试组中极性测试，一个组件则可能包含一个或多个模块；一个测试组中也可能直接包含一个或多个模块。测试组中包含的组件或模块也即为被测对象。应当理解的是，测试组中组件和模块的选择也是根据当前实际需求而定的，而针对各被测对象的自动测试用例的选择则根据对各被测对象的测试目的灵活选择组合。针对一个被测对象可能进选择一个测试用例，也可能选用多个测试用例。测试人员需要在各测试组中列出待测的被测组件或模块以及对应的测试用例即可。
测试用例层即用于根据各测试组中的各被测对象的各测试用例组合，从测试工具的自动化测试用例库中，根据不同的测试目录选择出所需的对应的目标测试用例。且所选择的各个目标测试用例可供一个测试工程调用。
基于上述设置，上述步骤102中获取测试工具当前测试工程的测试需求请参见图2所示，包括：
步骤201：获取测试人员设定的测试项目，测试项目中包含至少一个测试组；
步骤202：从所测试项目中获取各测试组，各测试组中包含至少一个被测对象以及各被测对象的测试用例组合；该组合可能仅包含1个测试用例，也可能包含多个测试用例；
步骤203：根据所述测试用例组合从所述自动测试用例库中获取各被测对象对应的目标自动化测试用例。
上述步骤104中，获取各目标测试用例对应的各目标驱动的过程请参见图3所示，包括：
步骤301：获取各目标测试用例对应的驱动参数；
不同目标测试用例的驱动参数可能会存在一些公用的驱动参数，且各测试用例中也可能存在自己独立的驱动参数，且这部分驱动参数中也可能存在一个或多个驱动参数需根据当前的测试参数通过各种算法获得；
步骤302：根据各目标测试用例的驱动参数分别对测试工具中的通用驱动模板进行设置得到各目标测试用例的目标驱动。
本实施例中是以在通用驱动模块的基础上对应各测试用例的驱动参数分别进行设置得到各测试用例的目标驱动。但应当理解的是本实施例中也可以分别对应不同的测试用例独立设置对应的专用驱动。
本实施例中的测试工具可以为各种测试工具，例如可以为统一功能测试工具UFT(unitedfunctiontesting)，也可以为WinRunnerMercury、Rational、AdventNet、SilkTest等测试工具。为了更好的理解本发明，下面以测试工具UFT为例进行示例说明。
自动化测试工具UFT有两个特点：一是，仅支持windows系统；二是，UFT支持的脚本语言为vbs，因此其自动阿测试脚本用例的脚本语言为vbs，而vbs也是仅支持windows系统的。测试系统中若完全使用UFT自己的vbs脚本实现自动测试系统测试的顶层脚本，则有两个不足：一是，UFT顶层脚本对UFT依赖性非常高；二是顶层脚本完全不能在linux中继续使用。所以，若另外需在linux系统中也实现GUI自动化测试时，首先是选用另外的自动化测试工具，然后再依照测试工具特点，另外全新开发自动化测试顶层脚本。而本实施例中设置独立于测试工具的顶层时可以选择兼容尽可能多系统的脚本语言，能进一步降低对测试工具的依赖程度。此时仍以使用python实现自动化测试顶层脚本为例进行说明。此时的测试过程如下：
框架核心目录结构如下：
|----GUI
|----auto_driver
自动化核心脚本程序
|----TPF(如readTpf.py、autoGui.tpf)
测试项目，按项目执行测试系统，为测试人员输入
|----TGF(如readTgf.py,FAB.tgf、CFG.tgf、…)
按组件执行测试系统，从TPF中分析获取，且该组件可能直接为模块
|----driver.vbs
通用驱动脚本模板，统一管控执行UFT的配置及脚本等
|----auto_uftpro
UFT源工程文件(使用默认设置)
|----com_bench
自动化及手动测试用例
|----soft(如FAB、CFG、…)
组件级别的测试模块
|----module(如A1_MAI、A2_BIT、…)组件下的模块测试
|----auto_object
自动化对象库，仅包含对象库文件，该模块共用
|----object.tsr
对象库文件
|----auto_project
存放自动化所需的工程文件
|----impl.prj、back_impl.prj，…
自动化测试工程文件,其中impl.prj和back_impl.prj的内容完全一样，为初始工程文件
|----auto_testcase
存放测试用例
|----a_5、…
测试用例编号(文件夹，也即用例存储的测试目录)
|----tcf.vbs，…
目标测试用例脚本等文件，测试用例脚本固定为文件名tcf.vbs，同时文件中的函数名固定为testcase，且为唯一入口函数。
|----auto_testdata
存放测试数据，该测试数据测试人员可以通过顶层结构输入，也可以通过测试工具提供的接口输入；
|----…
测试数据文件(如testdtat.xlsx)
|----auto_uftpro
UFT工程文件夹，主要用于按模块调试测试用例脚本，特别是在对象库中删除或修改对象(注：关联对象库，具有只读属性)
|----sourcefiles
测试资源文件(包括手动测试及自动测试时被测对象运行所需的资源文件)
|----common
公共资源文件(该模块下几乎所有测试用例均需使用)
|----file1、file2、…
单独资源文件(该模块下个别测试用例需使用)
|----[A1]主控界面测试用例.xlsx
手动测试用例(手动测试用例编号应与自动化测试用例编号对应)
|----auto_result
自动化测试结果文件夹(注：未执行脚本时无此文件夹)
|----soft(如FAB、CFG、…)
组件级别的测试模块
|----uftpro
UFT工程文件，在统一UFT工程下串行执行测试用例(仅保留最后一个测试用例的结果)
|----module_driver.vbs(如A1_MAI_driver.vbs)
软件下的各测试模块驱动程序(模块级别)
|----module_report.txt(如A1_MAI_report.txt)
软件下的各测试模块测试结果(模块级别)
对于以上测试过程中：
1.对无子测试模块的CFG、INS、DBG和SVR等组件(也即该组件下就一个模块)，上述结构中module＝soft，仅出现soft文件夹；
2.对有子测试模块的FAB组件，上述结构中module！＝soft，soft和module文件夹均存在。
3.在编写测试用例时，仅需编辑TCF即可(tcf.vbs)，但需注意的是文件中的函数名固定为testcase，且为唯一入口函数。具体如下：
PublicFunctiontestcase
'TODO:addfunctionbodyhere
EndFunction
以上框架执行简而言之分为以下三步：
1.正确配置TPF或TGF文件；
2.使用python脚本(也即顶层)运行对应的TPF或TGF文件；
3.在生成的组件结果文件夹下的报告文件中查看结果。若发现错误，需对错误结果进行手动测试确认或进行其他处理。具体运行过程请参见图4所示，包括：
步骤401：依次运行TPF、TGF、TCF；
步骤402：运行对应的驱动；
步骤403：运行得到的目标测试用例；
步骤404：得出并保存结果；
步骤405：对得到的结果进行分类统计并分析。
实施例二：
本实施例中的自动化测试控制终端可以是各种PC，该终端内包含自动化测试系统，该自动化测试系统则包含测试工具和独立于该测试工具的自动化测试控制装置。本实施例中的自动化测试控制装置可以自行现有各测试工具的顶层控制的各种功能，且该自动化测试控制装置可以选用通用性较好的脚本语言实现，例如python脚本语言。具体的，请参见图5所示，本实施例中的自动化测试控制装置包括：
测试用例设置模块，用于设置测试工具的自动测试用例库，该自动测试用例库中包含各种自动测试用例；
需求获取模块，用于获取测试工具当前测试工程的测试需求；
处理模块，用于根据测试需求确定当前测试工程中的被测对象，并从自动测试用例库中选择出当前需对所述被测对象进行测试的目标自动测试用例；
驱动获取模块，用于获取各目标测试用例对应的各目标驱动；
导入模块，用于通过各目标驱动将各目标自动测试用例导入所述测试工程对被测对象进行自动化测试。
以上测试过程都是通过自动化测试控制装置完成测试需求的获取、测试用例及驱动的调用，都不依赖测试工具自身的顶层控制，该自动化测试控制装置对于不同的测试工具都可通过上述过程实现顶层控制，因此可降低自动测试对测试工具的依赖性，提升测试效率并降低测试成本。
本实施例中的测试用例设置模块包括创建子模块、设置子模块和存储子模块
创建子模块用于对应测试工具的手动测试用例库中的各手动测试用例分别创建自动测试用例，各自动测试用例所使用的语言为所述测试工具支持的脚本语言(例如测试工具为UFT时，采用的脚本语言为vbs)。自动测试用例与各手动测试用例对应设置，这样测试人员即可用一套统一的验证规则进行后续验证。具体的，本实施例中可以要求各自动测试利用与各手动测试用例的编号一一对应。
另外，现有自动化测试过程中，各测试工具的一个测试用例对应一个测试工程，也即在一个测试工程中只能调用一个测试用例，导致测试时需调用的接口以及各种数据繁多、开销大、效率低且易出错。为此，本实施例中的设置子模块用于将自动化测试用例库中的各自动化测试用例的名称设置为相同，且将各自动化测试用例中的入口函数名相同；存储子模块用于将不同的自动化测试用例存储于不同的测试目录下。将自动化测试用例库中的各自动化测试用例的名称设置为相同，例如都设置为tcf.vbs(当然根据不同测试工具的需求该名称可以灵活设置)且将各自动化测试用例中的入口函数名相同，例如testcase，该入口函数为唯一入口函数，然后将不同的自动化测试用例存储于不同的测试目录下，这样就能通过不同的测试目录区分并调用不同的测试用例。而针对不同的测试用例的名称及入口函数相同，因此一个测试工程可以通过一个文件名和一个入口函数实现对不同测试用例的调用。因此不用对应每一个测试用例对应一个测试工程，可大大减少产生的接口及其他数据，降低开销，提升测试效率和准确率。
为了便于测试人员灵活的设置测试需求，可提供三层结构，从上往下依次为测试项目层(TPF)、测试组层(TGF)以及测试用例层(TCF)：
测试项目层供测试人员设计测试项目，一个测试项目中可包含一个或多个测试组，具体包含的测试组的个数以及各测试组之间的关系可以根据当前的实际测试需求灵活设定。
测试组层用于分析测试项目中的各测试组，一个测试组中可能包含一个或多个组件，此时则这些组件被划分到一个测试组中极性测试，一个组件则可能包含一个或多个模块；一个测试组中也可能直接包含一个或多个模块。测试组中包含的组件或模块也即为被测对象。
测试用例层即用于根据各测试组中的各被测对象的各测试用例组合，从测试工具的自动化测试用例库中，根据不同的测试目录选择出所需的对应的目标测试用例。且所选择的各个目标测试用例可供一个测试工程调用。
对应上述三层结构，本实施例中的需求获取模块包括：
测试项目获取子模块，用于获取测试人员设定的测试项目，所述测试项目中包含至少一个测试组；
测试组获取子模块，用于从测试项目中获取各测试组，各测试组中包含至少一个被测对象以及各被测对象的测试用例组合；该组合可能仅包含1个测试用例，也可能包含多个测试用例；
测试用例获取子模块，用于根据测试用例组合从所述自动测试用例库中获取各被测对象对应的自动化测试用例。
本实施例中的驱动获取模块包括：
驱动参数获取子模块，用于获取各目标测试用例对应的驱动参数；
不同目标测试用例的驱动参数可能会存在一些公用的驱动参数，且各测试用例中也可能存在自己独立的驱动参数，且这部分驱动参数中也可能存在一个或多个驱动参数需根据当前的测试参数通过各种算法获得；
驱动设置模块，用于根据各目标测试用例的驱动参数分别对测试工具中的通用驱动模板进行设置得到各目标测试用例的目标驱动。本实施例中是以在通用驱动模块的基础上对应各测试用例的驱动参数分别进行设置得到各测试用例的目标驱动。但应当理解的是本实施例中也可以分别对应不同的测试用例独立设置对应的专用驱动。
本实施例中的测试工具可以为各种测试工具，例如可以为统一功能测试工具UFT(unitedfunctiontesting)，也可以为WinRunnerMercury、Rational、AdventNet、SilkTest等测试工具。
显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。