在日常工作中，常见的接口测试主要包括：Web接口测试，应用程序接口（API, application programming interface）测试和数据库测试。
前言：
在做接口测试用例之前，首先要做接口分析。主要需明确以下内容：
1）收否有接口文档？接口文档内容有哪些？
2）明确接口测试流程。
3）分析每一个接口：header，url，参数（含义、可选/必选、格式、类型等等），响应数据来源及数据量。
4）分析实际可做接口测试的测试点。
1、接口文档
A、接口文档五要素：接口地址、接口请求的方式、是否有请求参数（参数相关属性）、返回参数说明（参数相关属性）、返回结果样例；
B、如果没有接口文档，到功能测试阶段，需要自己抓包，抓包工具如Fiddler等。
2、接口测试流程
主要的流程包括：接口文档 — 接口测试计划、方案 — 接口测试用例（评审）— 执行 — 集成到Jenkins — 接口反馈
3、测试点
A、单一接口功能的测试主要测试返回的数据结构是否和接口文档给出的一致；
B、接口的正常功能是否完成；
C、接口的参数检查测试，接口的异常测试；
D、多接口组合测试，实际上是在测试一个业务流；
E、在测试过程中一次调用多个接口。
在明确上述内容后，开始设计接口测试用例。（划重点啦）
1、输入
在输入参数方面，我们需要从以下几个方面进行设计：
A、必填项校验：在接口文档中是否有必须填写的相关内容（参考接口文档即可）。
B、参数长度校验：参数长度可以参考接口文档。
C、参数值的有效性校验：参数有效性的校验就需要结合实际业务场景，判断哪些数据是真实有效的数据，一定要确保所有真实有效的数据是可以验证通过的。
举个例子：身份证信息的校验。
我们在做相关校验时需要注意，虽然数据的长度符合设定规则，但并不代表它是真实有效的身份信息。（例：123456789012345678）
这种情况下，我们需注意身份证号的校验规则设定。一般情况下，采用的现成的身份证号校验器即可。但是，有些校验算法是自己写的，因此，要注意校对这种算法是否合理，
D、参数组合校验：不同的参数组合可能会存在不同的业务场景；
E、如果参数是枚举值，一定要各种枚举值都要测试，因为可能不同的枚举走的不同的业务流程；
F、参数值的默认值的校验：参考接口文档。
G、某些参数具有特定的生成规则，要单独针对生成规则设计用例，一定要保证真实有效的数据是可以验证通过的。
如：身份证号中间几位***19860701*，本人就遇到过输入***19861001*这种值校验不正确；
2、接口逻辑
接口逻辑我用的设计方法是分支覆盖—>路径覆盖—>场景覆盖，同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。
A、流程图
第一步先把业务流程图画出来；
B、异常情况
依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理；
以付款接口为例：
付款结果为：成功或失败。当付款成功后，应怎么处理，需要回写打款成功状态；若付款失败，也需要回写失败状态。失败后的数据可以操作退回，也可以操作重新出款等等；
C、业务场景
测试逻辑设计完成后要想一想不同的业务场景怎么去测试，需要哪些人员协助，如：接口超时怎么去测试，请求重复怎么去测试，请求并发怎么去测试。
3、输出
输入结果：正常输出和异常输出，常用的方法有错误推断法（列举出程序中可能存在的错误或者异常，根据他们选择测试用例）。
4、冗余
以上都完成后，要结合实际的业务场景去掉冗余的用例（即实际业务场景不存在的流程或者输入数据）；
5、状态转换
如果业务流程涉及到状态转换，要单独设计用户—方法：状态转换图；
6、正交试验法
涉及到多个不同金额或者手续费的计算，可能还会用到正交实验法去设计用例；
7、异常数据
另外，用例设计中还应当包含异常流程中产生的异常数据的处理流程；—通常所说的补偿机制，这块流程能大大的减轻人工运营的工作量，当然，这需要在做系统设计的时候就需要把这部分考虑进去。
在设计好测试用例后，接下来是调试接口脚本。可以使用jmeter，postman等接口工具，也可以自编接口测试脚本。在测试脚本过程中，应注意：
1）不断调试脚本；
2）添加逻辑控制，对脚本内的数据进行参数化（包括：前置条件，测试步骤及测试数据）；
3）添加用例里的预期结果。
最后，执行测试和脚本，并对执行结果进行分析。包括：错误分析、响应结果分析、响应时间分析等等。