接口测试小白必看

　一、接口测试的误区

负责一个电商平台的接口测试工作以及开始着手去搭建一个接口自动化测试平台。
　　因为该同事以前是做移动端的测试的，从来没有听说过，他有做接口测试的经验。于是我出于好奇，就问了一下：他目前是如何去进行接口测试的。
　　他对这个问题可能没有做出充足的准备，也有可能他因为之前没有接口测试的相关经验，他给到我的回答，其实和网上随便搜出来的答案差不多：
　　通过 Postman / Jmeter / 代码调用 等测试工具，来模拟网络请求，
　　1. 校验接口传参是否合理（少传 / 漏传 / 多传 / 边界值 / 参数类型校验等等）。
　　2. 测试响应结果是否会返回约定的数据格式，有没有字段没有下发或下发不正确。
　　3. 验证接口是否有安全性问题，是否鉴权。

对于这个回答，我并不感到意外，网上大多数的回复也都是这么说的。
　　但是对于一个纯服务端的测试而言，仅仅是调调参数，真的就能完成接口测试了么？
　　NO，这只是接口测试的冰山一角，接口测试远没有你想象中的那么简单！
　　那么，接口测试主要需要测试哪些方面呢？
　　按照惯例，先上老（nao）图：

二、接口测试的实战步骤
　　接下来我们以电商平台的搜索接口来做案例，一步步给大家讲解接口测试的步骤。
　　第一步：梳理上下游调用链
　　1）为什么要梳理上下游调用链？
　　目前互联网产品的后端服务，基本上都是分布式部署的，一个接口可能会调用其他接口，也有可能被其他接口调用，接口与接口之间，具有千丝万缕的依赖关系。
　　如果我们的把自己负责的接口纯粹地当成黑盒去测试，不可谓知己；
　　如果我们只熟悉自己的接口，不清楚与其他接口的依赖关系，不可谓知彼；
　　所谓知己知彼，方能百战不殆。
　　所以，梳理上下游调用链是首先要做的工作。

我们在测试的时候，很可能只会片面的去关注搜索网关开放给前端调用的接口，
　　但只要把整个调用链路和流程图画出来，我们会发现其实搜索网关依赖好多的服务。
　　比如：
　　搜索网关需要调用价签系统，去获取商品促销价格；
　　搜索网关需要调用推荐系统，去获取搜索场景下的推荐的商品；
　　搜索网关需要去调用商品系统，去获取实时的商品信息；
　　搜索网关需要去调用搜索服务，去ES召回商品、获取搜索排序信息等等。
　　前端在搜索框搜索一个关键词，对搜索网关发起一个HTTP请求，背后其实经过了很多道工序去处理这个请求。
　　如果只是单独的调调参数，就希望把接口测试做好，显然是不可能的。（开发自己都能调（tiao）接口参数，还要测试做什么？）
　　接口背后的业务逻辑是否正确处理、后端依赖的服务是否健壮、接口性能是否达标。

　2）怎么梳理上下游调用链？
　　1、看项目wiki、产品文档和开发文档。
　　2、看开发写的代码，阅读代码，当然是首选：JetBrains全家桶啦（Java用IDEA；Python用Pycharm）

3、梳理出上下游调用关系后，手绘一份系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认。
　　第二步：编写接口测试用例
　　接口测试用例和平常的测试用例差不多，没有太多的要求限制。因为测试工作中很多时候不是专门测接口的，所以这个步骤不一定要做。
　　但是你心里要清楚你要测的点，如果你是第一次做接口测试，臻叔还是建议自己去写一份接口测试用例，并且好好归档。
　　如果说要做接口自动化，接口测试用例也是很有帮助的。
　　这里给出一个接口测试用例的案例：

　第三步：测试接口文档&调试接口
　　接口文档在软件项目开发过程中非常重要，接口文档是连接前端开发和后端开发的一座桥梁。
　　在项目开发之初，前端开发和后端开发会共同去约定一套接口规范，然后由后端开发去编写接口文档，然后前后端就可以按照约定去进行协同开发。
　　接口文档的管理和编辑有多种方式：
　　有的团队习惯用wiki或者在线文档去编写接口文档；
　　有的团队喜欢用专业的接口文档工具，比如：Swagger、Yapi等去生成接口文档。

测试接口文档可以参考以下测试点：
　　确保开发必须提供接口文档。如果开发没有写接口文档的习惯，应push开发去写接口文档。
　　检查接口文档的格式内容等是否完备，包括：URL、请求方法、Header、入参、返回值、示例Demo等。
　　检查接口设计是否符合公司规范。包括接口命名、接口格式、字段命名、字段类型、响应状态码、接口容错、字段是否冗余、接口是否鉴权、是否做版本区分等等。
　　当后端开发完成接口的开发工作时，我们就可以提前开始对接口进行初步测试了。
　　步骤如下：
　　把后端代码部署到测试环境上。
　　通过postman或swagger去对接口文档提到的接口进行测试。

第四步：前端接口测试&Mock数据（接口层面的测试）
　　前面的步骤只是利用测试工具去发起网络请求，来模拟接口调用。
　　但在真实的场景下，搜索网关的接口实际上是提供给 APP/WEB/小程序 进行调用的。
　　我们同样也需要关注前端调用过程是否是正常的。（需要等待前端开发完毕，才能介入测试）
　　可以利用Charles来对前端发送的请求进行抓包：
　　1.验证前端调用接口的传参是否正确；
　　2.验证后端的接口响应是否符合预期；
　　3.前端拿到数据之后，交互和UI展示是否正确。
　　当有些数据有多种状态，并且数据比较难以构造时，我们可以通过Mock数据去进行测试。
　　常见的Mock数据的方式有：
　　1.用 Fiddler 或者 Charles 去篡改请求和响应。
　　2.如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。
　　3.数据库中去修改数据。
　　4.用专业的Mock工具去构造数据，如：EasyMock、TestableMock、Mockjs等。
　　比较快速的方式，当然是直接用Charles去模拟。

如果说只是改少量的响应数据，比如说：改变一个标签下发的文案，看看前端的展示。这种情形就非常适合用 Charles 去模拟数据。
　　但是 Charles 模拟也有一个弊病，那就是假如遇到接口下发的数据结构比较复杂，涉及到多个字段的变更，用 Charles 去 Mock 数据就比较麻烦。
　　第五步：后端接口测试&业务逻辑覆盖（看日志、看代码）
　　看日志
　　业务测试过程中，我们需要时刻关注后端日志状态。
　　有时候接口响应数据是正常的，但是后端日志可能正在报错。
　　比如：
　　搜索结果页返回空数组是常见现象，一般代表搜索关键词没有召回任何商品。
　　但是臻叔有一次测试过程中，发现同一个关键词，在同样的条件下，有时召回0个商品，有时召回多个商品。
　　一开始觉得很蹊跷，后来一查看后端日志，才发现召回商品的时候超时了。
　　看代码
　　推荐大家在做接口测试的时候，一定要去阅读开发的源码。
　　阅读源码可以对业务逻辑实现了解更加深入。
　　另外，有些条件，在手工测试中很难模拟出来，但是通过阅读源码，甚至单元测试，就能够轻松的模拟出来。
　　阅读源码还有个好处就是，对开发起到一个约束作用，因为代码是公开的，如果从代码层面发现很多Bug的话，开发的面子也过不去。
　　关于阅读源码，我们可以把代码拉到本地，用IDEA等工具去查看源码。
　　如果代码量很大怎么办？
　　告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这样就能知道他改了哪些地方。