CN107992404A - 一种软件自动测试方法及装置 - Google Patents

Abstract

本发明提供一种软件自动测试方法及装置，该方法包括：当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本；使用增量版本，进行增量部署；调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集；执行增量测试用例集中的测试用例，进行增量测试。本发明通过只增量构建、部署和测试存在新提交代码的目标目录，只运行目标目录相关的增量测试用例，可以缩短整个自动化流水线的时间，达到快速验证、快速反馈目的，解决了现有软件测试方法采用全量方式进行部署及测试导致的不能快速验证和快速反馈结果的技术问题。

Description

一种软件自动测试方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种软件自动测试方法及装置。

背景技术

现代软件项目一般规模较大，需要多个开发小组各负责一部分协同编写代码进行开发。软件项目较常见的运作方式为：开发人员完成代码编写自测后进行代码提交，代码提交触发自动化流水线；自动化流水线给出验证结果，开发人员根据验证的结果，及时进行修改并提交，整个过程往复，直到自动化流水线验证通过。

现有的自动化流水线流程通常是：若监控到有代码提交，则全量构建软件系统，部署构建好的全量软件系统，运行全量自动化测试用例，检查和推送验证结果等。在这一过程中，全量构建、全量部署和全量测试整个软件系统消耗时间过多，为了提高验证反馈速度，自动化流水线开始采用增量构建方式来替代全量构建。仅增量构建有代码提交的软件模块，将生成的增量版本覆盖到全量版本中，生成最新的全量版本。虽然增量构建方式可以缩短整个自动化流水线的时间，但是部署过程和测试过程依然采用全量方式进行的，并且增量构建是以软件模块为单位粒度太大，整个自动化流水线消耗时间依然较多，还是不能快速验证和快速反馈结果。

发明内容

本发明提供了一种软件自动测试方法及装置，用于解决现有软件测试方法采用全量方式进行部署及测试导致的不能快速验证和快速反馈结果的技术问题。

为解决上述技术问题，本发明提供一种软件自动测试方法，包括：

当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本；待构建目录为预设目标目录中存在新提交代码的目录；

使用增量版本，进行增量部署；

调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集；

执行增量测试用例集中的测试用例，进行增量测试。

进一步的，在调用待构建目录的构建操作，将待构建目录构建为增量版本之前，还包括：

调用待构建目录的属性检查规则，属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查；

使用属性检查规则对待构建目录的新提交代码进行检查；

调用待构建目录的构建操作，将待构建目录构建为增量版本包括：若检查通过，则调用待构建目录的构建操作，将待构建目录构建为增量版本；若检查未通过，则提醒新提交代码错误。

进一步的，还包括：

根据软件测试目的，选择与软件测试目的对应的软件目录作为预设目标目录，预设目标目录包括软件模块及软件模块的子目录中的至少一种；

设置预设目标目录中各目录对应的构建操作及测试用例；

根据预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表；

监控预设目标目录中各目录的代码提交状态。

进一步的，调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集包括：

根据映射关系表，调用待构建目录对应的测试用例，作为待执行的增量测试用例；

将待执行的增量测试用例进行整理，生成待执行测试用例集；

对待执行测试用例集中的测试用例进行去重复，形成增量测试用例集。

进一步的，使用增量版本，进行增量部署包括：

获取增量版本的文件类型，文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种；

根据增量版本的文件类型确定增量部署的部署粒度；

根据部署粒度，安装增量版本完成增量部署。

本发明提供一种软件自动测试装置，包括：增量构建模块、增量部署模块及增量测试模块，其中，

增量构建模块用于当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本；待构建目录为预设目标目录中存在新提交代码的目录；

增量部署模块用于使用增量版本，进行增量部署；

增量测试模块用于调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集，执行增量测试用例集中的测试用例，进行增量测试。

进一步的，增量构建模块还用于调用待构建目录的属性检查规则，使用属性检查规则对待构建目录的新提交代码进行检查；若检查通过，则调用待构建目录的构建操作，将待构建目录构建为增量版本；若检查未通过，则提醒新提交代码错误；属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查。

进一步的，增量构建模块还用于根据软件测试目的，选择与软件测试目的对应的软件目录作为预设目标目录，设置预设目标目录中各目录对应的构建操作及测试用例，根据预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表，并监控预设目标目录中各目录的代码提交状态；预设目标目录包括软件模块及软件模块的子目录中的至少一种。

进一步的，增量测试模块用于根据映射关系表，调用待构建目录对应的测试用例，作为待执行的增量测试用例，将待执行的增量测试用例进行整理，生成待执行测试用例集，对待执行测试用例集中的测试用例进行去重复，形成增量测试用例集。

进一步的，增量部署模块用于获取增量版本的文件类型，根据增量版本的文件类型确定增量部署的部署粒度，根据部署粒度，安装增量版本完成增量部署；文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种。

本发明的有益效果是：

根据本发明提供的软件自动测试方法、装置，通过将监控提交的新提交代码进行增量构建后进行增量部署和增量测试，每次只增量构建、部署和测试有代码提交的目标目录，构建粒度可以精确到软件模块的子目录，并且只运行目标目录相关的增量测试用例，可以进一步缩短整个自动化流水线的时间，达到快速验证、快速反馈目的，解决了现有软件测试方法采用全量方式进行部署及测试导致的不能快速验证和快速反馈结果的技术问题。

附图说明

图1为本发明实施例一提供的一种软件自动测试方法的流程图；

图2为本发明实施例二提供的一种软件自动测试方法的流程图；

图3为本发明实施例三提供的一种软件自动测试方法的流程图；

图4为本发明实施例四提供的一种软件自动测试装置的示意图。

具体实施方式

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

本发明可以运用到各种需要进行部署测试的场景，例如基于单片机的应用软件测试，基于大型网络系统的通信网络部署调试等场景。

现通过具体实施方式结合附图的方式对本发明做出进一步的诠释说明。

实施例一：

为了达到在提交的新提交代码后快速反馈结果和及时发现问题的目的，本发明实施例提供了一种软件自动测试方法，具体流程请参见图1。

S101，当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本。

实时或者周期性的监控预设目标目录的代码提交状态，当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本，本申请涉及的待构建目录为预设目标目录中存在新提交代码的目录。

预设目标目录是增量构建的基本单位，可以根据要提交的代码设置，可以以代码所在软件模块为基本单位，也可以进一步细化，以代码所在软件模块的子目录为基本单位。预设目标目录即为当前自动化流水线感兴趣的代码块，即正在开发的软件模块。监控预设目标目录的代码提交状态，即监控预设目标目录是否有代码提交。例如功能模块A，其编程代码位于代码管理系统的Par1/Path1子目录，其对应的配置文件分布在代码管理系统的Par2/Path2子目录。当需要监控功能模块A时，可以选择不监控Par1和Par2两个软件模块的整体目录，而是精确监控到Par1/Path1和Par/Path2子目录。

当检测到预设目标目录有代码提交时，开始进行增量构建。构建指将代码归属的目录生成发布版本。提交的代码为新提交代码，增量构建是只将监控到存在新提交代码的目标作为待构建目录，对待构建目录进行构建生成增量版本。构建操作可以是编程代码对应目录的增量编译构建、配置文件的直接拷贝、增量数据库脚本文件的收集等多种形式。不同类型的目标目录可以对应不同的增量构建操作，具体的增量构建操作根据新提交代码的目标目录设置。目标目录可以设置为软件模块子目录，在增量构建时，就不需要处理该软件模块的其余子目录及文件的构建，使得增量构建部分更加快速高效。增量构建生成增量版本会存储在某一地方。

例如，若Par1/Path1编程代码块有文件提交，则相应的增量构建为将编程代码做增量编译构建，然后发布到增量版本。若Par2/Path2配置文件块有代码提交，则相应的增量构建为将配置文件拷贝至增量版本。目标目录还有可能是数据库脚本文件，其相应的增量构建操作只需要把数据库脚本文件直接拷贝到增量版本中。如果构建操作失败，可以快速反馈检查结果，帮助开发人员及时发现问题并改正。

例如，新提交代码可以是新增应用/功能的程序代码，也可以是为了对现有程序代码进行变更而编写的变更代码。

在实际应用中，在本步骤之前，还包括：

根据软件测试目的，选择与软件测试目的对应的软件目录作为预设目标目录，预设目标目录包括软件模块及软件模块的子目录中的至少一种；在实际应用中，软件测试目的可大可小、可简单可复杂，当软件测试目的比较小或者简单时，可以仅选择一个软件目录作为预设目标目录，若软件测试目的比较大或者复杂，就需要多个软件目录配合实现，此时可以选择多个软件目录作为预设目标目录；

设置预设目标目录中各目录对应的构建操作及测试用例；

根据预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表；

监控预设目标目录中各目录的代码提交状态。

在实际应用中，本步骤在调用待构建目录的构建操作，将待构建目录构建为增量版本之前，还包括：

调用待构建目录的属性检查规则，属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查；

使用属性检查规则对待构建目录的新提交代码进行检查；

相应的，此时，调用待构建目录的构建操作，将待构建目录构建为增量版本包括：若检查通过，则调用待构建目录的构建操作，将待构建目录构建为增量版本；若检查未通过，则提醒新提交代码错误。

S102，使用增量版本，进行增量部署。

本步骤可以包括：获取增量版本的文件类型；根据增量版本的文件类型确定增量部署的部署粒度；根据部署粒度，安装增量版本完成增量部署。其中根据增量版本的文件类型确定增量部署的部署粒度包括：根据文件类型与部署粒度的对应关系，确定增量部署的部署粒度。

在实际应用中，文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种，增量版本不同的文件类型对应采用不同的部署方法。与文件类型对应，部署粒度包括客户端的所有增量文件、服务器端的所有增量文件、数据库脚本增量文件中的至少一种。例如客户端增量文件，其部署方法需要删除客户端缓存文件然后重启客户端；服务器端增量文件，其部署方法需要删除服务器端缓存文件然后重启服务器；数据库脚本增量文件，其部署方法需要连接数据库并执行数据库脚本文件。对应的部署粒度分别为客户端的所有增量文件、服务器端的所有增量文件、数据库脚本增量文件。

可以定时检查增量版本文件目录，在该时段有增量版本文件存在时开始增量部署。增量部署完成的同时，已完成增量部署的增量版本可以被清理，清理增量版本文件目录即增量版本文件的存储目录，为下一轮自动化流水线的启动做好准备.增量部署完成后，系统就更新到了最新的版本，此时就可以执行后续的测试用例的测试。

在实际应用中，步骤S101生成的增量版本可以作为系统补丁进行安装，本步骤S102涉及的使用增量版本则是指安装系统补丁，当然本步骤涉及的增量部署与现有常规部署是不相同的，本申请涉及的增量部署是指系统以加载热补丁的方式加载增量版本，实现系统升级，在增量部署过程中，系统不需要重启，也不需要安装已经安装过的软件及代码；而常规部署则是下载新版本系统所有的文件，然后依次执行设备重启、使用新版本系统文件覆盖之前系统文件、加载新版本系统文件，这样完成系统补丁的安装；将本申请提供的增量部署与常规部署进行比较，可以知道本申请的增量部署速度快、回退简单。

S103，调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集。

本步骤包括：根据步骤S101涉及的映射关系表，调用待构建目录对应的测试用例，作为待执行的增量测试用例；将待执行的增量测试用例进行整理，生成待执行测试用例集；对待执行测试用例集中的测试用例进行去重复，形成增量测试用例集。

不同类型的预设目标目录对应不同的测试用例。调用所有待构建目录对应的测试用例，作为待执行的增量测试用例，按照各增量测试用例的执行逻辑关系、时序关系等对其进行整理，形成待执行测试用例集；在实际应用中，可能出现多个目录共用一个测试用例的情况，此时需要进行去重复操作，即对待执行测试用例集中的测试用例进行去重复，形成增量测试用例集。

S104，执行增量测试用例集中的测试用例，进行增量测试。

增量部署完成后，系统就更新到了最新的版本，此时就可以进行测试，运行增量测试用例集中的测试用例，进行增量测试，反馈增量测试结果。增量测试结果为本次增量部署的测试结果，包含本次增量部署所有增量版本文件对应的新提交代码的验证结果。增量测试完成，清理增量测试用例文件。

本发明实施例提供的软件自动测试方法，通过将监控提交的新提交代码进行增量构建后进行增量部署和增量测试，每次只增量构建、部署和测试有代码提交的目标目录，构建粒度可以精确到软件模块的子目录，并且只运行目标目录相关的增量测试用例，可以进一步缩短整个自动化流水线的时间，达到快速验证、快速反馈目的。

显然，本领域的技术人员应该明白，不必每一次增量构建都进行增量部署，定时检查增量版本文件目录进行增量部署，可进一步节省测试时间。若将本发明实施例的方案应用于别的场景时，对方案内容进行相应改变，也都应当视为属于本发明的保护范围。

实施例二：

本发明实施例提供一种软件自动测试方法，具体流程请参见图2。

S201，构建映射关系表。

构建映射关系表包括以下过程：

根据软件测试目的，选择相关软件目录作为预设目标目录；设置预设目标目录中各目录对应的构建操作及测试用例；根据预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表。

预设软件目录包括软件模块及软件模块的子目录中的至少一种，将各目录的根路径、对应的构建操作及测试用例以表格的方式对应存储，构建生成映射关系表。

S202，监控预设目标目录的代码提交状态。

监控预设目标目录的代码提交状态，即监控预设目标目录是否有代码提交。预设目标目录即为当前自动化流水线感兴趣的代码块，即正在开发的软件模块。当软件系统预设目标目录有代码提交时，遍历映射关系表，依次查看每个目标目录在本次提交中是否有文件变化。

S203，检查新提交代码是否符合属性检查规则。若否，则转到S204；若是，则转到S205。

当检测到预设目标目录有代码提交时，检查新提交代码是否符合对应的属性检查规则。提交的代码为新提交代码。属性检查规则是软件系统版本验收时根据目标目录的特性所需的特性检查。例如针对配置文件，进行文件格式校验、内容检查；针对编程代码，利用静态分析工具进行静态分析检查。如果新提交代码没有通过属性检查，可以快速反馈检查结果，帮助开发人员及时发现问题并改正。不仅可以保证提交的新提交代码的质量，还能避免因新提交代码错误造成的无效构建，保证增量构建的正确性。

检查具体包括以下过程：

调用新提交代码对应目标目录的属性检查规则；使用该属性检查规则对新提交代码进行检查。若检查通过，则进入步骤205；若检查没通过，则进入步骤204。

S204，反馈检查结果。

若检查没通过，则说明新提交代码存在问题，可以将该检查结果反馈给开发人员。

S205，将存在新提交代码的待构建目录增量构建为增量版本。

若检查通过，则说明新提交代码没有问题，可以根据映射关系表中目标目录的根路径，查找对应的增量构建操作及增量测试用例，将新提交代码进行增量构建，生成增量版本。

S206，调用待构建目录对应的增量测试用例。

从映射关系表中查找新提交代码对应的增量测试用例，调出、保存并记录新提交代码对应的增量测试用例。或将新提交代码对应的增量测试用例写入负责记录增量测试用例的文件。

S207，判断增量版本文件目录是否有内容。若是，则转到S208；若否，则转回S207。

定时检查增量版本文件目录，判断增量版本文件目录是否有内容即判断增量版本文件目录是否为空。若判断增量版本文件目录有内容，即判断增量版本文件目录不为空，则转到S208；若判断增量版本文件目录没有内容，即判断增量版本文件目录为空，则转回S207，继续检查增量版本文件目录是否有内容。

S208，安装增量版本进行增量部署。

根据增量版本的文件类型，按照对应的部署方法及部署粒度进行增量部署。在实际应用中，本步骤还可以在步骤S206之前运行，也可以与步骤S206同时运行。

S209，生成增量测试用例集。

生成测试用例集具体包括以下过程：

获取待执行的增量测试用例；对待执行的增量测试用例去重复，形成测试用例集合。

待执行的增量测试用例为定时监控这段时间内，所有增量构建对应的增量测试用例，对待执行的增量测试用例去重复，形成应执行的最小测试用例集合即为测试用例集合，避免重复测试相同的增量测试用例。

S210，执行增量测试用例集中的测试用例，进行增量测试。

增量部署完成后，运行增量测试用例集中的测试用例，进行增量测试，反馈增量测试结果。增量测试完成后，清理测试用例集合中的增量测试用例文件。

本发明实施例提供的软件自动测试方法，通过将监控提交的新提交代码进行增量构建前进行属性检查再增量部署，增量测试前对增量测试用例进行去重复，既提高了新提交代码的正确性，也避免重复测试相同的增量测试用例，进一步缩短整个自动化流水线的时间，能更为快速的反馈结果和及时发现问题。

显然，本领域的技术人员应该明白，若将本发明实施例的方案应用于别的场景时，对方案内容进行相应改变，也都应当视为属于本发明的保护范围。

实施例三：

为了便于理解本发明，本实施例以OMMR(Oceanic Multiband MicrowaveRadiometer，针对中国卫星扫描微波辐射计的定标和检验而设计的五频段十通道微波辐射计)系统的FLASH组的自动化流水线为例进行说明，具体流程请参见图3。OMMR产品的FLASH组主要管理其配置管理模块。配置管理模块包括UMTS(Universal MobileTelecommunications System，通用移动通信系统)、GSM(Global System for MobileCommunication，全球移动通信系统)、AG(Access Gateway，接入网关)制式RNC(RadioNetwork Controller，无线网络控制器)的配置管理功能。OMMR系统采用Gerrit(一种免费、开放源代码的代码审查软件，使用网页界面)作为版本构建工具，测试用例基于RobotFramework框架(一款python编写的功能自动化测试框架)开发，自动化流水线采用Jenkins(一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使持续集成变成可能)搭建。

S301，代码提交触发Jenkins流水线运行。

Jenkins监控整个OMMR产品系统代码目录的文件提交状态。当开发人员利用GIT(一个开源的分布式版本控制系统)进行代码提交时，会触发整个自动化流水线开始运行。流水线共有12个目标目录，参见表1，分别是各制式公共编程代码块、数据库脚本代码块和配置文件代码块所在目录，UMTS编程代码块、数据库脚本代码块和配置文件代码块所在目录，GSM编程代码块、数据库脚本代码块和配置文件代码块所在目录，以及AG编程代码块、数据库脚本代码块和配置文件代码块所在目录。

S302，判断存在新提交代码的目录是否包含预设目标目录路径。若否，则转回S302；若是，则转到S303。

新提交代码即开发人员提交的代码。判断存在新提交代码的目录与预设目标目录路径中的一个相同，即判断为存在新提交代码的目录包含预设目标目录路径。若是，即在新提交代码的目录包含预设目标目录路径，则新提交代码为正在开发软件模块的代码块，转到S303；若否，即新提交代码没有包含在预设目标目录路径，则新提交代码不是正在开发软件模块的代码块，不再进行增量构建，转回S302，也可以提示开发人员新提交代码的提交是否有误。

在实际应用中，用户可以一次提供多个新提交代码，这些代码中有些是新增的新增代码，有些是对现有代码进行变更的变更代码，也有一些就是现有代码，这些新提交代码涉及多个软件模块或者同一软件模块的多个子目录，这些软件模块或者同一软件模块的多个子目录不是每个都是监控对象，本步骤实现了根据监控对象即预设目标目录对用户提供多个新提交代码进行筛选的目的。

具体的，遍历映射表的目标目录的根路径，看在diff文件是否存在变化。具体的判断过程如下：

利用GIT相关指令可以获取当前GIT提交的SHA(哈希)值，从流水线维护的shafile(储存哈希值的文件)中可以获取上次GIT代码提交的SHA值，利用“git diff”命令可以获取本次提交较上次提交变化的内容，判断diff文件中是否存在变化。若否，则转回S303；若是，则转到S304。

新提交代码中有些是新增的新增代码，有些是对现有代码进行变更的变更代码，也有一些就是现有代码，针对存在新增代码及变更代码的待构建目录需要进行增量版本的构建，而针对现有代码则不需要进行增量版本的构建，本步骤实现了根据SHA值对用户针对预设目标目录提供多个新提交代码进行筛选的目的。

S303，将变化的内容保存到diff文件中，并把本次GIT提交的SHA值更新到shafile文件中。

S304，进行增量构建，并且调用对应的增量测试用例。

按照映射表中对应的增量构建操作，进行相关的增量构建。例如，映射表为表1，UMTS编程代码块相应的增量构建操作是Gradle_UMTS_build.bat，记录UMTS的测试用例；各制式的公共编程代码块有内容提交，相应的增量构建操作是Gradle_build.bat，UMTS、GSM和AG的测试用例都需记录。

表1

S305，定时查看增量版本目录中是否有内容。若否，则转回S305；若是，则转到S306。

S306，进行增量部署。

增量部署时，如果增量版本客户端中有内容，则将这些文件拷贝到版本的客户端，删除客户端缓存然后重启；如果增量版本中存在数据库脚本文件，则连接数据库并执行这些数据库脚本；如果增量版本服务器端中有内容，则将这些文件拷贝到版本的服务端，删除服务器端缓存然后重启服务器。

S307，进行增量测试。

将记录的增量测试用例去重复后执行，完成增量测试。将测试结果及时通过Jenkins的邮件发送功能反馈给小组成员。

本发明实施例提供的软件自动测试方法，通过将提交的新提交代码进行增量构建后进行增量部署和增量测试，构建粒度可以精确到软件模块的子目录，并且只运行目标目录相关的增量测试用例，可以很大程度地节省每次自动化流水线过程的时间，达到快速验证、快速反馈目的。

显然，本领域的技术人员应该明白，若将本发明实施例的方案应用于别的场景时，对方案内容进行相应改变，也都应当视为属于本发明的保护范围。

实施例四：

本发明实施例提供软件自动测试装置4，具体示意图请参见图4。下面对各模块及功能进行进一步说明，软件自动测试装置4包括：增量构建模块41、增量部署模块42及增量测试模块43，其中，

增量构建模块41用于当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将待构建目录构建为增量版本；待构建目录为预设目标目录中存在新提交代码的目录；

增量部署模块42用于使用增量版本，进行增量部署；

增量测试模块43用于调用待构建目录对应的测试用例，对待构建目录对应的测试用例进行处理，生成增量测试用例集，执行增量测试用例集中的测试用例，进行增量测试。

在实际应用中，增量构建模块41还用于调用待构建目录的属性检查规则，使用属性检查规则对待构建目录的新提交代码进行检查，若检查通过，则调用待构建目录的构建操作，将待构建目录构建为增量版本，若检查未通过，则提醒新提交代码错误；属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查。

在实际应用中，增量构建模块41还用于根据软件测试目的，选择与软件测试目的对应的软件目录作为预设目标目录，设置预设目标目录中各目录对应的构建操作及测试用例，根据预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表，并监控预设目标目录中各目录的代码提交状态；预设目标目录包括软件模块及软件模块的子目录中的至少一种。

在实际应用中，增量测试模块43用于根据映射关系表，调用待构建目录对应的测试用例，作为待执行的增量测试用例，将待执行的增量测试用例进行整理，生成待执行测试用例集，对待执行测试用例集中的测试用例进行去重复，形成增量测试用例集。

在实际应用中，增量部署模块42用于获取增量版本的文件类型，根据增量版本的文件类型确定增量部署的部署粒度，根据部署粒度，安装增量版本完成增量部署；文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种。

本发明实施例提供的软件自动测试装置，通过只增量构建、部署和测试有代码提交的目标目录，将监控提交的新提交代码进行增量构建前进行属性检查再增量部署，增量测试前对增量测试用例进行去重复，只运行目标目录相关的增量测试用例，既提高了新提交代码的正确性，也避免重复测试相同的增量测试用例，进一步缩短整个自动化流水线的时间，能更为快速的反馈结果和及时发现问题。

显然，本领域的技术人员应该明白，上述本发明各实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在计算机存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。

以上仅是本发明的具体实施方式而已，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施方式所做的任意简单修改、等同变化、结合或修饰，均仍属于本发明技术方案的保护范围。

Claims (10)

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

当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将所述待构建目录构建为增量版本；所述待构建目录为所述预设目标目录中存在新提交代码的目录；

使用所述增量版本，进行增量部署；

调用所述待构建目录对应的测试用例，对所述待构建目录对应的测试用例进行处理，生成增量测试用例集；

执行所述增量测试用例集中的测试用例，进行增量测试。

2.如权利要求1所述的软件自动测试方法，其特征在于，在调用待构建目录的构建操作，将所述待构建目录构建为增量版本之前，还包括：

调用所述待构建目录的属性检查规则，所述属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查；

使用所述属性检查规则对所述待构建目录的新提交代码进行检查；

所述调用待构建目录的构建操作，将所述待构建目录构建为增量版本包括：若检查通过，则调用待构建目录的构建操作，将所述待构建目录构建为增量版本；若检查未通过，则提醒新提交代码错误。

3.如权利要求1所述的软件自动测试方法，其特征在于，还包括：

根据软件测试目的，选择与所述软件测试目的对应的软件目录作为所述预设目标目录，所述预设目标目录包括软件模块及软件模块的子目录中的至少一种；

设置所述预设目标目录中各目录对应的构建操作及测试用例；

根据所述预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表；

监控所述预设目标目录中各目录的代码提交状态。

4.如权利要求3所述的软件自动测试方法，其特征在于，所述调用所述待构建目录对应的测试用例，对所述待构建目录对应的测试用例进行处理，生成增量测试用例集包括：

根据所述映射关系表，调用所述待构建目录对应的测试用例，作为待执行的增量测试用例；

将所述待执行的增量测试用例进行整理，生成待执行测试用例集；

对所述待执行测试用例集中的测试用例进行去重复，形成所述增量测试用例集。

5.如权利要求1至4任一项所述的软件自动测试方法，其特征在于，所述使用所述增量版本，进行增量部署包括：

获取所述增量版本的文件类型，所述文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种；

根据所述增量版本的文件类型确定增量部署的部署粒度；

根据所述部署粒度，安装所述增量版本完成增量部署。

6.一种软件自动测试装置，其特征在于，包括：增量构建模块、增量部署模块及增量测试模块，其中，

所述增量构建模块用于当检测到预设目标目录有代码提交时，调用待构建目录的构建操作，将所述待构建目录构建为增量版本；所述待构建目录为所述预设目标目录中存在新提交代码的目录；

所述增量部署模块用于使用所述增量版本，进行增量部署；

所述增量测试模块用于调用所述待构建目录对应的测试用例，对所述待构建目录对应的测试用例进行处理，生成增量测试用例集，执行所述增量测试用例集中的测试用例，进行增量测试。

7.如权利要求6所述的软件自动测试装置，其特征在于，所述增量构建模块还用于调用所述待构建目录的属性检查规则，使用所述属性检查规则对所述待构建目录的新提交代码进行检查；若检查通过，则调用待构建目录的构建操作，将所述待构建目录构建为增量版本；若检查未通过，则提醒新提交代码错误；所述属性检查规则是软件系统版本验收时根据目标目录特性所需的特性检查。

8.如权利要求6所述的软件自动测试装置，其特征在于，所述增量构建模块还用于根据软件测试目的，选择与所述软件测试目的对应的软件目录作为所述预设目标目录，设置所述预设目标目录中各目录对应的构建操作及测试用例，根据所述预设目标目录中各目录的根路径、构建操作及测试用例，构建映射关系表，并监控所述预设目标目录中各目录的代码提交状态；所述预设目标目录包括软件模块及软件模块的子目录中的至少一种。

9.如权利要求8所述的软件自动测试装置，其特征在于，所述增量测试模块用于根据所述映射关系表，调用所述待构建目录对应的测试用例，作为待执行的增量测试用例，将所述待执行的增量测试用例进行整理，生成待执行测试用例集，对所述待执行测试用例集中的测试用例进行去重复，形成所述增量测试用例集。

10.如权利要求6-9任一项所述的软件自动测试装置，其特征在于，所述增量部署模块用于获取所述增量版本的文件类型，根据所述增量版本的文件类型确定增量部署的部署粒度，根据所述部署粒度，安装所述增量版本完成增量部署；所述文件类型包括客户端增量文件、服务器端增量文件、数据库脚本增量文件中的至少一种。