CN107133160A - 测试系统 - Google Patents

Abstract

本发明提供了一种服务器，当接收到来自客户端的请求后，规则分派引擎在对应于不同协议的多个规则搜索引擎中确定与请求的协议相匹配的规则搜索引擎。规则搜索引擎根据相应的预定方式搜索规则列表。规则匹配引擎在规则列表中确定与所述请求相对应的规则。模板填充引擎使用请求中的相应参数填充与所确定的规则相对应的响应数据模板，以得到要发送给客户端的响应数据。本发明还提供了一种客户端，包括代理模块和交互模块。代理模块对应用程序发出的请求进行拦截和协议适配。交互模块将不同协议格式的请求转换成统一的与服务器约定的约定数据格式并发送到服务器，并将来自服务器的约定数据格式的响应数据转换成与相应请求相同的数据格式。

Description

测试系统

技术领域

本发明总体上涉及软件技术领域，更具体地涉及一种测试系统。

背景技术

随着面向服务架构(Service-Oriented Architecture，SOA)的普及，以及业务的不断增长，系统划分越来越多，系统之间的服务依赖也越来越多，使得由于服务不可用或数据问题造成的系统测试难度越来越大。所以，迫切需要一种构建闭环、可测试的沙箱环境的方法及系统。

现有技术方案大致通过以下两种技术方案来解决上述问题：1、采用编写代码来模拟外部系统服务；2、读取提前配置好的数据文件来模拟外部系统服务。对于采用编写代码来模拟外部系统服务的方案，需要开发人员投入额外的时间来编写模拟代码，成本较高。对于读取提前配置好的数据文件来模拟外部系统服务的方案，配置的方式不够灵活，维护成本较高。而且，上述两种方法的复用率低，例如有A、B两个系统同时依赖服务S时，A、B两个系统都需要编写模拟S服务的代码或配置S服务的响应数据配置文件。而且，上述两种方法的响应参数固定，不能随着请求参数变化。

发明内容

本发明的一个方面提供了一种服务器，包括规则分派引擎、规则搜索引擎、规则匹配引擎和目标填充引擎，其中：规则分派引擎用于，当服务器接收到来自客户端的请求后，在对应于不同协议的多个规则搜索引擎中确定与请求的协议相匹配的规则搜索引擎；规则搜索引擎用于根据相应的预定方式来搜索包括一个或多个规则的规则列表；规则匹配引擎用于在所述规则列表中确定与所述请求相对应的规则；以 及模板填充引擎用于使用请求中的相应参数来填充与所确定的规则相对应的响应数据模板，以得到要发送给客户端的响应数据。

本发明还提供了一种客户端，包括代理模块和交互模块，其中：代理模块用于对应用程序发出的请求进行拦截和协议适配；以及交互模块用于将不同协议格式的请求转换成统一的与服务器约定的约定数据格式并发送到服务器，以及将来自服务器的约定数据格式的响应数据转换成与相应请求相同的数据格式。

根据本发明的测试系统，能够在SOA服务架构模式下搭建一个闭环的沙箱环境，降低系统开发环境、测试环境对外部服务的强依赖。该测试方法和测试系统简洁、灵活，使用人员只需用关注模板和规则的配置就能达到闭环效果。

附图说明

为了更完整地理解本发明及其优势，现在将参考结合附图的以下描述，其中：

图 1示意性示出了根据本发明实施例的测试系统的结构框图；

图 2示意性示出了根据本发明实施例的核心模块的结构框图；以及

图 3示意性示出了服务器处理客户端的请求的方法的流程图。

具体实施方式

根据结合附图对本发明示例性实施例的以下详细描述，本发明的其它方面、优势和突出特征对于本领域技术人员将变得显而易见。

在本发明中，术语“包括”和“含有”及其派生词意为包括而非限制；术语“或”是包含性的，意为和/或。

在本说明书中，下述用于描述本发明原理的各种实施例只是说明，不应该以任何方式解释为限制发明的范围。参照附图的下述描述用于帮助全面理解由权利要求及其等同物限定的本发明的示例性实施例。下述描述包括多种具体细节来帮助理解，但这些细节应认为仅仅是示 例性的。因此，本领域普通技术人员应认识到，在不背离本发明的范围和精神的情况下，可以对本文中描述的实施例进行多种改变和修改。此外，为了清楚和简洁起见，省略了公知功能和结构的描述。此外，贯穿附图，相同参考数字用于相似功能和操作。

图 1示意性示出了根据本发明实施例的测试系统1的结构框图。如图 1所示，测试系统1包括客户端100和服务器200。

根据本发明的实施例，客户端100包括代理模块110和交互模块120。代理模块110用于对应用程序发出的请求进行拦截和协议适配。经过协议适配的请求可能具有不同协议格式(例如http、mq、webservice、saf协议等)。交互模块120用于将不同协议格式的请求转换成统一的与服务器200约定的约定数据格式并发送到服务器200，以及将来自服务器200的约定数据格式的响应数据转换成与相应请求相同的数据格式(例如http、mq、webservice、saf协议等)。

根据本发明的实施例，可以如下设置约定数据格式：

请求数据格式为：{protocol：<http|webservice|mq|saf>，app：<application code>，ip：<client ip>，port：<client proxy port>，data：<json format>}，其中protocol字段表示请求的协议格式是http、webservice、mq、或saf协议，app字段表示发出请求的应用程序名称，用于区分不同应用程序，ip字段表示本地客户端100的ip地址，port字段表示本地客户端100的端口，data字段用于承载请求参数。

响应数据格式为：{success：<true|false>，

protocol：<http|webservice|mq|saf>，data：<string>，conf：<configuration>}，其中success字段表示根据请求参数来匹配对应模板是否匹配成功，protocol字段表示相应的请求的协议格式，data字段用于承载被模板填充引擎224所填充的响应参数。

如图 1所示，根据本发明的实施例，服务器200包括管理模块210、核心模块220、插件模块230、和存储模块240。服务器200可以处理客户端100的请求。

管理模块210用于后台管理用户界面的展示和权限管理等操作。

核心模块220包括规则分派引擎221、规则搜索引擎222、规则匹配引擎223、和模板填充引擎224。

插件模块230用于自定义参数生成方式，用户可根据实际需求，为模板填充引擎224要填充的参数定义用户自己的参数生成方式。比如，如果用户需要模拟外部系统生订单号，那么可以自定义订单号生成插件模块，在模板填充引擎224填充响应模板时，可以通过表达式“$plugin(‘OrderId’).createOrderId()”来调用自定义插件中生成订单号的方法。

存储模块240用于存储各种模板、应用程序、和/或用户相关信息等。

图 2示出了根据本发明实施例的核心模块220的结构框图。图 3示出了服务器200处理客户端100的请求的方法的流程图。

如图 2和图 3所示，当服务器200接收到客户端100的请求后，规则分派引擎221在不同协议的多个规则搜索引擎222中确定与请求的协议(即，请求中的protocol字段)相匹配的规则搜索引擎222(步骤S301)。然后，匹配的规则搜索引擎222根据相应的预定方式来搜索一个或多个规则的规则列表 (步骤S302)。

根据本发明的实施例，对于http协议，规则搜索引擎222可以具有两种搜索方式，即普通方式和RESTful方式。在普通方式中，根据请求的URL来搜索规则列表。在RESTful方式中，根据请求的URL(URL采用正则匹配)和Method参数来搜索规则列表。对于saf协议，搜索引擎根据请求的Interface、Method、Group、和Version全部参数来搜索对应的规则列表。对于webservice协议，搜索引擎根据请求的WSDL地址和service名称来搜索对应的规则列表。对于mq协议，根据消息的三种形式：Destination(JMS公共模式)、Queue(点对点模式)、Topic(发布/订阅模式)中的任意一种参数来搜索对应的规则列表。

当搜索到包括一个或多个规则的规则列表后，再由规则匹配引擎223将列表中的各个规则与相应请求参数进行匹配(步骤S303)，以 确定与所述请求相对应的规则。根据本发明的实施例，所述规则是根据预定表达式或语法来判断参数是否符合期望，比如有规则${name}＝＝’Lily’&&${age}＞18，表示期望参数中name字段为Lily并且age字段大于18岁，如果两个条件同时满足则表示符合期望匹配成功。

例如，如果采用开源技术Velocity引擎的语法来定义规则，例如：规则：${name}＝＝’Lily’&&${age}＞18，则如果请求参数中的name等于Lily，并且age大于18则是匹配成功。

在获得与请求参数匹配的规则之后，由模板填充引擎224根据与该规则对应的响应数据模板的格式，使用相应请求参数来填充响应数据模板，得到响应数据(步骤S304)。例如，如果使用开源技术Velocity引擎，则响应数据模板也是Velocity模板，例如：

响应数据模板：{sku：${sku}，goodsName：衣服，brand：某某牌}

请求中的相应参数为：{sku：123}

填充后的结果为：{sku：123，goodsName：衣服，brand：某某牌}

请求和响应数据可能具有多种对应关系例如一对一、一对多、多对多等对应关系。通过请求中的参数和响应数据中某些字段的关联，来体现这种对应关系。在上面的例子中，sku就是关联字段，请求和响应中的sku字段应当是一致的，通过填充来实现这一点。使用请求中的参数填充响应数据模板之后，得到响应数据。

另外，根据本发明的实施例，核心模块220还可以包括任务触发引擎225，如图 2所示。任务触发引擎225判断响应数据模板是否包括反向调用任务，如果是，则执行反向调用任务，具体流程如图所示。在步骤S305，判断响应数据模板是否包括反向调用任务。如果不包括反向调用任务，则方法在步骤S306结束。如果包括反向调用任务，则在步骤S307，获取事先配置好的多个任务参数模板，所述多个任务参数模板之间是有序的。在步骤S308，利用请求中的相应参数填充所述多个任务参数模板，得到相应的多个调用请求数据，作为一个调用链。在步骤S309，将调用请求数据存储在存储模块240(例如，内存 或集中式缓存)中。可选地，可以为调用请求数据设置过期时间。设置过期时间的作用是达到延迟的效果，主要有两个意图：a)用来模拟某个服务执行耗时b)防止前个响应数据还未到达客户端就发起了反向调用。在步骤S310，当存储的调用请求数据过期后将触发调用事件，向客户端100/目标服务系统(例如，其他系统)发起调用请求。在步骤S311，判断调用链中是否执行完毕。如果有，则在步骤S312，用针对该调用请求的响应内容来填充调用链中下一个调用请求数据，并返回执行步骤S310，否则，将最后得到的响应数据发送到客户端，该方法结束。反向调用用于回调客户端100或目标服务系统。比如在异步场景中，假设有A、B系统，A系统调用B系统某服务后，B系统返回一个临时结果，当B系统处理完成之后通过MQ或调用A系统某服务告知处理结果，客户端100在此充当A系统角色，而服务器200在此就充当了B系统角色。

本发明提供的测试系统的多个实施例，能够模拟应用程序依赖的外部系统的相关服务，并且除了外部系统服务的模拟之外，进一步能够实现调用流程上的模拟。因为能够模拟外部服务和调用流程模拟，所以可以建立一个闭环的、可独立运行的沙箱环境。对于开发人员而言，这有利于减少对外部系统服务的依赖，节省开发时间；对系统测试人员而言，这有利于建立稳定的测试环境，也可以通过配置不同模板来模拟不同的业务场景。对于同一个系统，不同的环境(开发环境、测试环境)可以设定不同的应用程序名称(请求数据的app字段)，比如可设置app字段值为：X系统-develop、X系统-test实现隔离，虽然他们对外发布服务都一样，对服务端200本质上来说把他们看做是两个系统，所以开发和测试对相同接口的模板配置互不影响。

根据本发明各实施例的各设备和/或其中的模块、引擎等可以通过有计算能力的电子设备执行包含计算机指令的软件来实现。所述有计算能力的电子设备可以是通用处理器、数字信号处理器、专用处理器、可重新配置处理器等，但不限于此。执行这样的指令使得电子设备被配置为执行根据本发明的上述各项操作。上述各设备和/或部件可以在 一个电子设备中实现，也可以在不同电子设备中实现。这些软件可以存储在计算机可读存储介质中。计算机可读存储介质存储一个或多个程序(软件模块)，所述一个或多个程序包括指令，当电子设备中的一个或多个处理器执行所述指令时，所述指令使得电子设备执行本发明的方法。

这些软件可以存储为易失性存储器或非易失性存储装置的形式(比如类似ROM等存储设备)，不论是可擦除的还是可重写的，或者存储为存储器的形式(例如RAM、存储器芯片、设备或集成电路)，或者被存储在光可读介质或磁可读介质上(比如，CD、DVD、磁盘或磁带等等)。应该意识到，存储设备和存储介质是适于存储一个或多个程序的机器可读存储装置的实施例，所述一个程序或多个程序包括指令，当所述指令被执行时，实现本发明的实施例。实施例提供程序和存储这种程序的机器可读存储装置，所述程序包括用于实现本发明的任何一项权利要求所述的装置或方法的代码。此外，可以经由任何介质(比如，经由有线连接或无线连接携带的通信信号)来电传递这些程序，多个实施例适当地包括这些程序。

根据本发明各实施例的各设备和/或其中的模块、引擎等还可以使用例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)或可以以用于对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式的适当组合来实现。在以这些方式实现时，所使用的的软件、硬件和/或固件被编程或设计为执行根据本发明的相应上述方法、步骤和/或功能。本领域技术人员可以根据实际需要来适当地将这些系统和模块中的一个或多个，或其中的一部分或多个部分使用不同的上述实现方式来实现。这些实现方式均落入本发明的保护范围。

尽管已经参照本发明的特定示例性实施例示出并描述了本发明，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本发明的精神和范围的情况下，可以对本发明进行形式和细节上 的多种改变。因此，本发明的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (12)

1.一种服务器，包括规则分派引擎、规则搜索引擎、规则匹配引擎和目标填充引擎，其中：

规则分派引擎用于，当服务器接收到来自客户端的请求后，在对应于不同协议的多个规则搜索引擎中确定与请求的协议相匹配的规则搜索引擎；

规则搜索引擎用于根据相应的预定方式来搜索包括一个或多个规则的规则列表；

规则匹配引擎用于在所述规则列表中确定与所述请求相对应的规则；以及

模板填充引擎用于使用请求中的相应参数来填充与所确定的规则相对应的响应数据模板，以得到要发送给客户端的响应数据。

2.根据权利要求1所述的服务器，其中：

来自客户端的请求具有如下格式：

{protocol：<http|webservice|mq|saf>，app：<application code>，ip：<client ip>，port：<client proxy port>，data：<json format>}，其中：protocol字段表示请求的协议格式是http、webservice、mq、或saf协议；app字段表示发出请求的应用程序名称，用于区分不同应用程序；ip字段表示客户端的ip地址；port字段表示客户端的端口；data字段用于承载请求参数；并且/或者

要发送给客户端的响应数据具有如下格式：

{success：<true|false>，

protocol：<http|webservice|mq|saf>，

data：<string>，conf：<configuration>}，其中：success字段表示根据请求参数来匹配对应模板是否匹配成功，protocol字段表示相应的请求的协议格式，data字段用于承载模板填充引擎所填充的响应参数。

3.根据权利要求2所述的服务器，其中：

确定与请求的协议相匹配的规则搜索引擎包括：确定与请求的protocol字段相匹配的规则搜索引擎。

4.根据权利要求1所述的服务器，其中规则搜索引擎具有以下任意一种或多种搜索方式：

对于http协议，规则搜索引擎具有两种搜索方式，即普通方式和RESTful方式，其中：在普通方式中，根据请求的URL来搜索规则列表；在RESTful方式中，根据请求的URL和Method参数来搜索规则列表；

对于saf协议，规则搜索引擎根据请求的Interface、Method、Group、和Version参数来搜索对应的规则列表；

对于webservice协议，搜索引擎根据请求的WSDL地址和service名称来搜索对应的规则列表；或者

对于mq协议，根据请求的以下任意一种参数来搜索对应的规则列表：对于JMS公共模式为Destination参数、对于点对点模式为Queue参数、对于发布/订阅模式为Topic参数。

5.根据权利要求1所述的服务器，其中：

规则匹配引擎将规则列表中的各个规则与请求中的相应参数进行匹配，以确定与所述请求相对应的规则。

6.根据权利要求1所述的服务器，还包括任务触发引擎，用于判断响应数据模板是否包括反向调用任务，如果是，则执行反向调用任务。

7.根据权利要求6所述的服务器，其中：

在执行反向调用任务之前，服务器向客户端返回临时结果；以及

执行反向调用任务包括：

获取事先配置好的多个任务参数模板，所述多个任务参数模板之间是有序的；

利用请求中的相应参数填充所述多个任务参数模板，得到相应的多个调用请求数据，作为一个调用链；并且

依次使用调用链中的调用请求数据触发调用事件，向客户端和/或目标服务系统发起调用请求，并用返回的响应数据填充下一个调用请求数据，直到调用链执行完毕，将最后得到的响应数据发送到客户端。

8.根据权利要求1所述的服务器，还包括以下中的一个或多个：

管理模块，用于后台管理用户界面的展示和权限管理等操作；

插件模块，用于允许用户自定义用于填充响应数据模板的参数的生成方式；或者

存储模块，用于存储各种模板、应用程序、和/或用户相关信息。

9.根据权利要求2所述的服务器，其中，为不同的应用程序和/或不同的系统环境设置不同的app字段值。

10.一种客户端，包括代理模块和交互模块，其中：

代理模块用于对应用程序发出的请求进行拦截和协议适配；以及

交互模块用于将不同协议格式的请求转换成统一的与服务器约定的约定数据格式并发送到服务器，以及将来自服务器的约定数据格式的响应数据转换成与相应请求相同的数据格式。

11.根据权利要求10所述的客户端，其中：

不同协议格式包括以下的至少两种：http协议、mq协议、webservice协议、或saf协议。

12.根据权利要求10所述的客户端，其中：

请求数据的约定数据格式为：

{protocol：<http|webservice|mq|saf>，app：<application code>，ip：<client ip>，port：<client proxy port>，data：<json format>}，其中：protocol字段表示请求的协议格式是http、webservice、mq、或saf协议；app字段表示发出请求的应用程序名称，用于区分不同应用程序；ip字段表示客户端的ip地址；port字段表示客户端的端口；data字段用于承载请求参数；并且/或者

响应数据的约定数据格式为：

{success：<true|false>，

protocol：<http|webservice|mq|saf>，

data：<string>，conf：<configuration>}，其中：success字段表示根据请求参数来匹配对应模板是否匹配成功，protocol字段表示相应的请求的协议格式，data字段用于承载模板填充引擎所填充的响应参数。