本文的接口只是限于HTTP的接口，其他的接口由于没有业务上的需求，也没有多做研究。关于接口测试，本人尝试过很多的方法，下面是过程中的一些想法，随感而发。
接口测试概念
1. Q：什么是接口？
A：子模块或者子系统间交互并互相作用的部分； WindowsAPI， 数据库访问接口；WebService；Http Rest
2. Q：Http接口是什么？包括哪些部分？
A：http接口就是一种基于http服务的api，是系统之间交互的一种约定，所谓的webservice其实也就是一种http接口，只不过它是比较规范的、通用的。
主要包括Http协议，请求值，返回值，调用方式，实现方式等
3. Q：为什么要测试接口？
A: 移动互联网；产品迭代加快，测试需要提速，前端界面修改频繁
4. Q：为什么可以提前测试接口？
A：不需要前端页面完成，可以直接模拟一个前端请求，测试接口，验证返回结果，能提早发现问题；而且还可以测试一些不容易在界面产生的请求，比如压力和性能测试等，可以提前测试接口的性能。还可以明确产品的状态，方便管理。
5. Q： 怎么测试接口？
A： 有很多开源的接口测试工具，比如postman,还有在线的http接口测试工具；SoapUI；开发脚本等。
6. Q：接口应该测试什么？
A：单一接口测试：测试某个接口的功能
组合接口测试： 类似于业务流程测试
结构检查： 验证发送和返回数据的结构
接口测试的必要性
1. Q: 我们需要做接口测试么？
A: 我们属于大型的互联网产品，结构复杂，功能繁多，迭代快速； 那么在有限的测试时间里面，要完成新功能的测试以及原有功能的回归测试将是一个很有挑战性的工作，这还不算中间可能会出现的突发性问题。 因此，本人认为，接口测试可以做到两点：第一，在前端界面完全做好前，测试app接口的正确性；第二，快速的回归测试，那么测试人员就可以把精力放在UI层面和业务层面。
2. Q：接口测试的投入产出比，即维护成本很大么？
A： 我们一直在做web自动化测试，并且为之付出了很多的努力，但是投入产出比仍然不高，主要原因有两个： 第一，前端页面变化太频繁；第二，人员不够，需要大量投入。但是如果做接口测试，那么工作量和维护成本就会下降至少2倍，而且由于不涉及到前端显示，只要接口不变，那么维护成本也不会很高。
3. Q: 做了接口测试，web自动化怎么办呢？
A: 其实这两个不冲突，还可以做到互补，虽然不是没有交集，但是也可以设计得交集很少，并且各有针对性。Web自动化主要针对前端比较稳定的功能，既不会频繁改动的页面，可以做回归测试；而接口测试则可以补充web的空缺，并且可以模拟一些前端不好模拟的测试场景。并且，接口测试的执行速度更快些。
未完待续... ...