因为最近想接触一下移动测试方面，所以了加入了 TesterHome 这个社区，看见了很多优秀的文章，也看见了很多讨论《自动化测试的困惑》《很多接口测试框架》《接口测试感悟》，下面我谈一下个人的见解，勿喜勿喷。

接口测试的好处

• 简单 (对于开发基础比较好的同学来说)
• 稳定 (成功率极高，很少出现 UI 自动化测试的各种状况)
• 效率 (1 个接口下的 100 条用例 1 秒执行完成)
• 可信 (UI 自动化测试报告天天发送，一堆 Fail，费了好大劲排查原因，结果各种环境、浏览器问题等，慢慢大家对这个就想白盒扫描工具的报告一样，当成垃圾邮件)
• 时间 (用例编写时间段短，也不需要写测试脚本，调试页面脚本)

接口分析、工具选择

• 目前主流的协议 HTTP、WEBSERVICE、REST 等，还有一些 dubbo、hessian 等个别公司内部开发或者二次改装的协议。
• 其实我们做接口测试对于是什么协议前期不用太怎么关注，我们主要关注怎么模拟发送请求。（当然学一样东西，不仅仅要知道，而且要知道原理，否则就违背了我们身为技术人员这个职业了）
• 当我们确定接口是哪些协议的时候，那么我们就开始选择模拟调用端了。
• 基于 HTTP 接口测试的工具:restclient、postman、jmeter、soapUI 等等，基于 JAVA 代码的 httpclinet、JAVA 自带的 URLConnection 等。
• Dubbo 之类的可能要自己客户端请求代码了。
• 所以接口测试第一件事情，确定客户端或者调用工具。

用例编写、开始执行

• 开始编写前置条件、入参、返回结果、预期结果等测试用例相关信息。
• 运用工具去执行测试用例。
• 校验返回结果是否正确。 -简单的一个 接口测试完成。

【思考】手工接口用例执行完了，那我们开始自动化测试吧

• 开始找各种开源框架，二次开发等。
• 编写各种脚本。
• 准备各种接口自动化测试用例。
• 准备接口数据。

我们在回顾一下自动化测试的好处，可以帮助人做某些事情，提高效率，减少资源。
那么我们专门为了做接口自动化测试而做了以上 4 点工作。
如果我作为功能测试人员的话，我是不会想做完手工测试在去维护各种接口自动化用例和数据 (事实证明其他同事确实如此)。
框架可能好做，接口请求客户端也可能好写，用例数据的维护呢？

一个想法

• 手工接口测试和自动化测试能够有效的结合起来是不是更有好处，测试人员在做手工接口测试的同时数据可以保存下来，然后可以批量运行，发送报告，这样是不是接口自动化测试呢?

实践

• 我们没有做框架。
• 根据公司的技术，做了一套接口测试的平台，它不是最好的，但是可能是最适合的。
• 当然你也可以基于开发工具二次开发。

• 菜单列表工程介绍。

  

• 工具箱是一个工具集合，和市面工具没有区别，打码的是公司内部的协议就不外传了。

  

接口测试菜单

-接口测试主要是创建接口与项目进行绑定。

• 直接在这里进行接口的手工测试，当手工接口测试结束之后，执行的用例数据可以作为自动化测试用例使用。
• 创建接口

• 接口列表，可以在这里选择接口执行所有测试用例，也可以设置前置，后置条件，数据恢复，维护接口写的测试用例。

• 测试用例维护

• 新增测试用例，里面可以设置一些数据库条件、数据查询校验条件、断言匹配规则以及接口测试，针对 JSON 的 List 自动排序对比，在这里测试之后直接就保存了自动化回归用例。

报告

• 当然还有执行报告、邮件报告、定时任务、Diff 对比等

• Diff

以上内容仅供参考，平台的功能没有全部介绍，希望能给大家带来帮助。