【测试笔记】接口测试

什么是接口

接口：有特定输入和特定输出的一套逻辑处理单元

特点：它不知道自身的内部实现逻辑，（叫它为 接口的黑盒处理逻辑）
由于服务对象不同，接口分为：

• 内部接口 ： 一种系统或服务器的内部接口
• 外部依赖接口

内部接口

系统内部调用的接口
实际场景描述： 购物流程中，从登录系统，到加入购物车，再到支付订单，这一整个过程中，都是通过系统内部接口来完成的。

外部接口

外部系统对外提供的接口
实际场景描述：在点击购物后点击付款时，页面会跳转到支付系统，等到完成支付之后，再跳回订单页，这个过程当中就涉及了，系统对外的接口，还有付款工程里面的支付接口、配送过程中的物流接口等等。

接口：一种契约

在开发前期，我们约定好接口会接受什么数据，在处理完成之后，又会返回什么样的数据。

接口测试

接口测试，就是验证内部处理逻辑是否正确，我们既要保证单接口的正确性，也要保证业务逻辑正确性：

• 输入正确测试数据：验证接口正常处理后返回的结果是否正确（数据接口、数据内容）
• 输入异常测试数据：验证接口能否正常处理异常数据并返回特定题是，是否健壮、是否合理……

正向测试

正确接收合法的request && 正确拒绝非法的request —— 均属于正向测试

反向测试

测试流程的反向测试，举个例子就是支付测试是正向，那么退款就是反向

为什么要接口测试？

项目中，接口测试直接测试后端服务，更加接近服务器上运行的代码程序，也能发现更加广泛的bug，越接近底层的bug，影响的用户范围就越广
随着中台化、服务化的发展，一套服务支持多种终端，例如 Android 端、iOS 端、Web 端等，这些服务都是由一套后端服务支持的。

如果在Web端发现一个界面问题，影响的只是Web端用户，倘若一个服务宕掉，影响的就不止是Web端，还有Android 端、iOS 端

接口测试更容易和其他自动化系统相结合；
相对于界面测试，接口测试可以更早开始，也可以测试一些界面测试无法测试的范围，因此它使测试更早的投入这句话变成现实；
接口测试还可以保障系统的鲁棒性，使得被测系统更健壮。

面试回答：接口测试是什么？接口测试优势/优点/覆盖面为什么广？

首先接口测试，就是模拟客户端的调用接口，通过接口通信的内容和状态，检测被测接口的正确性和容错性，等等。
所以他的优势有以下几个：
1、测试直接测试后端服务，更加贴近服务器上的运行代码
2、可以发现更广泛的bug，可能比手工测试覆盖范围更广，并且越接近底层的bug，影响的用户范围就越广；
3、相对于界面测试这些，接口测试可以更早的进行，使得测试可以更早投入
4、接口测试更容易与其他自动化系统相结合，保障系统的鲁棒性，更健壮。

测试模型

分层测试

分为 界面测试、接口测试（重点）、单元测试
分层测试偏向于（着重看重的）接口测试，质量保障过程当中，会不断增大接口测试的测试深度和测试广度，往下不断覆盖一些公共接口的单元测试内容，往上逐渐覆盖由UI曾保障的业务逻辑测试；目的都只有一个，交付一个可靠的、高质量的项目。
从接口测试这一环节开始，测试工程师就变成了质量保障工作的主要推动者，接口测试也变得愈发重要。

实质

接口测试其实就是模拟调用方，比如 Client 端，通过接口通信来检测被测接口的正确性和容错性。

不同协议形式的测试

• http
• RESTful
• WebService
• RPC
  都是通过某一个协议，在Client和Sevice端之间来完成数据传递的

假如测试的是 Web 端网站，那么 Client 端（客户端）就是浏览器，Server 端（服务端）就是 Web 服务，那么浏览器和 Web 服务之间，就是通过 HTTP 协议传输的；
测试的是移动端的app，那么 Client 端就是你的设备上安装app应用，Server 端就是 RESTful 格式的接口服务，那么app应用和 RESTful 格式的接口服务，就是通过 JSON 格式的数据来传递的。

面试：接口测试工作场景？应用场景？

第一，单接口的测试，这是重点，保证这个接口的正确性，健壮性，保障该接口可以按照需求，正确的传入参数，给出正确的范围时，也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝返回。 —— 需要足够的用例保证接口能正确处理各种情况。

第二，业务流程的接口测试（多接口测试），保障通过多个接口的串联操作，完成原来需求中提出的业务逻辑。——重点就在于业务流程，逻辑是否行得通。
在这个方面：我们更需要关心业务流和数据流的关系（逻辑），并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常问题。

第三：多接口串行分析
在大部分的测试场景中，我们都需要串行多个接口，才能完成一个完整的业务逻辑；多个接口之间并不是随意组合的，而是按照**业务逻辑、**通过数据传递来完成的。所以要完成整体业务逻辑的接口测试，需要理清每个流程的数据流程，而数据流程驱动了业务流处理。

面试：接口测试你学到了什么？

（分层测试中为什么在单元测试和界面测试之间要加入一层接口测试的主要原因之一）

• 通过单接口测试，可以更加接近于单元测试，
• 站在 Client 端的角度来完成测试，通过业务流的接口测试，可以更加接近于界面所承载的交互中的业务流验证；
• 接口测试更加关注有数据流驱动的业务流程，而不再着眼于代码异常、代码边界等，这些边界问题在接口测试过程中已经由单接口测试完成了。

实现接口测试要掌握什么？

接口测试中的Cookie

cookie当中传递的参数很多都是用来确认用户身份、鉴定角色权限等等需要的参数。
cookie内容是完成接口测试必须要模拟并传递的一些信息。并且也是接口测试必要输入的条件之一。它包括了访问的基本信息，头信息，还有一些开发定义的信息。

需要了解Cookie哪些信息？

参数的含义以及来源
要知道参数的含义是拿来干嘛的，也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到的？还是 JS 生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个字段？这样，当你开始做接口测试的时候，你就知道去哪里拿到这个参数的赋值了。

参数的作用域

是指这个参数在这个接口中是做什么用的，它在哪一个访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验证用户权限吗？它的验证算法是什么？之所以要搞清楚这些内容，是为了你在做接口测试的时候，可以设计更小的参数组合来覆盖更多的业务逻辑，这是测试用例去除冗余的一个很好的方法。

返回值的含义

针对接口返回的 JSON，你要搞清楚在返回值中，每一个 JSON 的 Key 所对应的含义，这样，当你需要和这个接口产生交互的时候，就可以快速地拿到对应参数的含义，完成业务逻辑上下文的参数串联了