CN111459800A - 一种业务系统可用性验证方法、装置、设备和介质 - Google Patents

Abstract

本发明提供一种业务系统可用性验证方法、装置、设备和介质，方法包括在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。本发明优点：能够实现灾备数据中心业务自动化测试，提高测试效率，并可使自动化测试能够达到真实业务测试的效果。

Description

一种业务系统可用性验证方法、装置、设备和介质

技术领域

本发明涉及计算机技术领域，特别涉及一种业务系统可用性验证方法、装置、设备和介质。

背景技术

现有的数据中心在主备切换后，系统可用性验证方法更多关注于数据一致性的检查，而未涉及应用系统的业务可用性验证。例如，公开日为2019-03-12，公开号为109460322A的中国发明专利公开了一种基于流程调度引擎技术的灾备切换演练系统及方法，解决了现有系统流程编排操作复杂和演练的成果难固化的问题，采用数据一致性比对模块，对主数据中心和灾备数据中心的数据进行比对验证，确保灾备数据的可用性。又如，公开日为2013-09-25，公开号为103324715A的中国发明专利公开了一种灾备系统可用性检测方法及装置，通过获取主数据中心及灾备数据中心系统的配置和运行状态信息，形成主-灾备中心可用运行指标，并通过运行指标比对，生成各指标项的差异，最终将差异转换成告警信息并生成统计报表。再如，公开日为2015-10-07，公开号为104965771A的中国发明专利公开了一种验证异地容灾数据一致性的方法和系统，将位于异地备份存储与生产存储进行数据实时同步复制，同步复制完成后，生产存储根据生产卷创建生产快照卷，备份存储根据备份卷创建备份快照卷，最后，验证生产存储中生产卷、生产快照卷，以及备份存储中备份快照卷的数据一致性，方便有效的完成数据一致性的验证测试。

然而，上述方法均不是通过真实业务的可用性测试来验证灾备数据中心的可用性，且都仅侧重于从某一方面对灾备数据中心环境可用性进行验证，未能全面、系统地验证灾备系统的可用性。而针对应用系统的业务可用性验证，目前都主要是通过人工验证方式来实现。综以上所述可知，现有的系统可用性验证方法存在有以下缺陷：

1、仅通过交易数据和系统基础环境的一致性比对，未进行系统连通性测试和真实的业务验证，难以保证灾备系统是否可用；2、灾备中心切换后的业务验证主要通过人工验证方式，需要花费大量时间进行沟通、协调及执行，难以在短时间内完成，且手工的系统可用性验证，参与验证的交易数、银行机构(分行)数较为有限，难以满足各种场景的业务验证需求；同时，目前业务可用性验证的实时进度也是通过手工方式进行管控，管理效率低下，且无法友好展示整体的验证进度。

发明内容

本发明要解决的技术问题，在于提供一种业务系统可用性验证方法、装置、设备和介质，解决现有系统可用性验证方法仅通过交易数据和系统基础环境的一致性比对，未进行系统连通性测试和真实的业务验证，难以保证灾备系统是否可用的问题。

第一方面，本发明提供了一种业务系统可用性验证方法，所述方法用于自动化测试调度模块，所述方法包括：

步骤S1、在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

步骤S2、在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

进一步的，所述步骤S1具体为：

在Python环境下，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

进一步的，所述步骤S2具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

第二方面，本发明提供了一种业务系统可用性验证装置，所述装置包括脚本生成单元以及自动化验证单元；

所述脚本生成单元，用于在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

所述自动化验证单元，用于在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

进一步的，所述脚本生成单元具体为：

在Python环境下，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

进一步的，所述自动化验证单元具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

第三方面，本发明提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面所述的方法。

第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面所述的方法。

本发明实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

通过自动化测试调度模块来实现计算机模拟测试人员进行业务测试操作，能够实现业务测试验证自动化。通过调度端对测试案例执行机器的调度控制与通信，能够实现业务测试案例执行控制与测试结果收集。调度端与执行机器(即自动化调度机)上的Agent进行通讯调度，通过增加执行测试的虚拟机就可以快速的进行横向扩展，能够提高测试的并行效率。通过调度端设置业务测试步骤执行的先后依赖关系，使得自动化测试能够达到真实业务测试的效果。同时，通过数据池，能够及时存放并区分每个机构切换演练中自动化测试所采用的业务验证数据。随着银行业务不断发展，灾备数据中心业务验证的案例愈加复杂繁多，通过人工测试按季度甚至按月开展灾备数据中心业务验证需要耗费大量人员与时间。本发明通过实现灾备数据中心业务自动化测试，提高测试效率，可使得灾备数据中心季度例行验证在较少人员参与的情况下也可以顺利开展，从而保障灾备数据中心可用性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

下面参照附图结合实施例对本发明作进一步的说明。

图1为本发明所涉及的系统的框架示意图；

图2为本发明中交易测试时序图。

图3为本发明中案例信息模板字段示意图。

图4为本发明实施例一中一种业务系统可用性验证方法的执行流程图；

图5为本发明实施例二中一种业务系统可用性验证装置的结构示意图；

图6为本发明实施例三中电子设备的结构示意图；

图7为本发明实施例四中介质的结构示意图。

具体实施方式

本申请实施例通过提供一种业务系统可用性验证方法、装置、设备及介质，用于解决现有系统可用性验证方法仅通过交易数据和系统基础环境的一致性比对，未进行系统连通性测试和真实的业务验证，难以保证灾备系统是否可用的问题。

在介绍具体实施例之前，先介绍本申请实施例方法所对应的系统框架，如图1所示，系统大概分调度端、自动化测试调度模块、自动化调度机以及手工测试模块四个部分；调度端由作业调度、健康巡检、日常操作、灾备切换等几个功能子模块组成，其中，灾备切换包含了切换总览、切换发起、列表监控、详情监控等功能单元；业务系统切换成功后的手工及自动化业务验证命令，可由列表监控及详情监控两个功能单元发起；且若发起的为手工案例验证，则对应的进入到手工测试模块，若发起的为自动化测试案例验证，则调用自动化测试调度模块，进入相关自动化测试操作。

自动化测试调度模块包含本地管理、执行管理以及数据池三大功能子模块，本地管理子模块包括验证交易的模板管理、全局变量及函数等关键字的管理、接收请求时调用本地案例的管理；数据池子模块存放测试过程中产生的业务测试数据，用于后续交易进行调用；执行管理子模块用于将请求Id对应的本地案例的可执行脚本，依据相关策略分配到各个可用的自动化调度机，由自动化调度机通过可执行脚本触发打开各个业务系统，并在业务系统上执行有关交易操作，最后根据自动化调度机返回的运行结果进行判断是否需要更新数据池，与此同时把运行结果返回给调度端，调度端根据运行结果中返回的结果标识值，判断与案例设计的预期返回值是否一致，从而判断案例执行成功与否，进而更新案例的执行状态。

自动化调度机由多台可用的虚拟机组成，虚拟机通过Agent与自动化测试调度模块关联起来，在接收到自动化测试调度模块发送的可执行脚本后，启动业务系统，操作执行相关交易案例，多台虚拟机可实现并行执行，待交易案例执行结束，返回运行结果给自动化测试调度模块，与此同时把交易的执行日志以及有关业务系统交易操作截图保存在本地，以供出错排查或后续有关确认。手工测试模块主要用于对案例进行手工测试，属于现有常规的做法，在此就不做详细说明。

实施例一

本实施例提供一种业务系统可用性验证方法，如图4所示，所述方法用于自动化测试调度模块，所述方法包括：

步骤S1、在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

步骤S2、在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

在本实施例中，所述步骤S1具体为：

在Python环境下，也就是说，本发明在具体实施时，需要在自动化验证调度模块所在的机子上先安装部署Python环境下，再利用Python环境下的requests组件来接收调度端发起的自动化验证案例执行请求，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，如图3所示，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；当然，在具体实施时还可以根据实际需要增加其它的相关字段；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

在本实施例中，所述步骤S2具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

为了更便于理解，下面从前期的统筹规划到业务系统切换后进行自动化业务验证所经历的各个环节来对本发明的技术方案做进一步的说明：

环节1：验证交易确定

由于农信法人组成既有农商行又有信用社，因此自动化业务验证需要同时覆盖两种性质的机构。此外，实际生产业务操作过程中，有密码输入、指纹验证、刷/插卡、移动设备支付等行为，业务验证时需争取保持与真实场景业务操作一致，但由于外设模拟受限，并非所有的手工业务交易都适合转换成自动化进行验证，因此在覆盖尽可能多切换系统、争取接近实际业务场景操作的原则下，先对柜面系统部分交易实现自动化验证。结合各个交易案例测试点，每个交易除可正常操作通过后，还需检查交易通过后核心账务、交易明细、会计分录等是否正确，因此每个案例功能点分析除确定主交易外，还确定了需要辅助验证的相关查询交易，具体如表1。

表1功能拆解表

环节2：自动化业务验证策略

在确定好需要进行自动化业务验证的交易后，采取业务验证的方式为：待所有机构同时完成一支交易的验证后，再同时进入到下一支交易的验证。此验证方式下，所有机构(包含农商行、信用社)同时对一支交易进行验证，且仅当每个机构都完成同一支交易的验证，才能进入下一支交易的验证，整体交易的自动化验证时序图如图2所示。

同时，在此种模式下，当作业调度系统(即调度端)发起某支交易业务的验证请求时，在自动化调度机足够多的前提下，所有机构将且在同一个时刻同时做相同交易。同一支交易会共用一个通用交易模板，且结合每个机构不同的测试数据(如登入柜员、授权柜员、凭证号码等)，一个通用交易模板可对应不同机构生成多个不同的交易执行脚本，即一个通用交易模板与交易执行脚本存在1：N的对应关系，从而N个机构存在N份交易执行脚本，每个机构的交易执行脚本都独立存在。

环节3：自动化案例设计

自动化案例设计包含两个方面的案例设计：第一、导入作业调度系统的案例，由案例的操作顺序、执行用户、执行所在设备等字段组成，此类型案例描述案例测试点内容，以及进行案例操作所需的关联事项，此类案例主要用于调度端用户判断选择发起哪些交易案例验证；第二、本地案例的设计，由自动化执行的类型、调用的脚本、适配器、全局变量等字段组成，主要用于描述每个案例生成自动化调度机最终可执行脚本所需的各类要素。

(1)导入作业调度系统的案例

调度端在发起业务验证时，判断案例为手工验证案例或自动化验证案例的依据在于调度端中，案例信息模板组成的字段不同。手工验证的结果取决于验证人员的主观判断，而自动化验证结果取决于模块对运行结果返回值的判断，因此自动化案例的调用、执行以及判断等操作，依靠于前期对环境、设备、脚本等的设计。

如图3所示，自动化案例模板的部分相关字段的说明：

步骤标识：每个案例都有独立的步骤标识，步骤标识的值从1开始顺序递增，调度端按照步骤标识的顺序，依次发起对应的业务验证请求；

顺序步骤：用于标识案例的执行顺序，数值从1开始顺序递增。顺序步骤与步骤标识存在1:1和1：N两种关系，1:1为一个顺序步骤对应一个步骤标识，代表某一个时刻只执行该步骤标识对应的一个案例；1：N为一个顺序步骤对应N个步骤标识，代表N个步骤标识内对应的N个案例在此顺序步骤可并行执行。仅当同一顺序步骤内所有步骤标识对应的案例均执行通过，调度端将自动发起下一个顺序步骤内所有步骤标识对应案例的执行请求。此处正好对应于上述所提及的自动化业务验证策略，在同一个时刻，仅当所有机构都验证完同一支交易后，才能同时进入到下一支交易的验证；

依赖：若某个交易业务，依赖于前期某个交易业务执行后，此业务才能开展，则可在此处标识出所依赖业务案例的步骤标识；若无，则置为空。

执行用户：自动化验证依靠系统命令发起，由应用的用户执行启动或停止应用系统，windows系统下使用administrator管理员；

任务类型：调度端依靠SHELL脚本来控制自动化测试案例的执行流程，因此任务类型值为：SHELL；

系统类型：用来区分调用脚本的方式，windows环境下直接执行.bat的脚本来触发自动化测试调度模块工作，此处系统类型值为：WINDOWS；

执行所在设备：接收作业调度系统(即调度端)命令，并调动自动化测试调度模块工作的脚本所在IP，本次安装的python环境与自动化测试调度模块在同一台机子，因此执行所在设备亦为自动化测试调度模块所在的虚拟机IP；

执行脚本：接收调度端命令，并调动自动化测试调度模块工作的脚本所在路径；

预期返回值：每个案例预期的返回值，用于与实际运行结果比对。设定每个案例预期返回值均为S00000，若实际返回值与预期一致，则案例执行成功，案例执行状态为通过；若实际返回值非S00000，则案例执行失败，失败的案例具体返回值为“F99999+具体报错信息”，对应案例执行状态为失败。

当然，自动化案例模板中还可包含有子步骤名称、执行检查参数、执行强制切换参数等。如以下表2即表示一个自动化案例：

表2自动化案例示意表

而手工案例模板中包含有用例标题、被测系统、模块名称、功能名称、用例描述、前置条件、步骤名称、步骤描述、预期结果、用例设计人、验证情况等相关字段(如图3所示)。由于手工案例测试验证属于现有常规做法，在此就不说详细说明。

(2)本地案例设计

自动化案例只有生成可执行脚本，才能够被自动化测试调度模块正常调用执行，因此自动化测试调度模块接收到调度端发起的案例Id请求后，会触发自动化测试调度模块根据该案例Id，获取案例管理中该Id的案例类型、调用的交易模板、采用的适配器、涉及的关键字及全局变量等信息，从而根据这些信息来生成最终的可执行脚本，以供自动化调度机执行。

在案例管理功能中，每个案例Id所对应的案例均由Id、名称、类型、脚本、关键字、适配器、全局变量、交易链数据池八个字段来生成最终的可执行脚本。具体每个字段说明如下：

Id：独立标识每个案例，自动化案例模板中执行切换参数字段中的Id值对应于此处的Id值；

名称：案例测试点描述；

类型：类型分为界面和接口两种，若为柜面系统界面UI的自动化测试，类型为界面；若为发起报文测试，则类型为接口；

脚本：每个案例执行时所调用的脚本，相同交易共用一个通用交易模板，通用交易模板内具体的变量取值于全局变量及每个机构的具体数据池，因此不同机构执行相同交易案例时，调用相同一个模板，但具体执行脚本不同；

关键字：存放启用脚本所需报文头及脚本中涉及的各类函数；

适配器：自动化调用的脚本类型字段，界面测试适配器为QTP，而接口测试适配器则为Java，由对应的适配器驱动执行；

全局变量：存放有关常量、固定查询语句等通用测试数据；

交易链数据池：交易过程中所需要保存的业务验证数据，用于后续关联交易直接调用，每个机构均拥有一个独立的数据池，避免数据交叉覆盖。如以下表3即表示一个本地案例：

表3本地案例示意表

环节4：交易模板设计

根据测试案例需求，对操作交易编写通用交易模板，通用交易模板原则上是根据交易业务逻辑进行编写，覆盖交易的各个业务分支，模板内容涉及的交易流程为：柜员登录、搜索交易、交易界面字段输入、流程分支、操作并提交、检查交易结果。编写通用交易模板前，需定义界面上不同类型的操作框：日期框、文本框、下拉框、表格、按钮等，不同类型操作框实现功能不同，因此必须进行定义封装；编写通用交易模板时，相同的字段输入可在模板中固定数值或从全局变量获取相同的常量值，而某个字段输入若依据机构前期业务操作作为特定来源，则通过“@XXX”来获取字段XXX前期保存在对应机构数据池的值；根据每支交易特定需求，可在模板中设计不同函数，设计的函数也可放到关键字中，供其他交易进行调用。以下为通用交易模板的一具体实例：

LoginFWT＝＝$@登陆柜员$＝＝888888＝＝$@授权柜员$＝＝

SetJavaEditType＝＝柜面.交易搜索＝＝043002＝＝

WaitLabels＝＝交易窗口.机构代码＝＝

SetJavaCombo＝＝交易窗口.支付渠道＝＝0-大额＝＝

SetJavaEdit＝＝交易窗口.平台流水号＝＝$@大额平台流水号$＝＝

ClickJavaAButton＝＝交易窗口.提交＝＝

#取消打印

WaitJavaWindow＝＝提示＝＝正在通讯＝＝$False$＝＝

GetKTable＝＝$CreditNumber$＝＝业务状态|账务状态＝＝已清算|记账成功＝＝支付渠道＝＝

SnapScreen＝＝交易页面截图＝＝

ClickJavaAButton＝＝交易窗口.退出＝＝

设计的常用函数：如截图关键字，可实现在某个操作后把柜面界面截图保存在本地，以供后续检查确认；凭证号获取函数，在关键字中封装好此函数功能，可在开户或其他交易中，直接通过此函数获取所需的凭证号码，避免在交易中重复编写获取凭证号的功能代码，减少代码冗余；表格字段获取函数，通过有关条件查询判断表格中是否存在相关记录，可用于在账务类交易后，通过交易流水号判断交易的会计分录及借贷是否正确等。具体的常用函数设计如表4：

表4自动化基本函数表

环节5：自动化业务验证测试执行

在自动化测试调度模块所在的机子安装部署Python环境，利用Python环境下的requests组件接收调度端发起的自动化验证案例执行请求，获取请求中的案例Id，触发自动化测试调度模块对该案例Id进行操作。在自动化测试调度模块接收该案例Id的执行请求时，首先根据执行请求内的案例Id关联触发对应本地案例，其次把本地案例对应的可执行脚本发送给可用的自动化调度机，自动化调度机根据接收到的可执行脚本(即交易脚本)进行自动化测试验证，最后自动化测试调度模块接收从自动化调度机返回的运行结果，具体流程如图4所示。

在具体实施时，若可执行脚本正常执行完成，则自动化调度机返回交易执行成功信息给自动化测试调度模块，自动化测试调度模块返回成功标识S00000给调度端；若可执行脚本执行报错，则自动化调度机获取业务系统上的报错信息返回给自动化测试调度模块，自动化测试调度模块返回失败标识F99999及具体业务报错信息给调度端。其中，S00000代表脚本正常执行完成，即代表案例验证通过；F99999代表脚本执行报错，即案例执行失败，此时返回的信息除F99999外，还有业务关联系统返回的具体报错信息，以方便验证人员排查具体业务验证失败原因。每个案例的运行结果都会及时返回给自动化测试调度模块及调度端，自动化测试调度模块在获取案例执行通过后，会根据通用交易模板的设计自动更新每个数据池中的有关数据，调度端在获取S00000后，更新案例执行状态为通过，在获取F99999及具体报错信息后，置案例执行状态为失败。当调度端发现同一‘顺序步骤’执行完后，存在有‘步骤标识’下的案例执行状态为失败，则调度端暂停发起下一‘顺序步骤’内的案例执行请求，此时，需要人工干预判断执行失败的原因，并针对失败原因进行分析，根据分析结果，可再次单独发起对某个失败案例的自动化执行请求，或无需处理可直接置该失败案例为忽略或通过。仅当同一‘顺序步骤’下的案例均执行通过后，调度端才自动进入发起下一个‘顺序步骤’所对应的案例执行请求。当调度端上所有‘顺序步骤’内的案例均执行通过，则说明自动化验证任务完成。

下面列举一具体应用实例来对本发明的技术效果进行验证说明：

本司在2019年第二季度引入自动化测试调度模块进行自动化业务验证，在灾备数据中心采用7台虚拟机(1台作为调度管理、6台执行机)，在6个机构上(涵盖农商行、信用社)执行了85个案例，覆盖核心账务系统CORE、柜面系统TOP、企业服务总线ESB、统一密钥管理系统KMS、统一支付系统UPP、内联通讯前置NLFE共六个系统，不仅验证灾备切换业务的正常操作，而且通过相关查询交易进一步验证操作交易账务、会计分录的正确性，借贷方向的一致性。切换测试总用时1小时14分57秒，自动化在六个机构上测试用时1小时6分钟，较一季度在一个机构进行18个案例的手工测试，验证时间缩短50％。2019年第四季度在异地灾备真实切换演练中，作业调度系统演练了153个流程、4000余个步骤，在覆盖日常交易量80％以上的柜面系统TOP、网络支付清算系统NPS、短信银行系统SMS、指纹认证系统FAS等23套重要系统上，成功的在67家行社、1家村镇银行、各科技分中心、科技部、运营部完成了覆盖ATM、手机银行、借记卡、支付结算等主要业务和渠道共66个案例的业务验证，验证阶段主灾备切换业务验证用时1小时19分56秒，灾备回切业务验证用时25分43秒。通过与作业调度系统对接，实现了全程自动化切换，通过引入自动化业务验证，不仅扩大了灾备切换验证的机构数，而且有效降低人员成本，达到与手工业务验证同样的效果，有效发挥自动化测试优势。

基于同一发明构思，本申请还提供了与实施例一中的方法对应的装置，详见实施例二。

实施例二

在本实施例中提供了一种业务系统可用性验证装置，如图5所示，，所述装置包括脚本生成单元以及自动化验证单元；

所述脚本生成单元，用于在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

所述自动化验证单元，用于在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

在本实施例中，所述脚本生成单元具体为：

在Python环境下，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

在本实施例中，所述自动化验证单元具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

由于本发明实施例二所介绍的装置，为实施本发明实施例一的方法所采用的装置，故而基于本发明实施例一所介绍的方法，本领域所属人员能够了解该装置的具体结构及变形，故而在此不再赘述。凡是本发明实施例一的方法所采用的装置都属于本发明所欲保护的范围。

基于同一发明构思，本申请提供了实施例一对应的电子设备实施例，详见实施例三。

实施例三

本实施例提供了一种电子设备，如图6所示，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，可以实现实施例一中任一实施方式。

由于本实施例所介绍的电子设备为实施本申请实施例一中方法所采用的设备，故而基于本申请实施例一中所介绍的方法，本领域所属技术人员能够了解本实施例的电子设备的具体实施方式以及其各种变化形式，所以在此对于该电子设备如何实现本申请实施例中的方法不再详细介绍。只要本领域所属技术人员实施本申请实施例中的方法所采用的设备，都属于本申请所欲保护的范围。

基于同一发明构思，本申请提供了实施例一对应的存储介质，详见实施例四。

实施例四

本实施例提供一种计算机可读存储介质，如图7所示，其上存储有计算机程序，该计算机程序被处理器执行时，可以实现实施例一中任一实施方式。

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

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

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

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

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

通过自动化测试调度模块来实现计算机模拟测试人员进行业务测试操作，能够实现业务测试验证自动化。通过调度端对测试案例执行机器的调度控制与通信，能够实现业务测试案例执行控制与测试结果收集。调度端与执行机器(即自动化调度机)上的Agent进行通讯调度，通过增加执行测试的虚拟机就可以快速的进行横向扩展，能够提高测试的并行效率。通过调度端设置业务测试步骤执行的先后依赖关系，使得自动化测试能够达到真实业务测试的效果。同时，通过数据池，能够及时存放并区分每个机构切换演练中自动化测试所采用的业务验证数据。

随着银行业务不断发展，灾备数据中心业务验证的案例愈加复杂繁多，通过人工测试按季度甚至按月开展灾备数据中心业务验证需要耗费大量人员与时间。本发明通过实现灾备数据中心业务自动化测试，提高测试效率，可使得灾备数据中心季度例行验证在较少人员参与的情况下也可以顺利开展，从而保障灾备数据中心可用性。

虽然以上描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。

Claims (8)

1.一种业务系统可用性验证方法，其特征在于：所述方法用于自动化测试调度模块，所述方法包括：

步骤S1、在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

步骤S2、在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

2.根据权利要求1所述的一种业务系统可用性验证方法，其特征在于：所述步骤S1具体为：

在Python环境下，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

3.根据权利要求1所述的一种业务系统可用性验证方法，其特征在于：所述步骤S2具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

4.一种业务系统可用性验证装置，其特征在于：所述装置包括脚本生成单元以及自动化验证单元；

所述脚本生成单元，用于在Python环境下接收调度端发起的自动化验证案例执行请求，获取自动化验证案例执行请求中的案例ID；根据获取到的案例ID关联触发对应的本地案例，将触发的本地案例所对应的交易执行脚本分配给自动化调度机；

所述自动化验证单元，用于在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，接收自动化调度机返回的运行结果，并根据所述运行结果更新数据池中的相关数据；同时，将运行结果返回给调度端，并更新案例的执行状态。

5.根据权利要求4所述的一种业务系统可用性验证装置，其特征在于：所述脚本生成单元具体为：

在Python环境下，接收调度端基于自动化案例模板发起的自动化验证案例执行请求，所述自动化案例模板中包含有以下相关字段：步骤标识、顺序步骤、依赖、执行用户、任务类型、执行所在设备、子步骤名称、系统类型、执行脚本、执行切换参数以及预期返回值；

在接收到自动化验证案例执行请求后，获取自动化验证案例执行请求中的案例ID，基于所述案例ID从案例管理中关联触发对应的本地案例，基于本地自动化案例模板将触发的本地案例生成交易执行脚本；且在生成交易执行脚本的过程中，对于任意一支交易，均根据测试案例需求预先编写通用交易模板，并结合每个机构不同的测试数据，对每个机构均生成一份交易执行脚本；所述本地自动化案例模板中包含有以下相关字段：案例ID、名称、类型、脚本、关键字、适配器、全局变量以及交易链数据池；

在生成交易执行脚本后，依据自动化业务验证策略将所述交易执行脚本分配给各可用的自动化调度机进行自动化验证；所述自动化业务验证策略具体包括：对于任意一支交易，涉及该交易的所有机构均同时对该交易进行验证，且当且仅当所有机构均完成对该交易的验证后，再同时进入到下一支交易的验证。

6.根据权利要求4所述的一种业务系统可用性验证装置，其特征在于：所述自动化验证单元具体为：

在自动化调度机调用业务系统执行完对所述交易执行脚本的自动化验证后，若所述交易执行脚本执行通过，则接收自动化调度机返回的成功标识，并自动更新数据池中的相关数据；同时，将成功标识返回给调度端，并基于所述成功标识将调度端中的案例执行状态置为通过；

若所述交易执行脚本执行报错，则接收自动化调度机返回的失败标识以及具体业务报错信息，且不更新数据池中的相关数据；同时，将失败标识以及具体业务报错信息返回给调度端，并基于所述失败标识将调度端中的案例执行状态置为失败。

7.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至3任一项所述的方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至3任一项所述的方法。

Images