CN105095059B - 一种自动化测试的方法和装置 - Google Patents

Abstract

本发明提供了一种自动化测试的方法和装置，预先存储测试件中各测试用例所属的测试分组；运行被测试项目对应的测试集，测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组；在运行测试集的过程中，解析测试集涉及的测试件和测试件中的测试用例；针对解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例；获取各测试任务的运行数据得到被测试项目的运行数据，运行数据至少包括测试结果。本发明能够更加灵活地组合测试用例，节约了测试资源和时间，降低了运行成本，且不会增加测试件的维护成本。

Description

一种自动化测试的方法和装置

【技术领域】

本发明涉及计算机应用技术领域，特别涉及一种自动化测试的方法和装置。

【背景技术】

测试件指的是一组相关测试用例的集合，例如将“淘宝首页所有用户行为”作为一个测试件，现有自动化测试必须基于测试件执行。

然而如果测试件较大，覆盖面广，这就可能会造成测试资源和时间的浪费，运行成本较高。例如，开发工程师A修改了淘宝首页的产品功能，他想用自动化测试件进行回归测试，就必须跑“淘宝首页所有用户行为”这个测试件，但这个测试件中可能包含了很多他不需要的测试用例，比如店铺信息相关的测试用例，那么就会浪费测试资源和时间。再例如，开发工程师B修改了产品功能的底层模块，他需要回归测试淘宝首页的产品功能和淘宝店铺的产品功能，涉及的测试用例分布于“淘宝首页所有用户行为”和“淘宝店铺所有用户行为”两个测试件中，那他就必须运行这两个测试件才能够覆盖他的测试场景，但这两个测试件中可能包含了很多他不需要的测试用例，比如店铺信息相关的测试用例，同样会浪费测试资源和时间。

如果测试件设置的比较小，使得每个测试件都仅包含一个或几个测试用例，每次运行的时候选取不同的测试件运行，降低运行成本，但随着测试用例的增加，测试件也越来越多，增加了维护成本。

【发明内容】

有鉴于此，本发明提供了一种自动化测试的方法和装置，以便于降低测试的运营成本和维护成本。

具体技术方案如下：

本发明提供了一种自动化测试的方法，预先存储测试件中各测试用例所属的测试分组；所述方法包括：

运行被测试项目对应的测试集，所述测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组；

在运行所述测试集的过程中，解析所述测试集涉及的测试件和测试件中的测试用例；

针对解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例；

获取各测试任务的运行数据得到所述被测试项目的运行数据，所述运行数据至少包括测试结果。

根据本发明一优选实施方式，所述预先存储测试件中各测试用例所属的测试分组包括：

获取并解析测试件的源代码，所述源代码中采用testng的group模式定义各测试用例所属的测试分组；

将解析得到的每个测试用例的名称和所属的测试分组存入数据库中。

根据本发明一优选实施方式，在所述运行被测试项目对应的测试集之前，该方法还包括：

判断已经创建的测试集中是否已经存在所述被测试项目对应的测试集，如果是，则执行所述运行被测试项目对应的测试集；否则，创建所述被测试项目对应的测试集后，执行所述运行被测试项目对应的测试集。

根据本发明一优选实施方式，创建所述被测试项目对应的测试集包括：

向用户提供新增测试集的界面；

将用户在所述新增测试集的界面中输入的测试集的名称、选择的测试件以及从选择的测试件中选择的测试分组作为测试集信息进行保存。

根据本发明一优选实施方式，所述获取各测试任务的运行数据得到所述被测试项目的运行数据包括：

如果所述测试任务为多个，则整合各测试任务的运行数据得到所述被测试项目的运行数据。

根据本发明一优选实施方式，所述运行数据还包括状态信息，在对各测试任务的状态信息进行整合时，采用以下原则：

如果所有测试任务都尚未开始，则整合后所述被测试项目的状态信息为等待执行；

如果至少有一个测试任务在运行中，则整合后所述被测试项目的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，则整合后所述被测试项目的状态信息为运行失败；

如果所有测试任务都运行结束且全部成功，则整合后所述被测试项目的状态信息为运行成功；

如果至少有一个测试任务运行异常，则整合后所述被测试项目的运行状态为运行异常。

根据本发明一优选实施方式，该方法还包括：

通过任务管理界面输出所述被测试项目的运行数据。

本发明还提供了一种自动化测试的装置，该装置包括：存储单元、运行单元和结果获取单元；

所述存储单元，用于预先存储测试件中各测试用例所属的测试分组；

所述运行单元，用于运行被测试项目对应的测试集，所述测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组；

其中所述运行单元具体包括：

第一解析子单元，用于解析所述测试集涉及的测试件和测试件中的测试用例；

运行子单元，用于针对所述第一解析子单元得到的解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例；

所述结果获取单元，用于获取各测试任务的运行数据得到所述被测试项目的运行数据，所述运行数据至少包括测试结果。

根据本发明一优选实施方式，所述存储单元具体包括：

第二解析子单元，用于获取并解析测试件的源代码，所述源代码中采用testng的group模式定义各测试用例所属的测试分组；

存储子单元，用于将所述第二解析子单元解析得到的每个测试用例的名称和所属的测试分组存入数据库中。

根据本发明一优选实施方式，该装置还包括：判断单元和创建单元；

所述判断单元，用于在所述运行单元运行被测试项目对应的测试集之前，判断已经创建的测试集中是否已经存在所述被测试项目对应的测试集，如果是，触发所述运行单元运行被测试项目对应的测试集；否则，触发所述创建单元；

所述创建单元，用于受到所述判断单元的触发后，创建所述被测试项目对应的测试集，触发所述运行单元运行被测试项目对应的测试集。

根据本发明一优选实施方式，所述创建单元具体用于向用户提供新增测试集的界面，将用户在所述新增测试集的界面中输入的测试集的名称、选择的测试件以及从选择的测试件中选择的测试分组作为测试集信息进行保存。

根据本发明一优选实施方式，如果所述测试任务为多个，则所述结果获取单元整合各测试任务的运行数据得到所述被测试项目的运行数据。

根据本发明一优选实施方式，所述运行数据还包括状态信息，所述结果获取单元在对各测试任务的状态信息进行整合时，采用以下原则：

如果所有测试任务都尚未开始，则整合后所述被测试项目的状态信息为等待执行；

如果至少有一个测试任务在运行中，则整合后所述被测试项目的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，则整合后所述被测试项目的状态信息为运行失败；

如果所有测试任务都运行结束且全部成功，则整合后所述被测试项目的状态信息为运行成功；

如果至少有一个测试任务运行异常，则整合后所述被测试项目的运行状态为运行异常。

根据本发明一优选实施方式，该装置还包括：结果输出单元，用于通过任务管理界面输出所述被测试项目的运行数据。

由以上技术方案可以看出，本发明引入了测试分组和测试集的概念，使得自动化测试基于测试集进行，能够更加灵活地组合测试用例，仅运行被测试项目所涉及的测试用例即可，节约了测试资源和时间，降低了运行成本，另外并没有改变测试件的数量，不会增加测试件的维护成本。

【附图说明】

图1为本发明提供的主要方法流程图；

图2为本发明实施例一提供的方法流程图；

图3为本发明实施例一提供的一种测试件的代码结构图；

图4a为本发明实施例一提供的新增测试集的界面的一个示意图；

图4b为本发明实施例一提供的新增测试集的界面的另一个示意图；

图4c为本发明实施例一提供的新增测试集的界面的再一个示意图；

图5为本发明实施例一提供的已经创建完成的测试集显示结果；

图6为本发明实施例一提供的测试集运行环境的配置界面示意图；

图7a为本发明实施例一提供的第一个测试任务的Html报告的示意图；

图7b为本发明实施例一提供的第二个测试任务的Html报告的示意图；

图7c为将图7a和图7b所示Html报告进行整合后得到的Html报告示意图；

图8a为本发明实施例一提供的测试任务运行过程中的任务管理界面示意图；

图8b为本发明实施例一提供的测试任务运行结束后的任务管理界面示意图；

图9为本发明实施例二提供的自动化测试的装置结构图。

【具体实施方式】

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

本发明的核心思想在于，打破测试件的限制，但最大限度的保留当前测试任务基于测试件的测试机制，采用在测试件中将测试用例划分为测试分组，基于测试分组构建测试集，使得自动化测试基于测试集。图1为本发明提供的主要方法流程图，如图1中所示，该方法主要方法包括以下步骤：

步骤101：预先存储测试件中各测试用例所属的测试分组。

即预先将各测试件中的测试用例划分到测试分组里，一个测试用例可以属于多个测试分组，例如测试件A中的测试用例被划分为2个测试分组a和b，其中测试用例1既属于测试分组a又属于测试分组b。最常见的测试分组的划分可以基于不同的业务需求，即将不同的业务模块对应到不同的测试分组，将同一个业务模块所涉及的测试用例划分到一个测试分组中。另外，不同的测试件也可以涉及相同的测试分组。例如测试件A和测试件B中都存在测试分组a。

通常情况下，各测试件是写在源代码中的，本步骤中可以获取并解析测试件的源代码，得到每个测试用例的名称及其所属的测试分组，然后存入数据库中保存。

步骤102：运行被测试项目对应的测试集，所述测试集中可以包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组。

在本发明中如果一个被测试项目仅涉及一个测试件中的部分测试分组，或者涉及多个测试件中的测试分组，则需要针对该测试项目创建测试集，在测试集中包含该测试项目所涉及的测试分组。创建的测试集可以被重复使用，当需要对一个被测试项目进行多次测试时，就可以直接运行已经创建的测试集。需要说明的是，本发明各实施例中所涉及的“多个”是指两个以上。

步骤103：在运行测试集的过程中，解析测试集中涉及的测试件和该测试件中的测试用例。

步骤104：针对解析结果中的每一个测试件分别创建一个测试任务，每个测试任务负责运行解析结果中其所针对测试件中的测试用例。

由于目前的测试任务都是基于测试件的，为了最大限度的兼容现有的测试机制和测试工具，在本步骤中创建测试任务时仍针对测试件，但测试任务在执行时运行的仅仅是测试集所涉及的测试件中的测试用例。

步骤105：获取各测试任务的运行数据得到被测试项目的运行数据。

如果被测试项目对应的测试集仅涉及一个测试件，也就是说仅运行一个测试任务，那么直接获取该测试任务的运行数据即可。由于一个被测试项目的测试集可能涉及到多个测试件，因此就可能存在多个测试任务的执行，每个测试任务都会存在运行数据，因此需要将各测试任务的运行数据进行整合，得到被测试项目的运行数据。该运行数据中至少包括测试任务的测试结果，还可以包括测试任务的状态信息、Html报告等。

下面通过实施例一对本发明提供的方法进行详细描述。

实施例一、

在本实施例中以一个测试项目为例进行描述，假设该测试项目涉及三个线上应用，分别是rfqaisn、rfqma和rfqbops，这三个线上应用分别对应一个测试件（当然，一个测试件并不一定非要对应一个应用，也可以是一对多，也可以是多对一，在此仅以一对一的方式为例）。由于在各线上应用中通常会涉及多个业务模块，例如采购需求（RFQ）模块、报价模块、样品模块等，因此各测试件中的测试分组可以基于业务模块划分，从而将测试用例在测试件内部管理起来。假设一个开发工程师改动了RFQ模块的内容，他的改动就可能涉及到这三个应用，即三个测试件，那么本次的测试项目就需要运行这三个测试件中对应RFQ模块的测试分组，本实施例中就以该测试项目为例。另外，本实施例中以MYUI自动化框架中实现为例，MYUI是一套自动化运行的框架和平台，基于selenium开发，有自己扩展的功能方法和一套完善的运行平台。图2为本发明实施例一提供的方法流程图，如图2中所示，该方法可以包括以下步骤：

步骤201：预先存储测试件中各测试用例所属的测试分组。

测试用例是放在测试件内的，一个测试件就是一个java的工程，测试用例和诸如配置文件等资源文件都有自己的存储路径，以rfqma测试件为例，如图3所示，测试用例的代码放在test/java目录下的com.alibaba.intl.rfqma.test.rfq.jstest，资源文件放在test/resources目录下。

每一个测试用例对应到具体的代码上就是一个java的method（方法），通常在每一个测试用例对应的method上加上@test标签，这个标签中包含很多属性，其中，description被用作这个测试用例的描述或者名字，groups就可以用于定义该测试用例所属的分组，也就是说，使用testng的group模式将每一个测试用例划分到不同的测试分组中，testng是一套开源的测试框架，用于java的测试。举一个例子：

@Test(dataProviderClass=RfqAccountProvider.class,dataProvider=“accountForRfq”,description=“买家发布RFQ”,groups={“买家管理Rfq”，“P1”})

public void testpostRfq(IntlAccount intlAccount,IntlServer server){

MUIDriver mDriver=new MUIDriver();

mDriver.login(server+POST_BUY_REQUEST_PAGE,intlAccount);

这个测试用例的名字就是“买家发布RFQ”，具体执行测试的java代码就是testPostRfq这个method，而这个测试用例所属的分组有2个，一个是“买家管理RFQ”，另一个是“P1”。

在MYUI系统中，自动从SVN（Subversion，一种版本管理工具）上获取并解析测试件的源代码，得到每个测试用例的名称和所属的测试分组，然后存入数据库中。

步骤202：针对被测试项目创建一个测试集。

如果已经存在可使用的测试集，则直接使用该测试集即可，如果尚未存在可使用的测试集，则需要针对被测试项目新创建一个测试集，选择对应的测试分组到该测试集中。

首先会提供给一个新增测试集的界面，用户输入测试集的名称，然后从不同的测试件中选择被测试项目涉及的测试分组到测试集中。举个例子，提供给用户的新增测试集的界面如图4a所示，点击“选择测试件”中“UI测试件”按钮，就会出现如图4a中所示的下拉框，从下拉框中选择测试件，假如选择了测试件rfqbops，就会显示该测试件中所有的测试分组，如图4b中所示。然后从中选择本测试件中被测试项目所涉及的测试分组，并给输入测试集的名称“rfq相关用例测试集”，最终界面如图4c所示。通过这种方式将被测试项目所涉及的不同测试件中的测试分组进行选择，测试集创建完成后点击“保存”按钮或者“保存并执行按钮”。如果点击“保存”按钮，就可以将已经创建完成的测试集显示给用户，如图5所示，箭头所指的就是刚才新建的测试集。

在完成测试集的创建后且在运行测试集之前，可以对该测试集的运行环境进行配置，包括但不限于：浏览器类型，主机（Host）信息等，如图6中所示。

步骤203：运行创建的测试集。

用户可以通过点选图5中所示的测试集对应的“运行”按钮，触发测试集的运行。测试集的运行过程可以包括步骤203-1～步骤203-2：

步骤203-1：解析测试集信息，得到该测试集中涉及的测试件和测试件中的测试用例。

具体地，测试集涉及的每一个测试件、测试分组以及测试用例都保存在MYUI系统的数据库中。测试集会记录测试件和测试分组的ID，例如“10：19,141；12:183,185”，其中不同的测试件之间用分号分割，测试件和测试分组之间用冒号分割，测试分组之间用逗号分割。然后根据测试集记录的测试件和测试分组的ID，到测试件和测试分组的表中获取对应的测试件和测试分组信息，包括测试分组中包括的测试用例。

步骤203-2：针对解析得到的每一个测试件分别创建一个Jenkins任务，每个Jenkins任务负责运行解析得到的该测试件中的测试用例。

在本发明实施例采用Jenkins平台来创建测试任务，Jenkins是一个开源软件项目，旨在提供一个开放易用的软件平台，是基于Java开发的一种持续集成工具，本发明实施例中用它来执行自动化脚本。当然除了Jenkins平台之外也可以选择其他平台来创建和运行测试任务。

每一个测试任务仅负责运行解析得到的该测试件中的测试用例，即仅仅是被测试项目对应的测试集中属于该测试件的测试分组所包含的测试用例，并不是该测试件中所有的测试用例。

步骤204：周期性地收集各Jenkins任务的运行数据并进行整合，得到被测试项目的运行数据。

例如，每隔30秒到Jenkins平台上收集各测试任务的运行数据并将结果整合到一起。整合的内容可以包括测试任务的状态信息、测试结果、Html报告等。

在对测试任务的状态信息进行整合时，可以采取以下原则：

如果所有测试任务都尚未开始，那么整合后的状态信息为等待执行；

如果至少有一个测试任务在运行中，那么整合后的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，那么整合后的测试任务为运行失败；

如果所有测试任务都运行结束且全部成功，那么整合后的状态信息为运行成功；

如果至少有一个测试任务运行异常，那么整合后的状态信息为运行异常。

在对各测试任务的测试结果进行整合时，整合的内容包括但不限于：总测试用例数、失败和/或成功的测试用例数、运行时间、开始和/或结束时间。

通常Jenkins平台上的每个测试任务都会独立生成一份Html报告，在此需要将各测试任务的Html报告合并成一份报告。假设有两个测试任务，如果测试任务1的Html报告如图7a所示，测试任务2的Html报告如图7b所示，那么进行整合后形成的Html报告可以如图7c中所示。

由于上述的运行数据是周期性收集和整合的，因此在测试任务的运行过程中就可以在任务管理界面查看到被测试项目的运行数据，如图8a中所示。测试任务全部运行结束后，可以在任务管理界面查看到被测试项目的最终运行数据，如图8b中所示，点击其中的“详情”选项就可以看到一份Html报告。

以上是对本发明所提供的方法进行的详细描述，下面通过实施例二对本发明提供的自动化测试的装置进行详细描述。

实施例二、

图9为本发明实施例二提供的自动化测试的装置结构图，如图9中所示，该装置可以包括存储单元00、运行单元10和结果获取单元20，还可以进一步包括：判断单元30、创建单元40和结果输出单元50。

其中，存储单元00预先存储测试件中各测试用例所属的测试分组，即预先将各测试件中的测试用例划分到测试分组中，一个测试用例可以属于多个测试分组，不同的测试件也可以涉及相同的测试分组。具体地，该存储单元00可以具体包括：第二解析子单元01和存储子单元02。

第二解析子单元01负责获取并解析测试件的源代码，该源代码可以从SVN上获取，源代码中采用testng的group模式定义各测试用例所属的测试分组，解析后得到每个测试用例的名称和所属的测试分组。

然后存储子单元02将第二解析子单元01解析得到的每个测试用例的名称和所属的测试分组存入数据库中。

运行单元10负责运行被测试项目对应的测试集，测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组。具体地，运行单元10可以包括：第一解析子单元11和运行子单元12。

第一解析子单元11负责解析测试集涉及的测试件和测试件中的测试用例。测试集涉及的每一个测试件、测试分组以及测试用例都保存在MYUI系统的数据库中，测试集会记录测试件和测试分组的ID，根据测试集记录的测试件和测试分组的ID，到测试件和测试分组的表中获取对应的测试件和测试分组信息，包括测试分组中包括的测试用例。

然后运行子单元12针对第一解析子单元11得到的解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例。本发明实施例中可以采用Jenkins平台来创建测试任务，每一个测试任务仅负责运行解析得到的该测试件中的测试用例，即仅仅是被测试项目对应的测试集中属于该测试件的测试分组所包含的测试用例，并不是该测试件中所有的测试用例。

需要说明的是，如果运行单元10在运行被测试项目对应的测试集之前，已经创建有可使用的测试集，则直接使用即可，如果尚未创建，则需要针对被测试项目新建一个测试集。也就是说，判断单元30在运行单元10运行被测试项目对应的测试集之前，首先判断已经创建的测试集中是否已经存在被测试项目对应的测试集，如果是，触发运行单元10运行被测试项目对应的测试集；否则，触发创建单元40。

创建单元40受到判断单元30的触发后，创建被测试项目对应的测试集，触发运行单元10运行被测试项目对应的测试集。其中创建被测试项目对应的测试集时，可以向用户提供新增测试集的界面，将用户在新增测试集的界面中输入的测试集的名称、选择的测试件以及从选择的测试件中选择的测试分组作为测试集信息进行保存。

另外，创建单元40在完成测试集的创建后，可以对该测试集的运行环境进行配置，包括但不限于对浏览器类型、Host信息的配置等等。

最后，结果获取单元20获取各测试任务的运行数据得到被测试项目的运行数据，运行数据至少包括测试结果，还可以包括测试测试结果、Html报告等。

如果运行的测试任务是一个，则直接获取该测试任务的运行数据就得到被测试项目的运行数据；如果测试任务为多个，则结果获取单元20需要整合各测试任务的运行数据得到被测试项目的运行数据。

结果获取单元20可以周期性地收集各测试任务的运行数据并进行整合，在对各测试任务的状态信息进行整合时，可以采用以下原则：

如果所有测试任务都尚未开始，则整合后被测试项目的状态信息为等待执行；

如果至少有一个测试任务在运行中，则整合后被测试项目的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，则整合后被测试项目的状态信息为运行失败；

如果所有测试任务都运行结束且全部成功，则整合后被测试项目的状态信息为运行成功；

如果至少有一个测试任务运行异常，则整合后被测试项目的运行状态为运行异常。

在对各测试任务的测试结果进行整合时，整合的内容包括但不限于：总测试用例数、失败和/或成功的测试用例数、运行时间、开始和/或结束时间。通常Jenkins平台上的每个测试任务都会独立生成一份Html报告，在此需要将各测试任务的Html报告合并成一份报告。

最后，结果输出单元50可以通过任务管理界面输出被测试项目的运行数据，供用户进行查看。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (14)

1.一种自动化测试的方法，其特征在于，预先存储测试件中各测试用例所属的测试分组；所述方法包括：

运行被测试项目对应的测试集，所述测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组；

在运行所述测试集的过程中，解析所述测试集涉及的测试件和测试件中的测试用例；

针对解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例；

获取各测试任务的运行数据得到所述被测试项目的运行数据，所述运行数据至少包括测试结果。

2.根据权利要求1所述的方法，其特征在于，所述预先存储测试件中各测试用例所属的测试分组包括：

获取并解析测试件的源代码，所述源代码中采用testng的group模式定义各测试用例所属的测试分组；

将解析得到的每个测试用例的名称和所属的测试分组存入数据库中。

3.根据权利要求1所述的方法，其特征在于，在所述运行被测试项目对应的测试集之前，该方法还包括：

判断已经创建的测试集中是否已经存在所述被测试项目对应的测试集，如果是，则执行所述运行被测试项目对应的测试集；否则，创建所述被测试项目对应的测试集后，执行所述运行被测试项目对应的测试集。

4.根据权利要求3所述的方法，其特征在于，创建所述被测试项目对应的测试集包括：

向用户提供新增测试集的界面；

将用户在所述新增测试集的界面中输入的测试集的名称、选择的测试件以及从选择的测试件中选择的测试分组作为测试集信息进行保存。

5.根据权利要求1所述的方法，其特征在于，所述获取各测试任务的运行数据得到所述被测试项目的运行数据包括：

如果所述测试任务为多个，则整合各测试任务的运行数据得到所述被测试项目的运行数据。

6.根据权利要求5所述的方法，其特征在于，所述运行数据还包括状态信息，在对各测试任务的状态信息进行整合时，采用以下原则：

如果所有测试任务都尚未开始，则整合后所述被测试项目的状态信息为等待执行；

如果至少有一个测试任务在运行中，则整合后所述被测试项目的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，则整合后所述被测试项目的状态信息为运行失败；

如果所有测试任务都运行结束且全部成功，则整合后所述被测试项目的状态信息为运行成功；

如果至少有一个测试任务运行异常，则整合后所述被测试项目的运行状态为运行异常。

7.根据权利要求1至6任一权项所述的方法，其特征在于，该方法还包括：

通过任务管理界面输出所述被测试项目的运行数据。

8.一种自动化测试的装置，其特征在于，该装置包括：存储单元、运行单元和结果获取单元；

所述存储单元，用于预先存储测试件中各测试用例所属的测试分组；

所述运行单元，用于运行被测试项目对应的测试集，所述测试集中包括一个测试件中的一个或多个测试分组，或者包括多个测试件的测试分组；

其中所述运行单元具体包括：

第一解析子单元，用于解析所述测试集涉及的测试件和测试件中的测试用例；

运行子单元，用于针对所述第一解析子单元得到的解析结果中的每一个测试件分别创建测试任务，每个测试任务负责运行解析结果中该测试任务所对应测试件中的测试用例；

所述结果获取单元，用于获取各测试任务的运行数据得到所述被测试项目的运行数据，所述运行数据至少包括测试结果。

9.根据权利要求8所述的装置，其特征在于，所述存储单元具体包括：

第二解析子单元，用于获取并解析测试件的源代码，所述源代码中采用testng的group模式定义各测试用例所属的测试分组；

存储子单元，用于将所述第二解析子单元解析得到的每个测试用例的名称和所属的测试分组存入数据库中。

10.根据权利要求8所述的装置，其特征在于，该装置还包括：判断单元和创建单元；

所述判断单元，用于在所述运行单元运行被测试项目对应的测试集之前，判断已经创建的测试集中是否已经存在所述被测试项目对应的测试集，如果是，触发所述运行单元运行被测试项目对应的测试集；否则，触发所述创建单元；

所述创建单元，用于受到所述判断单元的触发后，创建所述被测试项目对应的测试集，触发所述运行单元运行被测试项目对应的测试集。

11.根据权利要求10所述的装置，其特征在于，所述创建单元具体用于向用户提供新增测试集的界面，将用户在所述新增测试集的界面中输入的测试集的名称、选择的测试件以及从选择的测试件中选择的测试分组作为测试集信息进行保存。

12.根据权利要求8所述的装置，其特征在于，如果所述测试任务为多个，则所述结果获取单元整合各测试任务的运行数据得到所述被测试项目的运行数据。

13.根据权利要求12所述的装置，其特征在于，所述运行数据还包括状态信息，所述结果获取单元在对各测试任务的状态信息进行整合时，采用以下原则：

如果所有测试任务都尚未开始，则整合后所述被测试项目的状态信息为等待执行；

如果至少有一个测试任务在运行中，则整合后所述被测试项目的状态信息为运行中；

如果所有测试任务都运行结束且至少有一个测试任务运行失败，则整合后所述被测试项目的状态信息为运行失败；

如果所有测试任务都运行结束且全部成功，则整合后所述被测试项目的状态信息为运行成功；

如果至少有一个测试任务运行异常，则整合后所述被测试项目的运行状态为运行异常。

14.根据权利要求8至13任一权项所述的装置，其特征在于，该装置还包括：结果输出单元，用于通过任务管理界面输出所述被测试项目的运行数据。