首页> 中国专利> 基于Netty实现Restful接口模拟测试服务的方法及装置

基于Netty实现Restful接口模拟测试服务的方法及装置

摘要

本申请提供了一种基于Netty实现Restful接口模拟测试服务的方法、装置和计算机设备。该方法包括:模拟测试服务器接收来自前端的接口调用请求;对所述接口调用请求进行请求路径和请求参数的匹配检测,以使得所述接口调用请求满足后端所需的业务代码逻辑;所述接口调用请求被确认为合法后,进行接口响应处理;Netty服务器将处理完毕的响应结果发送给前端。本申请的方法提升了前后端业务开发效率和业务场景的完整覆盖性测试需求。

著录项

  • 公开/公告号CN114416602B

    专利类型发明专利

  • 公开/公告日2022-07-05

    原文格式PDF

  • 申请/专利号CN202210321387.5

  • 申请日2022-03-30

  • 分类号G06F11/36(2006.01);

  • 代理机构北京市万慧达律师事务所 11111;

  • 代理人黄玉东

  • 地址 101408 北京市怀柔区雁栖经济开发区兴科南二街3号院1号楼322室

  • 入库时间 2022-08-23 13:58:52

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-07-05

    授权

    发明专利权授予

  • 2022-05-20

    实质审查的生效 IPC(主分类):G06F11/36 专利申请号:2022103213875 申请日:20220330

    实质审查的生效

说明书

技术领域

本申请涉及web开发技术领域,特别是涉及一种基于Netty实现Restful接口模拟测试服务方法、装置、计算机设备和存储介质。

背景技术

随着时代的发展,现代web应用越来越复杂。相应的开发时投入的人力也会更多。为了更好的支持大规模协同开发的需要。人们提出了前后端分离的开发模式。从而将开发人员分开为:前端和后端,两种相对独立的开发团队。一般的模式是前端通过调用后端提供的接口,来完成相应的功能。前、后端定义好相关接口,就可以实现实现前、后端独立分开开发,实现开发资源更充分的利用。

在这种开发模式下,大家都依赖于相应的接口。因此对接口的测试,确保接口的正确性、健壮性、业务完整性就非常重要了。为了验证接口在不同返回值时,系统的响应是否符合预期,需要构造相应的业务场景数据。但实际中有些业务场景相对不是很容易构造,如果能模拟相应的场景将是一种完美的解决办法,因此有了模拟接口响应的需求。

另一方面,受限于前后端开发排期不同。有时候后端接口业务逻辑还没有来得及开发出来,但是前端却急需使用该接口。此时,如果能够提供模拟接口从而满足前端开发联测的需求,也将大大提升团队总体开发效率。

从以上分析可以看出,无论是出于业务完整性测试的需要,还是出于对开发效率的需要,接口模拟测试服务器的需求都是比较迫切的。

发明内容

基于此,针对上述技术问题,本申请提供了一种基于Netty实现Restful接口模拟测试服务的方法、装置、计算机设备和存储介质,以提升前后端业务开发效率和业务场景的完整覆盖性测试需求。

本发明的第一方面,提供了一种基于Netty实现Restful接口模拟测试服务的方法,包括:

模拟测试服务器接收来自前端的接口调用请求;

对所述接口调用请求进行请求路径和请求参数的匹配检测,以使得所述接口调用请求的格式及内容满足后端所需的业务代码逻辑;

所述接口调用请求被确认为合法后,按照业务要求进行接口响应处理;

Netty服务器将处理完毕的响应结果发送给前端展示。

进一步地,所述的接口响应处理包括对接口响应内容的渲染和修饰。

进一步地,通过调用MOCK类实体来编写相关的工具函数并返回给请求接口所需的函数,或返回响应接口所需的函数内容。

进一步地,所述请求路径匹配为检查所述接口调用请求的URL是否可接受,包括:通过startWith是否以指定字符开始、endWith是否以指定字符结尾、contain是否包含特定字符来判断所述接口调用请求是否合法。

进一步地,所述请求参数匹配包括:对json文件和form表单提交的请求参数进行解析,对header和cookie请求参数进行读取,判断各请求参数是否符合业务规则。

进一步地,根据业务需求将接口渲染成所需的格式,包括plain-text、xml或json格式,以及根据业务需求设置响应状态码status、响应头header和cookie数据。

进一步地,使用请求处理器提供的API接口来编写MOCK类实体,使用响应处理提供的API接口来编写请求处理器匹配到的请求对应的响应内容。

本发明的第二方面,提供了一种基于Netty实现Restful接口模拟测试服务的装置,包括:

请求处理器,用于接收前端的接口调用请求,并对所述接口调用请求进行路径和参数的匹配检测,以使得所述接口调用请求满足后端所需的业务代码逻辑;

响应处理器,用于在所述接口调用请求被确认为合法后,按照业务要求处理接口响应并生成响应结果;

Netty服务器,用于将所述响应结果发送给前端。

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

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

本发明所提供的基于Netty实现Restful接口模拟测试服务方法、装置和计算机设备,通过商定好的接口调用请求的URL、请求参数和对应的响应结果,当前端的模拟接口调用请求匹配到预设的请求时,模拟接口服务器就按要求返回商定好的响应内容。通过这种机制,一方面后端接口开发人员在和前端开发人员商定好接口规格后,即可快速编写出相应的模拟接口,从而快速响应前端开发人员的需求,提升了开发效率。另一方面可以根据期望预设相应的响应内容,因此可以很容易模拟出在真实业务场景下不太容易出现的结果,从而实现了业务场景的更全面的覆盖,提升了软件的健壮性。

附图说明

图1为本发明实施例中的基于Netty实现Restful接口模拟测试服务方法的流程示意图。

图2为本发明实施例中的基于Netty实现Restful接口模拟测试服务方法的各组件依赖关系图。

图3为本发明实施例中的基于Netty实现Restful接口模拟测试服务装置的结构示意图。

图4为本发明实施例中的Netty实现Restful接口模拟测试服务装置的框架架构图。

图5为本发明实施例中的计算机设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。此外,为了清楚和简洁,省略对公知功能和结构的描述。

本文使用的术语仅用于描述本发明的各种实施例,而不旨在限制本发明。除非上下文另有明确指示,否则单数形式旨在包括复数形式。在本发明中,应理解,术语“包括”或“具有”指示特征、数字、步骤、操作、元件、部件或其组合的存在,并且不排除一个或更多个其它特征、数字、步骤、操作、元件、部件或其组合的存在,或添加一个或更多个其它特征、数字、步骤、操作、元件、部件或其组合的可能性。

本申请实施例中的各技术术语解释如下:

Netty:Netty是一个高性能、基于事件驱动的高性能NIO(New IO/Non-blockingIO)框架,Netty对NIO的API进行了封装,它通过PipeLine机制简化了网络编程的难度,并支持FTP、SMTP、HTTP等多种应用层协议。在Netty里,Channel是通讯的载体,而ChannelHandler负责Channel中的逻辑处理。它是Netty网络通信的主体,由它负责同对端进行网络通信、注册和数据操作等功能。本申请基于它对HTTP协议的良好支持和简化的编程机制来实现Restful接口模拟测试服务器。

Mock:Mock即模拟,在软件开发过程中,有一些业务场景通过真实数据来构造起来相对比较困难。在此时,我们可以构造一个虚拟对象通过它来模拟真实的业务场景,以达到测试目的,这个测试方法就叫Mock。当前在进行Mock测试时,前端可以选择像fiddler、charles工具,通过抓包模拟响应来进行接口测试,后端可选择像Mockito、easyMock等工具。如果被测对象依赖对象的是一些远程服务(HTTP/RPC服务),就属于Remote Mock,Remote Mock一般实现对指定的服务/接口、客户端(消费者)进行Mock。可以通过MockServer等方式去实现。Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。有了Mock,前后端人员只需要定义好接口文档就可以开始并行工作,互不影响,只在最后的联调阶段往来密切;后端与后端之间如果有接口耦合,也同样能被Mock解决;测试过程中如果遇到依赖接口没有准备好,同样可以借助Mock;不会出现一个团队等待另一个团队的情况。这样的话,开发自测阶段就可以及早开展,从而发现缺陷的时机也提前了,有利于整个产品质量以及进度的保证。

Restful:REST英文Representational state transfer 表述性状态转移其实就是对资源的表述性状态转移。简单的说:RESTful是一种架构的规范与约束、原则,符合这种规范的架构就是RESTful架构。它是一种轻量级web服务,充分发挥HTTP协议的原生的GET,PUT,POST,DELETE语义来操作资源。REST风格的API中,URL定位资源,用HTTP动词(GET、POST、DELETE、PUT)描述来实现资源的添加,修改,删除等操作。Server和Client之间传递某资源的一个表现形式,比如用JSON,XML传输文本,或者用JPG,WebP传输图片等。当然还可以压缩HTTP传输时的数据(on-wire data compression)。用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功,500 表示Server内部错误等。REST 是面向资源的,而资源是通过 URI 进行暴露,REST很好地利用了HTTP本身就有的一些特征,如HTTP动词、HTTP状态码、HTTP报头等等

前后端分离:传统的Web应用开发模式是MVC模式,一般是通过jsp来承担视图的功能。但是这样,开发人员既要负责业务逻辑的编写,又要承担展现页面的开发,开发分工不明确,且可能造成代码耦合。基于此现状,人们提出来前后端分离模式,前后端分离是一种架构模式,后端给前端提供接口,前端调用后端提供的REST风格接口并专注写页面(html、jsp)和渲染(JS、CSS等各种前端框架)。前后端分离的核心:后台提供数据,前端负责展示。

实施例一

参照图1所示,本发明的实施例一提供了一种基于Netty实现Restful接口模拟测试服务方法,该方法应用于接口模拟测试服务器,其中,接口模拟测试服务器整体基于Netty-Server框架,在该框架上抽象了请求服务器(RequestExpect)、响应服务器(ResponseExpect)、Mock类(MockFunction)等实体组件,该方法包括:

步骤S1、接口模拟测试服务器接收来自前端的接口调用请求,对该接口调用请求进行匹配,以确定是否是预设的请求内容和格式。

具体来说,由请求服务器(RequestExpect)处理来自前端的接口调用请求,主要是进行路径匹配和参数匹配,通过匹配以精确的将接口调用请求匹配到后端业务所需的业务代码逻辑。首先,通过UrlMatcher(路径匹配器)来检查接口调用请求的URL是否可接受,即通过startWith是否以指定字符开始、endWith是否以指定字符结尾、contain是否包含特定字符等来判断接口调用请求是否合法。同时,通过ParameterMatcher(参数匹配器)进行接口调用请求的参数进行匹配,包括对json和form表单提交的请求参数进行解析,对header和cookie参数进行读取,以确定它们的格式和内容是否符合后端业务逻辑开发所需的业务规则,主要是指传进来的参数是否业务要求,比如:非空,大于0,等于特定的值等。

步骤S2、当该接口调用请求经过验证,被确认为合法后,将处理逻辑移送给响应服务器(ResponseExpect),由响应服务器处理接口响应。

具体的,当该接口调用请求通过UrlMatcher和ParameterMatcher的匹配,能够匹配到具体的后端业务逻辑时,则被认定为一个合法的接口请求,此后,由响应服务器来处理接口响应,主要是对接口响应内容进行渲染和修饰。其中,响应服务器使用ResponseBodyHandler来将接口响应内容渲染成业务需求所需的格式,包括plain-text、xml或json格式等,以及使用ResponseHandler根据需要来设置响应状态码status、响应头header和cookie等数据,可以对这些数据进行修改。比如说,在覆盖测试的场景下,前端需要模拟在接收到服务端返回异常(http状态码500)情况下的表现,此时,就可以按需要,人为设置响应状态码为500。使用Mock保证了接口测试的覆盖度。

步骤S3、当接口调用请求所需的响应内容处理完成后,处理逻辑将交给Netty服务器(Netty-server),由Netty服务器将接口响应内容发送给前端。

当前端的模拟接口调用请求匹配到预设的请求时,模拟接口服务器就按要求返回商定好的响应内容。响应服务器将响应结果封装成了Netty服务器可以识别的格式,由Netty服务器来完成网络传输层面的发送操作。

通过调用Mock类实体(MockFunction)来编写相关的工具函数并返回给请求接口或响应接口所需的内容。Mock类实体通过封装有一些工具类、工具函数等,方便编写请求接口或响应接口的MOCK业务逻辑,如:判断参数非空等,这样RequestExpect就可以使用MockFunction提供的判空函数(判断参数是否为空)来检查传入参数是否符合要求。在响应服务器的ResponseBodyHandler中可进行回调调用MOCK类实体提供的相关工具函数,通过在MOCK类实体编写具体的需要返回给接口调用方所需的业务数据的逻辑代码,如此方便快速的返回数据,如:curentDate()生成当前日期、randomStr()生成随机字符串等。

通过设置MOCK类实体能够提升系统整体使用便利性。当一个接口开发出来后,前端可能会根据接口返回的数据不同,有相应的展示,但是有些业务场景相对不太容易构造。因此,为了比较全面的覆盖业务场景,可以通过MOCK接口(指代具体的需要模拟测试的业务接口)响应来实现业务场景覆盖的目的;有时候前后端的开发时间规划可能不匹配,后端接口还没有开发完成,但是前端又依赖于待开发接口,此时可以通过MOCK接口来协助前端完成功能开发。假如我们需要调用一个post请求,为了获得某个响应,来看当前系统是否能正确处理返回的“响应”,但是这个post请求会造成数据库中数据的污染,那么就可以充分利用Mock,构造一个虚拟的post请求,我们给他指定返回就好了。

参照图2所示,图2是本申请实施例中的方法间各组件的依赖关系图。

如图2所示,系统整体构建在Netty-Server之上。通过Netty的ServerBootstrap启动API的Mock服务。使用RequestExpect提供的API来编写MOCK接口。RequestExpect调用UrlMatcher来匹配接口请求,通过ParameterMatcher来进行请求参数的匹配,从而将用户的请求匹配到具体的业务逻辑代码。使用ResponseExpect提供的API来编写RequestExpect匹配到的请求对应的响应内容。它通过ResponseBodyHandler来编写具体的响应内容处理逻辑,通过ResponseHandler来处理响应头。示例代码如下所示:

MockServer server = new MockServer();

serer.requestExpect(new RequestExpect(){

public String path(){

return “/getNodeList”;//请求路径

}

public String method(){

return “GET”;//请求方法

}

public Map pathParam(){

return null;//请求路径参数

}

public Map queryStringParam(){//请求参数

Map param = new HashMap();

param.put(“tldId”, “1|2|3|4”);

param.put(“dimension”, “month|day”);

return param;

}

}).responseExpect(new ResponseExpect(){

public ResponseBodyHandler body(){

return new ResponseBodyHandler(){

public Object response(){

return Json.fromString(“{id: 1, name: ‘top’}”);

}

};

}

public ResponseHandler header(){

return new ResponseHandler(){

public void header(Header header){

header.set(“jsessionId”, “jsessionId”);

}

};

}

});。

本申请实施例所提供的一种基于Netty实现Restful接口模拟测试服务方法,通过商定好的请求URL、请求参数和对应的响应结果。当前端的模拟接口调用请求匹配到预设的请求时,模拟接口服务器就按要求,返回商定好的响应内容。通过这种机制:一方面后端接口开发人员在和前端开发人员商定好接口规格后,即可快速编写出相应的模拟接口,从而快速响应前端开发人员的需求,提升了开发效率。另一方面可以根据期望预设相应的响应内容,因此可以很容易模拟出在真实业务场景下不太容易出现的结果,从而实现了业务场景的更全面的覆盖,提升了软件的健壮性。

实施例二

本发明的实施例二提供了一种基于Netty实现Restful接口模拟测试的服务装置,包括:

请求处理器,用于接收前端的接口调用请求,并对所述接口调用请求进行路径和参数的匹配检测,以使得所述接口调用请求满足后端所需的业务代码逻辑;

响应处理器,用于在所述接口调用请求被确认为合法后,根据业务要求处理接口响应并生成响应结果;

Netty服务器,用于将所述响应结果发送给前端。

其中,请求处理器和响应处理器均提供各自的API接口,使用请求处理器提供的API来编写Mock接口,使用响应处理器提供的API来编写请求处理器匹配到的请求对应的响应内容。请求处理器包括路径匹配器和参数匹配器,分别用于对接口请求的URL进行规则验证匹配和对接口请求的参数进行匹配,只有与后端业务逻辑所需要实现的功能代码匹配通过后,才进入响应处理器进行文件内容的渲染和修饰,响应处理器生成响应结果并进行封装成Netty服务器可用的格式后,由Netty服务器将响应内容发送至前端进一步处理,从而快速响应前端开发人员的需求,提升了开发效率,而且通过该种模式,业务开发人员也能够根据期望预设相应的响应内容,模拟出在真实业务场景下不太容易出现的结果,从而实现了业务场景的更全面的覆盖。

关于本实施例基于Netty实现Restful接口模拟测试服务装置的具体限定可以参见上文中对于基于Netty实现Restful接口模拟测试服务方法的限定,在此不再赘述。上述基于Netty实现Restful接口模拟测试服务装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。

实施例三

本发明的实施例三提供了一种计算机设备,其内部结构图可以如图3所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与其他的终端或者服务通过网络连接通信。该计算机程序被处理器执行时以实现一种基于Netty实现Restful接口模拟测试服务方法。其中,该计算机设备可以服务器,该服务器还可以包括数据库,该服务器的数据库可以存储预先训练的分类模型。该计算机设备还可以终端,该终端还可以包括显示屏和输入装置,该终端的显示屏可以是液晶显示屏或者电子墨水显示屏,该终端的输入装置可以是显示屏上覆盖的触摸层,也可以是计算机设备外壳上设置的按键、轨迹球或触控板,还可以是外接的键盘、触控板或鼠标等,也还可以是语音识别装置或者文字识别装置。

本领域技术人员可以理解,图3中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。

在一个实施例中,提供了一种计算机设备,包括存储器和处理器,存储器存储有计算机程序,计算机程序被处理器执行时,使得处理器执行上述基于Netty实现Restful接口模拟测试服务方法的步骤。此处基于Netty实现Restful接口模拟测试服务方法的步骤可以是上述各个实施例的基于Netty实现Restful接口模拟测试服务方法中的步骤:模拟测试服务器接收来自前端的接口调用请求;对所述接口调用请求进行请求路径和请求参数的匹配检测,以使得所述接口调用请求的格式及内容满足后端所需的业务代码逻辑;所述接口调用请求被确认为合法后,按需进行接口响应处理;Netty服务器将处理完毕的响应结果发送给前端展示。

实施例四

本发明的实施例四,提供了一种计算机可读存储介质,存储有计算机程序,计算机程序被处理器执行时,使得处理器执行上述基于Netty实现Restful接口模拟测试服务方法的步骤。此处基于Netty实现Restful接口模拟测试服务方法的步骤可以是上述各个实施例的基于Netty实现Restful接口模拟测试服务方法中的步骤:模拟测试服务器接收来自前端的接口调用请求;对所述接口调用请求进行请求路径和请求参数的匹配检测,以使得所述接口调用请求的格式及内容满足后端所需的业务代码逻辑;所述接口调用请求被确认为合法后,按照业务要求进行接口响应处理;Netty服务器将处理完毕的响应结果发送给前端展示。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink) DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号