近期一个刚入行的测试朋友希望我可以写一篇关于接口测试的文章，作为接口测试入门的参考。那作为每个测试都必须会的接口测试，是不是就是很简单呢？其实不是，我们的接口测试其实也有很多你不知道的点。本系列文章就带你系统的了解一下接口测试吧。
接口的定义
接口主要指外部系统与内部系统之间以及内部各个子系统之间的交互联系点，通过这些交互联系点，按照特殊的规则，也就是所谓的协议，进行系统间数据或资源的交换。
常见的接口分类
常见的接口可以通过协议的不同，分为http/https、webservice和其他rpc接口（诸如dubbo，thrift等）。
WebService接口是走的soap协议，通过http传输，请求报文和返回报文都是xml格式的，测试的时候需要通过工具（例如soapUI）或者自己代码实现进行调用。
Http/https接口是走http/https协议，通过路径来区分调用的方法，目前一般是restful风格，请求报文和返回报文一般都是json格式，但是为了传输效率和安全性的考虑，也可以走protobuffer(pb)的格式。其中get和post是最常用的两种请求方式。
Dubbo接口是阿里巴巴开源的致力于提供高性能和透明化的RPC远程服务调用方案以及SOA服务治理方案。dubbo框架告别了传统的web service的服务模式，改用provider和consumer模式进行服务。Dubbo接口采用全spring配置，基于tcp传输。常用的测试方法需要自己代码实现。
除此之外，还需要考虑走jms协议的消息队列。常见的消息队列有ActiveMq、RabbitMq、RocketMq和kafka等。通常通过消息队列实现接口物理和逻辑的解构，将同步接口变更为异步接口，常用的消息类型有topic和queue, 异步接口的测试可以通过代码及相关消息队列控制台进行。
接口测试的定义
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。简答的说就是通过URL向服务器或者其他方法等，传输指定的数据，然后看看它们返回的是不是我们预期的结果。
接口测试的必要性
- 从软件实现的角度看，方法构成了模块，模块构成了系统。与之相对应的分别是单元测试、接口测试和系统测试。很明显，接口测试相较于系统，更偏底层，从缺陷修复成本看，越底层发现问题，时效性越高。
- 目前软件开发提倡前后端架构分离，趋势也越来越趋向精细化，前端重展示交互轻逻辑，后台重逻辑，从逻辑完整性角度出发，有必要对后端进行接口测试。
- 从系统安全性考虑，前端传参不可信，诸如中间人攻击等可以篡改前端请求参数，因此需要独立对后端接口进行测试。
- 分布式、微服务导致系统复杂度不断上升，纯前端覆盖会造成测试成本的上升和测试效率的下降。
- 诸如限流、秒杀等场景，天然需要后台发起。
如何进行接口测试
测试接口时主要是通过工具或代码模拟请求或服务的调用。常用的工具有postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
接口功能测试的考虑点
接口测试可以从功能、性能、安全、兼容性、资损、发布和回退等多个维度入手考虑。
让我们先从功能角度入手吧。
接口功能测试首先需要确认接口的类型，是新接口还是已有接口变更。
新接口首先需要考虑接口的实际功能点。除了关注自身功能外，还需要关注在整个业务链路场景中的上下游交互，尤其需要注意整个业务链路的调用入口是否唯一，不能有遗漏；其次需要从接口实现上入手，是否是完全全新调用链路，不涉及已有公共模块的变更，如果有，需要评估对已有接口功能的影响；最后需要从数据层面出发，是否会导致持久数据存储形式的变更(诸如数据库存量表定义的变更等)，同时还需要评估是否会改变存量数据，进而影响线上已有功能点。
那已有接口变更呢？同样需要从上述3点入手，这边就不一一赘述了。
接口功能测试其次需要考虑接口的交互范围。如同接口定义所述的，接口调用可以区分为内部调用和外部调用。对于不同的调用范围，需要关注哪些点呢？
内部调用：首先需要确定上下游的排期是否一致，毕竟随着微服务和服务网络的兴起，业务链路越来越长，尤其是金融系统，任何接口都是整个系统链路的一环，层层依赖，有了统一的排期后，才可能统一发起联调测试。当然，如果不能统一排期，那至少需要上下游清晰的接口定义文档，并依据它生成相关的mock数据，当整条链路ready后，再发起统一的联调测试。
外部调用：如果需要调用外部第三方系统，很不幸，整个系统测试的复杂度上升了。这个时候需要提前和外部人员确定统一的接口定义文档，功能上线日期，对接的测试环境以及对接的外部测试人员。如果外部测试环境不存在或者上线日期不一致呢？只能走mock路线了。这个时候需要请外部人员评估mock数据的合理性。最后尤为重要的是，需要确认外部排期是否支持产线验证，毕竟说一千道一万，一切还需要在产线环境真实测试验证通过才能放心。
接下来需要借助通用方法对接口功能进行测试了。那有哪些通用方法呢？
接口参数组合。可以采用正交分析结合业务功能梳理的方法进行必填和非必填参数的各种组合，其中全部参数赋值是万万不能缺少的。
关键路径依赖。首先区分关键路径和非关键路径，诸如支付系统，显然支付链路是重中之重，这个是第一优先级需要保证的。路径梳理清楚后，那是否存在关键路径调用非关键路径的场景呢，如果有，是否是采用同步调用的方式，答案如果是，显然这是不可接受的，关键路径的正常运行不能依赖于非关键路径，这种情况下要么双方逻辑解耦，要么变更调用方式为异步。
资源依赖。首先区分可靠资源和非可靠资源，诸如数据库就是可靠资源，nas文件就是不可靠资源，是否存在可靠资源依赖非可靠资源，如果存在需要进行切除。
边界分析测试，一方面需要从业务规则的边界入手，比如订单的状态机，另一方面需要从入参出参的边界入手，诸如参数有无或为null、参数顺序、个数和类型、类型的边界和特殊字符等。
异常场景，是否做了幂等控制(防止重复提交)，是否有接口超时，接口异常应对(直接抛出异常，还是异常包装，或者进行降级处理等)，环境异常应对(是否有故障应对，是直接宕机还是自动切换等)，大数据量是否处理适当，是否并发安全，是否支持事务机制等。
除此之外，功能方面都结束了吗？
答案显而易见，熟悉互联网架构演变的朋友都知晓现在的互联网架构体系一般会按照微服务的方式进行水平拆分，诸如网关层(接入层)、业务层、业务核心层、数据访问层和持久层等。对于每层的职责，基本有个通用的定义，诸如网关接入层，通用职责无非是接口鉴权、数据格式转换、下游接口组装、限流、熔断、敏感字段过滤和异常封装等，显而易见，涉及网关接入层的接口，需要考虑这部分通用职责，这个是隐性定义，比如敏感字段过滤功能，显然需要天然具有类色情字样的过滤，当然这能力可以通过框架提供。
以上是接口功能测试的通用考虑点，希望可以给大家带来帮助。更多精彩，会在后面的文章里给大家一一呈现，敬请期待。
ps：如果大家有其他感兴趣的话题，也可以进群交流哦~
其他文章可以关注微信公众号测试架构师养成记,还有价值999的资料可以领哦~
