搬运工让你分分钟了解Web接口测试

百度说：接口泛指实体把自己提供给外界的一种抽象化物（可以为另一实体），用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式

上面这句有点抽象，网上的资料也是一大把，来自某个大佬的通俗解释：

从程序方面来说，接口习惯别叫做API（application programming interface），可大致分为程序接口和协议接口两类，见文章https://www.cnblogs.com/fanjq/p/7835438.html，

发展至今包括：
①、操作系统接口
②、web接口
③、应用程序接口
④、数据库接口
...

它们可能本质差别不大，姑且这么分个类，我们这里着重讲Web接口

接口测试是测试系统组件间接口的一种测试；接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点；测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试也是一种完整的测试体系，也分为接口功能测试、接口性能测试、接口稳定性测试、接口安全性测试。类比功能测试，有个通俗的解释：接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性要求

借鉴上面的文章，常见的web接口：

webService接口：
是用soap协议包装后用http运输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等。
http api接口：
直接用http协议运输，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等。

web应用中，客服端需要与服务端通信，也就是前端和后端通信，都是通过接口交互；根据是否是外部接口，web接口测试可分两类：服务端接口测试和外部接口测试。

在软件开发生命周期中发現缺陷越早，那么修正缺陷的代价就越小，所以应更早的介入测试，而接口测试就是一种及早介入的方式。

为什么做了功能测试还要做接口测试，上面两篇文章说得很清楚：

当然由于接口测试的特殊性，需要依赖一些测试工具或代码模拟http请求的发送和接收，对测试人员的要求更高。

接口测试也属于功能测试，每个公司的流程或侧重点可能不同。

第一种轻量级测试方案

1、分析出测试需求，并拿到开发提供的接口说明文档；

2、从接口说明文档中整理出接口测试案例，里面要包括详细的入参和出参数据以及明确的格式和检查点；

3、和开发一起对接口测试案例进行评审；

4、结合开发库，准备接口测试案例中的入参和出参数据，整理成测试用例；

5、执行测试用例，反馈接口测试结果。

第二种类似功能测试流程

（接口文档 —> 接口测试计划 —> 接口测试用例 —> 接口测试执行 —> 接口测试报告）：

1、接口文档

类似于需求文档，由项目组长制定相关接口规范，开发人员一起更改维护，其中应该包括接口说明、方法、uri（请求地址，url是uri的子集）、请求参数、返回参数。

2、接口测试计划

类似于测试计划，5w原则，包括测试目的，测试方案，测试范围，测试资源安排，进度安排，风险控制等。

3、接口测试用例

测试用例设计，根据接口文档，主要对请求参数进行分析，包括通过性测试用例，多业务场景测试用例等。

4、接口测试执行

执行接口测试用例，就是对接口进行请求，验证返回参数，可能还需要准备测试数据。

5、接口测试报告

及时反馈测试结果，如阻塞的测试，未通过的测试等。

做接口测试后可以顺便集成接口自动化，那么项目适合开展自动化吗？

接口自动化测试适用场景：

开发自测，冒烟测试：
一个新的自动化接口测试案例开发完成后，直接发给接口对应的开发，安排在开发本地环境执行，一旦开发确认完成接口开发，就开始执行接口测试案例，基本上可以实时拿到测试结果，方便开发快速做出判断。
回归测试：
开发本地测试通过后，或整个需求手工测试通过后，把自动化的接口测试案例做分类整理，挑选出需要纳入到回归测试中的案例，提高测试效率。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：