CN113238886A - 功能服务的测试方法、系统以及终端设备 - Google Patents

Abstract

本发明涉及金融科技技术领域，公开了一种功能服务的测试方法、系统以及终端设备。该功能服务的测试方法通过客户端获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果。相比于基于传统挡板测试技术—mock server进行功能服务测试的方式，本发明能改善传统挡板测试无法模拟挡板完成功能服务测试的缺陷，提升了针对功能服务进行测试的测试效率。

Description

功能服务的测试方法、系统以及终端设备

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及一种功能服务的测试方法、系统以及终端设备。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性以及稳定性等要求，也对技术提出了更高的要求。

目前，针对开发或者升级过程当中的应用或系统进行功能服务测试大都是基于挡板测试(又称mock测试，mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法)技术来进行，然而，由于目前的挡板测试技术都是针对需要测试的应用或系统外部的服务对象进行模拟，从而，在需要测试的应用或系统的功能服务与其它服务之间存在相互依赖关系，但若其它服务中的某一个或者多个服务不提供对外的服务或者尚未完成开发(未开发完成则挡板测试技术无法创建虚拟对象)时，则无法使用该挡板测试技术进行该功能服务的测试。

发明内容

本发明的主要目的在于提供一种功能服务的测试方法、装置、终端设备、计算机存储介质以及计算机程序产品，旨在提升基于挡板测试技术来进行功能服务测试的测试效率。

为实现上述目的，本发明提供一种功能服务的测试方法，所述功能服务的测试方法应用于客户端，所述功能服务的测试方法包括：

获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果。

此外，为实现上述目的，本发明还提供一种功能服务的测试方法，所述功能服务的测试方法应用于挡板服务端，所述挡板服务端与如上所述的客户端相连接，所述功能服务的测试方法包括：

根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

获取所述客户端传递的客户端信息；

按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

此外，为实现上述目的，本发明还提供一种功能服务的测试系统，所述功能服务的测试系统包括客户端，所述客户端包括：

第一获取模块，用于获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

拦截模块，用于拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

测试模块，用于在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果；

所述功能服务的测试系统还包括挡板服务端，所述挡板服务端包括：

规则配置模块，用于根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

第二获取模块，用于获取所述客户端传递的客户端信息；

规则推送模块，用于按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

其中，本发明功能服务的测试系统的各功能模块在运行时实现如上所述的功能服务的测试方法的步骤。

此外，为实现上述目的，本发明还提供一种终端设备，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的功能服务的测试程序，所述功能服务的测试程序被所述处理器执行时实现如上所述的功能服务的测试方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机存储介质，所述计算机存储介质上存储有功能服务的测试程序，所述功能服务的测试程序被处理器执行时实现如上所述的功能服务的测试方法的步骤。

此外，为实现上述目的，本发明还提供计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如上所述的功能服务的测试方法的步骤。

本发明提供一种功能服务的测试方法、系统、终端设备、计算机存储介质以及计算机程序产品，通过客户端获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果。

本发明在针对开发或者升级过程当中的应用或系统进行功能服务测试时，通过装载有该功能服务的客户端，获取在与该客户端连接的挡板服务端中配置得到的挡板规则，然后直接在本地拦截测试工作人员针对该功能服务所发起的测试请求，并解析该测试请求得到相关的请求参数，最后也是在本地按照获取到的该挡板规则针对该请求参数进行比较之后直接生成对应的测试结果。

本发明相比于基于传统挡板测试技术—mock server进行功能服务测试的方式，针对待测试的功能服务的测试请求无需再外发至挡板服务端，从而即使在该功能服务依赖的其他服务不提供对外服务或者没有完全开发完成时，也能够直接在客户端本地完成针对待测试功能服务的整个测试过程，进而改善了传统挡板测试无法模拟挡板完成功能服务测试的缺陷，提升了针对功能服务进行测试的测试效率。

此外，由于本发明功能服务的测试方法都是在客户端本地执行，即挡板规则的比较过程和测试结果的生成、输出等都在安装待测试的功能服务的本端，并不需要额外的将针对该功能服务的测试请求进行外发，从而减少甚至避免了可网络传输延时对于功能服务测试带来的影响，进一步提升了测试效率。

附图说明

图1为本发明实施例方案涉及的终端设备硬件运行环境的设备结构示意图；

图2为本发明功能服务的测试方法第一实施例的流程示意图；

图3为本发明功能服务的测试方法一实施例所涉及的应用场景示意图；

图4为本发明功能服务的测试方法一实施例所涉及的应用流程示意图；

图5为本发明功能服务的测试方法一实施例所涉及的另一应用流程示意图；

图6为本发明功能服务的测试方法一实施例所涉及的又一应用流程示意图；

图7为本发明功能服务的测试方法一实施例所涉及的图形用户界面；

图8为本发明功能服务的测试系统一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的终端设备硬件运行环境的设备结构示意图。

本发明实施例终端设备可以是装载有需要进行测试的功能服务的客户端设备，或者，本发明实施例终端设备还可以是专门用于针对该功能服务进行测试从而配置相关挡板规则的挡板服务端设备，该设备可以是智能手机、PC(Personal Computer，个人计算机)、平板电脑、便携计算机等等。

如图1所示，该终端设备可以包括：处理器1001，例如CPU，通信总线1002，用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如Wi-Fi接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的终端设备结构并不构成对终端设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及功能服务的测试程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的功能服务的测试程序，并执行以下功能服务的测试方法的各实施例。

基于上述硬件结构，提出本发明功能服务的测试方法的各实施例。

需要说明的是，目前，针对开发或者升级过程当中的应用或系统进行功能服务测试大都是基于挡板测试技术来进行，然而，由于目前的挡板测试技术都是针对需要测试的应用或系统外部的服务对象进行模拟，例如，参照如附图3所示的应用场景，在待测试的功能服务A的执行需要依赖针对外部功能B或者外部功能C的执行，且外部功能C的执行需要依赖针对外部功能D和外部功能E的共同执行时，传统的mock server就需要将该外部功能B、外部功能C、外部功能D和外部功能E都进行模拟，以供测试功能服务A时进行调用。

然而，在需要测试的应用或系统的功能服务与其它服务之间存在相互依赖关系，但其其它服务中的某一个或者多个服务不提供对外的服务或者尚未完成开发(例如上述例子中，外部功能D和外部功能E还未开发)时，传统的挡板测试技术就无法模拟该一个或者多个服务供待测试的功能服务进行调用，从而也就无法使用该挡板测试技术进行该功能服务的测试过程，因此，目前基于传统的挡板测试技术来进行功能服务测试的测试效率仍有待提升。

针对上述现象，本发明提供一种功能服务的测试方法。请参照图2，图2为本发明功能服务的测试方法第一实施例的流程示意图，在本实施例中，该功能服务的测试方法应用于上述装载有待测试的功能服务的客户端设备，该功能服务的测试方法包括：

步骤S10，获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

需要说明的是，在本实施例中，待测试的功能服务的挡板规则通过与当前客户端设备所连接的挡板服务端设备进行配置得到，该挡板服务端设备提供有面向测试工作人员的图形用户接口，从而该挡板服务端设备基于该图形用户接口接收测试工作人员针对待测试的功能服务进行测试所输入的规则配置数据，进而按照该规则配置数据配置生成挡板规则。

客户端设备在挡板服务端设备配置生成用于针对待测试的功能服务进行测试的挡板规则之后，从该挡板服务端设备当中直接获取该挡板规则并直接将该挡板规则存储在本地。

具体地，例如，客户端设备通过与挡板服务端设备建立http(Hypertext TransferProtocol：超文本传输协议)的网络连接或者建立rmb(Reliable Message Bus：可靠的消息总线，rmb支持消息队列的通信方式)类型的通信连接，从而通过该http网络连接或者rmb通信连接从挡板服务端设备当中，拉取用于针对待测试的功能服务进行测试而配置生成的挡板规则，然后将该挡板规则直接存储在本地以供后续调用。

进一步地，在一种可行的实施例中，上述步骤S10，可以包括：

步骤S101，在检测到所述功能服务启动时，从所述挡板服务端中获取针对所述功能服务配置的所述挡板规则，并将所述挡板规则存储在本地缓存当中。

客户端设备在安装了待测试的功能服务之后，即持续的监测该功能服务是否被触发启动，并在监测到该功能服务被触发启动时，即开始从挡板服务端设备当中，或者该挡板服务端设备配置生成用于针对该功能服务进行测试的挡板规则，并直接将该挡板规则存储在本地。

具体地，例如，请参照如图5所示的应用流程示意图，客户端设备在与挡板服务端设备建立http网络连接或者rmb通信连接，并在本地下载和安装待测试的功能服务之后(默认此时挡板服务端设备也已经在本地配置生成了针对该功能服务进行测试的挡板规则)，该客户端设备即持续的监测系统是否基于测试人员的操作触发针对该功能服务的启动指令，从而在客户端设备监测到该启动指令以启动运行该功能服务(图示应用系统)的同时，该客户端设备也同步的通过与挡板服务端设备(图示mock-admin)建立的http网络连接或者rmb通信连接，从挡板服务端设备当中查询已经配置生成的挡板规则，并进一步查询该挡板规则当中，属于当前客户端设备上所安装的该功能服务的目标挡板规则，最后，拉取该目标挡板规则并直接将该目标挡板规则存储在本地运行该功能服务的缓存(SDK)当中以供后续调用。

进一步地，在一种可行的实施例中，在上述步骤S10之前，本发明功能服务的测试方法，还可以包括：

步骤S40，采集客户端信息，并将所述客户端信息传递至所述挡板服务端，以供所述挡板服务端按照所述客户端信息推送所述挡板规则。

需要说明的是，在本实施例中，客户端信息为用于提供给挡板服务端设备，由该挡板服务端按照该客户端信息主动推送挡板规则的信息，例如，该客户端信息具体可以为ip(Internet Protocol，网际互连协议)地址信息和通信端口信息，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，该客户端信息当然也可以是其它本实施例所列举的上述ip地址信息和通信端口信息之外，但同样能够起到上述作用的其它信息，本发明功能服务的测试方法并不针对该客户端信息的具体种类进行限定。

客户端设备在与挡板服务端设备建立通信连接之后，即开始在本地采集用于提供给挡板服务端设备，由该挡板服务端主动推送挡板规则的客户端信息，然后，该客户端设备即将该客户端信息上传至挡板服务端设备，以供该挡板服务端设备在配置生成针对待测试的功能服务进行测试的挡板规则之后，主动的将该挡板规则推送至客户端设备，由该客户端设备直接将该挡板规则存储在本地。

具体地，例如，客户端设备在与挡板服务端设备建立http网络连接或者rmb通信连接之后，即开始在本地采集ip地址信息和通信端口信息，并将采集到的该ip地址信息和通信端口信息通过http网络连接或者rmb通信连接传递给该挡板服务端设备，从而，该挡板服务端设备即可在配置生成了针对待测试的功能服务的挡板规则之后，即按照该ip地址信息和通信端口信息，定期的主动推送该挡板规则至客户端设备，该客户端设备在接收到该挡板规则之后，同样的直接将该挡板规则存储在本地以供后续调用。

需要说明的是，在本实施例中，挡板服务端设备基于接收规则配置数据在本地配置生成针对待测试的功能服务进行测试的挡板规则。即挡板服务端设备通过前端屏幕面向测试工作人员输出的图形用户接口，接收该测试工作人员针对待测试的功能服务输入的用于配置挡板规则的规则配置数据，然后立即按照该规则配置数据在本地配置生成挡板规则。

具体地，例如，挡板服务端设备前端屏幕面向测试工作人员输出的图形用户接口具体可以为如附图7所示的图形用户界面，请参照如图4的应用流程，多个挡板服务端设备(图示mock-admin)中的任一个挡板服务端设备在接收到基于nginx(Nginx(engine x)是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务)技术进行分流后接入的登入请求，从而基于该登入请求允许对应的测试工作人员登录之后，即通过前端屏幕向该测试工作人员输出如附图7所示的图形用户界面，从而该挡板服务端基于该图形用户界面接收测试工作人员输入的规则配置数据配置挡板规则的条件以及返回值(即，配置当测试请求中的请求参数a＝1,则返回“true”,否则，返回“false”)，从而生成挡板规则(mock规则)。

步骤S20，拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

客户端设备在从挡板服务端设备获取得到用于对待测试的功能服务进行测试的挡板规则之后，进一步监测测试工作人员触发的针对该功能服务的测试请求，并在监测该测试请求时对该测试请求进行拦截，和解析该测试请求得到请求参数。

具体地，例如，请参照如图6所示的应用流程示意图，客户端设备在从挡板服务端设备中，拉取得到该挡板服务端设备配置生成的针对待测试的功能服务(应用系统)的挡板规则，并将该挡板规则存储在本地运行该功能服务(应用系统)的缓存(SDK)中之后，该客户端设备即开始监测测试工作人员(图示系统用户)基于测试需要而针对该功能服务(应用系统)发起的测试请求(图示用户请求)，客户端设备在监测到该测试请求(用户请求)之后，立即在本地缓存(SDK)当中拦截该测试请求(用户请求)并进行解析得到请求参数。

需要说明的是，在本实施例中，客户端设备基于spring aop技术(Spring:Spring框架是一个开源应用程序框架，是针对JAVA对象的生命周期进行管理的轻量级容器；AOP:Aspect Oriented Programming，面向切面编程，在程序开发中主要用来解决一些系统层面上的问题，在不改变原有的逻辑的基础上，增加一些额外的功能)来拦截针对待测试的功能服务所发起的测试请求。

具体地，由于测试工作人员针对待测试的功能服务所发起的测试请求若在没有被拦截的情况下，是通过该客户端设备与挡板服务端设备之间建立的http网络连接或者rmb通信连接传递至该挡板服务端设备的，因此，通过采用spring aop技术在存储有挡板规则的本地缓存——mock-sdk中预先对http或者rmb接收请求入口做拦截即可拦截到针对该功能服务的全部请求，采用spring aop技术，在该功能服务启动过程中动态生成代理对象，代理对象相对原代码中加入上述存储在缓存——mock-sdk中的mock规则的代码，如此，当接收到针对该功能服务的请求后，客户端设备也会执行该mock规则的代码，从而实现针对该请求的拦截以及相应的mock功能(将解析到的请求参数与挡板规则进行比较)。

步骤S30，在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果。

客户端设备在将从挡板服务端设备中获取到的针对待测试的功能服务的挡板规则存储在本地，以及拦截到针对该功能服务发起的测试请求并解析得到请求参数之后，该客户端设备即直接在本地将该请求参数与该挡板规则进行比较从而生成针对该功能服务的测试请求的测试结果，并将该测试结果通过该服务请求面向测试工作人员的图形用户接口进行输出。

进一步地，在一种可行的实施例中，上述步骤S30，可以包括：

步骤S301，在所述本地缓存中遍历所述挡板规则；

步骤S302，在遍历所述挡板规则的过程中，将所述请求参数与所述挡板规则进行比较以动态生成测试结果。

客户端设备在本地缓存当中遍历针对待测试的挡板规则，并逐一的将遍历到的挡板规则与解析到的请求参数进行比较，并将比较得到响应值作为针对该功能服务的测试请求的测试结果，最后直接在本地通过该服务请求面向测试工作人员的图形用户接口将该测试结果进行输出。

需要说明的是，在本实施例中，挡板服务端设备基于测试工作人员输入的规则配置数据配置生成的挡板规则当中，配置模拟了待测试功能服务所依赖的服务对应的响应值，如，该挡板服务端设备在某挡板规则的配置过程中配置了：“当请求参数A＝1时，返回“成功”；当请求参数A＝2时，返回“失败’”，如此，该配置过程中的“请求参数A＝1”以及“请求参数A＝2”即为挡板规则，对应的“返回成功”与“返回失败”为响应值。

具体地，例如，请参照如图6所示的应用流程示意图，客户端设备在本地缓存(SDK)当中拦截测试请求(用户请求)并进行解析得到请求参数之后，立即开始在本地缓存(SDK)当中遍历从挡板服务端设备中获取得到的挡板规则(mock规则)，并在每遍历到一条规则时，即将该规则与该请求参数进行比较，从而在比较到该规则当中记载的请求参数与解析得到的请求参数相同时，立即基于groovyshell(Groovy:用于Java虚拟机的一种敏捷的动态语言，它是一种成熟的面向对象的编程语言，即可以用于面向对象编程，又可以用作脚本语言)语言将该规则当中记载的请求参数所对应的响应值，封装成当前测试请求的测试结果，从而动态的在本地直接生成了针对待测试的功能服务(应用系统)的测试结果。此外，客户端设备在基于groovyshell语言动态生成测试结果之后，进一步通过前端屏幕上输出的该功能服务(应用系统)面向测试工作人员(系统用户)的图形用户接口—图形用户界面输出该测试结果。

需要说明的是，在本实施例中，客户端设备基于groovyshell语言动态生成测试结果具体可以为：由groovyshell语言基于java虚拟机执行java字节码语法要求，将挡板服务端设备—mock-admin中配置的挡板规则按照该java字节码语法要求，先动态生成一个java类，然后将该java类编译成java字节码文件加载到虚拟机中，从而java虚拟机在执行后就可以返回将请求参数与挡板规则进行比较后的测试结果，以将该测试结果直接响应给客户端设备前端。

本发明实施例提供一种功能服务的测试方法，通过客户端设备在挡板服务端设备配置生成用于针对待测试的功能服务进行测试的挡板规则之后，从该挡板服务端设备当中直接获取该挡板规则并直接将该挡板规则存储在本地；客户端设备在从挡板服务端设备获取得到用于对待测试的功能服务进行测试的挡板规则之后，进一步监测测试工作人员触发的针对该功能服务的测试请求，并在监测该测试请求时对该测试请求进行拦截，和解析该测试请求得到请求参数；客户端设备在将从挡板服务端设备中获取到的针对待测试的功能服务的挡板规则存储在本地，以及拦截到针对该功能服务发起的测试请求并解析得到请求参数之后，该客户端设备即直接在本地将该请求参数与该挡板规则进行比较从而生成针对该功能服务的测试请求的测试结果，并将该测试结果通过该服务请求面向测试工作人员的图形用户接口进行输出。

本发明相比于基于传统挡板测试技术—mock server进行功能服务测试的方式，针对待测试的功能服务的测试请求无需再外发至挡板服务端，从而即使在该功能服务依赖的其他服务不提供对外服务或者没有完全开发完成时，也能够直接在客户端本地完成针对待测试功能服务的整个测试过程，进而改善了传统挡板测试无法模拟挡板完成功能服务测试的缺陷，提升了针对功能服务进行测试的测试效率。

此外，由于本发明功能服务的测试方法都是在客户端本地执行，即挡板规则的比较过程和测试结果的生成、输出等都在安装待测试的功能服务的本端，并不需要额外的将针对该功能服务的测试请求进行外发，从而减少甚至避免了可网络传输延时对于功能服务测试带来的影响，进一步提升了测试效率。

进一步地，基于上述第一实施例，提出本发明功能服务的测试方法的第二实施例，本实施例与上述第一实施例之间的主要区别在于，在本实施例中，客户端设备除了将从挡板服务端设备当中获取得到的挡板规则存储在本地缓存(SDK)以外，该客户端设备还可以将该挡板规则存储在本地固定的内存当中。本发明功能服务的测试方法，还可以包括：

步骤S50，将所述挡板规则贮存在本地内存当中，并按照预设第一时间周期针对所述挡板规则进行更新处理；

需要说明的是，在本实施例中，本地内存为客户端设备除了每一次运行功能服务所占用的缓存(SDK)之外，用于稳定贮存系统文件的内部存储空间。

客户端设备在从挡板服务端设备当中，获取得到该挡板服务端设备配置生成的用于针对待测试的功能服务进行测试的挡板规则之后，进一步将该挡板规则贮存在本地用于稳定贮存系统文件的内部存储空间当中，从而，在后续监测到该功能服务基于测试工作人员的操作触发启动，并接收到该测试工作人员针对该功能服务发起的测试请求时，直接从本地的该内部存储空间当中遍历挡板规则以将遍历到的挡板规则与解析该测试请求得到的请求参数进行比较得到响应值，进而在本地直接将该响应值封装成测试结果进行输出。

此外，需要说明的是，在本实施例中，预设第一时间周期为客户端设备针对本地内存当中贮存的挡板规则进行更新处理所依据的时间周期，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施例当中，客户端设备当然可以采用不同大小的时间周期来针对本地贮存的挡板规则进行更新处理，本发明功能服务的测试方法并不针对该预设第一时间周期的具体大小进行限定。

客户端设备在从挡板服务端设备将挡板规则都拉取到本地的内部存储空间中进行贮存之后，由于该挡板服务端设备可能会基于测试人员新输入的规则配置数据对已经配置的挡板规则进行修改、删除原挡板规则或者增加新的挡板规则，因此，客户端设备为了保证本地贮存的挡板规则与该挡板服务端设备配置的挡板规则保持一致，该客户端设备即按照一定的时间周期(预设第一时间周期)再次从该挡板服务端设备当中获取全部的挡板规则，从而利用新获取到的挡板规则针对本地贮存的挡板规则进行更新，即，增加贮存新的挡板规则、替换已经修改过的挡板规则，和/或者，删除本地贮存的挡板规则存在，但新获取到的挡板规则中不存在的挡板规则。

进一步地，在另一种可行的实施例中，本发明功能服务的测试方法，还可以包括：

在本地内存当中配置生成针对待测试的功能服务的挡板规则。

客户端设备通过在本地接收测试工作人员针对待测试的功能服务的规则配置数据，直接在本地的内部存储空间当中配置生成挡板规则，并将该挡板规则以客户端设备运行系统能够提取的系统配置文件进行贮存，如此，客户端设备在后续监测到该功能服务基于测试工作人员的操作触发启动，并接收到该测试工作人员针对该功能服务发起的测试请求时，直接从本地的该内部存储空间当中提取系统配置文件以遍历挡板规则，并将遍历到的挡板规则与解析该测试请求得到的请求参数进行比较得到响应值，进而在本地直接将该响应值封装成测试结果进行输出。

在本实施例中，通过客户端设备将从挡板服务端设备中获取的挡板规则贮存在本地用于稳定贮存系统文件的内部存储空间当中，或者，通过客户端设备直接在本地接收测试工作人员针对待测试的功能服务的规则配置数据，以根据该规则配置数据在本地配置生成挡板规则，并将该挡板规则以客户端设备运行系统能够提取的系统配置文件进行贮存，从而，在后续监测到该功能服务基于测试工作人员的操作触发启动，并接收到该测试工作人员针对该功能服务发起的测试请求时，直接从本地的该内部存储空间当中遍历挡板规则以将遍历到的挡板规则与解析该测试请求得到的请求参数进行比较得到响应值，进而在本地直接将该响应值封装成测试结果进行输出。

如此，在客户端设备与挡板服务端设备之间的通信连接出现异常，从而无法在待测试的功能服务启动运行时拉取到挡板规则，或者该挡板服务端设备出现故障无法运行等异常情况下，客户端设备仍可以基于以前拉取贮存在内部存储空间或者直接配置在该内部存储空间的挡板规则，在本地进行针对该功能服务的测试请求的比较以生成测试结果，保障针对该功能服务的测试能够顺利进行，进一步提升了测试效率。

进一步地，基于上述第一实施例和第二实施例，提出本发明功能服务的测试方法的第三实施例，本实施例与上述第一实施例和第二实施例之间的主要区别在于，在上述步骤S20，拦截针对所述功能服务发起的测试请求之后，本发明功能服务的测试方法，还可以包括：

步骤A，检测所述测试请求是否与原测试请求相同；

需要说明的是，在本实施例中，客户端设备每一次在本地拦截针对待测试的功能服务的测试请求，并解析获取请求参数和遍历挡板规则进行比较生成测试结果之后，均将拦截到的该测试请求和生成的该测试结果关联存储在本地的缓存(SDK)和/或者内部存储空间当中，本实施例所述的原测试请求即为客户端设备在该缓存(SDK)和/或者内部存储空间当中存储且已经关联有对应测试结果的测试请求。

客户端设备在每一次拦截到测试工作人员针对待测试的功能服务发起的测试请求之后，均将该测试请求与预先存储在本地缓存和/或者内部存储空间当中且已经关联有对应测试结果的原测试请求进行比对，以检测该测试请求是否与该原测试请求相同。

具体地，例如，客户端设备在基于spring aop技术拦截到测试工作人员针对待测试的功能服务所发起的测试请求之后，立即将该测试请求与本地缓存(SDK)和/或者内部存储空间当中与测试结果相关联存储的原测试请求进行比对，即，比对该测试请求的请求参数是否与该原测试请求的请求参数相同，从而在比对该两种请求参数相同时，即确定该测试请求与该原测试请求是相同的。

步骤B，若是，则在本地索引所述原测试请求对应的原测试结果，并将所述原测试结果作为所述测试请求对应的测试结果进行反馈。

客户端设备在检测到新拦截的测试请求与原测试请求相同时，直接将预先存储在本地缓存和/或者内部存储空间当中，与该原测试请求相关联的测试结果作为当前新拦截的测试请求所对应的测试结果，并将该测试结果通过当前待测试的服务请求面向测试工作人员的图形用户接口进行输出。

具体地，例如，客户端设备在比对到当前新拦截到的测试请求的请求参数与原测试请求的请求参数相同，从而确定该测试请求与该原测试请求是相同的情况下，该客户端设备即直接在本地缓存(SDK)和/或者内部存储空间当中提取出与该原测试请求相关联着的测试结果，并将该测试结果作为当前新拦截到的测试请求所对应的测试结果，以通过该客户端设备前端屏幕上输出的该功能服务面向测试工作人员的图形用户接口—图形用户界面输出该测试结果。

需要说明的是，由于客户端设备在每一次基于GroovyShell在本地执行挡板规则时，即使是同一个挡板规则也都会重复生成一个字节码文件，然后将该字节码文件加载在java虚拟机上执行，从而如果对同一个测试请求进行多次mock操作(比较规则和请求的参数以得到响应值)后，使用GroovyShell造成的文件就会越来越多，影响客户端设备的整体性能。

基于此，在本实施例中，而通过客户端设备在每一次拦截到测试工作人员针对待测试的功能服务发起的测试请求之后，均将该测试请求与预先存储在本地缓存和/或者内部存储空间当中且已经关联有对应测试结果的原测试请求进行比对，以检测该测试请求是否与该原测试请求相同；客户端设备在检测到新拦截的测试请求与原测试请求相同时，直接将预先存储在本地缓存和/或者内部存储空间当中，与该原测试请求相关联的测试结果作为当前新拦截的测试请求所对应的测试结果，并将该测试结果通过当前待测试的服务请求面向测试工作人员的图形用户接口进行输出。如此，避免了GroovyShell在本地重复产生过多的文件，有效地保证了客户端设备的整体性能，进一步提升了针对该客户端设备上安装的待测试的功能服务，进行测试操作的测试效率。

进一步地，本发明还提供一种功能服务的测试方法，该功能服务的测试方法应用在如上各个实施例中所描述的挡板服务端，该功能服务的测试方法包括以下步骤：

步骤S60，根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

需要说明的是，在本实施例中，规则配置数据即为测试工作人员基于针对待测试的功能服务的测试需要，而输入挡板服务端设备用于配置挡板规则的数据，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，测试工作人员所输入的用于配置挡板规则的数据当然可以是不同的，本发明功能服务的测试方法并不针对该规则配置数据的具体内容进行限定。

挡板服务端设备通过前端屏幕面向测试工作人员输出的图形用户接口，接收该测试工作人员针对待测试的功能服务输入的用于配置挡板规则的规则配置数据，然后立即按照该规则配置数据在本地配置生成新的挡板规则或者针对预先已经配置的挡板规则进行更新。

具体地，例如，挡板服务端设备前端屏幕面向测试工作人员输出的图形用户接口具体可以为如附图7所示的图形用户界面，请参照如图4的应用流程，多个挡板服务端设备(图示mock-admin)中的任一个挡板服务端设备在接收到基于nginx(Nginx(engine x)是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务)技术进行分流后接入的登入请求，从而基于该登入请求允许对应的测试工作人员登录之后，即通过前端屏幕向该测试工作人员输出如附图7所示的图形用户界面，从而该挡板服务端基于该图形用户界面接收测试工作人员输入的规则配置数据配置：1)、挡板(mock)类型：基于http的网络连接还是基于rmb通信连接，2)、mock路径：需要进行mock操作的待测试的功能服务的测试请求发起路径，如拦截接口地址—http://127.0.0.1:8080/mock/test，以及，3)、mock规则：条件以及返回值，即，当测试请求中的请求参数a＝1,则返回“true”,否则，返回“false”。

步骤S70，获取所述客户端传递的客户端信息；

挡板服务端设备在配置生成待测试的功能服务的挡板规则之前或者同时又或者之后，通过与安装有该功能服务的客户端设备之间建立的通信连接，获取该客户端设备所传递的客户端信息。

需要说明的是，在本实施例中，客户端信息为用于挡板服务端按照该客户端信息主动推送挡板规则的信息，例如，该客户端信息具体可以为ip(Internet Protocol，网际互连协议)地址信息和通信端口信息，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，该客户端信息当然也可以是其它本实施例所列举的上述ip地址信息和通信端口信息之外，但同样能够起到上述作用的其它信息，本发明功能服务的测试方法并不针对该客户端信息的具体种类进行限定。

具体地，例如，客户端设备在与挡板服务端设备建立http网络连接或者rmb通信连接之后，即开始在本地采集ip地址信息和通信端口信息，并将采集到的该ip地址信息和通信端口信息通过http网络连接或者rmb通信连接传递给该挡板服务端设备。

步骤S80，按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

挡板服务端设备在接收到客户端设备传递的客户端信息之后，将在本地配置生成的针对待测试的功能服务的挡板规则，按照该客户端信息推送至该客户端设备，从而由该客户端设备在本地直接拦截测试工作人员触发的针对该功能服务的测试请求，并在解析该测试请求得到请求参数之后，遍历该挡板规则以针对该请求参数进行比较，进而成针对该功能服务的测试请求的测试结果，并将该测试结果通过该服务请求面向测试工作人员的图形用户接口进行输出。

具体地，例如，请参照如图4所示的应用流程，挡板服务端设备(mock-admin)在基于测试工作人员输入的规则配置数据在本地配置生成挡板规则，并在与本地下载和安装待测试的功能服务的客户端设备(图示应用系统)建立http网络连接或者rmb通信连接之后，在已经配置生成的全部挡板规则当中，基于该客户端设备的ip地址信息和通信端口信息，查询属于该客户端设备上所安装的该功能服务的目标挡板规则，最后，主动推送该目标挡板规则至该客户端设备或者由该客户端设备自动拉取该目标挡板规则，从而供该客户端设备将该目标挡板规则存储在本地运行该功能服务的缓存(SDK)当中，用于拦截到针对该功能服务的测试请求时进行调用来生成测试结果。

进一步地，在一种可行的实施例中，上述步骤S80中，“按照所述客户端信息将所述挡板规则推送至所述客户端”的步骤，可以包括：

步骤S801，确定针对所述挡板规则进行更新处理后的新的挡板规则；

需要说明的是，在本实施例中，由于挡板服务端设备会基于测试人员新输入的规则配置数据对已经配置的挡板规则进行修改得到新的挡板规则、删除原挡板规则或者增加新的挡板规则。

挡板服务端设备在每一次向客户端设备推送挡板规则时，均预先在本地检测全部的挡板规则当中，是基于测试人员新输入的规则配置数据对已经配置的挡板规则进行修改得到新的挡板规则和增加配置的新的挡板规则。

具体地，例如，挡板服务端设备在每一次基于测试人员新输入的规则配置数据对已经配置的挡板规则进行修改得到新的挡板规则之后，或者，基于该新的规则配置数据在本地配置得到新的挡板规则之后，均在该新的挡板规则上增加一个特定标识，从而，该挡板服务端设备在每一次向客户端设备推送挡板规则时，即可通过该特定标识检测得到本地全部的挡板规则中，携带有该特定标识的新的挡板规则。

步骤S802，按照预设第二时间周期将所述新的挡板规则推送至所述客户端。

需要说明的是，在本实施例中，预设第二时间周期为挡板服务端设备将本地新的挡板规则推送至客户端设备，供该客户端设备针对预先拉取的挡板规则进行更新处理所依据的时间周期，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施例当中，挡板服务端设备当然可以采用不同大小的时间周期来针对本地新的挡板规则进行推送，本发明功能服务的测试方法并不针对该预设第二时间周期的具体大小进行限定。

挡板服务端设备在本地检测全部的挡板规则当中，基于测试人员新输入的规则配置数据对已经配置的挡板规则进行修改得到新的挡板规则，和增加配置的新的挡板规则之后，即通过与安装有该功能服务的客户端设备之间建立的通信连接，将该新的挡板规则推送至该客户端设备，从而由该客户端设备在本地直接拦截测试工作人员触发的针对该功能服务的测试请求，并在解析该测试请求得到请求参数之后，遍历该挡板规则以针对该请求参数进行比较，进而成针对该功能服务的测试请求的测试结果，并将该测试结果通过该服务请求面向测试工作人员的图形用户接口进行输出。

在本实施例中，通过挡板服务端设备通过前端屏幕面向测试工作人员输出的图形用户接口，接收该测试工作人员针对待测试的功能服务输入的用于配置挡板规则的规则配置数据，然后立即按照该规则配置数据在本地配置生成新的挡板规则或者针对预先已经配置的挡板规则进行更新；挡板服务端设备在配置生成待测试的功能服务的挡板规则之前或者同时又或者之后，通过与安装有该功能服务的客户端设备之间建立的通信连接，获取该客户端设备所传递的客户端信息；挡板服务端设备在接收到客户端设备传递的客户端信息之后，将在本地配置生成的针对待测试的功能服务的挡板规则，按照该客户端信息推送至该客户端设备，从而由该客户端设备在本地直接拦截测试工作人员触发的针对该功能服务的测试请求，并在解析该测试请求得到请求参数之后，遍历该挡板规则以针对该请求参数进行比较，进而成针对该功能服务的测试请求的测试结果，并将该测试结果通过该服务请求面向测试工作人员的图形用户接口进行输出。

本发明相比于基于传统挡板测试技术—mock server进行功能服务测试的方式，针对待测试的功能服务的测试请求无需再外发至挡板服务端，从而即使在该功能服务依赖的其他服务不提供对外服务或者没有完全开发完成时，也能够直接在客户端本地完成针对待测试功能服务的整个测试过程，进而改善了传统挡板测试无法模拟挡板完成功能服务测试的缺陷，提升了针对功能服务进行测试的测试效率。

进一步地，本发明还提供一种功能服务的测试系统，该功能服务的测试系统包括客户端。请参照图8，图8为本发明功能服务的测试系统一实施例的功能模块示意图。如图8所示，所述客户端包括：

第一获取模块10，用于获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

拦截模块20，用于拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

测试模块30，用于在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果；

本发明功能服务的测试系统还包括挡板服务端，如图8所示，所述挡板服务端包括：

规则配置模块40，用于根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

第二获取模块50，用于获取所述客户端传递的客户端信息；

规则推送模块60，用于按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

进一步地，规则推送模块60，包括：

确定单元，用于确定针对所述挡板规则进行更新处理后的新的挡板规则；

推送单元，用于按照预设第二时间周期将所述新的挡板规则推送至所述客户端。

进一步地，第一获取模块10，还用于在检测到所述功能服务启动时，从所述挡板服务端中获取针对所述功能服务配置的所述挡板规则，并将所述挡板规则存储在本地缓存当中。

进一步地，测试模块30，包括：

规则遍历单元，用于在所述本地缓存中遍历所述挡板规则；

结果生成单元，用于在遍历所述挡板规则的过程中，将所述请求参数与所述挡板规则进行比较以动态生成测试结果。

进一步地，本发明功能服务的测试系统，还包括：

存储模块，用于将所述挡板规则贮存在本地内存当中，并按照预设第一时间周期针对所述挡板规则进行更新处理；

测试模块30，还用于在所述本地内存中遍历所述挡板规则，并在遍历所述挡板规则的过程中，将所述请求参数与所述挡板规则进行比较以动态生成测试结果。

进一步地，本发明功能服务的测试系统，还包括：

检测单元，用于检测所述测试请求是否与原测试请求相同；

结果反馈单元，用于在本地索引所述原测试请求对应的原测试结果，并将所述原测试结果作为所述测试请求对应的测试结果进行反馈。

进一步地，本发明功能服务的测试系统，还包括：

信息采集模块，用于采集客户端信息，并将所述客户端信息传递至所述挡板服务端，以供所述挡板服务端按照所述客户端信息推送所述挡板规则。

其中，上述功能服务的测试系统中各个模块的功能实现与上述功能服务的测试方法实施例中各步骤相对应，其功能和实现过程在此处不再一一赘述。

本发明还提供一种计算机存储介质，该计算机存储介质上存储有功能服务的测试程序，所述功能服务的测试程序被处理器执行时实现如以上任一项实施例所述的功能服务的测试方法的步骤。

本发明计算机存储介质的具体实施例与上述功能服务的测试方法各实施例基本相同，在此不作赘述。

本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如以上任一项实施例所述的功能服务的测试方法的步骤。

本发明计算机存储介质的具体实施例与上述功能服务的测试方法各实施例基本相同，在此不作赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种功能服务的测试方法，其特征在于，所述功能服务的测试方法应用于客户端，所述功能服务的测试方法包括：

获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果。

2.如权利要求1所述的功能服务的测试方法，其特征在于，所述获取所述功能服务的挡板规则的步骤，包括：

在检测到所述功能服务启动时，从所述挡板服务端中获取针对所述功能服务配置的所述挡板规则，并将所述挡板规则存储在本地缓存当中。

3.如权利要求2所述的功能服务的测试方法，其特征在于，所述在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果的步骤，包括：

在所述本地缓存中遍历所述挡板规则；

在遍历所述挡板规则的过程中，将所述请求参数与所述挡板规则进行比较以动态生成测试结果。

4.如权利要求1所述的功能服务的测试方法，其特征在于，所述功能服务的测试方法还包括：

将所述挡板规则贮存在本地内存当中，并按照预设第一时间周期针对所述挡板规则进行更新处理；

所述在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果的步骤，还包括：

在所述本地内存中遍历所述挡板规则，并在遍历所述挡板规则的过程中，将所述请求参数与所述挡板规则进行比较以动态生成测试结果。

5.如权利要求1所述的功能服务的测试方法，其特征在于，在所述拦截针对所述功能服务发起的测试请求的步骤之后，所述方法还包括：

检测所述测试请求是否与原测试请求相同；

若是，则在本地索引所述原测试请求对应的原测试结果，并将所述原测试结果作为所述测试请求对应的测试结果进行反馈。

6.如权利要求1-5任一项所述的功能服务的测试方法，其特征在于，在所述获取所述功能服务的挡板规则的步骤之前，所述方法还包括：

采集客户端信息，并将所述客户端信息传递至所述挡板服务端，以供所述挡板服务端按照所述客户端信息推送所述挡板规则。

7.一种功能服务的测试方法，其特征在于，所述功能服务的测试方法应用于挡板服务端，所述挡板服务端与如权利要求1至6任一项所述的客户端相连接，所述功能服务的测试方法包括：

根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

获取所述客户端传递的客户端信息；

按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

8.如权利要求7所述的功能服务的测试方法，其特征在于，所述按照所述客户端信息将所述挡板规则推送至所述客户端的步骤，包括：

确定针对所述挡板规则进行更新处理后的新的挡板规则；

按照预设第二时间周期将所述新的挡板规则推送至所述客户端。

9.一种功能服务的测试系统，其特征在于，所述功能服务的测试系统包括客户端，所述客户端包括：

第一获取模块，用于获取所述功能服务的挡板规则，其中，所述挡板规则在与所述客户端连接的挡板服务端中配置得到；

拦截模块，用于拦截针对所述功能服务发起的测试请求，并解析所述测试请求得到请求参数；

测试模块，用于在本地按照所述挡板规则针对所述请求参数进行比较以生成测试结果；

所述功能服务的测试系统还包括挡板服务端，所述挡板服务端包括：

规则配置模块，用于根据预设的规则配置数据配置生成针对所述功能服务的挡板规则，其中，所述规则配置数据基于图形用户接口接收得到；

第二获取模块，用于获取所述客户端传递的客户端信息；

规则推送模块，用于按照所述客户端信息将所述挡板规则推送至所述客户端，以供所述客户端在本地按照所述挡板规则生成测试请求对应的测试结果，其中，所述测试请求是针对所述功能服务发起的。

10.一种终端设备，其特征在于，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的功能服务的测试程序，所述功能服务的测试程序被所述处理器执行时实现如权利要求1至6和权利要求7至8中任一项所述的功能服务的测试方法的步骤。

Images