1.接口测试的流程

测试计划与方案 --> 接口用例设计 --> 接口测试执行 --> 缺陷报告与结果分析

2.接口工具的流程

脚本的设计，数据用例的设计，断言（预期结果的设计），执行

3.测试计划与方案：

1.测试计划：即时间人员任务的安排

1.1 设计是在开发环境中，执行：可以在开发环境中，测试环境中，甚至其他环境中。设置环境变量即可
1.2 缺陷比较容易出现在后台（接口模块），前端Bug比较容易出现在兼容性上。
1.3 系统完全实现好之后，仍然需要做系统测试。

2.测试方案：

2.1 接口测试的环境说明：
2.2 接口测试的内容说明：不是所有的功能（接口）都要做接口测试
2.3 UI自动化测试的内容：是核心功能的自动化测试，自动化率10%-30%

4.接口测试的应用场景：

1.还可以跟踪问题（可以跟踪出是前端Bug还是后端Bug）
2.协助测试：如果操作比较长，可以直接发个请求。

2.接口测试设计：

1.在原系统用例设计阶段实现，连接的是开发环境。
2.因为接口测试设计和执行压缩了功能测试用例设计时间，所以功能测试用例设计会改革。
3.功能测试用例设计会针对于复杂模块进行用例设计和评审，简单模块可能不会写用例。

3.接口测试执行：

1.开发环境的接口测试可以在原系统用例设计阶段执行
2.测试环境的接口测试需要在系统测试阶段执行，会在早期冒烟测试阶段执行。

4.接口测试能够发现的缺陷：

1.正常的接口测试，可以将测试执行时间提前。跟开发配合比较好，开发会主动告诉你哪个接口实现好了。告诉你一个接口，你测试一个接口。
2.接口测试是不关心界面的测试，突破了页面的限制。原来在页面做了限制在后台没有做限制的都可以被发现。可以让测试变得更深入。例如曾经发现过注册时：两次密码不一致也能注册成功，验证码只在前端进行了验证。
3.做接口是修改请求的测试，如果是修改了敏感信息也能够被服务器接收，那么就会有严重问题。例如在支付的时候，修改付款金额。
4.在游戏中，砸箱子得装备。砸箱子相当于点击了某个按键触发了这个请求，如果抓到了这个请求，再次发送会怎样，会不会出现多个装备。
5.投票功能，也是发送了一个请求，是否可以修改这个请求实现多次投票。类似的还有签到，抽奖。
6.关于抽奖：1元夺宝功能，将请求自动化执行。

5.接口测试报告：

1.表达测试了哪些接口，哪些是通过的，哪些是有缺陷的。
2.一般接口测试报告是一个中间测试过程，报告一般不是特别详细的那种。

接口测试的优点：

1.测试时间提前了，减轻测试的工作量。
2.需要明确哪些功能是核心功能，并且是单一功能。

接口测试的缺点：

1.有些功能不好测，关联的接口越多越不好测。
2.建议是测试明确的单一的接口，要么就是关联比较明确