之前都是在网上杂乱得看了很多接口测试的资料，但总感觉不够系统，特地找了本书重新系统的学习一下，结合之前收集的一些资料查漏补缺。

《接口自动化测试持续集成postman》，这本大部分内容还是讲的是 postman 工具的使用方法，对于接口测试的相关内容也只是简单概述了一下，并没有深入剖析接口测试的重难点。比较适合一些想了解或初次准备做接口测试的测试伙伴。

一、接口的介绍

软件测试中，常说的接口有两种：图形用户接口（GUI，人与程序的接口）、应用程序编程接口（API）。

接口（API）是系统与系统之间，模块与模块之间或者服务与服务之间相互调用的入口。它的本质：其实就是一种约定，在开发前期，我们约定接口会接收什么数据；在处理完成后，它又会返回什么数据。

开发岗位分为前端和后端，他们相互配合完成工作，会协商接口的定义方法。一般后端定义接口，前端调用接口。前后端分离是web应用开发的发展趋势，优势有：

• 后端不用精通前端技术，只专注与数据的处理，对外提供API即可。

• 前端的专业性越来越强，通过API获取数据，并专注与页面设计。

• 前后端分离可扩大接口的应用范围，开发接口即可应用到web应用上，也可应用到app上。

接口的分类：HTTP接口、Web Service接口、RESTful接口。

二、接口测试的定义、必要性/优点、原理

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

接口测试，其实就是验证接口内部处理逻辑是否正确；我们既要保证单接口的正确性，也要保证接口的业务逻辑正确性，主要体现在两方面：

• 输入正确的测试数据，验证接口正常处理后返回的结果是否正确（数据结构&数据内容）

• 输入异常的测试数据，验证接口能否正确处理异常数据并返回特定提示，是否合理，是否健壮

接口测试目的：测试接口的正确性和稳定性（持续集成是接口测试的核心）

2、接口测试的必要性/优点：

• 开展接口测试可以及早发现问题，有效降低测试成本

• 接口一般较UI相对稳定，更利于进行自动化和持续集成

• 特别适用于高复杂性的平台，可以带来高效的缺陷监测和质量监督能力（平台越复杂，系统越庞大，接口测试的效果越明显：提高测试效率，提升用户体验，降低研发成本）

PS：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。（持续集成是接口测试的低成本、高收益的根源，是接口测试的灵魂。没有持续集成接口测试带来工作量会成指数增长！）

3、接口测试的原理：测试借助工具模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，工具模拟客户端接收应答，然后测试人员检查应答是否准确。

三、接口测试的范围、原则、重难点

1、接口测试的范围：

1. 需要测试的接口：

随着系统的复杂性越来越高，接口越来越多，覆盖所有接口是很困难的事。通常主要测试最外层的两类接口：数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统的接口（验证系统处理后的数据是否正常）。

2. 被测接口需要测试的方面：

关注被测接口的功能是否实现，性能是否达标，安全性是否满足。重点关注数据的交换、传递、处理次数、以及控制管理过程。可参考下面用例设计中的接口测试点。

2、编写和执行测试时的原则：

1. 不同的接口参数覆盖不同的业务场景；

2. 在后台构造合适的数据来满足接口的测试用例；

3. 根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；

4. 测试用例涉及多个步骤的，应对涉及的步骤都验证

5. 删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

3、接口测试的重难点：

1. 动态变量参数化

2. 接口依赖及中间变量问题

3. 异步接口结果验证问题

4. 相应参数及嵌套很多的验证问题

5. 接口测试框架的稳定性问题

6. 资源清理问题

7. 多接口场景测试

四、接口测试的用例设计

接口测试对象主要为接口，但随着系统复杂度越来越高，接口越来越多，完全覆盖是一件很困难的事情，且实际过程中任意接口的变动都可能导致我们接口测试用例不可用。

1、接口测试点参考：

2、接口用例设计优先级

优先级-->针对所有接口：

• 暴露在外面的接口，因为通常该接口会给第三方调用；

• 供系统内部调用的核心功能接口；

• 供系统内部调用非核心功能接口；

优先级-->针对单个接口：

• 正向用例优先测试，逆向（异常）用例次之 (通常情况，非绝对)；

• 是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 > 参数数据类型自身的数据范围值限制

  • 是否满足前提条件：有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆 Token。逆向用例：针对是否满足前置条件 (假设为 n 个条件)，设计 0~n 条用例；

  • 是否携带默认值参数：设计 1 条正向用例，带默认值的参数都不填写、不传参，必填参数都填写正确且存在的 “常规” 值，非必填参数不填写、不传参；

  • 业务规则、功能需求：根据实际情况结合接口参数说明，可能需要设计 n 条正向用例和逆向用例

  • 参数是否必填：针对每个必填参数，都设计 1 条参数值为空的逆向用例

  • 参数之间是否存在关联：有些参数彼此之间存在相互制约的关系。逆向用例：根据实际情况，可能需要设计 0~n 条用例

  • 参数数据类型限制：针对每个参数都设计 1 条参数值类型不符的逆向用例

  • 参数数据类型自身的数据范围值限制：针对所有参数，设计 1 条每个参数的参数值在数据范围内为最大值的正向用例；针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都超出数据范围最大值的逆向用例；针对每个参数 (假设 n 个)，设计 n 条每个参数的参数值都小于数据范围最小值的逆向用例

  以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：主流程测试用例：正常的主流程功能校验；分支流测试用例：正常的分支流功能校验。异常流测试用例：异常容错校验

五、接口测试的流程

接口测试的流程和功能测试流程类似，依据的对象是需求说明书和接口需求，接口测试流程如下：

1、接口测试需求分析（从 UI 交互和接口参数分析接口的设计逻辑）

1. 首先根据接口设计的技术架构方案，了解清楚被测接口对应的公共入参、入参、出参及返回数据的 Json 结构规范，根据测试场景进行测试。

2. 理解接口参数，熟悉接口参数的输入要求、输入值范围、必填项等；

3. 理解接口输出，熟悉返回 json 的结构构成、返回值类别、返回值范围、返回 data 的不同类型等。

4. 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。

5. 寻找测试点，根据输入 (参数名、取值范围)、输出 (参数名、返回值范围)、关联关系，进行测试点分析；

2、编写接口测试计划

接口测试计划与功能测试计划的目标一致，都是为了确认需求、确定测试环境及测试方法，为设计测试用例做准备，初步指定接口测试进度方案。接口测试计划包括概述、测试资源、测试功能及重点、测试策略、测试风险、测试标准。

3、编写、评审、执行接口测试用例

编写的接口用例评审通过后，借助测试工具执行测试，上报发现的问题

接口数据准备：

4、接口自动化测试持续集成要点

项目测试时，接口会有变更，用例也会更新，需要借助工具（如github）来维护测试用例进行持续集成，通过自动化测试实时监控项目接口运行情况。接口自动化测试持续集成主要包括以下内容：

• 流程方面。在回归阶段加强接口异常场景的覆盖，并逐步向系统测试、冒烟测试阶段延伸，最终达到全流程自动化。

• 结果展示。更加丰富的结果展示、趋势分析、质量统计和分析等。

• 问题定位。报错信息、日志更精准，方便问题复现与定位。

• 结果校验。加强自动化校验能力，如数据库信息校验。

• 代码覆盖率。不断尝试有目前的黑盒向白盒下探，提高代码覆盖率。

• 性能需求。完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。

5、接口测试流程例子

1. 测试A借助Postman工具测试接口

2. 每天或定期将最新的接口集合文件导出到本地

3. 将最新的集合文件推送到git服务器

4. Jenkins每次运行接口测试时，先做一次文件拉取动作，再通过命令行执行接口测试

5. 将测试结果通过邮件或钉钉发送给项目负责人

六、各种场景下的接口测试

1、 单接口的测试

单接口测试的重点，其实就是保证该接口的正确性和健壮性。也就是说，你既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回；也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝性返回。

总结：需要有足够的用例保证接口能正确处理各种正常情况和异常情况

2、 业务流程的接口测试（多接口测试）

主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑

总结：重点在于业务流程是否能跑通

拓展：我们更需要关心业务流和数据流的关系，要完成整体业务逻辑的接口测试，需要理清每个流程的数据流程，而数据流程驱动了业务流处理,。并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常

3、 复杂场景的接口测试

测试场景一：被测业务操作是由多个API调用协作完成

背景：一个单一的前端操作可能会触发后端一系列的API调用，此时API的测试用例就不再是简单的单个API调用，而是一系列API的调用

存在的情况：存在后一个API需要使用前一个API返回结果的情况；需要根据前一个API的返回结果决定后面应该调用哪个API

存在问题：如何高效地获取单个前端操作所触发的API调用顺序

解决上述问题思路：通过网络监控手段，捕获单个前端操作时所触发的API调用顺序，譬如Fiddler、Charles等抓包工具。也可以通过用户行为日志，通过大数据手段来获取调用顺序

测试场景二：API 测试过程中的第三方依赖

背景：API 之间是存在依赖关系的，比如你的被测对象是 API A，但是 API A 的内部调用了 API B，此时如果由于某种原因，API B 在被测环境中处于不可用状态，那么 API A 的测试就会受到影响。

在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。

解决问题的核心思路：启用 Mock Server 来代替真实的 API

测试场景三：异步 API 的测试

什么是异步API：调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API

对异步 API 的测试主要分为两个部分：

• 测试异步调用是否成功：检查返回值和后台工作线程是否被创建两个方面就可以了

• 测试异步调用的业务逻辑处理是否正确

测试异步调用的业务逻辑复杂性：因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等