CN114706790B - 一种自动化软件测试方法、装置及设备 - Google Patents

Abstract

本申请实施例涉及计算机领域，公开了一种自动化软件测试方法、装置及设备。本申请实施例涉及的软件测试方法包括：在应用场景中存在多个项目共用一个触发规则的情况下，获取项目测试需求；依据项目测试需求调用项目关系信息，得到至少一个目标项目关系信息；调用触发规则，得到目标触发规则；调用触发器启动软件测试，触发器设置在代码仓库与集成工具之间。这样，一方面，触发规则库中存入多种触发规则，并通过预设的项目关系库中项目关系信息，可以实现同一个触发器在不同场景对于不同触发规则的调用，提高了触发器对多应用场景的兼容性；第二方面，通过预设建立项目与触发规则标识的联系，实现对触发规则的数据化驱动，从而减少人工维护成本。

Description

一种自动化软件测试方法、装置及设备

技术领域

本发明实施例涉及计算机领域，具体涉及一种自动化软件测试方法、装置及设备。

背景技术

在软件构建过程中，由于部分开发项目规模较大，通常需要多人合作。但是由于构建过程过于复杂，人工构建存在出错风险，因此需要自动化软件构建技术来进行软件功能测试。

在自动化软件构建中，触发器是其中较为关键的部分。触发器作为连接程序开发和自动化测试的纽带，其功能是当代码提交到代码仓库后，触发器依据预设的触发规则启动后续自动化测试流程。

现有的自动化软件构建系统中，触发器存在如下缺陷：首先，由于每个应用场景中通常仅存在一个触发规则，因此每个触发器只能在单独的一个应用场景中使用，无法适应多应用场景的需求。并且，当一个应用场景中存在多个项目共用同一个触发规则时，一方面，需要为每个项目分别单独设定触发规则，另一方面，当触发规则需要改变的时候，也需要对场景中的每个项目设定新的触发规则，导致维护成本过大。

发明内容

本申请实施例提供了一种自动化软件测试方法、装置及设备，以解决现有测试兼容性弱，以及测试效率低的问题。

第一方面，本申请实施例提供了一种自动化软件测试方法，所述方法包括：

在一个应用场景中存在多个项目共用同一个触发规则的情况下，获取至少一个项目测试需求；

分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标关系信息的内容包括：每个项目对应应用场景的关系以及每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

调用触发器根据至少一个目标触发规则启动软件测试，所述触发器设置在代码仓库以及集成工具之间。

这样，一方面通过在预先设置的触发规则库中预先存入至少一个触发规则，可以为触发器在不同场景下提供触发规则，实现了同一个触发器在不同应用环境的兼容；另一方面，通过预设的项目关系库中每个项目对应触发规则标识的关系，可以使系统通过标识对触发规则进行调用，以此实现对触发规则的数据驱动，减小维护成本。

在一些可能的实施方式中，所述项目关系信息内容还包括：每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系。这样，可以通过项目关系信息包括的内容确定同项目测试需求对应的项目对应的后续测试流程，以此实现后续的软件测试。

在一些可能的实施方式中，所述触发规则库中内容包括：至少一个触发规则以及每个触发规则对应的标识。这样，可以通过预设的项目关系库中每个项目对应触发规则标识的关系实现系统对触发规则的调用，以此实现触发规则的数据驱动，减小维护成本。

在一些可能的实施方式中，所述触发规则的内容依据预设在关键字库中的内容生成。这样，用户可以通过更新关键字库中的内容进而对触发规则进行更新、修改以及增加，以此降低用户对于测试系统的使用难度。

在一些可能的实施方式中，所述关键字库中的内容包括：普通关键字、关系关键字以及正则关键字。这样，可以使用户依据需求选择相应的关键字内容，实现对触发规则的自定义，以此扩大了触发规则的类别，并降低了用户对于测试系统的使用难度。

在一些可能的实施方式中，其特征在于，所述普通关键字内容的包括：项目代码提交分支信息、项目代码提交版本信息、项目备注信息、项目提交人信息以及项目提交时间信息。

在一些可能的实施方式中，所述项目关系库以及触发规则库的内容均依据实际需求进行定义和更新。这样，当具有更新需求的时候，用户无需针对每个项目重新建立对应触发规则的关系以及维护，以此减小维护成本。

第二方面，本申请实施例还提供了一种自动化软件测试装置，其特征在于，所述装置包括：

获取模块，用于在一个应用场景中存在多个项目共用同一个触发规则的情况下，获取至少一个项目测试需求；

第一调用模块，用于分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标项目关系信息内容包括：每个项目对应应用场景的关系以及每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

第二调用模块，用于依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

测试模块，用于调用触发器根据至少一个目标触发规则启动软件测试，所述触发器设置在代码仓库以及集成工具之间。

第三方面，本申请实施例还提供了一种电子设备，所诉电子设备包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存储有可执行指令，所述可执行指令运行时使所述处理器执行第一方面或者第二方面任一可能的实施方式中的测试方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述存储介质中存储有可执行指令，所述可执行指令运行时使计算设备执行第一方面或者第二方面任一可能的实施方式中的测试方法。

本申请实施例提供了一种自动化软件测试方法，本方案中，测试系统在获取至少一个测试需求后，依据测试需求，调用预设在项目关系库中的项目关系信息，依据项目关系信息中每个项目对应触发规则的标识关系以及每个项目对应应用场景的关系，在预设的触发规则库中实现对相应触发规则的调用，得到至少一个目标触发规则，最后依据至少一个目标触发规则进行软件测试。一方面，在预设的触发规则库中存入多种触发规则，并且通过预设的项目关系库中项目关系信息，可以实现同一个触发器在不同场景对于不同触发规则的调用，提高了触发器对于多应用场景的兼容性；第二方面，通过预设建立项目与触发规则标识的联系，实现了对触发规则的数据化驱动，当系统出现更新需求时仅需使项目同其它标识的触发规则建立联系，无需针对触发规则进行更新，从而减少了人工维护成本；第三方面，使用关键字库实现对触发规则的生成，使用户可以依据关键字库内容进行选择以及触发规则的自定义编辑，降低了测试系统的使用难度。

附图说明

图1是本申请实施例提供的软件测试方法流程示意图；

图2是本申请实施例提供的软件测试方法具体作用在触发器的应用流程示意图；

图3是本申请实施例提供的策略模型训练方法装置示意图；

图4是本申请实施例提供的策略模型训练电子设备示意图。

具体实施方式

本申请以下实施例中所使用的术语是为了描述可选实施方式的目的，而非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式。还应当理解，尽管在以下实施例中可能采用术语第一、第二等来描述某一类对象，但所述对象不限于这些术语。这些术语用来将该类对象的具体对象进行区分。例如，以下实施例中可能采用术语第一、第二等来描述的其他类对象同理，此处不再赘述。

本申请实施例提供了一种自动化软件测试方法，本方案中，测试系统在获取至少一个测试需求后，依据测试需求，调用预设在项目关系库中的项目关系信息，依据项目关系信息中每个项目对应触发规则的标识关系以及每个项目对应应用场景的关系，在预设的触发规则库中实现对相应触发规则的调用，得到至少一个目标触发规则，最后依据至少一个目标触发规则进行软件测试。一方面，在预设的触发规则库中存入多种触发规则，并且通过预设的项目关系库中项目关系信息，可以实现同一个触发器在不同场景对于不同触发规则的调用，提高了触发器对于多应用场景的兼容性；第二方面，通过预设建立项目与触发规则标识的联系，实现了对触发规则的数据化驱动，当系统出现更新需求时仅需使项目同其它标识的触发规则建立联系，无需针对触发规则进行更新，从而减少了人工维护成本；第三方面，使用关键字库实现对触发规则的生成，使用户可以依据关键字库内容进行选择以及触发规则的自定义编辑，降低了测试系统的使用难度。

本申请实施例提供的测试方法可以由一个电子设备执行，也可以由计算机集群执行。该计算机集群包括至少两个支持本申请实施例的测试方法的电子设备，任一电子设备可通过测试方法实现本申请实施例所描述的算法训练模型测试的功能。

本申请实施例设计的任一电子设备可以是诸如手机、平板电脑、可穿戴设备(例如，智能手表、只能手环等)、笔记本电脑、台式计算机和车载设备等电子设备。该电子设备预先安装有策略模型训练应用程序。可以理解的是，本申请实施例对电子设备的具体类型不作任何限制。

在软件构建过程中，由于部分开发项目规模较大，通常需要多人合作。但是由于构建过程过于复杂，人工构建存在出错风险，因此需要自动化软件构建技术来进行软件功能测试。

在自动化软件构建中，触发器是其中较为关键的部分。触发器作为连接程序开发和自动化测试的纽带，其功能是当代码提交到代码仓库后，触发器依据预设的触发规则启动后续自动化测试流程。

现有的自动化软件构建系统中，触发器存在如下缺陷：首先，由于每个应用场景中通常仅存在一个触发规则，因此每个触发器只能在单独的一个应用场景中使用，无法适应多应用场景的需求。并且，当一个应用场景中存在多个项目共用同一个触发规则时，一方面，需要为每个项目分别单独设定触发规则，另一方面，当触发规则需要改变的时候，也需要对场景中的每个项目设定新的触发规则，导致维护成本过大。

下面是对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。

参见图1，图1是本申请实施例提供的软件测试方法流程示意图，包括以下步骤：

在一个应用场景中存在多个项目共用同一个触发规则的情况下，获取至少一个项目测试需求；

分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标关系信息的内容包括：每个项目对应应用场景的关系以及每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

调用触发器根据至少一个目标触发规则启动软件测试，所述触发器设置在代码仓库以及集成工具之间。

这样，一方面通过在预先设置的触发规则库中预先存入至少一个触发规则，可以为触发器在不同场景下提供触发规则，实现了同一个触发器在不同应用环境的兼容；另一方面，通过预设的项目关系库中每个项目对应触发规则标识的关系，可以使系统通过标识对触发规则进行调用，以此实现对触发规则的数据驱动，减小维护成本。

一种可能的实施方式中，所述软件测试方法包括：所述触发规则库中内容包括：至少一个触发规则以及每个触发规则对应的标识。这样，可以通过预设的项目关系库中每个项目对应触发规则标识的关系实现系统对触发规则的调用，以此实现触发规则的数据驱动，减小维护成本。

一种可能的实施方式中，所述触发规则的内容依据预设在关键字库中的内容生成。这样，用户可以通过更新关键字库中的内容进而对触发规则进行更新、修改以及增加，以此降低用户对于测试系统的使用难度。

一种可能的实施方式中，所述关键字库中的内容包括：普通关键字、关系关键字以及正则关键字。这样，可以使用户依据需求选择相应的关键字内容，实现对触发规则的自定义，以此扩大了触发规则的类别，并降低了用户对于测试系统的使用难度。

一种可能的实施方式中，其特征在于，所述普通关键字内容的包括：项目代码提交分支信息、项目代码提交版本信息、项目备注信息、项目提交人信息以及项目提交时间信息。

示例性的，对于所述触发规则库的构建，具体包括：

对于触发规则库内容中的触发规则以及触发规则标识(可以为规则编号或者规则标签)建立对应关系，使每个触发规则内容对应一个标识信息。这样，可以保证在后续系统通过对于标识的识别以及调用，能够准确匹配到对应的触发规则内容；

对于预设的关键字库中的关键字内容与触发规则建立对应关系。其中，对于普通关键字的具体内容包括：项目代码提交分支信息(branch)、项目代码提交版本信息(version)、项目备注信息(message)项目提交人信息(author)以及项目体提交时间信息(date)；对于关系关键字的具体内容包括：等于(equle)、包含(contain)、大于(gt)以及小于(lt)。此外用户还可以通过正则关键字进行关键字内容的自定义，进一步实现对于触发规则的自定义。对此，使用关键字生成相应的触发规则的示例，可以如下所示：

rule_001＝{‘version’:{‘equal’:‘A’}}

rule_002＝{‘branch’:{‘equal’:‘*’}}

rule_003＝{‘branch’:{‘equal’:‘master’}}

rule_004＝{‘message’:{‘equal’:‘B’}}

rule_005＝{‘message’:{‘contain’:‘C’}}

rule_006＝{‘author’:{‘equal’:‘D’}}

上述六条规则对应的含义如下：

rule_001表示代码仓库中提交的项目版本为“A”版本(此处“A”仅指代版本号，不做限定)；

rule_002表示代码仓库中任意分支有代码提交，则触发后续流程；

rule_003表示代码仓库中的“master”分支有代码提交时，则触发后续流程(此处“master”仅指代分支标识，不做限定)；

rule_004表示代码仓库中提交信息内容等于“B”时，则触发后续流程(此处“B”可以为数量关系的相等也可以为信息内容的相等，不做限定)；

rule_005表示表示代码仓库中提交信息内容包含“C”时，则触发后续流程(此处“C”仅指代信息内容，不做限定)；

rule_006表示代码仓库中提交人是D时，则触发后续流程(此处“D”仅指代提交人，不做限定)。

一种可能的实施方式中，触发规则库的内容均依据实际需求进行定义和更新。这样，当具有更新需求的时候，用户无需针对每个项目重新建立对应触发规则的关系以及维护，以此减小维护成本。并且，用户可以通过关键字的识别，降低在自定义触发规则的操作难度。

可选的，可以通过对用户提供的接口功能中增加修改和添加的权限，以此实现用户对触发规则库内容的修改。

在一些可能的实施方式中，所述项目关系信息内容还包括：每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系。这样，可以通过项目关系信息包括的内容确定同项目测试需求对应的项目对应的后续测试流程，以此实现后续的软件测试。

可选的，项目关系库中每个项目关系定义内容包括：每个项目源程序在代码仓库中的网址(code_url)、代码仓库的类型(code_type)、要触发的后续流程的接口地址(webhook)以及每个项目对应的触发规则或者每个项目对应的触发规则标识(invoke_rule)。

可选的，代码仓库所用的系统类型可以选择当前主流开源的代码仓库系统，包括：GIT以及SVN，那么为了匹配代码仓库系统，所用的代码仓库的类型同样需要支持GIT以及SVN系统。

示例性的，以构建项目关系库中的项目“E”和项目“F”为例(其中“E”和“F”仅指代项目标识，不做限定)，项目关系库的构建过程包括：

如果对项目“E”的源程序使用GIT代码仓库进行管理，则得到在GIT代码仓库的地址，示例性的，具体可以表现为：http://10.10.10.1:8090/E.git(此处地址不做限定)；

依据项目源程序(或源程序代码)，得到后续流程触发的接口地址以及项目所使用的触发规则，

示例性的具体后续流程触发的接口地址可以表现为：http://10.10.10.1:8888/job/E/build？token＝token，后续项目使用rule_001对应的触发规则；

如果对项目“F”的源程序使用SVN代码仓库进行管理，则得到SVN代码仓库的地址，示例性的，具体可以表现为：http://10.10.10.1:8090/F(此处地址不做限定)；

依据项目源程序(或源程序代码)，得到后续流程触发的接口地址以及项目所使用的触发规则，

示例性的具体后续流程触发的接口地址可以表现为：

http://10.10.10.1:8888/job/wuziqi/build？token＝token，后续使用rule_02以及rule_03对应的规则。

这样，可以实现对项目关系库中的内容监控，当发现相应代码仓库符合触发规则时，可以自动触发启动配置的后续流程接口地址。

一种可能的实施方式中，项目关系库的内容均依据实际需求进行定义和更新。这样，可以支持用户对于任意项目的灵活定义，增大了触发器对多应用场景的兼容性。

一种可能的实施方式中，所述软件测试方法可以具体作用在触发器实施，所述软件测试方法具体作用在触发器的应用流程示意图如图2所示。通常的，对于软件开发一般采用MVC模式分层开发，此处“M”指模型层、“V”指视图层以及“C”指控制层。软件测试的时候针对于不同的层所用的测试方法以及测试工具是不同的，例如视图层通常采用页面测试，控制层一般采用接口测试。

可选的，所述触发器的结构包括：数据库、扫描器、规则过滤器以及启动器。

可选的，所述数据库用于为触发器运行提供数据支撑，具体包括：关键字库、触发规则库以及项目关系库。

可选的，所述扫描器用于对代码仓库进行代码获取，并对最新的代码提交信息和存储在数据库中的历史最新提交信息进行比对，如果不一致，则依照代码仓库对数据库中的历史最新提交信息进行更新，具体实现方式包括：

加载项目关系库，获取所述项目关系库中所有项目代码地址；

依据代码地址得到该项目最新的代码提交信息，所述代码提交信息包括：代码更新分支、提交版本、提交时间、版本号、代码提交人以及代码提交备注；

对最新的代码提交信息和存储在数据库中的历史最新提交信息进行比对，如果不一致，则依照代码仓库对数据库中的历史最新提交信息进行更新并启动规则过滤器。

可选的，所述规则过滤器用于确认当前代码提交信息是否符合触发规则，若不符合触发规则，则结束当前流程；若符合本次流程，则启动启动器。

可选的，所述启动器用于向项目后续测试流程接口发送启动信号(例如一个http请求)，以实现触发后续的自动化测试流程。

在图2所示的测试流程中，所述触发器设置在代码仓库(代码仓库可以为Gitlab)以及集成工具(集成工具可以为Jenkins)之间，并在所述触发器提供的项目关系库中配置不同的测试类型对应的后续测试流程接口。这样，在不同项目的代码提交时(例如接口测试以及页面测试)同步发送项目测试需求至所述触发器，所述触发器在获取项目测试需求后，可以调用相应测试类型的工具工作，从而实现了多场景下的软件自动化测试。

本申请实施例提供了一种自动化软件测试方法，本方案中，测试系统在获取至少一个测试需求后，依据测试需求，调用预设在项目关系库中的项目关系信息，依据项目关系信息中每个项目对应触发规则的标识关系以及每个项目对应应用场景的关系，在预设的触发规则库中实现对相应触发规则的调用，得到至少一个目标触发规则，最后依据至少一个目标触发规则进行软件测试。一方面，在预设的触发规则库中存入多种触发规则，并且通过预设的项目关系库中项目关系信息，可以实现同一个触发器在不同场景对于不同触发规则的调用，提高了触发器对于多应用场景的兼容性；第二方面，通过预设建立项目与触发规则标识的联系，实现了对触发规则的数据化驱动，当系统出现更新需求时仅需使项目同其它标识的触发规则建立联系，无需针对触发规则进行更新，从而减少了人工维护成本；第三方面，使用关键字库实现对触发规则的生成，使用户可以依据关键字库内容进行选择以及触发规则的自定义编辑，降低了测试系统的使用难度。

上述实施例从依据测试需求得到目标测试方案，首先依据项目测试需求得到项目测试需求对应的目标项目关系信息，然后依据每个所述目标项目关系调用预设在触发规则库中与相应目标项目关系对应的触发规则，得到至少一个目标触发规则，最后依据至少一个目标触发规则进行软件测试的角度，对本申请实施例提供的软件测试方法的各实施方式进行了介绍。应理解，依据项目测试需求得到项目测试需求对应的目标项目关系信息，依据每个所述目标项目关系调用预设在触发规则库中与相应目标项目关系对应的触发规则，得到至少一个目标触发规则，依据至少一个目标触发规则进行软件测试等的处理步骤，本申请实施例可以以硬件或硬件和计算机软件的结合形式来实现上述功能。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

例如，若上述实现步骤通过软件模块来实现相应的功能，如图3所示，软件测试装置可以包括：获取模块、第一调用模块、第二调用模块以及测试模块，

所述获取模块，

用于获取至少一个项目测试需求，每个所述项目测试需求应用在至少两个所述项目共用一个项目规则的场景中；

所述第一调用模块，

用于分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标项目关系信息内容包括：每个项目对应应用场景的关系以及每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

所述第二调用模块：用于依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

所述测试模块：用于调用触发器根据至少一个目标触发规则进行软件测试，所述触发器设置在代码仓库之后以及集成在软件测试流程之间。

可以理解的是，以上各个模块/单元的划分仅仅是一种逻辑功能的划分，实际实现时，以上各模块的功能可以集成到硬件实体实现，例如，获取模块、第一调用模块以及第二调用模块可以集成到收发器上实现，测试模块可以集成到处理器实现，实现上述各模块功能的程序和指令，可以维护在存储器中。例如，图4提供了一种电子设备，该电子设备包括可以包括处理器、收发器和存储器。其中，收发器用于对测试结果获取。存储器可以用于存储测试过程中产生的过程数据，也可以存储用于处理器执行的代码等。当处理器运行存储器存储的代码过程中，使得电子设备执行上述方法中测试方法的部分或全部操作。

具体实现过程详见上述方法示意的实施例所述，此处不再详述。

具体实现中，对应前述电子设备，本申请实施例还提供一种计算机存储介质，其中，设置在电子设备中的计算机存储介质可存储有程序，该程序执行时，可实施包括多智能体学习方法的各实施例中的部分或全部步骤。该存储介质均可为磁碟、光盘、只读存储记忆体(read-only memory，ROM)或随机存储记忆体(random access memory，RAM)等。

以上模块或单元的一个或多个可以软件、硬件或二者结合来实现。当以上任一模块或单元以软件实现的时候，所述软件以计算机程序指令的方式存在，并被存储在存储器中，处理器可以用于执行所述程序指令并实现以上方法流程。所述处理器可以包括但不限于以下至少一种：中央处理单元(central processing unit，CPU)、微处理器、数字信号处理器(DSP)、微控制器(microcontroller unit，MCU)、或人工智能处理器等各类运行软件的计算设备，每种计算设备可包括一个或多个用于执行软件指令以进行运算或处理的核。该处理器可以内置于SoC(片上系统)或专用集成电路(application specific integratedcircuit，ASIC)，也可是一个独立的半导体芯片。该处理器内处理用于执行软件指令以进行运算或处理的核外，还可进一步包括必要的硬件加速器，如现场可编程门阵列(fieldprogrammable gate array，FPGA)、PLD(可编程逻辑器件)、或者实现专用逻辑运算的逻辑电路。

当以上模块或单元以硬件实现的时候，该硬件可以是CPU、微处理器、DSP、MCU、人工智能处理器、ASIC、SoC、FPGA、PLD、专用数字电路、硬件加速器或非集成的分立器件中的任一个或任一组合，其可以运行必要的软件或不依赖于软件以执行以上方法流程。

进一步的，图4中还可以包括总线接口，总线接口可以包括任意数量的互联的总线和桥，具体由处理器代表的一个或多个处理器和存储器代表的存储器的各种电路链接在一起。总线接口还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发器提供用于在传输介质上与各种其他设备通信的单元。处理器负责管理总线架构和通常的处理，存储器可以存储处理器在执行操作时所使用的数据。

当以上模块或单元使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

应理解，在本申请的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对实施例的实施过程构成任何限定。

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

尽管已描述了本申请的可选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (9)

1.一种自动化软件测试方法，其特征在于，所述方法包括：

在一个应用场景中存在多个项目共用同一个触发规则的情况下，获取至少一个项目测试需求；

分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标项目关系信息的内容包括：每个项目对应应用场景的关系，每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

调用触发器根据至少一个目标触发规则启动软件测试，所述触发器设置在代码仓库以及集成工具之间。

2.根据权利要求1所述的自动化软件测试方法，其特征在于，所述触发规则库中内容包括：至少一个触发规则以及每个触发规则对应的标识。

3.根据权利要求1所述的自动化软件测试方法，其特征在于，所述触发规则的内容依据预设在关键字库中的内容生成。

4.根据权利要求3所述的自动化软件测试方法，其特征在于，所述关键字库中的内容包括：普通关键字、关系关键字以及正则关键字。

5.根据权利要求4所述的自动化软件测试方法，其特征在于，所述普通关键字内容包括：项目代码提交分支信息、项目代码提交版本信息、项目备注信息、项目提交人信息以及项目提交时间信息。

6.根据权利要求1所述的自动化软件测试方法，其特征在于，所述项目关系库以及触发规则库的内容均依据实际需求进行定义和更新。

7.一种自动化软件测试装置，其特征在于，所述装置包括：

获取模块，用于在一个应用场景中存在多个项目共用同一个触发规则的情况下，获取至少一个项目测试需求；

第一调用模块，用于分别依据每个项目测试需求调用预设在项目关系库中与相应项目测试需求对应的项目关系信息，得到至少一个目标项目关系信息，每个所述目标项目关系信息内容包括：每个项目对应应用场景的关系以及每个项目对应触发规则标识的关系，每个项目对应与之相关联的源程序代码地址的关系、每个项目对应的触发规则的关系以及每个项目对应启动接口的关系；

第二调用模块，用于依据每个所述目标项目关系信息调用预设在触发规则库中与相应目标项目关系信息对应的触发规则，得到至少一个目标触发规则；

测试模块，用于调用触发器根据至少一个目标触发规则启动软件测试，所述触发器设置在代码仓库以及集成工具之间。

8.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令执行权利要求1-6中任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使所述计算机执行权利要求1-6中任一项所述的方法。

Images