在进行API测试之前，我们先了解一下
1、什么是API？API（全称Application Programming Interface）是两个单独的软件系统之间的通信和数据交换。实现API的软件系统包含可以由另一个软件系统执行的功能/子例程。
2、什么是API测试API测试是一种用于验证API（应用程序编程接口）的软件测试类型。它与GUI测试非常不同，主要集中在软件体系结构的业务逻辑层。在API测试中，您无需使用标准的用户输入（键盘）和输出，而是使用软件将调用发送到API，获取输出并记下系统的响应。
API测试需要可以通过API进行交互的应用程序。为了测试API，您需要
使用测试工具调用API编写自己的代码调用API
API测试的测试用例基于
基于输入条件的返回值：相对容易测试，因为可以定义输入并可以验证结果不返回任何内容：没有返回值时，将检查系统上的API行为触发其他一些API /事件/中断：如果API的输出触发了某些事件或中断，则应跟踪这些事件和中断侦听器更新数据结构：更新数据结构将对系统产生某些结果或影响，应进行身份验证修改某些资源：如果API调用修改了某些资源，则应通过访问相应资源来对其进行验证4、API测试方法：以下几点可帮助用户进行API测试：
了解API程序的功能并明确定义程序范围应用诸如等效类，边界值分析和错误猜测之类的测试技术，并为API编写测试用例API的输入参数需要适当计划和定义执行测试用例，并比较预期结果和实际结果。API测试和单元测试之间的区别5、如何进行API测试API测试应至少涵盖除常规SDLC流程以外的以下测试方法：
发现测试：测试组应手动执行API中记录的一组调用，例如验证是否可以列出，创建和删除API公开的特定资源。可用性测试：此测试可验证API是否功能正常且用户友好。API是否也可以与其他平台很好地集成安全测试：此测试包括需要哪种身份验证以及是否通过HTTP加密敏感数据或同时通过这两种方法对敏感数据进行加密自动化测试：API测试应以创建一组脚本或可用于定期执行API的工具为最终结果文档：测试团队必须确保文档足够，并提供足够的信息来与API交互。文档应成为最终交付成果的一部分6、API测试的最佳做法：测试用例应按测试类别分组在每个测试的顶部，您应包括被调用的API的声明。测试用例中应明确提及参数选择确定API函数调用的优先级，以便测试人员轻松进行测试每个测试用例应尽可能独立且独立于依赖项在开发中避免“测试链”处理诸如-Delete，CloseWindow等一次性调用函数时必须格外小心。呼叫排序应执行且计划合理为了确保完整的测试范围，请为API的所有可能的输入组合创建测试用例。7、API测试检测到的错误类型无法优雅地处理错误情况未使用的标志功能缺失或重复可靠性问题。难以连接API并从API获得响应。安全问题多线程问题性能问题。API响应时间非常高。错误的错误/警告呼叫者对有效参数值的错误处理响应数据的结构不正确（JSON或XML）
由于API和单元测试都是目标源代码，因此可以使用工具/框架进行自动化。
jmeterpostwomenParasoft SOAtestRunscopePostmanCurlEclipse SDK tool- Automated API testing9、API测试的挑战API测试的挑战包括：
Web API测试中的主要挑战是参数组合，参数选择和调用排序没有可用于测试应用程序的 GUI ，这很难提供输入值对测试人员而言，在不同系统中验证和验证输出几乎没有困难测试人员必须知道参数的选择和分类异常处理功能需要测试测试人员必须具备编码知识10、结论：API由代表业务逻辑层的一组类/函数/过程组成。如果未正确测试API，则可能不仅会导致API应用程序出现问题，还会导致调用应用程序出现问题。它是软件工程中必不可少的测试。
感谢每一个认真阅读我文章的人！！！如果下面这些资料用得到的话可以直接拿走：1、自学开发或者测试必备的完整项目源码与环境2、测试工作中所有模板（测试计划、测试用例、测试报告等）3、软件测试经典面试题4、Python/Java自动化测试实战.pdf5、Jmeter/postman接口测试全套视频获取我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。需要的评论区留言谢谢。
什么是接口测试?
1接口测试的定义与分类，以下就是接口测试接口测试是测试系统组件间接口的一种测试。
主要用于检测外部系统与系统之间以及系统内部各个子系统之间的交互点。
重点测试数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等等。
这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。
接口测试般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。
接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。
接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。
接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换、传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。
我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。
有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试，这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
接口测试有的公司是归纳在集成测试里面，也有的公司会放在系统测试阶段，不过这个都没有什么区别，本质上接口测试就是通过某个功能模块对外暴露的一个接口地址传参进行测试。
一般来说接口分为如下三类：
A. 系统与系统之间的调用(如我们一般常见的分享内容到朋友圈或者是微信朋友时，微信会提供接口给这些需要用到分享的应用)上层服务对下层服务的调用（这个理解难度稍微有点大，在我们程序中功能是分层的，那么属于上层对底层服务的调用，以后能够有机会接触到代码或者更加稍微复杂点的接口测试就能够理解。举个例子，我们的程序框架分为三层，分别是web层：提供给用户请求的层次；feb迁至层：作为信息传递的中转站；service层：作为程序应用的核心，处理所有的请求
C.服务之间的调用（如添加一条数据时，会先调用数据查询的服务，查询该数据是否是重复数据）
不同类型的接口测试方法可能不一致，但总体来说不管是哪种类型，被测接口即为服务，测试手段为客服方，接口测试的目的就是：通过我们的测试手段，去验证满足其申明提供的功能。
2如何做接口测试
接口测试的原理：通过测试程序模拟客服端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（reques->response）。
接口测试的流程与功能测试有什么区别呢？从原则上以及流程上讲，是没有啥区别的，都同一套软件测试流程：需求讨论->评审需求->确定需求->产出接口定义->根据需求文档及接口定义设计测试用例（测试用例主要从业务场景，功能以及异常测试几个方面考虑）->评审用例->执行测试。
接口测试采用的最基本的就是黑盒测试，在这个测试过程中我们最需要关注的是，如何来设计测试用例，设计测试用例所采用的方法也是我们常所用的几大方法：等价类、边界值以及错误推测法、场景法。在设计测试用例之前，我们先来看看常见的接口文档形式。
这就是上图是一种比较规范的接口文档说明，包含了如下内容模块：接口的类型说明、接口地址、http请求方式、输入参数和请求接口后返回的响应结果。
接口测试编写测试用例，主要关注点是输入参数、输出结果以及内部业务逻辑是否正常‘，所以我梦设计用例也要从这几方面出发考虑：
a）输入参数测试：针对输入参数进行的测试，也可以说是假定接口参数的不正确性 进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法（不合法），输入参数为空，为null,输入参数超长等等；
b）接口是否满足了所提供的功能，相当正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例就有更好的可读性和可维护性；
c）逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清晰，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；
d）异常情况接口测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理；
针对上面的注册接口，我们利用测试用例设计方法来编写测试用例，如下所示：
3接口测试的工具选择
可以进行接口测试的工具有很多，这里简单介绍几个：
>loadrunner :一款商业性能测试工具，用来做接口测试，很好很强大。
>jmeter :一款开源的性能测试工具，操作简单方便，既有jdbc request 操作数据库数据，也有http request 和 soap request 应对测试；
>httprequester :火狐浏览器自带接口测试工具，插件中安装即可，界面简单明了，容易上手。
>postman :谷歌浏览器的扩展工具，界面简洁，开发者比较常用的一款插件工具。
>soapui : 开源测试工具，通过soap/http 来检查、调用、实现web service的功能/负载/符合性测试。
我们将在后面的教学中，重点讲解Jmeter这款综合性比较高的工具；
什么是接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。接口测试的目的是为了测试接口（听起来怪怪的），尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来来测试。等等这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
假设/预处理
项目的责任人/开发人员必须已经成功完成了单元测试、功能测试和集成测试，一些错误都已经被列出。测试策划人员拿到的是最新版本的源代码
期望
正如前面提到过的那样，最重要的是关于外部接口的测试，这需要依赖于外部接口的相关数据，而这可能是极其复杂的
测试项目需要一系列的测试计划以及和外部组织的协调工作，主要包括：
l 负责人选
l 预定的测试时间
如果没有合适的测试环境，测试可能需要在周末或者工作时间以外的时间里进行
l 需要什么类型的测试用例，需要多少以及这些用例分别是用来测试什么的
提供测试用例的副本及相关文件给相关合作人员
如果外部组织有一些特殊用例需要执行，我们也需要拿到相关副本及文件
l 谁将提供测试数据，这些测试数据包括哪些方面的内容，是以什么形式给出的（纸质，电子档还是只是一些数据的底稿并且需要相关的人员整理成可用的数据）
l 谁将对测试结果进行确认并且判别这些数据就是我们所需要的
l 每隔多久时间我们需要各路人马需要聚在一起讨论测试中遇到的问题以及测试进度
所有正常的情形和异常的情形都需要测试，测试的各个方面（数据的各个出口，路径，入口）都需要尽可能考虑周全。我们不仅需要用一般大小的数据量去测试，也需要用预期的或者规定的最大数据量去测试
如果允许的话，我们还可以测试各个部分处理一批数据的时间数据
如果因修复bug等改动代码从而改变了接口的某一端，相关的决定，到期时间，再测试等过程都应该被记录在案，并且分发到各个相关组织或人员。
职责划分
测试的建立------开发人员，数据库和/或系统的负责人， 或者测试人员
测试的执行-------测试人员
测试结果的确认，测试结束的决定------开发组长，测试组长，质量保证组长，架构人员，项目负责人，外部组织负责人（如果可以的话）
测试环境
系统测试环境和外部组织的测试环境
数据类型
真实的数据------被处理过的用于测试的数据
测试结束
依照某某文档