测试开发：从0到1学习如何测试API网关

Posted 2021-05-27 测试开发技术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了测试开发：从0到1学习如何测试API网关相关的知识，希望对你有一定的参考价值。

关注上方“测试开发技术”，选择星标，

干货技术，第一时间送达！

日常工作中，难免会遇到临危受命的情况，虽然没有这么夸张，但是也可能会接到一个陌生的任务，也许只是对这个概念有所耳闻。也许这个时候会感到一丝的焦虑，生怕没法完成领导交给的测试任务。其实也没有必要那么紧张，面对一个陌生的被测对象，我们只需要去了解清楚它的应用场景、内部原理、实现逻辑，结合开发的设计需求，一样也能完成好测试任务，积累经验。这次就分享一些从0到1学习如何测试API网关的经验。

一、什么是API网关

简述：

客户端复杂性增加，现在一般同一套后端服务会支撑多个客户端
存在跨域请求，在一定场景下处理相对复杂
认证复杂，每个服务都需要单独验证
耦合度高，难以重构
某些微服务会存在防火墙等一些保护措施，无法直接访问

微服务网关是微服务架构中的一个关键角色，用来保护，增强和控制对于微服务的访问，微服务网关是一个处于应用程序或服务之前的系统，用来管理授权，访问控制和流量限制等，这样微服务就会被微服务网关保护起来对所有的调用者透明。因此，隐藏在微服务网关后面的业务系统就可以更加专注于业务本身。

组成：

路由转发：接受外界请求，转发到后端微服务
过滤器：完成一系列横切功能，例如权限校验，限流以及监控等

优点：

安全性高，只有网关系统对外进行暴露，微服务可以隐藏在内网，通过防火墙策略保护
易于监控，可以在网关收集监控数据并将其推送到外部监控系统进行分析
易于认证，可以在网关处统一进行认证，无需在后端微服务中进行认证
减少耦合，避免多个客户端与后端微服务之间的交互次数
易于鉴权，在网关处统一鉴权

职能：

请求接入，作为所有API接口服务请求的接入点
业务聚合，作为所有后端业务服务的聚合点
中介策略，实现安全，验证，路由，过滤，流控等策略
统一管理，对所有API服务和策略进行统一管理

二、微服务网关常见技术

nginx是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务
zuul，Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器
spring-cloud-gateway是spring出品的基于spring的网关项目，集成断路器，路径重写等，性能比Zuul好

2.1 gateway是什么

Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Zuul，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

几个概念

Route（路由）：这是网关的基本构建块。它由一个ID，一个目标URI，一组断言和过滤器定义。如果断言为真，则路由匹配成功。
Predicate（断言）：输入类型是一个ServerWebExchange。我们可以使用它来匹配来自HTTP请求的任何内容，例如headers或参数。
Filter（过滤器）：Gateway中的Filter分为两种类型的filter，分别是gateway filter和global filter，过滤器会对请求和响应作处理。

2.2 gateway怎么用

说到底predicate就是为了实现一组匹配规则，方便让请求过来找到对应的Route进行处理，而spring cloud gateway内置了几种predicate的使用。

1、通过时间匹配

Predicate 支持设置一个时间，在请求进行转发的时候，可以通过判断在这个时间之前或者之后进行转发。比如我们现在设置只有在 2018 年 1 月 20 日才会转发到我的网站，在这之前不进行转发，我就可以这样配置：

spring:
  cloud:
    gateway:
      routes:
       - id: time_route
        uri: http://youknowit.com
        predicates:
         - After=2018-01-20T06:06:06+08:00[Asia/Shanghai]

2、通过cookie匹配

Cookie Route Predicate 可以接收两个参数，一个是 Cookie name , 一个是正则表达式，路由规则会通过获取对应的 Cookie name 值和正则表达式去匹配，如果匹配上就会执行路由，如果没有匹配上则不执行。

spring:
  cloud:
    gateway:
      routes:
       - id: cookie_route
         uri: http://youknowit.com
         predicates:
         - Cookie=youknowit, value

3、通过请求路径匹配

Path Route Predicate 接收一个匹配路径的参数来判断是否走路由。

spring:
  cloud:
    gateway:
      routes:
      - id: host_route
        uri: http://x.x.x.x:8022/
        predicates:
        - Path=/foo/{segment}

如果请求路径符合要求，则此路由将匹配，例如：/foo/1或者/foo/bar。

注意：

一个请求满足多个路由的谓词条件时，请求只会被首个成功匹配的路由转发

本次提测版本，开发使用spring-cloud-gateway来将平台业务侧引入网关，将网关作为调用PaaS的唯一入口，便于维护，同时利用网关的能力实现限流，熔断，鉴权，灰度验证等功能。第一期只接入统一前装，充分验证后后续接入其他应用。因此，本次测试的重点在路由转发功能。

三、常见测试点

spring:
  cloud:
    gateway:
      httpclient:
        connect-timeout: 5000
        response-timeout: 5s
        ssl:
          close-notify-flush-timeout-millis: 3000
          close-notify-read-timeout-millis: 0
          handshake-timeout-millis: 10000
          useInsecureTrustManager: true
      routes:
        # gis
        - id: gis_route
          predicates:
            - Path=/gis/**
          uri: http://x.x.x.x:8022/

知道了网关的基础知识和基本原理之后，对于我们如何测试它，作为一名测试人员心中已经有了大概的思路，接下来就是根据我们实际的需求去列出测试点，并进一步转换为用例去执行。从上面开发给出的配置能知道，此次开发提测主要是实现了基于路径匹配的路由转发功能，其余功能暂未引入，这样想来就简单了许多。

3.1 功能测试

常见请求正常转发

get请求正常转发：带参数与不带参数
post请求正常转发：数据格式校验，例如json，form等
delete请求正常转发：带参数与路径带参
put请求正常转发：数据格式校验，例如json，form等
patch请求正常转发：数据格式校验，例如json，form等
接口超时测试：具体的边界值测试需根据自身业务需求场景来设计case
文件上传功能：大小限制，乱码问题，格式问题
路由规则：根据项目需求的不同规则来制定，例如全量匹配，正则，先后顺序等
负载策略：轮询，权重等
超时设置

3.2 插件测试

API网关插件各个公司根据不同的需求有不同的插件，此次提测也没有涉及，所以收集整理了一些常见的通用插件，例如降级，限流，熔断，跨域，abtest插件等，提供一些测试思路。

限流

基本概念：客户端请求太多，超出了服务端的承受能力，导致服务端不可用或无法响应，耗尽服务端资源甚至是服务崩溃。解决方案：服务端对客户端进行限流，保护服务端资源。对各类请求设置最高的QPS阈值，当请求高于阈值时直接阻断。

限流插件测试思路：可以在API网关平台为对应测试接口配置限流策略。根据不同时间，使用压测工具进行阶段性的压力测试，并统计阻断接口数，具体的数值可以根据自身业务场景进行测试。

降级

基本概念：服务降级是指当服务器压力剧增的情况下，根据实际业务情况，将一些不重要的接口换种简单的方式处理，从而将服务器资源释放给当前的核心业务使其可以高效运作。

降级插件测试思路：降级策略主要看开发如何选择，有的就是让请求无法访问到后端服务，借口暂停使用，当接口配置降级插件。插件开关打开，返回API网关所配置的响应信息状态码等，接口是无法真正的请求到后端服务。

熔断

基本概念：微服务架构中，各个微服务之间相互依赖非常普遍，因此在整个链路中，有一个环节出现问题，都会造成整个上下游服务调用出现问题，服务出现宕机。也就是说，熔断就是调用方发起服务调用时，如果被调用方返回的错误率超过一定的阈值，那么后续的请求不会真正发起请求，而是调用方直接返回错误。两个关键点，判断何时熔断和何时从熔断状态恢复。

熔断插件测试思路：不同的网关有不同的熔断策略，例如针对5xx的返回，根据不同的入参控制返回，可返回2xx，4xx，5xx，当规定的时间5xx数达到阈值，服务是否开启熔断。熔断恢复测试也是一样，比如10s，允许部分请求通过，你可以继续控制请求，若这部分请求都成功，恢复熔断。具体的case设计还是要根据自身业务为准。

跨域

基本概念：跨域是指，只要协议，域名，端口有任何一个不相同，都被当作是不同的域。所谓同源策略就是指，协议，域名和端口都要相同，其中有一个不同都会产生跨域。

跨域测试思路： CORS是一种基于HTTP头的机制，该机制通过允许服务器标识除了自己以外的其他origin，这样浏览器可以访问加载这些资源。浏览器必须首先使用OPTIONS方法发起一个预检请求，从而获知服务端是否允许该垮源请求。服务器允许之后，才发起实际的HTTP请求。在预检请求的返回中，服务端也可以通知客户端，是否需要携带身份凭证。测试时，我们就可以通过是否需要携带参数，身份凭证等；各种参数组合，不同请求等方面去设计case。

3.3 容错测试

数据库宕机或者重启：新发布的路由或者插件设置等数据操作可能失败，但是不影响已生效的路由和插件
后端服务其中一台或多台宕机，重启，添加新节点等：负载策略能够自动提出不可用的服务节点和自动增加新的服务节点
redis服务宕机一台或多台：不影响已生效路由和插件
eureka挂一台或多台：不影响已生效负载策略

注意：数据库down,因为有本地缓存，验证本地缓存是否生效，所以数据库重启或者down掉，不能影响已经生效的路由和插件；后端服务down掉一台，验证eureka是否有将死掉的节点删除，若eureka并没有将死掉的节点删除，则会报错。添加新的节点，需要看请求是否有轮询；redis主要用于限流，在redis down掉限流策略失效，但是其他插件功能及路由应该不受影响；eureka是注册中心，注册中心在启动的时候会将所有资源加载本地，所以eureka挂一台或者多台，不影响已经加载到本地的。总上所述，总结来说就是API网关的所有依赖都可以down，但是gateway不可以不用。

3.4 压力测试

正常压测：压API网关的API即可
负载测试：压测时，增加和减少后端服务节点；某个服务资源打满或者超时严重，不影响其他项目正常访问
切换路由配置
项目资源测试：超过配置资源返回错误
...

注意：项目资源的作用是进行线程隔离，每个项目资源分配应该是固定的，不能抢占其他项目资源而导致其他服务不可用，进行负载测试时，增加压力，增加和减少后端服务节点，请求应该不报错。

四、总结

上述内容，是对一些网关通用功能的测试思路总结。由于本次开发提测网关版本并没有涉及过多的功能，例如还有集群的热加载，插件在集群项目与API间的运用，API的发布，下线，插件的随时切换，监控等需求，亲身实践还不够，只能提供一些思路，还需要具体结合项目的业务进行更为准确的case设计。