CN113468043B - 一种基于多服务部署的自动化测试方法 - Google Patents

Abstract

本发明提供了一种基于多服务部署的自动化测试方法，所述方法为：步骤1、测试前准备，录入产品需求，将多个产品对应的被测服务进行设置被测服务之间的前后置依赖关系；步骤2、服务器部署监测，在服务器上导入部署被测服务，监测服务器部署被测服务完成情况，监测被测服务运行状态；步骤3、测试准入，即将被测服务根据功能模块进行分组，根据产品的业务场景进行被测服务关联，进入等待测试指令下发状态；步骤4、测试数据初始化；步骤5、执行批量被测服务自动化测试；步骤6、测试结果收集和收集信息反馈。本发明提高测试效率的同时，减少测试人力成本投入，缩短产品交付周期。

Description

一种基于多服务部署的自动化测试方法

技术领域

本发明涉及网络通讯技术领域，特别是一种基于多服务部署的自动化测试方法。

背景技术

现有开发公司存在较多小型化拼装产品，而拼装产品包括多服务的混合部署与服务之间的业务交付依赖，它们被运用于给产品提供不同领域的功能支持，但是目前测试交付流程存在较多问题：

（1）由于小型化部署的需求较为紧急，部署测试周期性要求较短，因此对产品多服务混合部署后的回归测试效率要求很高，传统的测试回归人力投入较大效率低下。

（2）小型化产品通常部署于独立的内部私有领域，对应服务域名无法与公共网络实现通信，故传统的线上监听方案无法实现交付后线上服务可用性监控。

（3）多个被测服务的测试数据准备对环境存在强耦合关系，新部署一个小型化产品，就需要重新准备测试数据，并投入较大人力完成测试数据准备。

（4）上层业务被测服务数据依赖基础被测服务的运行情况，若基础被测服务存在问题，则影响上层业务被测服务的测试回归，增加版本测试往返时间。

（5）因部署时间较短，被测服务可能存在较多问题，但是开发人员未有足够时间和足够完备的自我校验的手段，导致提交测试时，仍然存在较多问题。

发明内容

为克服上述问题，本发明的目的是提供一种基于多服务部署的自动化测试方法，提高进入测试流程的被测服务质量，高效完成后续集成部署的自动化测试，提高测试效率。

本发明采用以下方案实现：一种基于多服务部署的自动化测试方法，所述方法包括如下步骤：

步骤1、测试前准备，录入产品需求，将多个产品对应的被测服务进行设置被测服务之间的前后置依赖关系；

步骤2、服务器部署监测，在服务器上导入部署被测服务，监测服务器部署被测服务完成情况，监测被测服务运行状态；

步骤3、测试准入，即将被测服务根据功能模块进行分组，根据产品的业务场景进行被测服务关联，进入等待测试指令下发状态；

步骤4、测试数据初始化；

步骤5、执行批量被测服务自动化测试；

步骤6、测试结果收集和收集信息反馈。

进一步的，所述步骤1进一步具体为：测试前准备：录入产品需求，部署与产品相关的几个拼装被测服务，并进行混合部署，将产品需求信息录入自动化测试平台后，平台将自动读取被测服务及其相关信息为后续测试做好准备，所述相关信息包括所用域名、所部属的实例名、数据库的资源连接信息。

进一步的，所述步骤2进一步具体为：服务器部署监测：是实现对被测服务部署情况进行监听，以确认部署服务是否完成部署，其确认逻辑是监听所部署的服务所在实例是否存活、其所用主核心域名是否处于能正常访问来判断；正常访问的判断指标为：通过HTTP协议的GET请求访问被测服务的根路径不会返回500、502、503的错误故障码、且能正常返回响应码，且被测服务在重启后监测状态保持可用。

进一步的，所述步骤3进一步具体为：将被测服务根据功能模块进行分组，被测服务根据业务依赖关系建立关联关系，监测被测服务准入指令，收到触发指令，对指令解析、信息抽取；根据解析信息，自动将指定被测服务及其存在业务关联的被测服务脚本列入准入被测范围形成被测服务列表，触发脚本构建测试结果收集和反馈，准入测试结束。

进一步的，所述步骤4进一步具体为：测试数据准备自动化开始，读取被测服务列表，输出被测服务上下游服务信息，将根据测试准入通过的被测服务列表梳理被测服务脚本的前置数据依赖，并自动化完成数据准备，执行数据准备自动化脚本完成数据写入数据库，被测服务从数据库读取所需测试初始化数据，进入待触发测试状态，测试数据准备结束。

进一步的，所述步骤5进一步具体为：读取被测服务列表，读取当前被测服务关联的被测服务依赖关系图谱，并根据图谱，自动将相关测试脚本列入待执行测试列表，根据被测服务读取数据库中所准备的初始化数据并进行服务端接口参数传递，陆续完成后续的自动化测试执行。所有被测服务脚本执行结束后，会进行测试结果批量收集和反馈。

进一步的，步骤6进一步具体为：执行测试若存在测试失败的情况将会进行测试中止和反馈，并等待下一次开发修复完成后测试发起，若测试均通过则会进入线上监控部署环节。

进一步的，所述步骤6后还包括步骤7、被测服务发布部署上线后，定时监测被测服务部署。

进一步的，步骤7进一步具体为：被测服务在预发布环节测试通过后，开发人员会将测试通过的脚本发布至正式环境，从预发布环境的测试脚本中，抽离出对应用于正式环境定时监控的脚本，并进行批量的参数替换和兼容性匹配，完成脚本改造后，会根据部署模板，完成云服务器的脚本部署和定时任务配置，同被测服务一同部署于线上云服务器。

本发明的有益效果在于：本发明完成小型化多服务部署后的自动化测试验证，并根据被测服务的依赖关系，自动化完成测试策略制定，测试脚本调度，测试数据初始化准备，测试脚本参数替换，测试脚本执行，测试结果收集反馈和发布后的测试脚本监控部署。提高测试效率的同时，减少测试人力成本投入，缩短产品交付周期。并通过自动化测试准入环节，提高进入测试流程的被测服务质量，高效完成后续集成部署的自动化测试；同时通过模板化的参数替换实现脚本跨系统的兼容部署，并通过同环境部署，解决小型化产品局限访问下的脚本监控问题。

附图说明

图1是本发明的方法流程示意图。

图2是本发明的步骤3的具体流程示意图。

图3是本发明的步骤4的具体流程示意图。

图4是本发明的步骤5的具体流程示意图。

具体实施方式

下面结合附图对本发明做进一步说明。

请参阅图1所示，本发明的一种基于多服务部署的自动化测试方法，所述方法包括如下步骤：

步骤1、测试前准备，录入产品需求，将多个产品对应的被测服务进行设置被测服务之间的前后置依赖关系；

步骤2、服务器部署监测，在服务器上导入部署被测服务，监测服务器部署被测服务完成情况，监测被测服务运行状态；

步骤3、测试准入，即将被测服务根据功能模块进行分组，根据产品的业务场景进行被测服务关联，进入等待测试指令下发状态；

步骤4、测试数据初始化；

步骤5、执行批量被测服务自动化测试；

步骤6、测试结果收集和收集信息反馈。

步骤7、被测服务发布部署上线后，定时监测被测服务部署。

所述步骤1进一步具体为：测试前准备：录入产品需求，部署与产品相关的几个拼装被测服务，并进行混合部署，将产品需求信息录入自动化测试平台后，平台将自动读取被测服务及其相关信息为后续测试做好准备，所述相关信息包括所用域名、所部属的实例名、数据库的资源连接信息。

所述步骤2进一步具体为：服务器部署监测：是实现对被测服务部署情况进行监听，以确认部署服务是否完成部署，其确认逻辑是监听所部署的服务所在实例是否存活、其所用主核心域名是否处于能正常访问来判断；正常访问的判断指标为：通过HTTP协议的GET请求访问被测服务的根路径不会返回500、502、503的错误故障码、且能正常返回响应码，且被测服务在重启后监测状态保持可用。

如图2所示，所述步骤3进一步具体为：将被测服务根据功能模块进行分组，被测服务根据业务依赖关系建立关联关系，监测被测服务准入指令，收到触发指令，对指令解析、信息抽取；根据解析信息，自动将指定被测服务及其存在业务关联的被测服务脚本列入准入被测范围形成被测服务列表，触发脚本构建测试结果收集和反馈，准入测试结束。

如图3所示，所述步骤4进一步具体为：测试数据准备自动化开始，读取被测服务列表，输出被测服务上下游服务信息，将根据测试准入通过的被测服务列表梳理被测服务脚本的前置数据依赖，并自动化完成数据准备，执行数据准备自动化脚本完成数据写入数据库，被测服务从数据库读取所需测试初始化数据，进入待触发测试状态，测试数据准备结束。

如图4所示，所述步骤5进一步具体为：读取被测服务列表，读取当前被测服务关联的被测服务依赖关系图谱，并根据图谱，自动将相关测试脚本列入待执行测试列表，根据被测服务读取数据库中所准备的初始化数据并进行服务端接口参数传递，陆续完成后续的自动化测试执行。所有被测服务脚本执行结束后，会进行测试结果批量收集和反馈。

所述步骤6进一步具体为：执行测试若存在测试失败的情况将会进行测试中止和反馈，并等待下一次开发修复完成后测试发起，若测试均通过则会进入线上监控部署环节。

步骤7进一步具体为：被测服务在预发布环节测试通过后，开发人员会将测试通过的脚本发布至正式环境，从预发布环境的测试脚本中，抽离出对应用于正式环境定时监控的脚本，并进行批量的参数替换和兼容性匹配，完成脚本改造后，会根据部署模板，完成云服务器的脚本部署和定时任务配置，同被测服务一同部署于线上云服务器。

下面结合一具体实施例对本发明作进一步说明：

自动化测试平台在收到产品需求后会开启自动化测试流程，测试流程主体分为几个部分，分别是：测试前准备、服务部署监测、测试准入、测试数据初始化、自动化测试、测试结果收集和往返、脚本部署监控。

1、测试前准备：如收到一个小型化部署的产品需求需要实现用户直播、聊天、学习的功能，则就需要部署与之相关的几个拼装被测服务（用户登录、直播、聊天、学习），并进行混合部署。而被测服务分别又由各自更细小粒度的客户端服务、服务端服务、定时任务服务等组成。将其信息录入自动化测试平台后，平台将自动读取被测服务及其相关信息（所用域名、所部属的实例名、数据库等资源连接信息）为后续测试做好准备。

2、服务部署监测：主要是实现对被测服务部署情况进行监听，以确认部署服务是否完成部署，其确认逻辑主要是监听所部署的服务所在实例是否存活、其所用主核心域名是否处于可正常访问来判断。正常访问的判断指标为：通过HTTP协议的GET请求访问被测服务的根路径不会返回500、502、503等错误故障码、且能正常返回响应码（如200等），且被测服务在重启后监测状态保持可用。

3、测试准入：

3.1主要是将被测服务根据功能模块进行分组，并根据产品业务场景进行被测服务关联，如直播服务的使用场景是：需要一个用户登录账号后，进入直播模块，然后点击开启直播，且直播的同时可以进行聊天。这个场景里可以看出，直播被测服务对用户登录服务存在前置依赖关系，且直播被测服务的功能验证，需要在用户登录服务可用的基础上，方可进行后置被测服务的执行。

3.2在关联关系梳理完成后，自动化平台可以根据依赖关系，在后续测试调度和回归时，会自动化制定测试回归策略，如用户登录被测服务未测试通过时，将直接测试中止，输出测试结果，不再进行后续依赖它的服务测试。

3.3多个被测服务关联关系建立完成后测试系统将进入等待指令下发状态，当收到被测服务完成部署，且服务部署监测状态正常后，将发起自动化脚本调度。

如需要部署的被测服务分4个模块（用户登录、直播、聊天、学习），每个模块分别存在2个功能服务，则就需要部署8个被测服务，当8个服务通过服务部署监测，并确认可用后，则进入测试触发环节。测试平台会根据指定的被测服务信息，在脚本库中自动化查找对应模块的被测服务测试脚本进行匹配，将用户登录、直播、聊天、学习及与这四块模块存在关联关系的测试脚本列入待构建脚本集，并等待构建执行，并进行测试结果收集，若执行通过则说明测试准入通过，则进入后续正式自动化测试流程。若存在服务脚本执行失败，则返回测试准入失败反馈，测试中停，不进行后续的全量自动化测试。

值得一提的是，此处用于测试准入的待执行测试脚本仅覆盖各被测服务模块的主核心业务场景，非全量功能覆盖。

4、测试数据自动化初始化：

在多个被测服务通过测试准入测试通过后，进入自动化测试流程，则就需要预先进行自动化测试数据的初始化准备，系统将根据测试准入通过的被测服务清单梳理被测服务脚本的前置数据依赖，如测试账号、测试账号密码、测试资源ID等并自动化完成数据准备。如被测服务是直播模块，则与直播相关的前置初始化数据包括主播账号秘密、主播室、观看主播的用户等。测试平台通过自动化调用完成这部分前置数据创建写库完成后续正式测试的数据初始化准备。

5、执行测试：

测试平台获取被测服务列表，读取当前被测服务关联的被测服务依赖关系图谱，并根据图谱，自动将相关测试脚本列入待执行测试列表，根据被测服务读取数据库中上一步所准备的初始化数据并进行服务端接口参数传递，陆续完成后续的自动化测试执行。所有被测服务脚本执行结束后，会进行测试结果批量收集和反馈。

6、测试往返：执行测试若存在测试失败的情况将会进行测试中止和反馈，并等待下一次开发修复完成后测试发起。若测试均通过则会进入线上监控部署环节。

7、正式环境场景监控部署：被测服务在预发布环节测试通过后，开发人员会将测试通过的脚本发布至正式环境，而小型化产品部署的正式环境通常在小型区域内允许访问。传统本地化的部署和定时访问无法满足这个业务需求，因此测试平台在被测服务上线后，会根据被测服务清单，梳理相关的自动化脚本，根据特定的模板，基于部署云服务器系统的情况（Windows或Linux）进行脚本转化和参数替换，从预发布环境的测试脚本中，抽离出对应用于正式环境定时监控的脚本，并进行批量的参数替换和兼容性匹配，完成脚本改造后，会根据特定的部署模板，完成云服务器的脚本部署和定时任务配置，同被测服务一同部署于线上云服务器。

总之，本发明基于多被测服务之间的业务依赖关系图，构造被测服务与被测服务之间的前后置依赖关系，利用前置被测服务的输出为后置被测服务的输入提供测试数据准备完成测试数据自动化准备，并通过基础被测服务的抽离和有序流程化调度执行，除了完成基础被测服务之间的测试数据准备，还为上层被测业务服务完成的测试数据准备。为了解决部署完成后的测试准入环节的自动化校验，本发明还从现有被测服务的自动化测试脚本根据各组件特性，抽离核心可用的场景做为部署集成后的自动化验证，以保障提交测试时，产品主核心服务不存在阻塞，提高测试效率的同时降低测试成本投入。

以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。

Claims (7)

1.一种基于多服务部署的自动化测试方法，其特征在于：所述方法包括如下步骤：

步骤1、测试前准备，录入产品需求，将多个产品对应的被测服务进行设置前后置依赖关系；

步骤2、服务器部署监测，在服务器上导入部署被测服务，监测服务器部署被测服务完成情况，监测被测服务运行状态；

步骤3、测试准入，即将被测服务根据功能模块进行分组，根据产品的业务场景进行被测服务关联，进入等待测试指令下发状态；

步骤4、测试数据初始化；

步骤5、执行批量被测服务自动化测试；

步骤6、测试结果收集和收集信息反馈；

所述步骤3进一步具体为：将被测服务根据功能模块进行分组，被测服务根据业务依赖关系建立关联关系，监测被测服务准入指令，收到触发指令，对指令解析、信息抽取；根据解析信息，自动将指定被测服务及其存在业务关联的被测服务脚本列入准入被测范围形成被测服务列表，触发脚本构建测试结果收集和反馈，测试准入结束；所述步骤4进一步具体为：测试数据准备自动化开始，读取被测服务列表，输出被测服务上下游服务信息，将根据测试准入通过的被测服务列表梳理被测服务脚本的前置数据依赖，并自动化完成数据准备，执行数据准备自动化脚本完成数据写入数据库，被测服务从数据库读取所需测试初始化数据，进入待触发测试状态，测试数据准备结束。

2.根据权利要求1所述的一种基于多服务部署的自动化测试方法，其特征在于：所述步骤1进一步具体为：测试前准备：录入产品需求，部署与产品相关的几个拼装被测服务，并进行混合部署，将产品需求信息录入自动化测试平台后，平台将自动读取被测服务及其相关信息为后续测试做好准备，所述相关信息包括所用域名、所部属的实例名、数据库的资源连接信息。

3.根据权利要求1所述的一种基于多服务部署的自动化测试方法，其特征在于：所述步骤2进一步具体为：服务器部署监测：是对被测服务部署情况进行监听，以确认部署服务是否完成部署，其确认逻辑是监听所部署的服务所在实例是否存活、其所用主核心域名是否处于能正常访问；正常访问的判断指标为：通过HTTP协议的GET请求访问被测服务的根路径不会返回500、502、503的错误故障码、且能正常返回响应码，且被测服务在重启后监测状态保持可用。

4.根据权利要求1所述的一种基于多服务部署的自动化测试方法，其特征在于：所述步骤5进一步具体为：读取被测服务列表，读取当前被测服务关联的被测服务依赖关系图谱，并根据图谱，自动将相关测试脚本列入待执行测试列表，根据被测服务读取数据库中所准备的初始化数据并进行服务端接口参数传递，陆续完成后续的自动化测试执行，所有被测服务脚本执行结束后，会进行测试结果批量收集和反馈。

5.根据权利要求1所述的一种基于多服务部署的自动化测试方法，其特征在于：步骤6进一步具体为：执行测试若存在测试失败的情况将会进行测试中止和反馈，并等待下一次开发修复完成后测试发起，若测试均通过则会进入线上监控部署环节。

6.根据权利要求1所述的一种基于多服务部署的自动化测试方法，其特征在于：所述步骤6后还包括步骤7、被测服务发布部署上线后，定时监测被测服务部署。

7.根据权利要求6所述的一种基于多服务部署的自动化测试方法，其特征在于：步骤7进一步具体为：被测服务在预发布环节测试通过后，开发人员会将测试通过的脚本发布至正式环境，从预发布环境的测试脚本中，抽离出对应用于正式环境定时监控的脚本，并进行批量的参数替换和兼容性匹配，完成脚本改造后，会根据部署模板，完成云服务器的脚本部署和定时任务配置，同被测服务一同部署于线上云服务器。