接口测试主要分HTTP和RPC两类,RPC类型里面以Dubbo较为知名。
互联网微服务架构,两种接口都需要做接口测试的,不管是业务测试还是回归测试;


为什么要做接口测试?

1.比如‘下单’和‘订单查询’,分别在不同的机器不同的系统上,某种原因比如环境不行、包没打好,可能下单的系统就不可用,但是‘订单查询’又得依赖人家下单的系统,这时候就可以mock下订单查询的接口的入参,去做订单查询的测试,不然就得等人家环境;

2.有的公司会区分前后端,以及前端测试和后端测试,这里的后端指的是后端的接口(一般都是业务逻辑上的,比如前端在首次进入beike时会自动开通beike,这里的开通其实是点击beike时调了后端的开通beike的接口,发奖、查询发奖结果、问询:有哪些可用的券、定价:选中某个券的利息),前端指的手机的app,app在操作时会调用后端的接口(当然前端一般也有自己的接口什么的),所以作为后端测试,就要做接口测试;albb

3.还有一种接口是提供给别人用的,比如我们是一个预定商品的系统:商品没货了可以预定,这个系统不仅可以我们自己做商品无货预定,还可以把商品无货预定的接口给到客户,让客户用自己的系统调我们的无货预定的接口去预定,这样,这个接口就需要测试;jd

 

接口测试(不管http还是rpc流程都是一样的):

  1、首先本次项目都涉及哪些接口

  2、每个接口的入参、出参、依赖(jar)应该是什么、是什么样子

  3、每个接口调通

  4、按业务流程、业务逻辑依次执行接口,与预期作比较    如:创建测试账号-->推荐权益-->查询权益推荐的结果-->核销权益

 

 

传说中的三板斧:

  可灰度、可监控、可回滚

 

Dubbo:Java栈的互联网公司比如阿里、美团、58、滴滴、京东等等都是差不多的服务端架构,所以这些公司,两类接口测试也是必不可少的工作部分;
Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求,并且本质上是个服务调用的东东,说白了就是个远程服务调用的分布式框架(告别Web Service模式中的WSdl,以服务者与消费者的方式在dubbo上注册)

 

dubbo发展史

      博主第一次接触dubbo的时候,那还是2015年的时候,那时候很多公司都在基于阿里巴巴的dubbo封装,各大公司基于 dubbo的开源使用,首当其冲的是有:京东jsf、新浪motan 、 蚂蚁金服 sofa 、当当的dubboX等。先给大家普及下dubbo的历史吧。dubbo在2012年由阿里巴巴开源,那时候由梁飞(花名虚极)等人一起负责研发。后由于阿里策略变化,2014年10月Dubbo停止维护,随后部分互联网公司公开了自行维护的Dubbo版本,比较著名的如当当DubboX,新浪Motan等。经过三年的沉寂,在2017年9月,阿里宣布重启Dubbo项目,并决策在未来对开源进行长期持续的投入。2018.2月,阿里将Dubbo捐献给Apache基金会,Dubbo成为Apache顶级孵化项目之一。也由原来的alibba.dubbo变成了apache.dubbo。

京东的JSF相比于Dubbo而言多了一个注册中心寻址服务,为什么会这样呢?主要是因为2015年双十一时候注册中心挂了以后,后端容器服务重启以后之前缓存的服务地址列表丢失,服务无法调用。而且以Zookeeper为注册中心的Dubbo,会受制于Zookeeper的缺点:在Zookeeper主节点挂了以后,新的主节点被选出来之前,Zookeeper集群不可用。而且Zookeeper没有动态水平扩展的能力。由此可见注册中心是瓶颈所以京东在这一块做了改进,我觉得就是抛弃Zookeeper集群,自己取长补短的去实现一个服务治理。