目录

• 我们为什么需要接口测试？
• 接口的分类 与 对应测试方法
• • 1.HTTP
  • • HTTPS
    • RESTFUL
  • 2.RPC
  • 3.WebSocket
  • 4.WebService
  • 5.FTP、SMTP
• 接口文档系统
• 接口自动化测试

我们为什么需要接口测试？

  根据测试金字塔，我们知道越往上层的测试，越慢而且成本也越高，所以我们会尽可能多的在下层进行测试。

  在做好单元测试后，我们还需要进一步检测外部系统与系统之间、内部各个子系统之间的交互情况，先在接口层级测试完全，则可以减少在下一层UI界面测试时发现问题的概率，进而减少修复成本，提升效率。

  接口测试从系统内外划分，可以分为两类：1.外部系统与本系统之间的调用；2.本系统内各个层级（如MVC三层间）的调用。其中，系统内的调用，通常在单元测试时，通过集成测试来覆盖。本篇博客主要是面向多个系统间的接口调用场景进行介绍。

接口的分类 与 对应测试方法

  要对接口做测试，首先要做的就是了解接口。（对任何事务做测试，“充份了解”，总是第一步，对我来说也是最有魅力的一步）

  若是硬件的接口，可能更直观更好理解一些，比如：手机的Type-C接口、电脑的USB3.0接口。提供接口的一方，给定了接口的规则，而去使用接口的一方则需要满足其规则，一但接口连接成功，那么调用方则可以通过接口，借助被调用方来实现其原本不具备的能力。

  在软件系统领域，接口也是类似的理念。由服务提供方开发接口，并指定调用规则。调用方需要去适配其规则，一旦顺利调用后，则可以向服务方传输数据，并获取被特定能力加工后的返回结果。通过接口，可以让调用方快速地扩展能力。

  硬件领域中的接口有的诸多问题，在软件领域也时常可以看见。比如接口规则不统一的问题，明明都是手机，安卓阵营用Type-C接口，而苹果坚持使用它自己的Lightning接口，就会造成接口的不兼容，让用户使用时不够便捷。在软件领域内，也是有各式各样的接口规则，各有利弊，百花齐放。但好在有一些协会，指定协议，并且开发者会用实际代码投票，现在市面上常见的接口（协议）已经不算太多太复杂了，下文列举并介绍我工作中常见的几个。

1.HTTP

  HTTP协议可以说是当前最流行的协议了，我目前工作中接触的80%接口是使用此协议，其具体协议内容可以查看我之前的博客：《HTTP协议》，就不再重复了。

  简单来说，HTTP是一个基于TCP/IP协议实现的应用层协议，其特点为无状态、无连接。在一次HTTP接口交互中，主要需要关注的要素有：URL、请求头、请求行、请求数据、响应码、响应行、响应数据等。

  测试HTTP接口时，可有以下几个方法：

• 1.直接使用浏览器访问url，前提是请求方式为GET，具体的入参可以直接在URL上拼接；
• 2.编写客户端代码调用，如编写一个Java工程，可以使用HttpClient、WebResource等依赖包中的功能，快捷实现调用；
• 3.使用接口调用工具，如Postman、JMete等。这些工具都是免费的，而且功能强大，推荐使用该方式。

HTTPS

  HTTPS是对HTTP的扩展，解决了HTTP协议的安全性问题，可以理解成HTTP + 加密 + 认证 + 完整性保护 = HTTPS。更简单来说：就是在HTTP上增加了SSL或TLS证书。

  最主要的就是对证书的处理，平时通过浏览器访问时，浏览器已对接CA（证书的签发机构），故证书如果已在CA认证通过，则可以直接通过浏览器访问。但如果使用自行编写程序、工具调用时，还需要处理证书的部分。

RESTFUL

  RESTFUL接口，也是对HTTP协议的扩展，但它不是对协议内容进行扩展，而是约定了一套如何使用HTTP的习惯。

  大致上来说，是结合了不同的请求方式，让同一个请求URI有了不同的功能。比如定义一个URI：http://127.0.0.1:8080/users/

• 使用GET方式调用时，表示查询所有用户
• 使用POST方式调用时，表示新增用户
• 使用PUT方式调用时，表示更新用户数据
• 使用DELETE方式调用时，表示删除用户数据

  而且入参不再以 ?userId=1 这样的形式传入，而是在URI后面继续拼接，如：http://127.0.0.1:8080/users/1

  发现有一篇文章介绍的很清楚，可以查看：《RESTful介绍和使用教程》

2.RPC

  RPC是远程过程调用（Remote Procedure Call）的缩写形式。

  比如两台服务器A、B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。而使用RPC框架，就可以实现这类远程调用。

  RPC只是一个抽象框架，具体的实现有很多，如：Hessian、RMI、Dubbo等。

  从使用上看，RPC就是将服务方的接口定义相关信息也在消费方定义一份，但消费方不需要有具体的实现。消费方调用时，直接调用接口即可，其底层会解决对象序列化、网络传输等事情，让服务方真实执行后，将结果返回给消费方。

  测试RPC接口时，需要编写RPC对应的客户端，向测试环境的服务端发送请求即可。

3.WebSocket

  WebSocket是一种在单个TCP连接上进行全双工通信的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并由RFC7936补充规范。WebSocket API也被W3C定为标准。

  WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

  WebSocket的主要特点：客户端不再需要轮询的方式去服务端查询，服务端可以直接向客户端推送消息。

  进一步了解可参考：《WebSocket协议》

  对WebSocket做测试时，需要将测试环境服务端的回调地址，改为本地测试工程的地址，在本地工程接收服务端消息以执行测试用例。

4.WebService

  WebService就是一种跨编程语言和跨操作系统平台的远程调用技术，使用HTTP协议的POST方式发送请求和接收结果，但其有着自己的一套服务暴露与调用的方式，其主要特点为以下三下技术概念：

• WSDL(Web Services Description Language), web服务描述语言，他是webservice服务端使用说明书，说明服务端接口、方法、参数和返回值，WSDL是随服务发布成功，自动生成，无需编写。
• SOAP即简单对象访问协议，他是使用http发送的XML格式的数据，它可以跨平台，跨防火墙，SOAP不是webservice的专有协议。
• UDDI 是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。如果我们要使用一种服务，但是不知道地址（wsdl等），我们就可以在UDDI中查找。

  整体下来，就很有微服务的服务注册与发现那味了。

  测试WebService接口时，也是需要编写客户端来调用服务，可以参考《WebService技术详解》

5.FTP、SMTP

  还有常见文件传输协议FTP，用来与服务器做文件交互，有了 FTP 服务器以后，客户端就可以与其建立连接，进行登录，然后进行文件传输，并实现各种操作，如上传文件/目录、下载文件/目录、列出目录信息等操作。

文件传输协议（File Transfer Protocol，FTP）是用于在网络上进行文件传输的一套标准协议，它工作在 OSI
模型的第七层， TCP 模型的第四层， 即应用层， 使用 TCP 传输而不是 UDP，
客户在和服务器建立连接前要经过一个“三次握手”的过程， 保证客户与服务器之间的连接是可靠的， 而且是面向连接， 为数据传输提供可靠保证。

  测试FTP接口时，可以使用FileZilla工具。

  SMTP是建立在FTP文件传输服务上的一种邮件服务，主要用于系统之间的邮件信息传递。调用SMTP接口时，可以使用javax.mail这个jar包即可。

接口文档系统

  接口的定义经常会变动，增加字段或修改字段含义，其文档准确性十分重要。过去往往以word文档的形式在本地保存，后来使用SVN、Git等版本管理工具，也收效甚微。如今，大家更偏向于选择搭建一个API文档系统，来更方便的维护与管理。

  通过注释、注解直接从代码工程生成接口文档的工具：Swagger、apidoc

  搭建独立系统，网页在线编辑操作：YApi、DOClever

  还有其他众多选项，此处不一一列举，有机会再进行比较。

接口自动化测试

  接口的自动化测试分两步走：

• 1.借助测试框架，开发测试用例及断言。这样每次测试时只需要手动触发跑一遍该工程即可；
• 2.接入持续集成，每次开发人员提交完代码，则会自动触发跑一遍所有测试案例，并返回测试案例执行结果。

  持续集成是接口测试低成本、高收益的根源，是接口测试的灵魂！

标签：协议,调用,HTTP,理念,接口,测试,使用
来源： https://blog.csdn.net/HhmFighting/article/details/122493064