基于Java的API网关登录鉴权的测试方法与流程

文档序号:28499835发布日期:2022-01-15 04:42阅读:630来源:国知局
基于Java的API网关登录鉴权的测试方法与流程
基于java的api网关登录鉴权的测试方法
技术领域
1.本技术涉及互联网微服务技术领域,尤其涉及一种基于java的api网关登录鉴权的测试方法。


背景技术:

2.目前越来越多的项目采用微服务架构设计模式,将软件根据业务拆分成多个独立运行的服务,在实际工作中可能会有上千或更多的应用需要一个统一的入口,通过网关访问各自业务的api并返回数据。在对网关进行测试的时候,因为业务方的不同,身份鉴权有会有所不同,如可能是移动端、web端以及通过jwt验证或基于预设设置的key方式进行验证的业务类型。
3.现有技术中,在验证鉴权的时候需要不同的场景而且每一种鉴权需要提前配置一些基础数据,此时需要各个业务放的配合,才能完成对网关的测试,而且需要针对各种鉴权方式,记忆逻辑或通过查看文档对每个鉴权逐个进行验证,同时还需要提前准备各种鉴权对应的api接口及api接口的服务,整个测试过程,繁琐耗时,效率低下。


技术实现要素:

4.本技术提供一种基于java的api网关登录鉴权的测试方法,用于解决现有技术中,测试过程,繁琐耗时,效率低下的问题。
5.本技术的上述目的是通过以下技术方案实现的:
6.本技术实施例提供一种基于java的api网关登录鉴权的测试方法,包括:
7.编写dubbo服务,并部署网关服务;其中,所述dubbo服务包括移动端sso服务、web端sso服务、jwt服务和加密key服务;
8.注册所述dubbo服务至预设协调服务中,并将所述dubbo服务发布至网关,生成对应4个所述dubbo服务的4个api;所述4个api分别为移动端sso api、web端sso api、jwt服务api和加密key api;
9.在网关中对所述4个api配置权限;
10.创建与所述4个api分别对应的4个自动化测试用例;
11.运行所述自动化测试用例,通过网关自动进行鉴权,并基于鉴权结果返回对应数据或信息。
12.进一步的,所述在网关中对所述4个api配置权限,包括:
13.在网关中对所述移动端sso api配置移动端sso权限,对所述web端sso api配置web端sso权限,对所述jwt服务api配置jwt访问权限和对所述加密key api配置对应key权限。
14.进一步的,所述自动化测试用例包括:
15.包括移动端sso api权限测试用例、web端sso api权限测试用例、jwt服务api权限测试用例和加密key api权限测试用例。
16.进一步的,所述运行所述自动化测试用例,通过网关自动进行鉴权,并基于鉴权结果返回对应数据或信息,包括:
17.运行所述自动化测试用例,调用网关地址;
18.通过网关根据每种api配置的权限进行鉴权,若鉴权成功,则根据配置的协调服务地址找到所述dubbo服务,并返回接口返回的数据;若鉴权失败,则返回失败信息。
19.进一步的,还包括:
20.为每种所述自动化测试用例编写对应测试断言,并基于所述测试断言判断对应所述自动化测试用例是否成功返回结果。
21.本技术的实施例提供的技术方案可以包括以下有益效果:
22.本技术涉及一种基于java的api网关登录鉴权的测试方法,包括:编写dubbo服务,并部署网关服务;其中,dubbo服务包括移动端sso服务、web端sso服务、jwt服务和加密key服务;注册dubbo服务至预设协调服务中,并将dubbo服务发布至网关,生成对应4个dubbo服务的4个api;然后在网关中对所述4个api配置权限;创建与所述4个api分别对应的4个自动化测试用例;运行所述自动化测试用例,通过网关自动进行鉴权,并基于鉴权结果返回对应数据或信息。如此,通过将所有验证写成一种可执行的测试项目,只有当业务变更时去维护这套代码,以后每次验证只需要运行测试代码就可以完成测试,大大提高效率。
23.应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本技术。
附图说明
24.此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本技术的实施例,并与说明书一起用于解释本技术的原理。
25.图1为本技术实施例提供的一种基于java的api网关登录鉴权的测试方法的流程示意图;
26.图2为本技术另一实施例提供的一种基于java的api网关登录鉴权的测试方法的流程示意图。
27.图3为本技术实施例提供的一种基于java的api网关登录鉴权的测试方法的部分示意图。
具体实施方式
28.这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
29.目前越来越多的项目采用微服务架构设计模式,将软件根据业务拆分成多个独立运行的服务,在实际工作中可能会有上千或更多的应用需要一个统一的入口,通过网关访问各自业务的api并返回数据,同时网关是一个服务器,承载着多种应用的身份鉴权,因此网关登录鉴权的重要性不得而知。与此同时,实际业务应用对接网关时会有移动端sso鉴权、pc端sso鉴权、jwt验证、其它key验证方式等,因此,需要在每次发版及日常回归确保登
录鉴权能正常工作,每次发版回归测试时,都需要请业务方配合验证或我们自己去根据不同搭建自己的api服务辅助测试,多种场景手工测试花费时间比较长还有可能有遗漏,不利于快速迭代及保障产品质量。另外,我们需要记住这些不同类型鉴权方式的验证逻辑或去看文档。
30.具体的,我们在测试网关的时候,因为业务方的不同,身份鉴权有会有所不同。比如,我们的业务方如果移动端的,那它的身份验证会先走移动端的sso进行鉴权,如果通过则返回正常api数据给用户,如果鉴权失败,则返回无权访问给业务方;如果我们的业务方使用的是web端的sso登录验证,则会先去web端sso进行身份鉴权,如果通过则返回正常api数据给用户,如果鉴权失败,则返回无权访问给业务方;如果我们的业务方使用的是jwt的验证方式,则需要用户提供token来进行身份鉴权,如果通过则返回正常api数据给用户,如果鉴权失败,则返回无权访问给业务方;另外,往往有一些旧的应用或其它情况,可能会使用一些自定义的鉴权方式,如果业务方向网关提供一个事先商量好的key经过一系列的加密,在调用api的时候传入这个key到网关后台,网关后台代码将这个key解密,如果解密后鉴权通过则返回正常api数据给用户,如果鉴权失败,则返回无权访问给业务方;此时,我们已经看到,我们在验证鉴权的时候是需要不同的场景而且每一种鉴权需要提前配置一些基础数据,我们可以请各个业务方帮忙,但整个测试完成下来后会花掉很多时间,而且业务方也不一定有时间配合我们,各种鉴权方式不同,所以每次都需要记住这些逻辑或去看文档一个个验证,时间上消耗比较多。同时,我们需要提前准备好各种鉴权对应的api接口及api接口的服务,因为考虑到不能破坏业务方的api数据,因此,我们需要有自己的api服务来支撑辅助完成测试工作。这使得测试工作变得比较困难,沟通协调等可能要花掉几个小时甚至一天或更多的时间,过程繁琐耗时,效率低下。
31.实施例
32.图1为本技术实施例提供的一种基于java的api网关登录鉴权的测试方法的流程示意图,图2为本技术另一实施例提供的一种基于java的api网关登录鉴权的测试方法的流程示意图,其中,图2中用实线标注流程关系,虚线标注数据关系,如图1和图2所示:本技术实施例提供的基于java的api网关登录鉴权的测试方法包括:
33.s101、编写dubbo服务,并部署网关服务。
34.其中,所述dubbo服务包括移动端sso服务、web端sso服务、jwt服务和加密key服务。
35.具体的,首先搭建一个用来提供后端的服务的java spring boot工程,并编写代码完成4个dubbo服务,分别为移动端sso服务,web端sso服务,jwt服务,加密key服务,这4个服务用来做为测试几种鉴权的服务接口。然后成功部署一个网关服务(网关服务是研发提供的,需要被测试的服务)。
36.其中,dubbo是一款开源的一个高性能优秀的服务框架。是一款高性能、轻量级的开源java rpc框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现;jwt为json web token(jwt),是一个开放标准,是为了在网络应用环境间传递声明而执行的一种基于json的开放标准。jwt的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被
加密;sso为单点登录(singlesignon,sso),就是通过用户的一次性鉴别登录.
37.另外,需要说明的是,api网关是一个服务器,是系统的唯一入口(也是微服务领域中重要的组件之一)。是大型分布式系统中,为了保护内部服务而设计的一道屏障,可以提供高性能、高可用的api托管服务,从而帮助服务的开发者便捷地对外提供服务,而不用考虑安全控制、流量控制、审计日志等问题,统一在网关层将安全认证,流量控制,审计日志,黑白名单等实现。网关的下一层,是内部服务,内部服务只需开发和关注具体业务相关的实现。网关可以提供api发布、管理、维护等主要功能。开发者只需要简单的配置操作即可把自己开发的服务发布出去,同时置于网关的保护之下。
38.s102、注册所述dubbo服务至预设协调服务中,并将所述dubbo服务发布至网关,生成对应4个所述dubbo服务的4个api。
39.具体的,在上述步骤中建立的java spring boot工程中添加分布式应用程序协调服务(zookeeper,zk)相关的配置信息,并启动java工程并将准备好的4个dubbo服务注册到zk注册中心。然后,将上述步骤中的4个dubbo服务发布到api网关,发布后分别产生4个api。即移动端sso api、web端sso api、jwt服务api和加密key api。
40.s103、在网关中对所述4个api配置权限。
41.具体的,为上述步骤中发布到网关的api分别配置权限,包括移动端sso api配置移动端sso权限,web端sso api配置web端sso权限,jwt服务api配置jwt访问权限,加密key api配置对应key权限。主要用来测试不同权限的鉴权。
42.s104、创建与所述4个api分别对应的4个自动化测试用例。
43.具体的,编写自动化测试代码,新建一个基于testng测试框架的java测试工程,创建自动化测试用例(移动端sso api权限测试用例,web端sso api权限测试用例,jwt服务api权限测试用例,加密key api权限测试用例)并为它们编写测试断言。
44.s105、运行所述自动化测试用例,通过网关自动进行鉴权,并基于鉴权结果返回对应数据或信息。
45.具体的,在确保上述步骤中的后端dubbo服务和网关服务正常运行的情况下,运行自动化测试用例,当每个api的测试用例开始运行时,它们会先去调用网关的地址,然后网关根据每种api配置的权限去鉴权,如果鉴权成功,则根据配置的zk地址找到后端的dubbo服务并成功得到接口返回的数据。如果鉴权失败,则返回失败信息。自动化测试用例会根据事先写好的测试断言去判断每种用例是否成功且返回结果给测试人员。如此,实现自动测试,节省人力物力,提高工作效率。
46.本技术涉及一种基于java的api网关登录鉴权的测试方法,利用java编程语言编写4个用于测试登录鉴权的后端dubbo服务(移动端sso服务,web端sso服务,jwt服务,加密key服务),并启动注册到zk,部署一个正常的测试网关服务;然后,将这些服务发布到api网关并为它们设置不同的登录鉴权权限;再利用java编程语言基于testng测试框架编写一个自动化测试工程,并根据每种登录鉴权创建测试用例及测试断言;最后,利用测试工程在每次发版后运行测试用例,达到对各种登录鉴权覆盖的高效回归测试。本技术中,根据被测功能复杂度及重要度,将测试链路经过分析并利用java编程语言及相关技术搭建一套api网关各种登录鉴权的测试工程,达到高效回归测试的目的。将不同的鉴权场景及不同业务测试服务都做成自动化,从而达到降本提效的目的,在实际应用中,预计使用代码去测试所有
场景只需要几分钟便可完成,大大提高效率。
47.为更清晰的描述本技术中提供的基于java的api网关登录鉴权的测试方法,现从实际应用场景出发,对该方法实施过程进行说明,图3为本技术实施例提供的一种基于java的api网关登录鉴权的测试方法的部分示意图,如图3所示,在本技术提供的基于java的api网关登录鉴权的测试方法中:
48.首先用户通过调用api的方式,在网关处进行登录,网关基于身份信息进行鉴权,其中包括移动端sso身份鉴权、web端sso身份鉴权、jwt身份鉴权和加密key身份鉴权,如果鉴权成功,则通过预设的dubbo服务,返回api接口数据信息,如果鉴权失败,则返回无权访问,完成整个鉴权流程。
49.可以理解的是,上述各实施例中相同或相似部分可以相互参考,在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。
50.需要说明的是,在本技术的描述中,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性。此外,在本技术的描述中,除非另有说明,“多个”的含义是指至少两个。
51.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本技术的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本技术的实施例所属技术领域的技术人员所理解。
52.应当理解,本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(pga),现场可编程门阵列(fpga)等。
53.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
54.此外,在本技术各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。
55.上述提到的存储介质可以是只读存储器,磁盘或光盘等。
56.在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
57.尽管上面已经示出和描述了本技术的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本技术的限制,本领域的普通技术人员在本技术的范围内可以对上述实施例进行变化、修改、替换和变型。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1