CN109710524A - 一种自动测试方法、系统和计算机存储介质 - Google Patents

Abstract

本发明公开了一种自动测试方法、系统和计算机存储介质，所述方法应用于工程机械的云平台接口，包括：将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包；根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例；利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。根据本发明的技术方案，可以快速实现对工程机械云平台的新增功能或原有功能的修改的自动化测试，进而促进快速迭代开发，提高了开发效率，快速响应了客户需求等。

Description

一种自动测试方法、系统和计算机存储介质

技术领域

本发明涉及工程机械技术领域，尤其涉及一种自动测试方法、系统和计算机存储介质。

背景技术

随着互联网的快速发展，工程机械的数字化云平台管理也越来越受欢迎。对于一些开发工程机械数字化云平台的公司，需要针对客户需求，进行快速迭代开发出客户需要的新功能或者修改原有功能等。

通常，该新功能或修改功能开发完后，需要快速部署到测试执行环境中，并快速进行新功能或修改功能的自动化测试，以评估本次迭代的版本是否能否部署到生产环境。一旦发现此版本中存在缺陷，则应上报bug，要求研发人员进行快速修改，而在修改后再次部署到测试执行环境并在测试通过后再次部署等，如此不断循环迭代。

然后，针对现有的人工部署及人工测试等过程，测试工程师需要对该功能开发后的代码进行人工编译、打包，然后进行逐个部署，并在部署后进行逐个相关功能的测试，测试后出具测试报告等，这一系列的工作至少需要1人多个工作日才可以完成。显然，这很难满足快速响应客户需求，且效率较低等等。

发明内容

鉴于上述问题，本发明提出一种自动测试方法、系统和计算机存储介质，通过实现自动编译打包到自动部署再到自动化测试一体化的闭环，可以解决现有技术的测试开发周期长、无法快速响应客户需求等问题。

本发明实施例提出一种自动测试方法，应用于工程机械的云平台接口，所述自动测试方法包括：将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包；

根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例；

利用预设测试脚本对各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

进一步地，本发明实施例的自动测试方法，还包括：将通过所述测试的微服务实例对应的微服务镜像包作为产线最新候选包，并部署到对应的所述云平台应用的产线环境中。

进一步地，本发明实施例的自动测试方法，还包括：若所述产线最新候选包在部署到所述产线环境时出现异常，则将上一产线候选包进行回滚。

进一步地，本发明实施例的自动测试方法，还包括：若所述测试脚本中存在至少一测试用例测试失败，收集并记录所述失败对应的业务逻辑信息。

进一步地，所述“利用Docker技术将每一微服务打包为对应的微服务镜像包”之后，还包括：

每隔预设时间间隔从关联的源代码管理库中获取用于新增或更新微服务的功能代码，并在所述功能代码成功编译后进行所述打包，以获取最新的所述微服务镜像包。

进一步地，所述云平台接口应用包括用户管理、至少一机械设备管理、保养服务订单管理、故障推送管理、设备配件注册管理、机型月度报表管理中的一种或多种组合。

进一步地，所述打包为串联打包或并联打包；若两个微服务之间具有依赖关系，则采用所述串联打包；若两个微服务之间没有依赖关系，则采用所述并联打包。

进一步地，所述预设测试环境配置文件为JSON文件，所述“根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中”包括：

利用Ansible技术将各微服务镜像包放到对应的测试roles中，并通过对所述测试roles配置所述JSON文件，以用于将对应的微服务镜像包部署到所述测试环境中。

根据上述的自动测试方法，本发明的另一实施例还提出一种自动测试系统，应用于工程机械的云平台接口，所述自动测试系统包括：

编译打包模块，用于将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包；

自动化部署模块，用于根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例；

自动化测试模块，用于利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

本发明的又一实施例还提出一种计算机存储介质，其存储有计算机程序，在所述计算机程序被执行时，实施上述的自动测试方法。

通过本发明的技术方案可以实现由功能代码的自动编译打包到自动部署再到自动化测试一体化操作，可以快速实现对工程机械云平台的新增功能或原有功能的修改的自动化测试，进而促进快速迭代开发，提高了开发效率，快速响应了客户需求等。

附图说明

为了更清楚地说明本发明的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对本发明保护范围的限定。

图1为本发明实施例的自动测试方法的第一流程示意图；

图2为本发明实施例的自动测试方法的串联打包方式示意图；

图3为本发明实施例的自动测试方法的并联打包方式示意图；

图4为本发明实施例的自动测试方法的第二流程示意图；

图5为本发明实施例的自动测试系统的结构示意图。

主要元件符号说明：

100-自动测试系统；10-编译打包模块；20-自动化部署模块；30-自动化测试模块。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在限制本发明。本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。

下面结合具体的实施例对本发明进行详细说明。

实施例1

请参照图1，本实施例提出一种自动测试方法，应用于工程机械的云平台接口等。下面对该自动测试方法进行详细说明。

步骤S100，将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包。

在上述步骤S100中，将基于微服务架构来实现该云平台的应用开发。通过将一个大的工程机械云平台应用按照多个业务逻辑分解成多个小的微服务，其中，每一微服务可单独部署并可向外提供一API接口以便实现与其他微服务之间的通信。

例如，以一机械设备的云平台管理应用为例，该云平台应用可分解成用户管理、至少一机械设备管理、保养服务订单管理、故障推送管理、设备配件注册管理和机型月度报表管理等等。其中，上述每一个管理对应形成一个微服务。本实施例中，该机械设备管理可根据客户的不同需求实现对不同机械设备的管理。若存在多个机械设备，则可分解成多个机械设备管理。示范性地，该机械设备可包括但不限于为混凝土机械、挖掘机、起重机、桩工机械、风机、筑路机械、港口机械、煤炭机械、数控机床、压缩机、矿用自卸车、石油装备或消防装备等等。

于是，将上述的云平台应用被分解成若干个微服务后，然后将每一个微服务进行自动编译及打包，从而获取对应的微服务镜像包。

示范性地，可利用Jenkins等持续集成工具对各微服务对应的功能代码进行自动编译。在自动编译成功后，利用Docker技术对编译成功的代码封装成对应的微服务镜像包，即为上述的打包。其中，该微服务镜像包又称为Docker容器，该容器可移植性高，可利用不同的JSON文件将其部署到不同环境中并运行等。例如，可将各微服务镜像包部署到云平台测试环境和/或产线环境等。

本实施例中，所述打包可以是采用串联打包方式，也可以是并联打包方式。其中，若两个微服务之间具有依赖关系，则可采用串联打包方式来打包这两个微服务。而若两个微服务之间没有依赖关系，则可采用并联打包方式进行多个微服务的并行打包。

示范性地，对于串联打包方式，以一工程机械的云平台应用为例，如图2所示，若该云平台的一Platform库为微服务A，一云平台接口为微服务B，由于微服务B依赖于微服务A，于是，当微服务B打包之前，必须先完成微服务A的打包，然后将打包得到的微服务镜像包发布到共享的Maven库中，其次再打包微服务B。在微服务B在打包时，通过从Maven库中获取该微服务镜像包以作为微服务B的底层依赖库。

对于并联打包方式，如图3所示，由于网关微服务C与云平台接口微服务D并不存在依赖关系，故这两个微服务可同时进行持续集成打包。

进一步地，如图4所示，在上述步骤S100之后，还包括步骤S110，即每隔预设时间间隔从关联的源代码管理库中获取用于新增或更新微服务的功能代码，并在所述功能代码成功编译后进行所述打包，以获取最新的微服务镜像包。

本实施例中，所述预设时间间隔，优选地设为每个工作日清晨时段中的一特定时间。于是当该时间到时，系统将自动触发从关联的源代码管理库中获取由研发人员提交的上一工作日的功能代码，并进行自动编译。其中，该功能代码通常是用于实现新增微服务或者是对原有的微服务的更新等。

于是，对于编译成功的功能代码，将输入到Docker工具中进行打包，从而可得到最新的微服务镜像包。其中，系统在获取上述功能代码前，还将先清除掉原先的微服务镜像包。

步骤S200，根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在该测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例。

当获取到各微服务镜像包后，系统将利用预先存储的测试环境配置文件将其部署到对应的测试环境，并对其实例化为该环境下的特定微服务。示范性地，可通过Ansible等运维工具将不同的微服务镜像包放到测试roles(即测试角色)中，再通过对该测试roles配置该预设测试环境配置文件，，从而实现将对应的微服务镜像包配置到该云平台的测试环境中。本实施例中，该预设测试环境配置文件采用JSON格式进行数据存储，故也可称为JSON文件。其中，JSON是一种数据存储格式，可用于传递对象等。本实施例中，该预设测试环境配置文件主要包括用于对各微服务镜像包在对应的运行环境下的配置属性数据。示范性地，该配置属性数据可包括但不限于为微服务所占用的集群运算和存储资源、实现功能所必须访问的数据库和消息队列的地址和/或暴露给集群统一监控的心跳url地址等等。

本实施例中，所述部署是指对各微服务镜像进行运行环境的环境配置，更具体地包括，进行安装及环境变量的设置等，从而使得这些各微服务可以在对应的环境下正常使用。可以理解，在进行部署时，系统还根据不同的环境配置文件可将微服务镜像包部署到不同的环境中。示范性地，可通过将不同的微服务镜像包放到不同的roles中，并通过对不同的roles分别配置不同环境配置文件，以用于将对应的微服务镜像包部署到对应的环境中。例如，该环境配置还可以包括但不限于为研发环境配置、产线环境配置等等。

步骤S300，利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

在完成环境部署后，系统将利用自动化测试工具对该测试环境下的各微服务实例进行用例测试，更具体地，通过调用这些微服务实例对应的API接口进行功能测试。本实施例中，这些预设测试脚本可预先设计，具体内容可根据该云平台应用的多个功能逻辑来进行设计，不同的功能逻辑对应有不同的测试脚本。而一个测试脚本又可包括多个测试用例，这些测试用例可利用不同的边界取值等测试各云平台接口是否存在Bug。

示范性地，可采用专用于接口自动化的Jmeter等工具进行自动化测试。通过将这些预设测试脚本按照功能逻辑预先存储在对应的测试文件夹中，然后根据对应的配置关系串联地或者并联地执行测试脚本中的测试用例。最终，输出所有测试用例的测试结果。

进一步地，该方法还包括步骤S400，将通过所述测试的微服务实例对应的微服务镜像包作为产线最新候选包，并部署到对应的所述云平台应用的产线环境中。

在上述步骤S400中，对于测试通过的微服务实例，可将其对应的微服务镜像包作为产线最新候选包。示范性地，可通过Tag(标记)方法将该测试通过的微服务镜像包按照预设产线候选包规则对其进行打标记，于是打标记后的包即作为该产线候选包。

在上述步骤S400之后，该方法还可包括步骤S410，若所述产线最新候选包在部署到所述产线环境时出现异常，则将上一产线候选包进行回滚。

本实施例中，所述回滚，即系统将找到上一产线候选包并恢复到上一成熟版本的产线环境。例如，若测试通过的最新版本的一微服务镜像包打标后，其包名为“evi-portal-web:sprint_01.3P_20181010000000”。一旦该最新候选包在部署失败或出错时，则将找出上一个产线候选包，如将包名“evi-portal-web:sprint_01.2P_20181001000000”的候选包进行回滚。

进一步地，该方法还包括步骤S500，若该预设测试脚本中存在至少一测试用例测试失败，收集并记录所述失败对应的业务逻辑信息。

示范性地，在运行该测试脚本的过程中，如果有某一条或多条测试用例运行失败，则说明该测试用例所测试的对应微服务的API接口的调用可能存在问题，或者是该微服务本身的功能代码可能存在Bug等。于是，系统将收集并记录与该测试用例有关的API接口以及各API接口之间的业务逻辑等信息，然后可通过邮件、弹框消息等多种方式通知相关测试人员。随后，测试人员将进行人工判断具体是哪里出现Bug并主导对其进行修复等操作。

本实施例提出的应用于工程机械的云平台接口的自动测试方法，通过将客户的应用需求分解成相互关联又独立的若干微服务，并利用持续集成技术对功能代码进行自动编译并打包成可部署的Docker镜像包，然后将这些镜像包自动部署到云平台测试环境中以进行功能测试，并自动输出测试报告等。本方法基于微服务架构，利用微服务的特性，不仅可实现应用需求的快速迭代开发或修改等，也更容易理解和维护；相比人工部署和测试，可大大节省时间，同时利用自动化测试，还可以防止人员的失误操作等。另外，对于测试通过的上述镜像包还可进一步自动部署到云平台产线上，若在产线部署出问题时又将重新由研发人员进行修改并进入编译打包阶段，从而可使得整个应用需求的开发过程形成一个包含“打包-部署-测试”的闭环，使得整个流程开发能够高效地执行，从而快速响应客户需求，可增加客户体验等。

实施例2

请参照图5，基于上述实施例1的自动测试方法，本实施例中提供一种自动测试系统100，应用于工程机械的云平台接口。该工程机械的云平台接口自动测试系统100可应用于如计算机等终端。本实施例中，该工程机械的云平台接口自动测试系统100包括：

编译打包模块10，用于将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包。

自动化部署模块20，用于根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例。

自动化测试模块30，用于利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

上述的各模块对应于实施例1的自动测试方法。实施例1中的任何可选项也适用于本实施例，这里不再详述。

本发明还提供一种终端，该终端可以为服务器或计算机等。该终端包括存储器和处理器，存储器可用于存储计算机程序，处理器通过运行所述计算机程序，从而使终端执行上述的自动测试方法或者上述自动测试系统中的各个模块的功能。

存储器可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据移动终端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本发明还提供了一种计算机存储介质，用于储存上述终端中使用的所述计算机程序。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。

也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种自动测试方法，其特征在于，应用于工程机械的云平台接口，所述自动测试方法包括：

将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包；

根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例；

利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

2.根据权利要求1所述的自动测试方法，其特征在于，还包括：

将通过所述测试的微服务实例对应的微服务镜像包作为产线最新候选包，并部署到对应的所述云平台应用的产线环境中。

3.根据权利要求2所述的自动测试方法，其特征在于，还包括：

若所述产线最新候选包在部署到所述产线环境时出现异常，则将上一产线候选包进行回滚。

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

若所述预设测试脚本中存在至少一测试用例测试失败，收集并记录所述测试失败对应的业务逻辑信息。

5.根据权利要求1所述的自动测试方法，其特征在于，所述“利用Docker技术将每一微服务打包为对应的微服务镜像包”之后，还包括：

每隔预设时间间隔从关联的源代码管理库中获取用于新增或更新微服务的功能代码，并在所述功能代码成功编译后进行所述打包，以获取最新的所述微服务镜像包。

6.根据权利要求1所述的自动测试方法，其特征在于，所述云平台应用包括用户管理、至少一机械设备管理、保养服务订单管理、故障推送管理、设备配件注册管理、机型月度报表管理中的一种或多种组合。

7.根据权利要求1所述的自动测试方法，其特征在于，所述打包为串联打包或并联打包；

若两个微服务之间具有依赖关系，则采用所述串联打包；若两个微服务之间没有依赖关系，则采用所述并联打包。

8.根据权利要求1所述的自动测试方法，其特征在于，所述预设测试环境配置文件为JSON文件，所述“根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中”包括：

利用Ansible技术将各微服务镜像包放到对应的测试roles中，并通过对所述测试roles配置所述JSON文件，以用于将对应的微服务镜像包部署到所述测试环境中。

9.一种自动测试系统，其特征在于，应用于工程机械的云平台接口，所述自动测试系统包括：

编译打包模块，用于将云平台应用分解成若干个包括API接口的微服务，并利用Docker技术将每一微服务打包为对应的微服务镜像包；

自动化部署模块，用于根据预设测试环境配置文件将各微服务镜像包部署到对应的测试环境中，并在完成所述部署后，在所述测试环境下对各微服务镜像包进行实例化以获取对应的微服务实例；

自动化测试模块，用于利用预设测试脚本并调用各微服务实例对应的API接口进行业务逻辑组合测试，并输出对应的测试结果。

10.一种计算机存储介质，其特征在于，其存储有计算机程序，在所述计算机程序被执行时，实施根据权利要求1-8中任一项所述的自动测试方法。