接口测试中请求URL管理的正确姿势

一. 概述

      接口测试中，必不可少的第一个要素就是请求URL。一般来说，一个常规的请求URL分为以下四个部分: 请求协议，请求地址(域名:端口)，请求路由(或资源路径)，查询参数。如下图所示：

      而合格的接口测试用例，应当可以在多个环境去执行，那多个环境下一个接口的请求会哪些不同呢？

      首先，先说说哪些是不变的。请求协议必然是不变的，最多是否需要SSL验证，也就是http和https的不同，但一般来说对于代码发送请求，可以自适应，因此可以忽略，只有特定情况才需要做一些改变，如忽略证书校验等配置。

      其次，请求路由在多个环境下也不会改变，当然会有一些动态路由参数，但是这就与请求数据相关，通常都是动态关联。查询参数也是如此，查询参数名一般不会变，但是参数值一般是需要动态关联来生成。这二者都是通过请求数据的设计来解决，不与环境配置挂钩，与业务数据挂钩。

      那最后与环境挂钩的自然是请求地址，即ip加端口或者说是域名。不同的环境请求地址自然是不同的，如果我们希望接口测试用例在不同环境去执行，第一件事就要解决接口请求地址的动态获取。

二. 实现

      那如何实现接口请求地址的动态获取呢？如果所有接口测试用例只是测试单个服务的话，当然很简单，只需要每个环境下接口自动加上环境对应的请求地址即可，一些简单的测试平台或者测试框架也确实是这样实现的。

      但事实上肯定不会如此简单，现在的服务架构通常服务端都不会是单一的服务，尤其是微服务架构中，后端可能会有多个子服务。线上环境可能还会只有一个域名然后来代理所有的子服务，但测试环境一般都会存在多个请求地址。那将属于不同服务的接口动态匹配自己服务所属的域名或ip地址就相对麻烦一些。

      首先，常规做法是根据路由匹配。不同的微服务其路由参数前一两个参数必然是和业务挂钩的命名，因此我们可以参考nginx反向代理的配置方式，当遇到路由是以A开头的接口时，就自动将A对应的请求地址加在接口请求中，遇到BCD..则同理。这样做的优势是比较灵活的，但是有一种情况无法解决。

      在作者过往工作中，遇到这种情况，两个服务A和B，在环境1中，他们是部署在一起的，其请求路由前面也是一样，请求地址自然也是一样的。但是在环境2中，他们却是分开部署的，请求路由还是一样，但请求地址自然是不一样的。遇到这种情况，再套用路由匹配，针对环境2，就不是很好使了。虽然这种特殊情况是因为不规范导致的，但在现实中，这类情况并不少见。

      那如何解决这类问题呢，这时候我们就需要引入一个服务标识的概念，一个接口，无论在任何一个环境，他一定是属于系统架构中的某个子服务的。那么，如果一个被测系统有多个子服务，那我们就给每个子服务配置一个对应的标识，用来区分其服务的IP端口或域名，我称之为域名标识。而我们在维护接口文档时，对每个接口都加上所属服务的字段，即加上域名标识的记号，如此，不仅可以清晰知道被测接口所属的服务，而且不管不同环境怎么部署，通过标识一定可以找到接口对应的请求地址。

      当然，这种解决办法有一个缺点，当系统架构比较复杂时，如果有n个微服务，那就必须每个环境都配置n个域名标识对应的域名，即便在一些环境中这些标识对应的域名是一样的。

      因此，全局考虑，我们一般采用的请求URL管理的方式是路由匹配和标识匹配的结合。即域名标识字段我们在接口文档中还是正常维护，当遇到请求地址混乱的环境我们用域名标识来匹配，当遇到请求地址相对统一的环境我们用路由来匹配，如此就可以相对简单的完成多服务架构下的请求URL管理。