CN111382082A - 持续集成测试方法及装置 - Google Patents

Abstract

本发明提供了一种持续集成测试方法及装置，涉及测试技术领域，该方法包括：获取测试环境定义参数；根据测试环境定义参数为目标测试案例集确定测试环境资源；测试环境资源包括物理环境资源和虚拟环境资源；测试案例集包括第一案例集和第二案例集；第一案例集的优先级高于第二案例集；利用物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果；利用虚拟环境资源并根据第一测试结果执行第二案例集的测试，得到第二测试结果；根据第一测试结果和第二测试结果生成持续集成测试结果。本发明通过在不同测试阶段对环境资源的充分利用，可以提高企业级软件持续集成测试的资源的利用率和测试效率。

Description

持续集成测试方法及装置

技术领域

本发明涉及测试技术领域，尤其是涉及一种持续集成测试方法及装置。

背景技术

在计算机软件领域，企业级软件是非常重要的一类软件。企业级软件指面向企业使用的软件，具有软件包大，部署时间长等特点，一般部署于企业内部，为企业或者企业内部员工提供服务。企业级软件生产商在发布企业级软件给客户之前，需要对企业级软件的每个开发阶段的代码提交进行充分的测试和集成测试。目前，现有的技术方案没有专门针对企业级软件的特点做持续集成测试，存在资源浪费，效率低的特点。

发明内容

本发明提供了一种持续集成测试方法及装置，可以提高企业级软件持续集成测试的资源的利用率和测试效率。

第一方面，本发明实施例提供了一种持续集成测试方法，该方法包括：获取测试环境定义参数；根据所述测试环境定义参数为目标测试案例集确定测试环境资源；所述测试环境资源包括物理环境资源和虚拟环境资源；所述目标测试案例集包括第一案例集和第二案例集；所述第一案例集的优先级高于所述第二案例集；利用所述物理环境资源和所述虚拟环境资源执行所述第一案例集的测试，得到第一测试结果；利用所述虚拟环境资源并根据所述第一测试结果执行所述第二案例集的测试，得到第二测试结果；根据所述第一测试结果和所述第二测试结果生成持续集成测试结果。

第二方面，本发明实施例还提供一种持续集成测试装置，该装置包括：获取模块，用于获取测试环境定义参数；部署模块，用于根据所述测试环境定义参数为目标测试案例集确定测试环境资源；所述测试环境资源包括物理环境资源和虚拟环境资源；所述测试案例包括第一案例集和第二案例集；所述第一案例集的优先级高于所述第二案例集；第一测试模块，用于利用所述物理环境资源和所述虚拟环境资源执行所述第一案例集的测试，得到第一测试结果；第二测试模块，用于利用所述虚拟环境资源并根据所述第一测试结果执行所述第二案例集的测试，得到第二测试结果；结果模块，用于根据所述第一测试结果和所述第二测试结果生成持续集成测试结果。

第三方面，本发明实施例还提供一种计算机设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述持续集成测试方法。

第四方面，本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行上述持续集成测试方法。

本发明实施例带来了以下有益效果：本发明实施例提供了一种持续集成测试方案，该方案通过测试环境定义参数可以为目标测试案例集确定测试环境资源，根据物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果，根据虚拟环境资源和第一测试结果执行第二案例集的测试，得到第二测试结果，通过采用物理环境资源与虚拟环境资源相结合的方式，实现不同阶段使用不同的部署环境进行测试，得到持续集成测试结果。本发明实施例通过在不同测试阶段对环境资源的充分利用，可以提高企业级软件持续集成测试的资源的利用率和测试效率。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的持续集成测试方法流程图；

图2为本发明实施例提供的持续集成测试方法实施流程图；

图3为本发明实施例提供的持续集成测试方法实施流程所用装置的模块架构图；

图4为本发明实施例提供的持续集成测试装置结构框图；

图5为本发明实施例提供的计算机设备结构框图。

具体实施方式

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

企业级软件具有软件包大，部署时间长，大多支持多种平台部署，多种软件升级路径等特点，如何提高企业级软件的开发效率，以及如何对其进行高效充分的测试，提高测试效率，节省测试资源对企业级软件生产商具有重要意义。

企业级软件一般具有以下特点：

(1)支持的平台版本多(如不同的Linux发行版本，Windows版本等)；

(2)软件版本包大，构建时间长部署时间长；

(3)不同企业部署的版本不同，需要同时支持全新安装和不同版本路径的升级。

目前已有的持续集成方法并没有专门针对企业级软件的特点设计，在资源利用和效率上表现不佳。

基于此，本发明实施例提供的一种持续集成测试方法及装置，通过融合不同的策略和方法，可以提高资源的利用率，提高企业级软件的测试的充分性和效率。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种持续集成测试方法进行详细介绍。

首先对下文提到的术语进行解释：

企业级软件：指面向企业使用的软件，一般部署于企业内部，为企业或者企业内部员工提供服务。

BQ(Build Quality，构建质量验证)：最基本的构建任务质量验证。

Golden stack/Silver stack：为根据客户的使用情况和产品的部署情况定义的企业级软件的不同的安装配置(不同的操作系统版本+不同的数据库版本等等)。其中，Golden stack为主要安装配置，Silver stack次要安装配置情况。

本发明实施例提供了一种持续集成测试方法，参见图1所示的一种持续集成测试方法流程图，该方法包括以下步骤：

步骤S102，获取测试环境定义参数。

在本发明实施例中，测试环境定义参数是预先设置的数据，是根据企业级软件的使用情况和部署情况定义的企业级软件的不同的安装配置参数，包括主要安装配置参数(对应主流客户使用企业级软件时的安装配置情况)和优先级稍低的次要安装配置参数。根据测试环境定义参数可以用于部署不同的测试环境。

步骤S104，根据测试环境定义参数为目标测试案例集确定测试环境资源。

在本发明实施例中，测试环境资源包括物理环境资源和虚拟环境资源；目标测试案例集包括多个待执行的测试案例。目标测试案例集中的测试案例可以按照优先级划分为第一案例集和第二案例集；第一案例集用于覆盖企业级软件的目标功能，第二案例集用于保证测试的覆盖程度，因此，第二案例集中的测试案例的重要程度小于第一案例集中的测试案例。

在本发明实施例中，物理环境资源为实体的机器，无需重新部署和配置，配置高，速度快，缺点是价格高，专门留给测试人员的资源有限。虚拟环境资源为在虚拟环境中部署的虚拟机器，例如，可以为虚拟的Linux或windows机器，每次测试均需部署。由于多套测试环境共享资源池，导致速度和运行测试的效率比物理环境低。

第一案例集和第二案例集是按照案例的重要程度进行分类得到的，第一案例集的优先级高于第二案例集。第一案例集用于覆盖企业级软件的目标功能，目标功能可以是企业级软件的核心功能点，通过运行第一案例集，实现运行测试中最重要最核心的测试案例，通过运行第二案例集，实现运行测试中次重要的测试案例。

步骤S106，利用物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果。

在本发明实施例中，尽量使用物理环境资源执行第一案例集的测试，以保证测试的充分性和效率。在物理环境资源不足，不能够支持第一案例集测试的情况下，可以采用物理资源环境和虚拟资源环境相结合的方式执行第一案例集的测试，以保证测试的高效进行。如果不存在物理环境资源，则通过虚拟环境资源执行第一案例集的测试，以保证测试能够正常的进行。执行第一案例集的测试后，得到第一测试结果，第一测试结果可能为测试通过或测试失败，如果测试失败，则持续集成测试结束。如果测试通过，则继续执行后续步骤。

步骤S108，利用虚拟环境资源并根据第一测试结果执行第二案例集的测试，得到第二测试结果。

在本发明实施例中，可以通过预先设置测试环境定义参数中的数据，实现为第二案例集配置虚拟环境资源，在第一测试结果为测试通过的情况下，在虚拟环境资源中执行第二案例集的测试，得到第二测试结果。第二测试结果也包括测试通过或测试失败。

需要说明的是，如果第一测试结果为测试失败，则停止测试，不再继续执行第二案例集的测试步骤和后续测试步骤。

步骤S110，根据第一测试结果和第二测试结果生成持续集成测试结果。

在本发明实施例中，对第一测试结果和第二测试结果进行收集、统计、结果发布以及日志收集处理，得到持续集成测试结果。

本发明实施例提供了一种持续集成测试方案，该方案通过测试环境定义参数可以为目标测试案例集确定测试环境资源，根据物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果，根据虚拟环境资源和第一测试结果执行第二案例集的测试，得到第二测试结果，通过采用物理环境资源与虚拟环境资源相结合的方式，实现不同阶段使用不同的部署环境进行测试，得到持续集成测试结果。本发明实施例通过在不同测试阶段对环境资源的充分利用，可以提高企业级软件持续集成测试的资源的利用率和测试效率。

考虑到企业级软件的构建时间一般较长，自动化测试周期也相对较长，所以传统的持续集成方法中每次代码提交即触发构建的方式不适合企业级软件，可能造成本次构建尚未测试完成，而下次构建已经开始的情况。且企业级软件的发布周期较互联网类软件也相对较长，并不需要每次代码提交都完成测试并发布。定时构建的方式既可以满足所提交代码相对及时的得到测试，满足发布需求，也可避免每次构建测试造成的资源浪费。因此，获取测试环境定义参数之前，还可以执行如下步骤：

按照预设时长间隔启动构建任务，得到构建结果；构建结果包括识别序号；根据识别序号判断构建结果是否已更新；如果是，根据构建结果启动第一案例集的测试；如果否，停止持续集成测试。

在本发明实施例中，预设时长间隔可以根据实际需求进行设置，可根据具体的企业级软件灵活调整，本发明实施例对此不作具体限定。例如，可以将预设时长间隔设置为每日2次。通过构建任务可以实现将收到的开发代码打包，得到构建结果，每个构建结果都有识别序号，并且可以设置识别序号递增，因此，如果构建结果的识别序号没有增加，则证明构建结果没有更新，不触发后续的测试工作，如果构建结果的识别序号增加，则启动第一案例集的测试。

需要说明的是，有些情景下，由于代码或者环境原因，存在构建任务执行失败的情况，而上次构建结果已经运行过测试，为了避免重复运行相同的测试，耗费资源以及对测试结果重复进行人工分析，可以执行本步骤。

考虑到为了提高第一案例集测试的运行速度，提高严重问题发现的效率，以进一步提升测试的效率，根据测试环境定义参数为目标测试案例集确定测试环境资源，可以按照如下步骤执行：

判断是否存在可用状态的设备资源；如果是，根据可用状态的设备资源确定第一案例集的第一物理环境资源，并根据测试环境定义参数判断第一物理环境资源是否不小于第一案例集测试所需资源；如果第一物理环境资源不小于第一案例集测试所需资源，则将第一物理环境资源作为第一案例集的测试环境资源；如果第一物理环境资源小于第一案例集测试所需资源，根据测试环境定义参数生成第一虚拟环境资源，并将第一物理环境资源和第一虚拟环境资源作为第一案例集的测试环境资源；如果否，根据测试环境定义参数生成第二虚拟环境资源，并将第二虚拟环境资源作为第一案例集的测试环境资源；根据测试环境定义参数生成第三虚拟环境资源，并将第三虚拟环境资源作为第二案例集的测试环境资源。

在本发明实施例中，可用状态的设备资源是指未被占用的，可以用于执行测试任务的设备资源。如果存在可用状态的设备资源，则可以从该可用状态的设备资源中选择第一案例集的第一物理环境资源，考虑到可能有虽然存在可用状态的设备资源，但是可用状态的设备资源不足以支持第一案例集测试的情况存在，因此，需要对第一物理环境资源是否不小于第一案例集测试所需资源进行判断，如果能够满足第一案例集的测试，则将第一物理环境资源作为第一案例集的测试环境资源，如果不能满足第一案例集的测试，那么需要根据测试环境定义参数生成第一虚拟环境资源，通过第一物理环境资源和第一虚拟环境资源相结合，实现第一案例集的测试。

如果不存在可用状态的设备资源，则直接根据测试环境定义参数生成第二虚拟环境资源，根据第二虚拟环境资源执行第一案例集的测试。

由于第一案例集是持续集成测试所必须要测试的重点案例，第二案例集的优先级低于第一案例集，通过将充足的尽量多的物理环境资源部署给第一案例集，保证第一案例集的测试能够充分实现，第二案例集的测试对于速度的要求相对第一案例集较低，因此，可以根据测试环境定义参数为第二案例集部署第三虚拟环境资源。

需要说明的是，为了实现虚拟环境资源的部署，在本发明实施例中，需要预先定义所有测试可能用到的环境的模板，并将模板在虚拟环境中部署和配置，根据测试环境定义参数，从模板部署机器，并做机器初始化。

考虑到为了第一案例集测试能更全面的发现重要问题，第一案例集包括界面测试案例集和应用程序接口测试案例集，根据物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果，可以按照如下步骤执行：

根据物理环境资源和虚拟环境资源，通过目标容器执行界面测试案例集，得到界面案例测试结果；根据物理环境资源和虚拟环境资源，通过目标容器执行应用程序接口测试案例集，得到应用程序案例测试结果；根据界面案例测试结果和应用程序案例测试结果生成第一测试结果。

在本发明实施例中，第一案例集是运行测试中最重要最核心的测试案例，特点是测试案例少，运行速度快，但是可以覆盖最核心的功能点。第一案例集包括界面测试案例集和应用程序接口测试案例集，其中，界面测试案例集可以是UI(User Interface)界面，应用程序接口测试案例集可以是API(Application Programming Interface，应用程序接口)。

企业级软件的部署方式支持通过UI界面部署，且为最重要的部署方式之一，因此本发明将通过UI界面的方式部署企业级软件放在最重要的第一案例集的测试中，通过自动化的脚本将界面测试案例集部署自动化。

企业级软件的功能的使用既支持UI操作的方式，同时又支持API调用的方式。部署方式亦是如此。UI测试的通过并不一定能保证API测试也能通过，而且API测试较UI测试相比，具有稳定性高，执行速度快的特点，为了保证构建结果的基本API的BQ质量，对API执行测试也是必要的，筛选出最重要，优先级高的API测试案例进行环境部署和执行，提高快速发现重要问题的能力。

在本发明实施例中，目标容器可以是Docker容器(应用容器引擎)。考虑到一般软件系统的核心功能是稳定的，本发明实施例将运行该第一案例集的模块做成Docker镜像，通过试案Docker的方式运行。并通过启动多个Docker容器并行运行测例，多个容器的执行相互隔离，互不影响，加快运行速度，提高快速发现重要问题的能力。

对界面测试案例集和应用程序接口测试案例集，可以并行进行测试，根据界面案例测试结果和应用程序案例测试结果得到第一测试结果。

为了便于迅速定位问题所在，根据界面案例测试结果和应用程序案例测试结果生成第一测试结果，可以按照如下步骤执行：

判断是否存在界面案例测试结果或应用程序接口测试案例集测试结果为测试失败；如果是，生成失败通知信息，并将失败通知信息发送至提醒模块；如果否，将界面案例测试结果和应用程序案例测试结果作为第一测试结果。

在本发明实施例中，在第一案例集的测试过程中，如果界面测试案例集或应用程序接口测试案例集中任一项测试结果为测试失败，生成失败通知信息，停止测试，并将失败通知信息发送至提醒模块，例如，提醒模块可以为相关测试和开发人员的预先设置的邮箱，将失败信息发送至邮箱，以便快速定位问题所在。如果第一案例集测试通过，则将界面案例测试结果和应用程序案例测试结果作为第一测试结果，启动后续测试步骤。

考虑到为了测试还包括全新按照测试和升级测试，其中，全新安装测试，与上述第一案例集相比，测试更为全面，覆盖高中低优先级的所有测试用例，以及更为复杂的安装配置场景，并且，升级测试中覆盖常用的用户升级路径，包括不同大版本之间的升级以及大小版本升级路径。测试案例包括升级过程测试和升级后的功能验证测试，可以将安装场景测试案例集和升级场景测试案例集划分至第二案例集，利用虚拟环境资源和第一测试结果执行第二案例集的测试，得到第二测试结果，可以按照如下步骤执行：

获取安装场景测试案例集的稳定级别信息，根据稳定级别信息确定安装场景测试案例集的测试方式；测试方式包括目标容器测试方式和系统测试方式；利用虚拟环境资源，采用目标容器测试方式或系统测试方式执行安装场景测试案例集的测试，得到安装场景测试案例集测试结果；获取升级场景测试案例集的升级路径信息；利用虚拟环境资源，按照识别序号和升级路径信息执行升级场景测试案例集，得到升级场景测试案例集测试结果；将安装场景测试案例集测试结果和升级场景测试案例集测试结果作为第二测试结果。

安装场景测试案例集包括在安装场景下执行的多个测试案例。升级场景测试案例集包括在升级场景下执行的多个测试案例。

在本发明实施例中，由于安装场景测试案例集可能数量较多，顺序执行会造成整个测试执行时间长，为解决该问题，可以预先设定各个安装场景测试案例的稳定级别信息，对于较稳定的安装场景测试案例设置较高的优先级，对于优先级较高的案例采用目标容器测试方式进行测试，例如，可以使用Docker容器进行测试，对于优先级较低的安装场景测试案例，例如，对于新功能的测试案例，由于一般新功能变动较大，可能会造成测试案例需要经常改动的情况，可以采用系统测试方法，如，采用直接在Linux运行的方式，需要更改案例代码时，直接更新代码运行即可，不需要更改Docker镜像。待新功能完成且比较稳定后，再将这些测试案例放入Docker镜像，采用容器运行的方式。稳定级别信息用于评估安装场景测试案例的稳定程度，具体对优先级的划分，可以根据稳定级别信息预先进行设定，本发明实施例对此不作具体限定。

一般企业级软件支持不同版本的升级以及不同版本的小版本之间的升级。该步骤按照客户常用的部署版本路径定义测试的升级路径，同全新安装一样，分为Golden stack和Silver stack。不同的stack对应不同的升级路径。如Golden stack定义为7.1->7.1.1->8.0的升级路径，Silver stack定义为6.3->6.3.2->8.0的升级路径，获取这些升级路径相关的数据，得到升级路径信息，本发明实施例的测试框架支持同一框架同时支持全新安装、不同版本及小版本之间的升级，只需将各个版本的识别序号作为参数传入，通过该识别序号即可确定相应的构建结果，从而，框架便可以自动判断为全新安装或升级，若为升级，自动判断升级路径，由于各个版本间的升级扫描并不相同，本发明实施例可以依据不同的升级路径选择对应的操作进行升级。

考虑到为了便于相关人员获取测试结果，根据第一测试结果和第二测试结果生成持续集成测试结果，可以按照如下步骤执行：

根据第一测试结果和第二测试结果生成测试统计信息；将测试统计信息发送至显示模块，以使显示模块显示统计信息；根据企业级软件的系统日志数据和测试案例的执行日志数据生成日志信息；将统计信息和日志信息作为持续集成测试结果。

在本发明实施例中，包括Docker中并行运行测试案例和在Linux系统上直接运行测试案例的步骤，因此，首先收集第一测试结果和第二测试结果，之后，基于收集到的信息进行统计，例如，统计测试案例的执行情况，包括总共执行的测试用例数，通过的测试用例数，失败的测试用例数，忽略的测试用例数，以及按不同模块分的统计情况等，得到统计信息，并将统计信息发送显示模块，进行显示，便于相关人员了解各类案例的执行情况。

在本发明实施例中，还可以收集所部署的企业级软件的系统日志，以及收集所有容器测试的日志以及主机运行测试用例的日志，并将收集的日志，打包并上传到持续集成平台，测试或开发人员分析失败测试案例时可以直接下载查看。

考虑到测试案可能存在不能运行的情况，为了保证测试效率，该方法还可以包括如下步骤：

生成忽略列表；利用忽略列表存储目标测试案例；目标测试案例不用于执行测试任务。

在本发明实施例中，系统存在某些错误导致某些测试案例不能通过，而这些错误能通过的测试案例作为目标测试案例，在修复之前先将这些目标测试案例加入忽略列表，在忽略列表中的测试案例本次测试不运行，修复好之后，再将这些案例加入测试列表。

为了保证测试的覆盖程度，获取测试环境定义参数之前，还可以执行如下步骤：

获取执行计划数据、第一场景数据和第二场景数据；按照执行计划数据确定第一场景数据的第一执行日期和第二场景数据的第二执行日期；根据第一执行日期和第一场景数据执行持续集成测试方法，根据第二执行日期和第二场景数据执行持续集成测试方法。

在本发明实施例中，执行计划数据用于确定按照第一场景数据和第二场景数据进行持续集成测试的日期。例如，可以通过执行计划数据，预先设置日期为奇数则按照第一场景数据执行，日期为偶数则按照第二场景数据执行持续集成测试方法，从而实现不同场景的交替执行。具体的执行计划数据可以根据实际需求进行设置，本发明实施例对此不作具体限定。

需要说明的是，第一场景数据和第二场景数据可以按照场景的重要程度划分，例如将使用频率较高或者使用人数较多的场景相关的配置数据，确定为第一场景数据，将使用频率较低或者使用人数较少的场景相关的配置数据，确定围第二场景数据。例如，Goldenstack为主要安装配置，则相关的配置数据为第一场景数据，Silver stack次要安装配置，则相关的配置数据为第二场景数据。

另外需要说明的是，根据第一场景数据或第二场景数据可以确定持续集成测试方法运行所需要的操作系统版本数据、网络类型数据、存储方式数据、存储位置数据以及存储类型数据等。

参见图2所示的持续集成测试方法实施流程图，下面以一个具体实施例该方法的执行过程进行说明。

步骤100，开发代码提交，触发代码扫描验证，验证通过，代码评审并合并代码。

步骤200，定时触发构建任务，构建成功后将构建放至构建仓库。

由于企业级软件的构建时间一般较长，自动化测试周期也相对较长，所以传统的持续集成方法中每次代码提交即触发构建的方式不适合企业级软件，可能造成本次构建尚未测试完成，而下次构建已经开始的情况。且企业级软件的发布周期较互联网类软件也相对较长，并不需要每次代码提交都完成测试并发布。定时构建的方式(如2次/日，可根据具体的企业级软件灵活调整)既可以满足所提交代码相对及时的得到测试，满足发布需求，也可避免每次构建测试造成的资源浪费。

步骤300，定时触发持续集成测试流水线。

步骤400，执行第一案例集测试。

包括一个配置的UI测试和一个配置的API测试。

步骤500，执行完整测试。

包括多个配置的第二案例集API测试和多个配置的升级测试。

步骤600，测试结果收集。

步骤700，测试结果发布。

步骤800，日志收集。

步骤300包括下列步骤：

步骤310，定时触发持续集成流水线任务的工作项。

步骤320，以上工作项自动判断是否需要执行本测试，若需要，执行步骤330，若不需要，结束。

在该工作项中设置逻辑，判断该工作项最近一次运行成功所使用的构建号(识别序号)，如果该次运行的构建已经跑过测试，则结束，不触发后续的测试工作。设置此逻辑的目的在于有些情景下，由于代码或者环境原因，构建失败，而上次构建已经运行过测试，避免重复运行相同的测试，耗费资源以及对测试结果重复进行人工分析。

步骤330，预先为测试环境定义Golden stack/Silver stack配置。Golden stack/Silver stack为根据客户的使用情况和产品的部署情况定义的软件的不同的安装配置。Golden stack为主要安装配置(对应主流客户使用软件时的安装配置情况)。

Silver stack为优先级稍低的次要安装配置情况。为了做到测试的全覆盖，本发明自动在Golden stack和Silver stack切换，并将所选的Golden stack或Silver stack的配置部署信息传给后续的步骤400，用以部署不同的环境并做测试。

步骤400包括下列步骤：

步骤410，资源判定。本发明中测试环境分为两类：物理环境和虚拟环境。物理环境为实体的机器，无需重新部署和配置，配置高，速度快，缺点是价格高，专门留给测试人员的资源有限。虚拟环境为采用vmware(威睿)的vsphere，vc解决方案，在vmware虚拟环境中部署Linux/Windows机器。每次测试均需部署。由于多套测试环境共享资源池，导致速度和运行测试的效率比物理环境低。

本发明将物理环境放到一个特定的资源池，为提高第一案例集测试的运行速度，提高严重问题发现的效率，第一案例集测试根据步骤330的部署配置信息，优先从物理环境资源池中选择环境资源。若有可用物理环境资源，则选择机器，执行步骤430。若没有，执行步骤420。

步骤420，预先定义所有测试可能用到的环境的模板，并将模板在vmware虚拟环境中部署和配置。根据步骤330的配置信息，从模板部署机器，并做机器初始化(开机，系统数据配置，设定IP等)。

步骤430，第一案例集测试为运行测试中最重要最核心的测试案例，特点是测试案例少，运行速度快，但是可以覆盖最核心的功能点。所以本发明持续集成流水线中最先运行第一案例集测试，若第一案例集测试通过，则执行步骤500，否则立即邮件通知相关人员进行问题定位和分析。同时为了第一案例集测试能更全面的发现重要问题，本发明将第一案例集测试拆分为两个Job并行运行。即步骤4310和步骤4320。

步骤4310，UI第一案例集测试。该步骤包括以下两个子步骤：

步骤4311，通过UI的方式部署企业级软件。

一般企业级软件的部署方式支持通过UI界面部署，且为最重要的部署方式之一，因此本发明将通过UI的方式部署企业级软件放在最重要的第一案例集测试中，通过自动化的脚本将UI部署自动化。若该步骤执行失败，执行步骤4330。

步骤4312，UI对主要功能的自动化测试。

客户对软件的使用主要为通过UI的方式，通过UI对核心功能的验证是非常重要的。因此本发明实施例将UI对核心功能的自动化测试放在第一案例集测试中。同时，因为一般软件系统的核心功能是稳定的，本发明将运行该核心功能测试案例的模块做成Docker镜像，通过试案Docker的方式运行。并通过启动多个Docker容器并行运行测例，多个容器的执行相互隔离，互不影响，加快运行速度，提高快速发现重要问题的能力。若该步骤执行失败，执行步骤4330。

一般UI测试框架在windows运行，本测试采用在Linux运行，采用远程连接vncserver(一个为了满足分布式用户共享服务器上面的资源，而在服务器上开启的一项服务)的方式启动浏览器。

步骤4320，API第一案例集测试。

一般企业级软件的功能的使用既支持UI操作的方式，同时又支持API调用的方式。部署方式亦是如此。UI，具有稳定性高，执行速度快的特点，为了保证构建的基本API的BQ的质量，对API执行第一案例集测试也是必要的，筛选出最重要，优先级高的API测试案例进行环境部署和执行，提高快速发现重要问题的能力。

该步骤与步骤4310并行执行。并包括以下两个子步骤。

步骤4321，通过API的方式部署企业级软件。

通过调用系统部署的API的方式而非通过界面对企业级软件进行部署。该部署方式的特点运行稳定，速度快。若该步骤执行通过，执行步骤500，若失败，执行步骤4330。

步骤4322，对主要功能的API测试。

本发明在创建测试用例时，需要定义测试用例的优先级，测试框架会自动筛选优先级高的测试用例放入第一案例集测试，对软件的核心功能通过API的方式进行接口测试。同步骤4312，该步骤也采用Docker容器并行执行的方式，测试完成后，对执行测试后的环境保存生成新的Docker镜像。后续如果测试出现问题，需要重现问题时，可以直接启动该Docker镜像运行案例，方便重现。若该步骤执行通过，执行步骤500，若失败，执行步骤4330。

步骤4330，若上述UI案例或API案例测试任一测试失败，则停止执行流水线的后续步骤，并发邮件通知相关测试和开发人员，以便迅速定位问题所在。若测试通过，执行步骤500。

步骤500执行第二案例集测试。第二案例集测试又划分为全新安装测试和升级测试。全新安装测试中较步骤400相比，测试更为全面，覆盖高中低优先级的所有测试用例，以及更为复杂的安装配置场景。升级测试中覆盖常用的用户升级路径，包括不同大版本之间的升级以及大小版本升级路径。测试案例包括升级过程测试和升级后的功能验证测试。该步骤包括下列子步骤：

步骤510，执行全新安装的API测试。

该步骤的部署过程与步骤4321类似，是通过API的方式安装。因为界面UI安装的验证已在步骤4311验证，所以本步骤采用速度较快，并且自动化运行较稳定的API安装的方式来进行，随后进行测试。该步骤包括下列子步骤：

步骤511，API的方式安装部署企业级软件。

由于快速验证构建质量已在第一案例集测试中验证，因此本阶段对测试结果的及时性要求稍差，而考虑到物理资源的高成本和有限性，本阶段部署资源的选定为在vmware虚拟环境中部署，节省成本，同时满足测试结果的及时性要求。

步骤512，执行第二案例集API测试。

本步骤在步骤511完成后，顺序执行。本发明在创建测试用例时，需要定义测试用例的优先级，测试框架会自动筛选相应的测试用例放入第二案例集测试中，得出需要跑的第二案例集测试的测试案例列表，执行案例。

本发明实施例包括如下特点：

(1)在筛选测试用例列表时，灵活支持忽略测试，即可以灵活的将某个/某些测试用例加入到忽略列表，在忽略列表中的测试案例本次测试不运行。此功能的应用于如下场景：系统存在某些错误导致某些测试案例不能通过，而这些错误不能在短时间内修复，在修复之前这些案例都会失败，为了避免重复分析，在修复之前先将这些案例加入忽略测试案例列表，不对这些案例进行测试，修复只好再将这些案例加入测试列表。

(2)第二案例集测试的测试案例比较多，顺序执行会造成整个测试执行时间长，为解决该问题，本发明采用Docker运行测试案例与Linux直接运行案例相结合的方式。对于已经稳定的功能，测试案例变动不大，将其做成Docker镜像，同时启动多个Docker运行，相互隔离互不影响，提高运行效率。对于新功能的测试案例，由于一般新功能变动较大，可能会造成测试案例需要经常改动的情况，采用直接在Linux运行的方式，需要更改案例代码时，直接更新代码运行即可，不需要更改Docker镜像。待新功能完成且比较稳定后，再将这些测试案例放入Docker镜像，采用容器运行的方式。

步骤520，执行升级测试。

该步骤分为以下子步骤：

步骤521，定义升级路径。

一般企业级软件支持不同版本的升级以及不同版本的小版本之间的升级。该步骤按照客户常用的部署版本路径定义测试的升级路径，同全新安装一样，分为Golden stack和Silver stack。不同的stack对应不同的升级路径。如Golden stack定义为7.1->7.1.1->8.0的升级路径，Silver stack定义为6.3->6.3.2->8.0的升级路径。

步骤522，升级自动化测试。

按照步骤521的升级路径进行升级测试。本发明的测试框架支持同一框架同时支持全新安装、不同版本及小版本之间的升级，只需将各个版本的构建号作为参数传入，框架便可以自动判断为全新安装或升级，若为升级，自动判断升级路径，由于各个版本间的升级扫描并不相同，本发明依据不同的升级路径选择对应的操作进行升级。

该步骤分为以下子步骤：

步骤5221，升级路径判断。

若框架启动时，所传构建参数只有一个构建号(识别序号)，则判定为全新安装，执行全新安装的操作(与步骤511相同)；

若所传构建参数有多个，则根据构建号去构建仓库查询，查出对应的版本号，若版本号为基础版本和基础版本的patch，如7.1和7.1.1,则执行步骤52221；

若版本号即存在patch版本，又存在升级本版，则执行patch到升级或者升级后patch的操作，即步骤52222。如版本号为7.1,7.1.1,8.0,则执行安装7.1->patch到7.1.1->升级到8.0，如版本号为7.1,8.0,8.0.1,则执行7.1->升级到8.0->patch到8.0.1。

步骤5222，企业级软件升级执行，分为以下子步骤：

步骤52221，执行patch操作。

该步骤在初始版本的基础上执行安装patch。

步骤52222，执行patch和升级操作。

该步骤通过判断整个路径，灵活支持多个patch和多种升级路径。

步骤523，升级后功能验证。

升级完成后执行功能验证，验证企业级软件在升级后主要功能依然正常工作。由于第二案例集测试全新安装中已经做了全测试覆盖，而升级测试的目的之一是验证升级过程，因此升级完成后的功能验证主要放在优先级高的测试用例，主要分为两类：其一为旧版本已有的主要功能的验证，其二为新版本新增功能验证(目的是测试新功能在升级环境中不出现问题)。该步骤的所有测试用例为高优先级用例且第二部分新增功能验证为全新安装中已经稳定的案例，因此采用Docker容器并行运行的方式。

步骤510和步骤520为并行执行的Job。原因为步骤400已测试通过，最核心的安装和功能已验证，表示构建可用，因此后续的第二案例集测试可以并行运行。

步骤600，测试结果收集。

测试结果收集将以上单次部署所运行的测试用例结果收集汇总。包括一下子步骤：

步骤610，由于上述执行测试用例的步骤中，有两种运行测试案例的方式，在多个Docker中并行运行测试案例和在Linux系统上直接运行测试案例，因此测试结束后，需要将这些测试结果收集。本步骤通过Docker cp将各个容器运行的测试用例的结果拷贝至运行测试框架的宿主机，并与主机本身运行测试用例的结果合并，生成html文件，供前端展示和下载查看。

步骤620，统计。

统计测试案例的执行情况，包括总共执行的测试用例数，通过的测试用例数，失败的测试用例数，忽略的测试用例数，以及按不同模块分的统计情况。

步骤700，测试结果发布。

本持续集成方法包含一个重要的结果发布模块，结果发布模块包括前端和后端，后端为测试结果提供数据，前端用来展示。第一案例集测试通过后，自动更新构建号至展示页面的BQ构建号，并带有构建下载链接。预使用该软件的相关的开发测试人员不用通过查看详细的测试结果便可获得构建的情况，比如最近可用的测试构建号等。第二案例集测试完成后，将更新详细测试结果的链接到展示页面，该页面保留最近一周的持续集成构建运行的状况，包括案例执行统计以及详情链接，相关测试开发人员若想了解某次执行情况，即可点击查看。

步骤800，日志收集。

本步骤包括下列子步骤：

步骤810，企业级软件系统日志收集。

收集所部署的企业级软件的系统日志

步骤820，测试日志收集。

收集所有容器测试的日志以及主机运行测试用例的日志。

步骤830，日志归集、打包、上传。

将步骤810和步骤820的日志归集到一起，打包并上传到持续集成平台，测试或开发人员分析失败测试案例时可以直接下载查看。

步骤900，测试结果通知、邮件发送。

执行完毕后，自动发送测试结果给相关人员。对不同的测试结果，灵活定义不同的收件人列表和邮件级别，以便相关人员采取不同的应对措施。如第一案例集测试失败时，只发送给相关持续集成测试人员和开发人员，邮件级别高，以便相应人员立即处理。测试全部成果时，发送成功邮件给所有测试人员组。

为了实现上述各步骤，参见图3所示的持续集成测试方法实施流程所用装置的模块架构图，可以设置持续集成测试装置，具体包括如下模块：

模块100：启动与测试准备模块，该模块包括以下几个子模块：模块110：任务触发模块，用以实现步骤310；

模块120：构建获取与判断模块，用以实现步骤320；

模块130：环境部署模块，用以实现步骤400中的环境部署；

模块200：安装与升级模块，该模块包括以下几个子模块：

模块210：安装/升级路径处理模块，用以实现步骤520中的升级/安装相关路径的操作；

模块220：安装模块，用以实现4311UI部署和4321API部署；

模块230：Patch模块，用以实现步骤520中的patch操作；

模块240：升级模块，用以实现步骤520中的升级操作；

模块250：安装/升级结果检测模块，用以实现步骤520中的验证；

模块300：测试模块，该模块包括以下几个子模块：

模块310：测试用例筛选模块，按照第一案例集或者第二案例集测试所测模块，筛选出本次测试所需的所有测试用例；

模块320：测试用例忽略模块，用于实现步骤512中的灵活忽略测试用例功能；

模块330：Docker容器测试模块，用以实现步骤512的容器运行测试用例；

模块340：Linux运行测试用例模块，用以实现步骤512的Linux直接运行测试用例；

模块400：结果收集统计模块，该模块包括以下几个子模块：

模块410：测试结果收集模块，用以实现步骤610的测试结果收集；

模块420：测试结果汇总模块，用以实现步骤620的测试结果统计；

模块430：测试日志收集模块，用以实现步骤820的测试日志收集功能；

模块440：系统日志收集模块，用以实现步骤810的系统日志收集功能；

模块450：日志汇总模块，用以实现步骤830的日志归集、打包、上传功能；

模块500：通知模块，用以实现步骤900中的测试结果通知、邮件发送功能；

模块600：结果展示模块；

模块610：健康构建展示模块；

模块620：详细结果展示模块；

上述两个模块用以实现步骤700中的测试结果发布功能。

本发明实施例例提供了一种持续集成测试方法及装置，该方法采用物理环境和虚拟环境相结合的方式，在不同测试阶段灵活选择不同的部署环境；结合测试不同阶段和测试案例的不同特点，灵活采用Docker容器和直接在Linux运行测试用例；灵活忽略测试案例；同一测试框架，通过配置驱动，灵活支持全新安全和不同路径升级，无需更改代码；主要、次要配置场景(文中所述Golden stack、Silver stack)交替执行达到全覆盖。

本发明实施例还提供一种持续集成测试装置，参见图4所示的持续集成测试装置结构框图，该装置包括：

获取模块71，用于获取测试环境定义参数；部署模块72，用于根据测试环境定义参数为测试案例确定测试环境资源；测试环境资源包括物理环境资源和虚拟环境资源；测试案例包括第一案例集和第二案例集；第一案例集的优先级高于第二案例集；第一测试模块73，用于利用物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果；第二测试模块74，用于利用虚拟环境资源并根据第一测试结果执行第二案例集的测试，得到第二测试结果；结果模块75，用于根据第一测试结果和第二测试结果生成持续集成测试结果。

在一个实施例中，该装置还包括构建模块，用于：按照预设时长间隔启动构建任务，得到构建结果；构建结果包括识别序号；根据识别序号判断构建结果是否已更新；如果是，根据构建结果启动第一案例集的测试。

在一个实施例中，部署模块，具体用于：判断是否存在可用状态的设备资源；如果是，根据可用状态的设备资源确定第一案例集的第一物理环境资源，并根据测试环境定义参数判断第一物理环境资源是否不小于第一案例集测试所需资源；如果第一物理环境资源不小于第一案例集测试所需资源，则将第一物理环境资源作为第一案例集的测试环境资源；如果第一物理环境资源小于第一案例集测试所需资源，根据测试环境定义参数生成第一虚拟环境资源，并将第一物理环境资源和第一虚拟环境资源作为第一案例集的测试环境资源；如果否，根据测试环境定义参数生成第二虚拟环境资源，并将第二虚拟环境资源作为第一案例集的测试环境资源；根据测试环境定义参数生成第三虚拟环境资源，并将第三虚拟环境资源作为第二案例集的测试环境资源。

在一个实施例中，第一案例集包括界面测试案例集和应用程序接口测试案例集；第一测试模块，具体用于：根据物理环境资源和虚拟环境资源执行第一案例集的测试，得到第一测试结果，包括：根据物理环境资源和虚拟环境资源，通过目标容器执行界面测试案例集，得到界面案例测试结果；根据物理环境资源和虚拟环境资源，通过目标容器执行应用程序接口测试案例集，得到应用程序案例测试结果；根据界面案例测试结果和应用程序案例测试结果生成第一测试结果。

在一个实施例中，第一测试模块，具体用于：判断是否存在界面案例测试结果或应用程序接口测试案例集测试结果为测试失败；如果是，生成失败通知信息，并将失败通知信息发送至提醒模块；如果否，将界面案例测试结果和应用程序案例测试结果作为第一测试结果。

在一个实施例中，第二案例集包括安装场景测试案例集和升级场景测试案例集，第二测试模块，具体用于：根据虚拟环境资源和第一测试结果执行第二案例集的测试，得到第二测试结果，包括：获取安装场景测试案例集的稳定级别信息，根据稳定级别信息确定安装场景测试案例集的测试方式；测试方式包括目标容器测试方式和系统测试方式；根据虚拟环境资源，采用目标容器测试方式或系统测试方式执行安装场景测试案例集的测试，得到安装场景测试案例集测试结果；获取升级场景测试案例集的升级路径信息；根据虚拟环境资源，按照识别序号和升级路径信息执行升级场景测试案例集，得到升级场景测试案例集测试结果；将安装场景测试案例集测试结果和升级场景测试案例集测试结果作为第二测试结果。

在一个实施例中，结果模块，具体用于：根据第一测试结果和第二测试结果生成测试统计信息；将测试统计信息发送至显示模块，以使显示模块显示统计信息；根据企业级软件的系统日志数据和测试案例的执行日志数据生成日志信息；将统计信息和日志信息作为持续集成测试结果。

在一个实施例中，该装置还包括列表模块，用于：生成忽略列表；利用忽略列表存储目标测试案例；目标测试案例不用于执行测试任务。

本发明实施例还提供一种计算机设备，参见图5所示的计算机设备结构示意框图，该计算机设备包括存储器81、处理器82，存储器中存储有可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一种方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的计算机设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述

本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，程序代码使处理器执行上述任一种方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种持续集成测试方法，其特征在于，应用于企业级软件，所述方法包括：

获取测试环境定义参数；

根据所述测试环境定义参数为目标测试案例集确定测试环境资源；所述测试环境资源包括物理环境资源和虚拟环境资源；所述目标测试案例集包括第一案例集和第二案例集；所述第一案例集的优先级高于所述第二案例集；

利用所述物理环境资源和所述虚拟环境资源执行所述第一案例集的测试，得到第一测试结果；

利用所述虚拟环境资源并根据所述第一测试结果执行所述第二案例集的测试，得到第二测试结果；

根据所述第一测试结果和所述第二测试结果生成持续集成测试结果。

2.根据权利要求1所述的方法，其特征在于，获取测试环境定义参数之前，还包括：

按照预设时长间隔启动构建任务，得到构建结果；所述构建结果包括识别序号；

根据所述识别序号判断所述构建结果是否已更新；

如果是，根据所述构建结果启动第一案例集的测试。

3.根据权利要求1所述的方法，其特征在于，根据所述测试环境定义参数为目标测试案例集确定测试环境资源，包括：

判断是否存在可用状态的设备资源；

如果是，根据所述可用状态的设备资源确定第一案例集的第一物理环境资源，并根据所述测试环境定义参数判断所述第一物理环境资源是否不小于第一案例集测试所需资源；

如果所述第一物理环境资源不小于第一案例集测试所需资源，则将所述第一物理环境资源作为第一案例集的测试环境资源；

如果所述第一物理环境资源小于第一案例集测试所需资源，根据所述测试环境定义参数生成第一虚拟环境资源，并将所述第一物理环境资源和所述第一虚拟环境资源作为第一案例集的测试环境资源；

如果否，根据所述测试环境定义参数生成第二虚拟环境资源，并将所述第二虚拟环境资源作为第一案例集的测试环境资源；

根据所述测试环境定义参数生成第三虚拟环境资源，并将所述第三虚拟环境资源作为第二案例集的测试环境资源。

4.根据权利要求1所述的方法，其特征在于，所述第一案例集包括界面测试案例集和应用程序接口测试案例集；

根据所述物理环境资源和所述虚拟环境资源执行所述第一案例集的测试，得到第一测试结果，包括：

根据所述物理环境资源和所述虚拟环境资源，通过目标容器执行所述界面测试案例集，得到界面案例测试结果；

根据所述物理环境资源和所述虚拟环境资源，通过目标容器执行所述应用程序接口测试案例集，得到应用程序案例测试结果；

根据所述界面案例测试结果和所述应用程序案例测试结果生成第一测试结果。

5.根据权利要求4所述的方法，其特征在于，根据所述界面案例测试结果和所述应用程序案例测试结果生成第一测试结果，包括：

判断是否存在所述界面案例测试结果或所述应用程序案例测试结果为测试失败；

如果是，生成失败通知信息，并将所述失败通知信息发送至提醒模块；

如果否，将所述界面案例测试结果和所述应用程序案例测试结果作为第一测试结果。

6.根据权利要求2所述的方法，其特征在于，所述第二案例集包括安装场景测试案例集和升级场景测试案例集；

利用所述虚拟环境资源和所述第一测试结果执行所述第二案例集的测试，得到第二测试结果，包括：

获取所述安装场景测试案例集的稳定级别信息，根据所述稳定级别信息确定所述安装场景测试案例集的测试方式；所述测试方式包括目标容器测试方式和系统测试方式；

利用所述虚拟环境资源，采用所述目标容器测试方式或所述系统测试方式执行所述安装场景测试案例集的测试，得到安装场景测试案例集测试结果；

获取所述升级场景测试案例集的升级路径信息；

利用所述虚拟环境资源，按照所述识别序号和所述升级路径信息执行所述升级场景测试案例集，得到升级场景测试案例集测试结果；

将所述安装场景测试案例集测试结果和所述升级场景测试案例集测试结果作为第二测试结果。

7.根据权利要求1所述的方法，其特征在于，根据所述第一测试结果和所述第二测试结果生成持续集成测试结果，包括：

根据所述第一测试结果和所述第二测试结果生成测试统计信息；

将所述测试统计信息发送至显示模块，以使所述显示模块显示所述统计信息；

根据所述企业级软件的系统日志数据和测试案例的执行日志数据生成日志信息；

将所述统计信息和所述日志信息作为持续集成测试结果。

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

生成忽略列表；

利用所述忽略列表存储目标测试案例；所述目标测试案例不用于执行测试任务。

9.根据权利要求1-7任一项所述的方法，其特征在于，获取测试环境定义参数之前，还包括：

获取执行计划数据、第一场景数据和第二场景数据；

按照所述执行计划数据确定所述第一场景数据的第一执行日期和所述第二场景数据的第二执行日期；

根据所述第一执行日期和所述第一场景数据执行所述持续集成测试方法，根据所述第二执行日期和所述第二场景数据执行所述持续集成测试方法。

10.一种持续集成测试装置，其特征在于，包括：

获取模块，用于获取测试环境定义参数；

部署模块，用于根据所述测试环境定义参数为目标测试案例集确定测试环境资源；所述测试环境资源包括物理环境资源和虚拟环境资源；所述目标测试案例集包括第一案例集和第二案例集；所述第一案例集的优先级高于所述第二案例集；

第一测试模块，用于根据所述物理环境资源和所述虚拟环境资源执行所述第一案例集的测试，得到第一测试结果；

第二测试模块，用于根据所述虚拟环境资源和所述第一测试结果执行所述第二案例集的测试，得到第二测试结果；

结果模块，用于根据所述第一测试结果和所述第二测试结果生成持续集成测试结果。

11.一种计算机设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1至9任一项所述的方法的步骤。

12.一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行上述权利要求1至9任一项所述的方法。

Images