CN112732572A - 服务的测试方法、装置及系统、存储介质、电子装置 - Google Patents

Abstract

本申请公开了一种服务的测试方法、装置及系统、存储介质、电子装置。其中，该方法包括：获取业务请求；在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试；响应于业务请求，向终端返回测试结果。本申请解决了相关技术中mock服务对前端代码的入侵性较高的技术问题。

Description

服务的测试方法、装置及系统、存储介质、电子装置

技术领域

本申请涉及测试领域，具体而言，涉及一种服务的测试方法、装置及系统、存储介质、电子装置。

背景技术

mock服务就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便进行测试的测试方法，这个虚拟的对象就是mock对象，mock对象就是真实对象在调试期间的代替品，可使用一个接口来描述这个虚拟的对象，在产品代码中实现这个接口，在测试代码中实现这个接口，在被测试代码中只是通过接口来引用对象，所以它不知道这个引用的对象是真实对象，还是mock对象，从而可以完成测试。

目前，mock服务主要分代理型mock服务和前端入侵式mock两大类型。前者通过启用一个mock后端服务，配置好接口返回并且在前端项目代理到mock服务。后者通过拦截ajax或fetch的响应进行修改返回，或者直接修改api接口为json文件返回json文件的数据。

目前的mock服务存在以下问题：高入侵，需要对前端业务代码进行修改适配，而且发布生产需要修改正常代码，开发成本高且易出错。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种服务的测试方法、装置及系统、存储介质、电子装置，以至少解决相关技术中mock服务对前端代码的入侵性较高的技术问题。

根据本申请实施例的一个方面，提供了一种服务的测试系统，包括：终端，终端上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试；数据库，数据库用于保存与目标服务关联的测试数据；测试服务器，测试服务器用于设置目标服务的测试配置，在根据测试配置确定获取的业务请求为测试请求的情况下，向终端返回测试结果。

根据本申请实施例的另一方面，还提供了一种服务的测试方法，包括：获取业务请求；在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试；响应于业务请求，向终端返回测试结果。

根据本申请实施例的另一方面，还提供了一种服务的测试装置，包括：获取单元，用于获取业务请求；处理单元，用于在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试；响应单元，用于响应于业务请求，向终端返回测试结果。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

在本申请实施例中，获取业务请求；在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作；响应于业务请求，向终端返回测试结果，由于对业务的测试配置可在服务器端完成，而不用修改前端的业务逻辑，可以解决相关技术中mock服务对前端代码的入侵性较高的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的服务的测试系统的示意图；

图2是根据本申请实施例的一种可选的服务的测试方法的流程图；

图3是根据本申请实施例的一种可选的服务的测试系统的示意图；

图4是根据本申请实施例的一种可选的服务的配置界面的示意图；

图5是根据本申请实施例的一种可选的服务的配置界面的示意图；

图6是根据本申请实施例的一种可选的服务的配置界面的示意图；

图7是根据本申请实施例的一种可选的服务的配置界面的示意图；

图8是根据本申请实施例的一种可选的服务的配置界面的示意图；

图9是根据本申请实施例的一种可选的服务的配置界面的示意图；

图10是根据本申请实施例的一种可选的服务的配置界面的示意图；

图11是根据本申请实施例的一种可选的服务的配置界面的示意图；

图12是根据本申请实施例的一种可选的服务的配置界面的示意图；

图13是根据本申请实施例的一种可选的服务的配置界面的示意图；

图14是根据本申请实施例的一种可选的服务的配置界面的示意图；

图15是根据本申请实施例的一种可选的服务的测试方案的示意图；

图16是根据本申请实施例的一种可选的服务的测试装置的示意图；

以及

图17是根据本申请实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

swagger：是一个规范和完整的框架，用于生成、描述、调用和可视化RESTful风格的Web服务。

JSON：全称为JavaScript Object Notation，即JS对象简谱，是一种轻量级的数据交换格式。它基于ECMAScript(欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。

JS：全称为javascript，是一种由Netscape的LiveScript发展而来的脚本语言，主要目的是为了解决服务器终端语言遗留的速度问题。

http：全称为HyperText Transfer Protocol，即超文本传输协议，是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使开发和部署非常地直截了当。

Ajax：全称为“Asynchronous Javascript And XML(异步JavaScript和XML)，是指一种创建交互式、快速动态网页应用的网页开发技术，无需重新加载整个网页的情况下，能够更新部分网页的技术。

Fetch被称为下一代Ajax技术，采用Promise方式来处理数据。是一种简洁明了的API，比XML Http Request更加简单易用。

API，全称为Application Programming Interface，即应用程序接口，是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

根据本申请实施例的一方面，提供了一种服务的测试方法的方法实施例，即可插拔式的前端客户端mock服务的实现方案。

可选地，在本实施例中，上述服务的测试方法可以应用于如图1所示的由终端101和测试服务器103所构成的服务的测试系统中。如图1所示，终端101上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试，测试服务器103通过网络与终端101进行连接，测试服务器103用于设置目标服务的测试配置，在根据测试配置确定获取的业务请求为测试请求的情况下，向终端返回测试结果，可在服务器上或独立于服务器设置数据库105，用于为测试服务器103提供数据存储服务，如保存与目标服务关联的测试数据，上述网络包括但不限于：广域网、城域网或局域网，终端101并不限定于PC、手机、平板电脑、服务器等。

可选地，上述系统还可包括：节点服务器，节点服务器用于将接收到的业务请求转发给测试服务器；引擎服务器，引擎服务器用于将业务请求的来源地址与测试配置中的业务地址进行比较，并将业务请求的业务类型与测试配置中的业务类型进行比较；在业务请求的来源地址与测试配置中的业务地址匹配、且业务请求的业务类型与测试配置中的业务类型匹配的情况下，确定业务请求为测试请求。

本申请实施例的服务的测试方法可以由测试服务器103来执行，也可以是由测试服务器103和终端101共同执行。图2是根据本申请实施例的一种可选的服务的测试方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，测试服务器获取业务请求。

步骤S204，在根据测试配置确定业务请求为测试请求的情况下，测试服务器根据业务请求在数据库中执行对应的操作，终端上有待测试的目标服务，终端用于通过向目标接口发送测试请求来对目标服务进行测试。

对于要测试的业务，可以预先在测试服务器上配置好，对于收到的任意业务请求，可以通过与配置进行对比来确定是否为测试请求，若是则使用mock服务来进行处理。

对于需要测试的业务，具体需要测试的功能(如登录功能、交易功能等)，可使用测试用例实现功能测试，测试用例是为发现软件中存在的问题而编写的一组包含测试输入、执行条件以及预期结果的文档，用来核实软件产品是否满足要求，而以上业务请求即测试用例在执行过程中产生的。

对于测试用例产生的每个业务请求，测试用例均设有对应的预期结果，以登录功能的测试为例，要求输入11位手机号登录，当仅输入10位数字时，预期结果为“帐号输入有误”，业务请求会携带这10位数字到本申请的测试服务器，若服务器反馈“帐号输入有误”则本项测试通过，若服务器反馈其他信息(如服务器反馈“密码有误”)则测试不通过。

步骤S206，响应于业务请求，测试服务器向终端返回测试结果。

通过上述步骤S202至步骤S206，获取业务请求；在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作；响应于业务请求，向终端返回测试结果，由于对业务的测试配置可在服务器端完成，而不用修改前端的业务逻辑，可以解决相关技术中mock服务对前端代码的入侵性较高的技术问题。

有了mock服务，前后端的开发工程师只需要定义好接口文档就可以开始并行处理各自的工作而互不影响，只需要在最后的联调阶段协调工作，实现了前后端开发的完全解耦，既能提高产出的效率，又能优化投入的成本；后端与后端之间如果有接口耦合，同样也能使用mock服务来解决；测试过程中如果遇到依赖的接口还没有准备好，同样可以借助mock服务来解决；在使用mock服务后，不会出现一个团队等待另一个团队的情况，这样便于开发自测阶段尽早开展，使得缺陷的发现时机提前，有利于提高整个产品的质量并保证产品进度的推进。下文结合具体实施例详述本申请的技术方案：

步骤1，对mock接口的地址和类型进行配置。

步骤11，展示第一配置界面，第一配置界面用于配置目标服务的测试请求的业务类型type和业务地址url。

步骤12，将在第一配置界面的第一输入框接收到的业务类型作为目标服务的测试请求的业务类型，将在第一配置界面的第二输入框接收到的业务地址作为目标服务的测试请求的业务地址。

步骤2，对mock接口的mock方式进行配置。

步骤21，在需要模拟目标接口对测试请求进行响应的情况下，展示第二配置界面，第二配置界面用于配置对目标服务的测试请求的处理方式(即mock方式)。

步骤22，在第二配置界面接收对测试请求的处理方式。

在第二配置界面接收对测试请求的处理方式包括以下至少之一：

其一是，在第二配置界面接收第一处理方式，第一处理方式表示使用预设数据交换格式的数据(如JSON数据)对测试请求进行响应；在第二配置界面的第三输入框接收输入的表示第一处理方式的源码；

其二是，在第二配置界面接收第二处理方式，第二处理方式表示使用预设模板(如mockJS模板，mockJS用于生成随机数据，拦截Ajax请求)的数据对测试请求进行响应；在第二配置界面的第四输入框接收输入的表示第二处理方式的源码；

其三是，在第二配置界面接收第三处理方式，其中，第三处理方式表示使用预设数据交换格式的文件(如JSON文件)对测试请求进行响应；在第二配置界面接收上传的预设数据交换格式的文件；

其四是，在第二配置界面接收第四处理方式，第四处理方式表示使用预设脚本(如JS脚本)对测试请求进行响应；在第二配置界面的第五输入框接收输入的脚本源码。

步骤3，截取业务请求。

可截取携带有预设字段的业务请求，预设字段(即请求报文的头文件header中的字段，如mock-data字段)用于表示该请求为用于测试的请求。可以预先设定多种目标类型type的请求，类型可携带于预设字段中，进而可查看请求报文的header有没有mock-data字段，以此判断是真实请求或者mock服务请求(即测试请求)。

步骤4，根据测试配置确定业务请求是否为测试请求。

步骤41，获取业务请求的来源地址和业务类型、测试配置中的业务地址和业务类型。

步骤42，在业务请求的来源地址与测试配置中的业务地址匹配、且业务请求的业务类型与测试配置中的业务类型匹配的情况下，确定业务请求是测试请求。

步骤43，在业务请求的来源地址与测试配置中的业务地址不匹配和/或业务请求的业务类型与测试配置中的业务类型不匹配的情况下，确定业务请求不是测试请求。

步骤5，在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作，如读取数据、修改数据、写入数据、删除数据等。

根据业务请求在数据库中执行对应的操作时，可根据业务请求在测试服务器的内存数据库中执行对应的数据操作，数据操作包括业务数据的写入、修改以及删除；在根据业务请求在数据库中执行对应的操作的同时或之后，在测试服务器本地的静态文件中进行业务数据的更新，如将新增的业务数据写入静态文件，在静态文件中删除业务数据或者修改业务数据，更新后的静态文件中的业务数据与内存数据库中的业务数据相同。

本方案的业务数据可同时缓存到内存数据库(或称内存上的缓存数据库)和本地静态文件当中，采用该方案具备如下优点：1)由于对内存上的数据进行操作的速度远高于在磁盘等存储设备上的数据操作速度，故可利用内存上的数据以最快的速度对用户的请求进行响应；2)因为业务数据在内存和本地的静态文件中是实时并且有效更新的，可以更加有效的模拟真实请求跟随数据变动，也能保证在断电时数据不丢失(内存上的数据会在断电时丢失，而本地静态文件中的数据则不会)；3)本方案不需额外安装其他后端语言的服务，对外部数据库没有依赖，同时对业务代码零入侵，大大降低了测试数据及测试代码发布到线上环境的概率。

步骤6，响应于业务请求，向终端返回测试结果，如返回所请求的数据。

本方案可通过http请求拦截，同时实现了对ajax及fech的拦截，采用一系列技术，通过界面配置的方式，简化了使用方式、降低了学习成本，又能解决前文中提到的高入侵和低可用性低等问题。作为一种可选的实施例，下文结合具体实施方式详述本申请的技术方案：

实现本方案的系统结构图如图3所示，从系统结构可以看到，整体mock服务包括以下几部分：

节点服务器node server：该部分为mock服务的载体，比如express服务器、egg服务器、webpack dev server服务器等，前端发送的请求会由node server转发给mock服务进行处理。

mock服务(即测试服务器)：该部分提供mock服务的配置管理页面，有两种方式获取系统所有的接口数据，第一种是可以直接通过swagger接口导入后端所有接口进行保存配置，第二种可以通过抓包拦截过滤所有请求，通过排重处理将接口列表保存到本地配置。

mock规则引擎(即引擎服务器)：该部分通过四种mock数据方式(JSON数据、JSON文件、mockJs模板、Js脚本)生成符合配置规则的mock数据，数据同时缓存到内存跟本地静态文件当中，同时因为数据是实时并且有效更新的，可以更加有效地模拟真实请求和数据变动。

配置管理实现流程如下：

步骤1，进入配置列表。

本方案有一个可以查看系统所有请求配置情况的列表，通过列表可以很清楚的查看每一个接口api当前的配置属性，点击列表每一行数据的url属性或者设置按钮进入该接口的配置页面，如图4所示。

步骤2，进行接口的mock设置。

在配置页面中，系统可以针对每一个接口进行单独配置，可以为该接口配置是否启用mock服务，同时可以配置对应的mock数据生成规则方式，以上配置在保存修改时可实时生效。系统支持的mock数据生成规则方式有JSON数据、mockJs、JS脚本、JSON文件等多种方式。

步骤2.1，在接口mock设置界面中，如果将‘是否mock’栏设置为‘不需要mock’，该接口则不启用mock服务，如图5所示；如果将‘是否mock’栏设置为‘需要mock’，该接口则启用mock服务，如图6所示。

步骤2.2，若将‘是否mock’栏设置为‘需要mock’并且将mock数据生成规则方式设置为‘JSON数据’，此时在mock数据输入框填写JSON格式的数据，设置‘mock方式’为‘JSON数据’的配置页面如图7所示，设置‘mock方式’为‘JSON数据’请求响应的界面如图8所示(返回的消息为“success”，即成功，返回的结果数据来源于JSON数据)，保存后设置生效。

步骤2.3，若将‘是否mock’栏设置为‘需要mock’并且将mock数据生成规则方式设置为“mockJS模板”，则在mockJS模板输入框填写mockJs模板保存生效，设置‘mock方式’为‘mockJs模板’的配置页面如图9所示，设置‘mock方式’为‘mockJs模板’请求响应的界面如图10所示(如返回“天津市”等)，保存后设置生效。

步骤2.4，若将‘是否mock’栏设置为‘需要mock’并且将mock数据生成规则方式设置为“JSON文件”，点击上传JSON文件保存即可，设置‘mock方式’为‘JSON文件’的配置页面如图11所示，设置‘mock方式’为‘JSON文件’请求响应的界面如图12所示(返回的消息为“success”，返回的结果数据来源于JSON文件)。

步骤2.5，若将‘是否mock’栏设置为‘需要mock’并且将mock数据生成规则方式设置为“JS脚本”，则在JS脚本输入框内输入对应的脚本，设置‘mock方式’为‘JS脚本’的配置页面如图13所示，设置‘mock方式’为‘JS脚本’请求响应的界面如图14所示(返回的消息为“success”，返回的结果数据来源于javascript文件，即JS脚本)，保存后设置生效。

实现本方案的业务流程如图15所示：

步骤1，业务发出请求，该请求可能是ajax(XMLHttpRequest)或者fetch，但是他们都是一种HTTP请求。

本方案mock服务可基于http request在服务端进行拦截，将服务引入到前端服务框架即可运行使用，mock配置及实现都是在服务端完成，对业务代码无污染零入侵，这里解决了mock技术存在的高入侵问题，达到即插即用的效果。

步骤2，判断是否需要拦截，若不需要拦截则执行步骤3，若需要拦截则执行步骤4。

mock服务解析请求，匹配请求地址以及请求的类型(POST、GET、DELETE等)，如果与预先设定的需要进入mock数据服务的地址相同，且请求的类型相同，则获取相应的mock规则(即预先配置的需要测试的服务，如前文描述的登录测试、业务数据的操作等)，进入mock数据服务，否则继续原先请求。

所有配置均可通过配置管理页面进行实时修改保存生效，配置规则由经研究简化固定成mock开关(如图7所示的“是否mock”，选择“需要mock”相当于启用mock服务，选择“不需要mock”相当于关闭mock服务)、mock类型(即如图7所示的“mock方式”)，mock数据源(如图11所示的“mock数据”)等几项参数配合起来使用，使用起来简单易懂，同时该过程所有配置均无数据库依赖，通过diff算法(diff算法是对数据进行different比较不同的一种算法)判断数据变动保存为纯前端静态数据。这里同时接口了现有mock技术灵活性不高及学习成本高的问题。

步骤3，继续原请求，返回真实数据。

步骤4，暂停原请求，进入mock服务。

mock数据服务过程中，根据mock类型及mock数据源，mock服务中断原先请求并且返回对应mock数据给对应的请求，该过程对用户是无感的，用户只能通过查看请求响应header查看有没有mock-data字段判断是否为真实请求或者mock服务请求。

所有的mock数据操作都是会经过缓存来操作的，通过diff算法比较数据差异，大大的减少因为文件读取跟写入导致的性能问题，这样可以保证系统的使用效率，同时可以保证多方使用数据一致性，mock数据一旦发生改动将保存到静态文件当中，保障下次访问返回的mock数据为修改后的数据。mock服务里的所有数据操作都是没有数据库依赖的，都是通过静态文件跟缓存配合起来实现的，解决了对数据库有依赖而需要额外安装数据库的麻烦。

本方案最大的特点是低成本高可用性，纯前端实现，只需要引入服务并且简单配置就可以上手使用。可针对ajax和fetch同时进行拦截mock；不需要独立配置一套mock运行环境，运营成本低而且学习成本也低；较高灵活性，能真实模拟请求过程，对复杂情况的mock也不需要在业务中增加耦合性高的测试代码，只需要在后端配置即可。

提供UI管理页面，可以清晰明了的查看所有接口的配置，同时通过UI可以简单快捷的修改接口的mock配置并且实时生效。对于前端开发人员，通过UI开关mock服务，可以不受后端服务是否可用的限制而正常开发。对于后端开发人员，通过UI管理，在跟前端协议好接口后，后端人员就直接配置接口的mock数据，这里节省了前后端多次联调环境部署发布的过程，前后端可以更加的独立互不干扰进行各自的工作。再者本方案不需额外安装其他后端语言的服务，对数据库没有依赖，同时对业务代码零入侵，大大降低了测试数据及测试代码发布到线上环境的概率。具有多种mock数据生成方式，大大提高了mock服务的灵活性。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

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

根据本申请实施例的另一个方面，还提供了一种用于实施上述服务的测试方法的服务的测试装置。图16是根据本申请实施例的一种可选的服务的测试装置的示意图，如图16所示，该装置可以包括：

获取单元1601，用于获取业务请求；

处理单元1603，用于在根据测试配置确定所述业务请求为测试请求的情况下，根据所述业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，所述终端用于通过向目标接口发送所述测试请求来对所述目标服务进行测试；

响应单元1605，用于响应于所述业务请求，向所述终端返回测试结果。

需要说明的是，该实施例中的获取单元1601可以用于执行本申请实施例中的步骤S202，该实施例中的处理单元1603可以用于执行本申请实施例中的步骤S204，该实施例中的响应单元1605可以用于执行本申请实施例中的步骤S206。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，获取业务请求；在根据测试配置确定业务请求为测试请求的情况下，根据业务请求在数据库中执行对应的操作；响应于业务请求，向终端返回测试结果，由于对业务的测试配置可在服务器端完成，而不用修改前端的业务逻辑，可以解决相关技术中mock服务对前端代码的入侵性较高的技术问题。

可选地，处理单元在根据测试配置确定所述业务请求是否为测试请求时，还用于：获取所述业务请求的来源地址和业务类型、所述测试配置中的业务地址和业务类型；在所述业务请求的来源地址与所述测试配置中的业务地址匹配、且所述业务请求的业务类型与所述测试配置中的业务类型匹配的情况下，确定所述业务请求是所述测试请求；在所述业务请求的来源地址与所述测试配置中的业务地址不匹配和/或所述业务请求的业务类型与所述测试配置中的业务类型不匹配的情况下，确定所述业务请求不是所述测试请求。

可选地，本申请的装置还可包括配置单元，用于：在根据测试配置确定所述业务请求为测试请求之前，展示第一配置界面，其中，所述第一配置界面用于配置所述目标服务的测试请求的业务类型和业务地址；将在所述第一配置界面的第一输入框接收到的业务类型作为所述目标服务的测试请求的业务类型，将在所述第一配置界面的第二输入框接收到的业务地址作为所述目标服务的测试请求的业务地址。

可选地，本申请的配置单元还用于：在根据测试配置确定所述业务请求为测试请求之前，在需要模拟所述目标接口对所述测试请求进行响应的情况下，展示第二配置界面，其中，所述第二配置界面用于配置对所述目标服务的测试请求的处理方式；在所述第二配置界面接收对所述测试请求的处理方式。

可选地，本申请的配置单元在所述第二配置界面接收对所述测试请求的处理方式时，还用于：在所述第二配置界面接收第一处理方式，其中，所述第一处理方式表示使用预设数据交换格式的数据对所述测试请求进行响应；在所述第二配置界面的第三输入框接收输入的表示所述第一处理方式的源码；在所述第二配置界面接收第二处理方式，其中，所述第二处理方式表示使用预设模板的数据对所述测试请求进行响应；在所述第二配置界面的第四输入框接收输入的表示所述第二处理方式的源码；在所述第二配置界面接收第三处理方式，其中，所述第三处理方式表示使用预设数据交换格式的文件对所述测试请求进行响应；在所述第二配置界面接收上传的预设数据交换格式的文件；在所述第二配置界面接收第四处理方式，其中，所述第四处理方式表示使用预设脚本对所述测试请求进行响应；在所述第二配置界面的第五输入框接收输入的脚本源码。

可选地，本申请的获取单元在获取业务请求时，还用于：截取为目标类型中任一类型的所述业务请求，其中，所述目标类型包括多个预先设定的请求类型。

本方案最大的特点是低成本高可用性，纯前端实现，只需要引入服务并且简单配置就可以上手使用。可针对ajax和fetch同时进行拦截mock；不需要独立配置一套mock运行环境，运营成本低而且学习成本也低；较高灵活性，能真实模拟请求过程，对复杂情况的mock也不需要在业务中增加耦合性高的测试代码，只需要在后端配置即可。

提供UI管理页面，可以清晰明了的查看所有接口的配置，同时通过UI可以简单快捷的修改接口的mock配置并且实时生效。对于前端开发人员，通过UI开关mock服务，可以不受后端服务是否可用的限制而正常开发。对于后端开发人员，通过UI管理，在跟前端协议好接口后，后端人员就直接配置接口的mock数据，这里节省了前后端多次联调环境部署发布的过程，前后端可以更加的独立互不干扰进行各自的工作。再者本方案不需额外安装其他后端语言的服务，对数据库没有依赖，同时对业务代码零入侵，大大降低了测试数据及测试代码发布到线上环境的概率。具有多种mock数据生成方式，大大提高了mock服务的灵活性。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供了一种用于实施上述服务的测试方法的服务器或终端。

图17是根据本申请实施例的一种终端的结构框图，如图17所示，该终端可以包括：一个或多个(仅示出一个)处理器1701、存储器1703、以及传输装置1705，如图17所示，该终端还可以包括输入输出设备1707。

其中，存储器1703可用于存储软件程序以及模块，如本申请实施例中的服务的测试方法和装置对应的程序指令/模块，处理器1701通过运行存储在存储器1703内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的服务的测试方法。存储器1703可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1703可进一步包括相对于处理器1701远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置1705用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置1705包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置1705为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器1703用于存储应用程序。

处理器1701可以通过传输装置1705调用存储器1703存储的应用程序，以执行下述步骤：

获取业务请求；

在根据测试配置确定所述业务请求为测试请求的情况下，根据所述业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，所述终端用于通过向目标接口发送所述测试请求来对所述目标服务进行测试；

响应于所述业务请求，向所述终端返回测试结果。

处理器1701还用于执行下述步骤：

在所述第二配置界面接收第一处理方式，其中，所述第一处理方式表示使用预设数据交换格式的数据对所述测试请求进行响应；在所述第二配置界面的第三输入框接收输入的表示所述第一处理方式的源码；

在所述第二配置界面接收第二处理方式，其中，所述第二处理方式表示使用预设模板的数据对所述测试请求进行响应；在所述第二配置界面的第四输入框接收输入的表示所述第二处理方式的源码；

在所述第二配置界面接收第三处理方式，其中，所述第三处理方式表示使用预设数据交换格式的文件对所述测试请求进行响应；在所述第二配置界面接收上传的预设数据交换格式的文件；

在所述第二配置界面接收第四处理方式，其中，所述第四处理方式表示使用预设脚本对所述测试请求进行响应；在所述第二配置界面的第五输入框接收输入的脚本源码。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图17所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图17其并不对上述电子装置的结构造成限定。例如，终端还可包括比图17中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图17所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行服务的测试方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

获取业务请求；

在根据测试配置确定所述业务请求为测试请求的情况下，根据所述业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，所述终端用于通过向目标接口发送所述测试请求来对所述目标服务进行测试；

响应于所述业务请求，向所述终端返回测试结果。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

在所述第二配置界面接收第一处理方式，其中，所述第一处理方式表示使用预设数据交换格式的数据对所述测试请求进行响应；在所述第二配置界面的第三输入框接收输入的表示所述第一处理方式的源码；

在所述第二配置界面接收第二处理方式，其中，所述第二处理方式表示使用预设模板的数据对所述测试请求进行响应；在所述第二配置界面的第四输入框接收输入的表示所述第二处理方式的源码；

在所述第二配置界面接收第三处理方式，其中，所述第三处理方式表示使用预设数据交换格式的文件对所述测试请求进行响应；在所述第二配置界面接收上传的预设数据交换格式的文件；

在所述第二配置界面接收第四处理方式，其中，所述第四处理方式表示使用预设脚本对所述测试请求进行响应；在所述第二配置界面的第五输入框接收输入的脚本源码。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。

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

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

1.一种服务的测试系统，其特征在于，包括：

终端，所述终端上有待测试的目标服务，所述终端用于通过向目标接口发送测试请求来对所述目标服务进行测试；

数据库，所述数据库用于保存与所述目标服务关联的测试数据；

测试服务器，所述测试服务器用于设置所述目标服务的测试配置，在根据所述测试配置确定获取的业务请求为所述测试请求的情况下，向所述终端返回测试结果。

2.根据权利要求1所述的系统，其特征在于，所述系统还包括：

引擎服务器，所述引擎服务器用于将所述业务请求的来源地址与所述测试配置中的业务地址进行比较，并将所述业务请求的业务类型与所述测试配置中的业务类型进行比较；在所述业务请求的来源地址与所述测试配置中的业务地址匹配、且所述业务请求的业务类型与所述测试配置中的业务类型匹配的情况下，确定所述业务请求为所述测试请求；

节点服务器，所述节点服务器用于将接收到的所述业务请求转发给所述测试服务器。

3.一种服务的测试方法，其特征在于，包括：

获取业务请求；

在根据测试配置确定所述业务请求为测试请求的情况下，根据所述业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，所述终端用于通过向目标接口发送所述测试请求来对所述目标服务进行测试；

响应于所述业务请求，向所述终端返回测试结果。

4.根据权利要求3所述的方法，其特征在于，根据测试配置确定所述业务请求是否为测试请求包括：

获取所述业务请求的来源地址和业务类型、所述测试配置中的业务地址和业务类型；

在所述业务请求的来源地址与所述测试配置中的业务地址匹配、且所述业务请求的业务类型与所述测试配置中的业务类型匹配的情况下，确定所述业务请求是所述测试请求；

在所述业务请求的来源地址与所述测试配置中的业务地址不匹配和/或所述业务请求的业务类型与所述测试配置中的业务类型不匹配的情况下，确定所述业务请求不是所述测试请求。

5.根据权利要求3所述的方法，其特征在于，在根据测试配置确定所述业务请求为测试请求之前，所述方法还包括：

展示第一配置界面，其中，所述第一配置界面用于配置所述目标服务的测试请求的业务类型和业务地址；

将在所述第一配置界面的第一输入框接收到的业务类型作为所述目标服务的测试请求的业务类型，将在所述第一配置界面的第二输入框接收到的业务地址作为所述目标服务的测试请求的业务地址。

6.根据权利要求3所述的方法，其特征在于，在根据测试配置确定所述业务请求为测试请求之前，所述方法还包括：

在需要模拟所述目标接口对所述测试请求进行响应的情况下，展示第二配置界面，其中，所述第二配置界面用于配置对所述目标服务的测试请求的处理方式；

在所述第二配置界面接收对所述测试请求的处理方式。

7.根据权利要求6所述的方法，其特征在于，在所述第二配置界面接收对所述目标服务的测试请求的处理方式包括以下至少之一：

在所述第二配置界面接收第一处理方式，其中，所述第一处理方式表示使用预设数据交换格式的数据对所述测试请求进行响应；在所述第二配置界面的第三输入框接收输入的表示所述第一处理方式的源码；

在所述第二配置界面接收第二处理方式，其中，所述第二处理方式表示使用预设模板的数据对所述测试请求进行响应；在所述第二配置界面的第四输入框接收输入的表示所述第二处理方式的源码；

在所述第二配置界面接收第三处理方式，其中，所述第三处理方式表示使用预设数据交换格式的文件对所述测试请求进行响应；在所述第二配置界面接收上传的预设数据交换格式的文件；

在所述第二配置界面接收第四处理方式，其中，所述第四处理方式表示使用预设脚本对所述测试请求进行响应；在所述第二配置界面的第五输入框接收输入的脚本源码。

8.根据权利要求3所述的方法，其特征在于，

根据所述业务请求在数据库中执行对应的操作包括：根据所述业务请求在测试服务器的内存数据库中执行对应的数据操作，其中，所述数据操作包括业务数据的写入、修改以及删除；

在根据所述业务请求在数据库中执行对应的操作的同时或之后，所述方法还包括：在所述测试服务器本地的静态文件中进行业务数据的更新，其中，更新后的所述静态文件中的业务数据与所述内存数据库中的业务数据相同。

9.根据权利要求3所述的方法，其特征在于，获取业务请求包括：

截取携带有预设字段的所述业务请求，其中，所述预设字段用于表示该请求为用于测试的请求。

10.一种服务的测试装置，其特征在于，包括：

获取单元，用于获取业务请求；

处理单元，用于在根据测试配置确定所述业务请求为测试请求的情况下，根据所述业务请求在数据库中执行对应的操作，其中，终端上有待测试的目标服务，所述终端用于通过向目标接口发送所述测试请求来对所述目标服务进行测试；

响应单元，用于响应于所述业务请求，向所述终端返回测试结果。

11.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求3至9任一项中所述的方法。

12.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求3至9任一项中所述的方法。

Images