CN107766226A

CN107766226A - 一种测试方法及装置

Info

Publication number: CN107766226A
Application number: CN201610683076.8A
Authority: CN
Inventors: 焦忠彬
Original assignee: Beijing Kingsoft Cloud Network Technology Co Ltd; Beijing Kingsoft Cloud Technology Co Ltd
Current assignee: Beijing Kingsoft Cloud Network Technology Co Ltd; Beijing Kingsoft Cloud Technology Co Ltd
Priority date: 2016-08-18
Filing date: 2016-08-18
Publication date: 2018-03-06
Anticipated expiration: 2036-08-18
Also published as: CN107766226B

Abstract

本发明实施例公开了一种测试方法及装置，该方法包括：接收针对目标程序的测试指令，其中，所述测试指令中包含针对所述目标程序的测试用例；集成所述测试用例对应的配置文件；确定所述测试用例对应的目标控件；根据所述测试用例，修改所述目标控件的参数；根据修改参数后的所述目标控件，生成所述测试用例对应的测试脚本；执行所述测试脚本，测试所述目标程序。应用本发明实施例，可以减少编写测试脚本的时间，提高测试效率。

Description

一种测试方法及装置

技术领域

本发明涉及测试技术领域，特别涉及一种测试方法及装置。

背景技术

现有技术中，对于软件的自动化测试，无论是单元测试还是集成测试，都可以基于测试用例，利用自动化测试工具完成。

其中，测试用例(TestCase)，是一种文档，用于描述输入、执行条件以及预期结果等，其可以被编译为可执行代码，可执行代码也就是测试脚本。针对软件测试用例而言，其基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤和预期结果。执行测试用例的目的在于，核实某个程序(比如软件的单元，或者由单元组成的集成系统)是否满足特定需求。

在确定了测试用例、进行自动化测试之前，还需要根据确定的测试用例编写对应的测试脚本。目前，测试脚本中的全部代码都是由测试人员手工编写的，而手工编写测试脚本通常会花费测试人员大量的时间，测试效率较低，并且随着技术的不断革新，业务量的不断增长，手工编写测试脚本的方式已经不能满足当下的业务需求与发展。

发明内容

本发明实施例的目的在于提供一种测试方法及装置，以减少编写测试脚本的时间，提高测试效率。

为达到上述目的，本发明实施例公开了一种测试方法，所述方法包括：

接收针对目标程序的测试指令，其中，所述测试指令中包含针对所述目标程序的测试用例；

集成所述测试用例对应的配置文件；

确定所述测试用例对应的目标控件；

根据所述测试用例，修改所述目标控件的参数；

根据修改参数后的所述目标控件，生成所述测试用例对应的测试脚本；

执行所述测试脚本，测试所述目标程序。

优选的，在所述接收针对目标程序的测试指令之前，还包括：

获得与程序的页面元素对应的原始通用控件；

从通用API接口库中获得所述原始通用控件所需要挂接的API接口；

将所获得的API接口挂接到所述原始通用控件上，得到通用控件，并集成所述通用控件。

优选的，所述确定所述测试用例对应的目标控件，包括：

判断已集成的通用控件中是否有所述测试用例对应的目标控件；

如果是，从已集成的通用控件中，确定所述测试用例对应的目标控件；

否则，获得所述目标程序的页面元素对应的原始业务控件；

判断所述原始业务控件需要挂接的API接口是否为通用API接口；

如果所述原始业务控件需要挂接的API接口是通用API接口，从所述通用API接口库中获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件，并集成所述业务控件；

如果所述原始业务控件需要挂接的API接口不是通用API接口，根据用户输入的API接口信息，获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件，并集成所述业务控件；

将所述业务控件确定为所述测试用例对应的目标控件。

优选的，所述方法还包括：

利用已集成的版本控制工具，确定所述测试用例对应的测试脚本的版本信息；

根据所述版本信息，生成所述测试脚本。

优选的，所述确定所述测试用例对应的目标控件，包括：

利用所述目标控件对应控件类型的快捷键，获得所述控件类型对应的所有控件的信息；

根据所获得的信息，确定所述测试用例对应的目标控件。

优选的，在所述执行所述测试脚本，测试所述目标程序之后，还包括：

获得测试结果。

优选的，所述测试用例包括预期结果，在所述获得测试结果之后，还包括：

判断所述测试结果与所述预期结果是否匹配；

如果是，判定所述测试用例测试通过，否则，判定所述测试用例测试不通过。

生成测试日志。

为达到上述目的，本发明实施例还公开了一种测试装置，所述装置包括：

接收模块，用于接收针对目标程序的测试指令，其中，所述测试指令中包含针对目标程序的测试用例；

第一集成模块，用于集成所述测试用例对应的配置文件；

第一确定模块，用于确定所述测试用例对应的目标控件；

修改模块，用于根据所述测试用例，修改所述目标控件的参数；

第一生成模块，用于根据修改参数后的所述目标控件，生成所述测试用例对应的测试脚本；

测试模块，用于执行所述测试脚本，测试所述目标程序。

优选的，在所述接收模块接收针对目标程序的测试指令之前，还包括：

第一获得模块，用于获得与程序的页面元素对应的原始通用控件；

第二获得模块，用于从通用API接口库中获得所述原始通用控件所需要挂接的API接口；

第二集成模块，用于将所获得的API接口挂接到所述原始通用控件上，得到通用控件，并集成所述通用控件。

优选的，所述第一确定模块，包括：

第一判断子模块，用于判断已集成的通用控件中是否有所述测试用例对应的目标控件；

第一确定子模块，用于在判断出已集成的通用控件中有所述测试用例对应的目标控件时，从已集成的通用控件中，确定所述测试用例对应的目标控件；

第一获得子模块，用于在判断出已集成的通用控件中没有所述测试用例对应的目标控件时，获得所述目标程序的页面元素对应的原始业务控件；

第二判断子模块，用于判断所述原始业务控件需要挂接的API接口是否为通用API接口；

第一集成子模块，用于在判断出所述原始业务控件需要挂接的API接口是通用API接口时，从所述通用API接口库中获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件；

第二集成子模块，用于在判断出所述原始业务控件需要挂接的API接口不是通用API接口时，根据用户输入的API接口信息，获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件；

第二确定子模块，用于将所述业务控件确定为所述测试用例对应的目标控件。

优选的，所述装置还包括：

第二确定模块，用于利用已集成的版本控制工具，确定所述测试用例对应的测试脚本的版本信息；

第二生成模块，用于根据所述版本信息，生成所述测试脚本。

优选的，所述第一确定模块，包括：

第二获得子模块，用于利用所述目标控件对应控件类型的快捷键，获得所述控件类型对应的所有控件的信息；

第三确定子模块，用于根据所获得的信息，确定所述测试用例对应的目标控件。

优选的，在所述测试模块执行所述测试脚本，测试所述目标程序之后，还包括：

第三获得模块，用于获得测试结果。

优选的，所述测试用例包括预期结果，在所述第三获得模块获得测试结果之后，还包括：

判断模块，用于判断所述测试结果与所述预期结果是否匹配；如果是，判定所述测试用例测试通过，否则，判定所述测试用例测试不通过。

第三生成模块，用于生成测试日志。

由以上可见，本发明实施例提供的方案中，在接收到针对目标程序的测试指令后，集成该测试指令中的测试用例对应的配置文件，确定该测试用例对应的目标控件，根据测试用例修改目标控件的参数，根据修改参数后的目标控件生成该测试用例对应的测试脚本，执行测试脚本即可测试目标程序。与现有技术相比，根据目标程序的测试用例确定目标控件后，修改目标控件的相关参数即可生成测试用例，不需要测试人员根据目标程序的测试用例手工编写测试脚本，可以减少编写测试脚本的时间，提高测试效率；进一步的，该方案不需要测试人员手工编写测试脚本，降低了对测试人员的技能要求，避免了复杂繁琐的培训流程。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种测试方法的流程示意图；

图2为图1所示实施例中确定测试用例对应的目标控件的方法的流程示意图；

图3为本发明实施例提供的一种测试装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为解决现有技术问题，本发明实施例提供了一种测试方法及装置。下面首先通过具体实施例，对本发明实施例所提供的一种测试方法进行详细说明。

需要说明的是，本发明实施例提供的测试方法的执行主体可以是具有测试功能的客户端，可以理解的，具有测试功能的客户端也可以称为测试工具，该测试工具可以是基于IDE(Integrated Development Environmen，集成开发环境)开发的，也可以是基于其他方式开发的，本申请对此不做限定。

图1为本发明实施例提供的一种测试方法的流程示意图，该方法包括：

S101，接收针对目标程序的测试指令。

其中，测试指令中包含针对目标程序的测试用例。

可以理解的，测试用例中可以包含：目标程序名称、目标程序版本、测试用例名称、测试用例编号、功能模块名称、测试功能点、测试目的、预置条件、测试步骤、预期结果等信息，当然，测试用例中还可以包含其他信息，本申请对此不做限定。

实际应用中，在步骤S101接收针对目标程序的测试指令之前，还需要封装并集成程序的页面元素对应的通用控件，以便于直接从已集成的通用控件中获得目标程序的测试用例所需的控件，提高编写测试脚本的速度，提高测试效率。

具体的，测试工具封装并集成通用控件的过程为：获得与程序的页面元素对应的原始通用控件，从通用API接口库中获得原始通用控件所需要挂接的API接口，将所获得的API接口挂接到原始通用控件上，得到通用控件，并集成通用控件。

其中，程序的页面元素包括程序对应的页面中的文字、图片、输入框、按钮、链接等，例如对于浏览器来说，登录按钮、返回按钮、最大化按钮、刷新按钮等都是浏览器对应的页面元素。可以理解的是，对于所有的程序而言，在编写测试脚本时，这些相同的页面元素所对应的测试脚本中的代码是相同的。因此，可以将相同的页面元素所对应的测试脚本中的代码进行封装成为控件，以使得所有包含相同页面元素的程序都可以直接使用封装好的控件，而不必每次都重新编写这部分代码，减轻测试人员编写测试脚本的工作量。

上述通用控件仅是说明该控件的类型，表示该控件对于所有的程序都是通用的，例如登录控件、退出控件、点击控件、双击控件等。同样的，下述的业务控件表示该控件不是对所有的程序通用，而是仅对某一程序或多个特定的程序适用。

上述通用API接口仅是说明该API接口的类型，表示该API接口对于所有的程序都是通用的，例如元素的获取、元素的定位、元素的绑定事件等API接口，通用API接口库中保存了通用API接口。

本领域技术人员可以理解的是，原始控件和API接口实质上是以代码的形式存在的，将API接口挂接到原始控件上，可以理解为：将API接口对应的代码嵌入到原始控件对应的代码中，得到可以实现特定功能的控件，即控件是基于API接口生成的。

S102，集成测试用例对应的配置文件。

可以理解的，目标程序可以包含多个功能模块，而每个功能模块还可以包含多个功能，也就是说，目标程序包含多个功能，而一个测试用例只是用于测试目标程序的多个功能中的一个功能。对于目标程序的一个测试用例，在生成对应的测试脚本之前，还需要集成该测试用例对应的配置文件，配置文件是针对目标程序的所有测试用例之间的公共设置，例如全局域名、登录用户信息、用户授权信息等配置信息，根据配置信息生成测试用例对应的配置文件。

可以理解的，在对目标程序的所有功能进行测试时，可以将目标程序作为一个测试项目，目标程序的每个功能模块作为一个测试套件，每个功能模块的每个功能作为一个测试用例，也就是说，一个测试项目是同属目标程序的一组测试套件的集合，一个测试套件是同属一个功能模块的一组测试用例的集合。此时，配置文件可以分为全局配置文件和元素配置文件，其中，全局配置文件为针对一个测试项目中的所有测试套件之间的公共设置，而元素配置文件为针对一个测试套件中的所有测试用例之间的公共设置。这样，一个测试用例可以通过继承测试项目的全局配置文件和测试套件的元素配置文件，来获得该测试用例的配置文件。

S103，确定测试用例对应的目标控件。

可以理解的，测试用例中的测试步骤表示测试该测试用例所针对的功能的具体流程。流程中的每一步骤对应一个控件，确定测试用例的每一步骤对应的目标控件，将确定的目标控件按照流程顺序添加到流程列表中。每一个控件实质上是一段代码，后续根据流程列表中的目标控件生成测试脚本，该测试脚本实质上是根据流程列表中的目标控件所对应的代码按照顺序叠加得到的。

将确定的控件按照流程顺序添加到流程列表，可以是在接收到用户双击该控件的添加指令后，将该控件按照流程顺序添加到流程列表，也可以是在接收到用户拖拽该控件的添加指令后，将该控件按照流程顺序添加到流程列表。

在本发明实施例中，上述确定测试用例对应的目标控件，如图2所示，可以包括以下步骤：

S1031、判断已集成的通用控件中是否有测试用例对应的目标控件；如果是，执行S1032，否则，执行S1033；

S1032、从已集成的通用控件中，确定测试用例对应的目标控件；

S1033、获得目标程序的页面元素对应的原始业务控件；

S1034、判断原始业务控件需要挂接的API接口是否为通用API接口；如果是，执行S1035，否则，执行S1036；

S1035、从通用API接口库中获得该API接口，将该API接口挂接到原始业务控件上，得到业务控件，并集成业务控件；

S1036、根据用户输入的API接口信息，获得该API接口，将该API接口挂接到原始业务控件上，得到业务控件，并集成业务控件；

S1037、将业务控件确定为测试用例对应的目标控件。

可以理解的，已集成的通用控件中只是程序中通用的控件，并不能涵盖所有程序中所需要的控件。当测试用例对应的某一个目标控件不属于通用控件时，此时该目标控件也可以称为业务控件。业务控件表示针对于目标程序的具体业务而生成的控件。

可以理解的，原始业务控件需要挂接API接口后才可以生成业务控件。如果需要挂接的API接口不属于通用API接口，则需要用户输入需要挂接的API接口的信息，根据用户输入的API信息获得该API接口。这种根据用户输入的API信息所获得的API接口，也可以称为扩展API接口。

可以理解的，在获得扩展API接口后，也可以将该API接口作为通用API接口保存到通用API接口库中，以便于在后续测试其他项目时可以直接获得该API接口。

在本发明实施例的一种优选的实施方式中，该方法还可以包括：

根据所获得的信息，确定所述测试用例对应的目标控件。

可以理解的，已集成的控件有很多种，为便于查找，可以将已集成的控件进行分类。例如，与浏览器相关的控件分为一类、与web页面中的元素相关的控件分为一类等，对每一类型的控件的集合设置快捷键，当目标控件为浏览器相关的控件时，利用浏览器相关的控件的控件类型所对应的快捷键，快速查找到所有与浏览器相关的控件的信息，然后从中选择出所需要的目标控件，进一步地提高了生成测试脚本的速度。

当然，还可以根据其他方式对已集成的控件进行分类并设置快捷键，本申请并不对此进行限制。

S104，根据测试用例，修改目标控件的参数。

S105，根据修改参数后的目标控件，生成测试用例对应的测试脚本。

可以理解的，不同的测试用例所要测试的内容是不一样的，测试所基于的参数也是不一样的，因此，需要根据测试用例，对目标控件的相关参数进行修改，以适应该测试用例的要求。

在一种优选实施方式中，该方法还可包括：

利用已集成的版本控制工具，确定测试用例对应的测试脚本的版本信息；

根据版本信息，生成测试脚本。

其中，版本控制工具可以为SVN(Subversion)、GIT等，SVN为一种集中式版本控制工具，GIT为一种分布式版本控制工具。测试工具集成版本控制工具后，可以允许多个测试人员同时对一个测试用例生成不同版本的测试脚本。

S106，执行测试脚本，测试目标程序。

在一种优选的实施方式中，在执行测试脚本，测试目标程序之后，还可以包括：获得测试结果。

实际应用中，测试用例中还可以包括对测试的预期结果，在获得测试结果之后，还可以判断测试结果与预期结果是否匹配；如果是，判定该测试用例测试通过，否则，判定该测试用例测试不通过。

在另一种优选的实施方式中，在执行所述测试脚本，测试目标程序之后，还可以生成测试日志，以记录测试过程中的数据，测试日志中可以包含目标程序的标识信息、测试用例的标识信息、测试脚本的生成时间、执行测试的测试人员的信息、测试结果信息等。测试日志可以直接显示在测试工具中，使测试人员直观的了解测试过程和测试结果，进一步的，还可以将测试日志保存在日志库中，便于日常维护。

由以上可见，本发明实施例提供的方案中，在接收到针对目标程序的测试指令后，集成该测试指令中的测试用例对应的配置文件，确定该测试用例对应的目标控件，根据测试用例修改目标控件的参数，根据修改参数后的目标控件生成该测试用例对应的测试脚本，执行测试脚本即可测试目标程序。与现有技术相比，根据目标程序的测试用例确定目标控件后，修改目标控件的相关参数即可生成测试用例，不需要测试人员根据目标程序的测试用例手工编写测试脚本，可以减少编写测试脚本的时间，提高测试效率，降低测试成本；进一步的，该方案不需要测试人员手工编写测试脚本，降低了对测试人员的技能要求，避免了复杂繁琐的培训流程。

下面以一个具体实施例对本发明实施例所提供的测试方法进行说明。

表1为针对目标程序的一个测试用例。

表1

根据表1可知，将目标程序“互联互通网关”作为一个测试项目，则该测试项目的其中一个测试套件为“管理网页”，在测试套件“管理网页”下的一个测试用例为“非法用户登录管理网页”，测试用例编号为TC000002。

对于测试用例TC000002，对应的配置文件有全局域名、登录用户信息、登录界面地址信息等。首先集成测试用例TC000002对应的配置文件：全局域名(www.xxx.com)、和登录信息(登录用户名为admin、登录密码为test)、登录界面地址信息(www.xxx.com/login)等。

对于测试步骤中的5个步骤，分别对应不同的控件，表2为上述测试用例对应的流程列表，包含确定的目标控件以及根据测试用例修改目标控件的参数信息。在测试工具中，基于表2所示的控件，即可生成测试用例TC000002对应的测试脚本。

表2

由该具体实施例可知，本方案只需要根据目标程序的测试用例确定目标控件，修改目标控件的相关参数即可生成测试用例，不需要测试人员根据目标程序的测试用例手工编写测试脚本，可以减少编写测试脚本的时间，提高测试效率，降低测试成本；同时，由于该方案不需要测试人员手工编写测试脚本，因此对测试人员的技能要求较低，不需要对测试人员进行复杂繁琐的培训。

与上述的测试方法相对应，本发明实施例还提供了一种测试装置。

与图1所示的方法实施例相对应，图3为本发明实施例提供的测试装置的结构示意图，该装置可以包括：

接收模块301，用于接收针对目标程序的测试指令，其中，所述测试指令中包含针对目标程序的测试用例；

第一集成模块302，用于集成所述测试用例对应的配置文件；

第一确定模块303，用于确定所述测试用例对应的目标控件；

修改模块304，用于根据所述测试用例，修改所述目标控件的参数；

第一生成模块305，用于根据修改参数后的所述目标控件，生成所述测试用例对应的测试脚本；

测试模块306，用于执行所述测试脚本，测试所述目标程序。

在实际应用中，在所述接收模块301接收针对目标程序的测试指令之前，该装置还可以包括：

第一获得模块(图中未示出)，用于获得与程序的页面元素对应的原始通用控件；

第二获得模块(图中未示出)，用于从通用API接口库中获得所述原始通用控件所需要挂接的API接口；

第二集成模块(图中未示出)，用于将所获得的API接口挂接到所述原始通用控件上，得到通用控件，并集成所述通用控件。

在实际应用中，所述第一确定模块303，可以包括：

第一判断子模块(图中未示出)，用于判断已集成的通用控件中是否有所述测试用例对应的目标控件；

第一确定子模块(图中未示出)，用于在判断出已集成的通用控件中有所述测试用例对应的目标控件时，从已集成的通用控件中，确定所述测试用例对应的目标控件；

第一获得子模块(图中未示出)，用于在判断出已集成的通用控件中没有所述测试用例对应的目标控件时，获得所述目标程序的页面元素对应的原始业务控件；

第二判断子模块(图中未示出)，用于判断所述原始业务控件需要挂接的API接口是否为通用API接口；

第一集成子模块(图中未示出)，用于在判断出所述原始业务控件需要挂接的API接口是通用API接口时，从所述通用API接口库中获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件；

第二集成子模块(图中未示出)，用于在判断出所述原始业务控件需要挂接的API接口不是通用API接口时，根据用户输入的API接口信息，获得所述API接口，将所述API接口挂接到所述原始业务控件上，得到业务控件；

第二确定子模块(图中未示出)，用于将所述业务控件确定为所述测试用例对应的目标控件。

在实际应用中，该装置还可以包括：

第二确定模块(图中未示出)，用于利用已集成的版本控制工具，确定所述测试用例对应的测试脚本的版本信息；

第二生成模块(图中未示出)，用于根据所述版本信息，生成所述测试脚本。

在实际应用中，所述第一确定模块303，可以包括：

第二获得子模块(图中未示出)，用于利用所述目标控件对应控件类型的快捷键，获得所述控件类型对应的所有控件的信息；

第三确定子模块(图中未示出)，用于根据所获得的信息，确定所述测试用例对应的目标控件。

在实际应用中，在所述测试模块306执行所述测试脚本，测试所述目标程序之后，该装置还可以包括：

第三获得模块(图中未示出)，用于获得测试结果。

在实际应用中，所述测试用例包括预期结果，在所述第三获得模块获得测试结果之后，该装置还可以包括：

判断模块(图中未示出)，用于判断所述测试结果与所述预期结果是否匹配；如果是，判定所述测试用例测试通过，否则，判定所述测试用例测试不通过。

第三生成模块(图中未示出)，用于生成测试日志。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机可读取存储介质中，这里所称得的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims

1.一种测试方法，其特征在于，所述方法包括：

集成所述测试用例对应的配置文件；

确定所述测试用例对应的目标控件；

根据所述测试用例，修改所述目标控件的参数；

执行所述测试脚本，测试所述目标程序。

2.根据权利要求1所述的方法，其特征在于，在所述接收针对目标程序的测试指令之前，还包括：

获得与程序的页面元素对应的原始通用控件；

3.根据权利要求2所述的方法，其特征在于，所述确定所述测试用例对应的目标控件，包括：

否则，获得所述目标程序的页面元素对应的原始业务控件；

将所述业务控件确定为所述测试用例对应的目标控件。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据所述版本信息，生成所述测试脚本。

5.根据权利要求1所述的方法，其特征在于，所述确定所述测试用例对应的目标控件，包括：

根据所获得的信息，确定所述测试用例对应的目标控件。

6.根据权利要求1所述的方法，其特征在于，在所述执行所述测试脚本，测试所述目标程序之后，还包括：

获得测试结果。

7.根据权利要求6所述的方法，其特征在于，所述测试用例包括预期结果，在所述获得测试结果之后，还包括：

判断所述测试结果与所述预期结果是否匹配；

8.根据权利要求1所述的方法，其特征在于，在所述执行所述测试脚本，测试所述目标程序之后，还包括：

生成测试日志。

9.一种测试装置，其特征在于，所述装置包括：

第一集成模块，用于集成所述测试用例对应的配置文件；

第一确定模块，用于确定所述测试用例对应的目标控件；

测试模块，用于执行所述测试脚本，测试所述目标程序。

10.根据权利要求9所述的装置，其特征在于，在所述接收模块接收针对目标程序的测试指令之前，还包括：

11.根据权利要求10所述的装置，其特征在于，所述第一确定模块，包括：

12.根据权利要求9所述的装置，其特征在于，所述装置还包括：

13.根据权利要求9所述的装置，其特征在于，所述第一确定模块，包括：

14.根据权利要求9所述的装置，其特征在于，在所述测试模块执行所述测试脚本，测试所述目标程序之后，还包括：

第三获得模块，用于获得测试结果。

15.根据权利要求14所述的装置，其特征在于，所述测试用例包括预期结果，在所述第三获得模块获得测试结果之后，还包括：

16.根据权利要求9所述的装置，其特征在于，在所述测试模块执行所述测试脚本，测试所述目标程序之后，还包括：

第三生成模块，用于生成测试日志。