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

本文来自我的一名学员分享

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

一、什么是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。

当然内置的匹配规则还有很多，通过请求参数，请求方式，请求IP地址等去匹配，也可以组合使用。

注意：

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

本次提测版本，开发使用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设计。