前言
大家好,我是洋子,最近工作有些繁忙,好久没写文章啦,趁着周末赶紧补一篇
接口是什么
在网上查询编程相关资料,我们或多或少听过API (Application Programming Interface,应用程序编程接口)这个词,简称接口
当我在手机上打开某个APP应用,点击应用里的某个按钮,一般就会调用某个接口
,向服务端发起HTTP请求
,接口返回数据
后,我们就能在应用里看到相应结果
举个例子,打开某个查询天气网站,点击“北京”字样的按钮,通过打开浏览器调试工具可以抓包看到,调用了province/beijing/30
接口去获取北京最近30天的天气,最后返回了HTML,浏览器渲染后我们就能看到最后的结果
所以说一个用户通过手机,PC浏览器等客户端进行打开APP、点击按钮等操作,就会调用外部接口,并通过API网关或者Nginx转发,然后请求会到达服务端的集群当中,现在主流的服务端架构大多采用了微服务,在服务与服务之间,也存在内部接口调用
接口协议的类型
基于 HTTP
协议的接口是我们日常测试工作当中接触最多的接口类型,除此之外,还有其他协议的接口,如常见的WebService
、WebSocket
、Dubbo
、MQTT
等最好也有所了解
可能有同学觉得协议理解起来很困难,所以在讲解协议以前,希望大家心中有个概念,协议没有这么可怕
所谓协议就是一组规则
,基于这组规则进行各种操作,就好比马路上有红绿灯,红灯停绿灯行就是一种规则,就可以理解成一种协议。没有协议这个世界就会乱套,在计算机世界里面也一样,有了协议才会让这个世界变得有序,所以理解各种计算机网络通信协议非常有必要,而做软件测试也是,只有理解清楚协议我们才能更好的进行测试
HTTP 协议以及 Restful API
HTTP(Hyper Text Transfer Protocol)是超文本传输协议的缩写,是用于从 WWW 服务器传输超文本到本地浏览器的传输协议。HTTP 是一个应用层协议,由请求和响应构成
对于HTTP请求,由请求行、请求头、请求体 三部分构成 对于HTTP响应,由响应行(状态行)、响应头、响应体 三部分构成
HTTP 目前常见的有8种请求方式,如下图
Restful 风格的API,本质也是基于HTTP协议,只是它符合Restful风格,这是一种设计风格,该风格有2个特点
- 每一个URI代表1种资源;
- 客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源;
通俗点理解就是,URI我描述的是一个资源,这个请求基于HTTP,使用GET、POST、PUT、DELETE4个分别表示增删改查4种操作方式服务端资源进行操作
例如我现在要实现一个博客系统的接口,以下为符合以及不符合Restful 风格的两种情况
Web Service
Web Service
是一种跨编程语言、 跨操作系统平台的远程调用技术,主要用来实现不同系统之间的通信
Web Service
通过SOAP
(Simple Object Access Protocol,简单对象访问协议) 在 Web上提供服务,提供的Web服务使用WSDL
(Web Services Description Language,Web服务描述语言) 文件进行描述说明,并通过UDDI
(Universal Description, Discovery and Integration,通用描述、发现与集成服务)进行注册
是不是不好理解,先看看Web Service的交互逻辑
- Web Service服务
提供方
将自己的Web服务通过SOAP动态地发布到UDDI注册中心,其中是以WSDL文件来进行描述 - Web Service服务
消费方
向UDDI注册中心通过SOAP请求WSDL文件 - UDDI返回WSDL文件给服务消费方,服务消费方解析解析服务提供方提供的方法
- 服务消费方根据解析好的WSDL文件,生成SOAP消息,发送给 Web 服务提供者,以实现 Web 服务的调用
- 提供者按 SOAP 消息执行相应的 Web 服务,并将服务结果返回给 Web 服务请求者
Web Service交互逻辑总结为一句话:Web Service遵循SOAP协议通过XML封装数据,然后由HTTP协议来传输数据
看完交互逻辑,我们再来理解Web Service的三要素,分别是:SOAP
、UDDI
、WSDL
SOAP协议可以理解成HTTP XML
Web Service通过HTTP协议发送请求和接收结果时,发送的请求内容和结果内容都采用XML格式封装,并增加了一些特定的HTTP消息头,以说明HTTP消息的内容格式,这些特定的HTTP消息头和XML内容格式就是SOAP协议里面规定的
那WSDL文件是什么呢,WSDL就像是一个说明书,说明Web Service提供方有什么服务可以对外调用,用于描述Web Service提供的方法、参数和返回值。就好比我们去商店买东西,要知道商店里面有什么卖的,然后再来购买,商家的做法就是张贴广告海报,WSDL就类似于海报
WSDL文件保存在Web服务器上,通过一个URL地址就可以访问到它。消费方要调用一个Web Service服务之前,要知道该服务的WSDL文件的地址。Web Service服务提供方可以通过两种方式来暴露它的WSDL文件地址:1.注册到UDDI服务器,以便被人查找;2.直接告诉给客户端调用者
UDDI 是一种目录服务,企业可以使用它对 Web services 进行注册和搜索。UDDI,英文为 "Universal Description, Discovery and Integration",可译为“通用描述、发现与集成服务”。通过UDDI,企业可以根据自己的需要动态查找并使用Web服务,也可以将自己的Web服务动态地发布到UDDI注册中心,供其他用户使用
UDDI 由 WSDL 来进行描述并且存在映射关系,用户可以在UDDI注册表(registry)查找服务,取得服务的WSDL描述,然后通过SOAP来调用服务
WSDL和UDDI的区别就是,WSDL用来描述服务,UDDI用来注册和查找服务
WebSocket
谈到WebSocket,你可能会想到Socket,但两者区别较大
Socket即套接字,是在应用层和传输层之间的一个抽象层,它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用以实现进程在网络中通信
WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议,位于OSI模型的应用层
WebSocket允许服务端主动向客户端推送数据。在 WebSocket 中,浏览器和服务器只需要利用HTTP协议完成一次握手,两者之间就直接可以创建持久性的连接(长连接),并进行双向数据传输。与HTTP短连接、HTTP 长连接对比如下图
与HTTP协议相比,由于WebSocket协议是全双工的,所以服务器可以随时主动给客户端下发数据。相对于 HTTP 请求需要等待客户端发起请求服务端才能响应
另外 Websocket 是一种有状态的协议,通信就可以省略部分状态信息。而HTTP是无状态的协议,即服务器不保留与客户交易时的任何状态,也就是说,上一次的请求对这次的请求没有任何影响,服务端也不会对客户端上一次的请求进行任何记录处理,所以HTTP请求可能需要在每个请求都在Cookie携带状态信息(如身份认证等)
Dubbo
Apache Dubbo (incubating) 是一款高性能、轻量级的开源 Java RPC 框架, 它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及 服务自动注册和发现
官网:http://dubbo.apache.org/
Dubbo 工作原理
- 暴露服务的服务提供方(Provider),服务提供者在启动时, 向注册中心(Registry)注册自己提供的服务
- 调用远程服务的服务消费方(Consumer),服务消费者在启动时,向注册中心订阅(subscribe)自己所需的服务,注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者
- 服务消费者从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用
- 最后服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心 (Monitor)
Dubbo 协议报文
为了提高效率,研发团队为 Dubbo 框架实现了一套数据交互协议,称为Dubbo协议,Dubbo协议是建立在TCP之上的一种应用层协议,它的协议报文由header和body两部分组成
Dubbo 接口
利用Dubbo协议传输数据的接口就是 Dubbo 接口,其对应的就是一个个 Dubbo 服务中的方法
通过上面的Dubbo架构图我们知道,Dubbo 接口的使用方式就是通过消费者“消费”生产者提供的一个个服务,这也是我们测试 Dubbo 基本原理,即测试端充当消费者, 测试对象是生产者提供的服务方法
实现测试端的方法有3种,第一种是通过编程语言实现一个消费者,第二种使用Dubbo提供的命令行工具,第三种是使用JMeter等第三方工具
MQTT
刚接触MQTT时,大家应该会疑惑它跟MQ是什么关系,先分别解释一下
MQ(Message Queue)中文名叫消息队列。先不管消息(Message)这个词,先看看队列(Queue),队列就是一种先进先出
的数据结构,所以消息队列可以简单理解为:把要传输的数据放在队列中
MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的“轻量级”通讯协议,该协议构建于TCP/IP协议上,属于应用层协议,由IBM在1999年发布
所以MQ和MQTT有两个字母相同,但差别很大,前者是数据结构,后者为通信协议
MQTT最大优点在于,用极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务
作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用
MQTT是一个基于客户端-服务器的消息发布/订阅传输协议,MQTT使用的发布/订阅消息模式,它提供了一对多的消息分发机制,从而实现与应用程序的解耦
这是一种消息传递模式,消息不是直接从发送器发送到接收器(即点对点),而是由MQTT 服务器(或称为 MQTT Broker
)分发的
如果客户端发布到 MQTT 服务器,则客户端将是发送者,MQTT 服务器将是接收者。当MQTT服务器向客户端发布消息时,服务器是发送者,客户端是接收者
MQTT 服务器是发布-订阅架构的核心,服务器分发消息,因此必须是发布者,但绝不是订阅者。客户端可以发布消息(发送方)、订阅消息(接收方)或两者兼而有之
MQTT服务质量
QoS(服务质量,Quality of Service levels)是 MQTT 的一个重要特性。当我们使用 TCP/IP 时,连接已经在一定程度上受到保护。但是在无线网络中,中断和干扰很频繁,MQTT 在这里帮助避免信息丢失及其服务质量水平,制定了服务质量级别,这些级别在发布时使用
MQTT 协议支持三种消息服务质量,分别是QoS 0
,QoS 1
,QoS 2
- QoS 0:发送者只发送一次消息,不进行重试,MQTT Broker 不会返回确认消息。在 Qos0 情况下,Broker 可能没有接受到消息
- QoS 1:发送者最少发送一次消息,确保消息到达 Broker,Broker 需要返回确认消息 PUBACK。在 Qos1 情况下,Broker 可能接受到重复消息
- QoS 2:使用两阶段确认来保证消息的不丢失和不重复。在 Qos2 情况 下,Broker 肯定会收到消息,且只收到一次
MQTT 数据包格式
整体MQTT的消息格式分为三大部分,分别是固定头
、可变头
、消息体
- 固定头(Fixed header),存在于所有MQTT数据包中,表示数据包类型及数据包的分组类标识;
- 可变头(Variable header),存在于部分MQTT数据包中,数据包类型决定了可变头是否存在及其具体内容
- 消息体(Payload),存在于部分MQTT数据包中,表示客户端收到的具体内容
MQTT固定头的结构如下
结束语
本文为大家介绍了HTTP
、WebService
、WebSocket
、Dubbo协议
、MQTT
这5种常见的协议,这些协议构成的接口常常是我们的测试对象
那么我们怎么对这些协议构成的接口进行测试呢?
由于目前HTTP协议使用得最广泛,下篇文章给大家详解基于HTTP协议的接口测试方法,包括接口用例设计、测试工具以及测试框架使用