话题
因为本人没有怎么做过接口的测试，但这几天都在看一些资料，说下我自己的理解：这里是思寒大神写的一个接口测试的实例：点我、点我
从我个人的角度理解：
- 接口测试的是同属于功能测试、压力测试、性能测试，就看使用的方式
- 接口测试就是用一些特定的框架把一些请求参数按一定的规则传给服务端，并处理从服务端返回的数据，使用到时断言等方式
- 接口测试是偏业务方面的测试和一般的功能测试不一样
暂时想到的就这些，如果还有一些想法，可以回复，我再添加进来。
接口测试的是同属于功能测试、压力测试、性能测试，就看使用的方式
Monkey：表示没有明白是啥意思。。。。
接口测试是偏业务方面的测试和一般的功能测试不一样
Monkey：这句话。。。我表示。。。。对是对。。能不能说说自己深入点的理解呢？
另外，这标题明确下。。。。
最近也在做接口测试，不过刚入门，有些理解可能不对，不过也分享下看能不能有火花。
首先，我觉得接口测试偏业务还是偏功能甚至类似单测偏覆盖，取决于你的使用场景和最终目的。
对于已经有成型的应用/接口，或者业务比较多，比较复杂的应用，应该是先上偏业务的接口测试，能最快速度找到最关键的问题。（我前几周就钻了牛角尖，每个接口都写不少用例去覆盖各种的参数情况，如缺少必选参数，必选参数值无效等，结果发现按照进度安排完全写不完。。。）
对于开发中的接口，可以花多一些时间做高覆盖度一些的测试（反正本来开发也在花时间做接口实现），例如检查调用接口后数据库是否正常更新，一些缓存是否有正确更新，尽量保证接口在实际对接时没有太多隐藏的问题（貌似客户端和服务端因为接口问题撕逼的事情不少），同时也能对接口的使用方式有个比较详细的了解，便于后面沟通。
和其它的测试没啥区别吧。能用吗？靠得住吗？
其实我也这方面的困惑，因为一直就自己一个人测试，不太明白这些区分。
我用 js 写了一个校验后台 api 反馈和字段的，以及用 jmeter 对部分后台提供的业务接口进行多线程并发
这些算是接口测试吗
@monkey @lihuazhang（希望没有打扰你们）
ps：好像没有私信功能，刚来不久~
#5 楼 @pandachen 嗯 没有私信功能。jmeter 的可以分享出来啊。 testerhome 最近在推动 jmeter。
@lihuazhang 还没脱离黑盒测试的大部队，不好意思班门弄斧 哈哈哈
我的理解是这样的，假设一个系统对外提供服务，如银行的 ESB 系统，提供 webservices 接口，没有任何 gui 界面可供直接调用。
现在我们要对这个系统做测试。
1：功能测试：没有 gui，我们只有通过发送报文的形式进行测试，很多人用 soapui。这也是接口测试，属于接口的功能测试。
2：性能测试：通过 lr 或 jmeter 并发发送报文，这也是接口测试，属于接口的性能测试。
以上为我的理解。
再来一个假设，一个手机银行的 app，后台有个服务器。app 和后台的服务器必然会遵循一种接口规范。
现在我们需要测试这个手机银行的 APP。
两种方法：
1：基于 gui，不管你用人点，还是用 gui 的自动化，流程上都是通过 app 连接到后台的服务器。
2：基于接口，模拟 app 给后台服务器发送报文。
第二种就属于接口测试，但这样的接口测试会存在一局限性，有时候接口是好的，app 端的处理逻辑存在问题，则这样的缺陷是发现不了的。
所以，最合理的方式，就是 基于 gui+ 基于接口的方式，接口可做为 gui 的前置测试，接口都存在问题，gui 的就不用做了，但接口的没有问题，并不能代表 gui 没有问题。 我个人的看法是，接口一般比较简单，覆盖大部分就可以了。
以上，都可以自动化，接口的自动化有时候更加有效，因为接口不会经常变动。gui 的自动化维护成本太高，很多时候然并卵。
所以，我个人的看法是，覆盖 90% 以上的接口 + 覆盖 30% 左右核心功能的 gui。剩下的，交给手工把。
以上为个人看法，供参考。
#7 楼 @pandachen 大家都是黑盒，白盒是另外一个层次了。重在分享，我也期待看一下 Jmeter 的东西。
我也觉得其实跟普通的测试并没有太大区别，恒温两句话简直就是说到了点子上了好么...我拓展一下...
接口也是程序；
接口负责处理 client 提交过来的请求，根据请求内容，完成 操作数据库/读取数据库/数据排序/请求其他服务 等操作，然后将操作的结果返回给 client，client 做出相应的展示或处理；
那么接口实现了什么功能，你就测什么功能，无非是 “点点点” 变成了更加直接的 post 操作或者 get 操作；
功能没问题了，那么丢点异常的数据进去看看会怎么样....异常包括安全方面的考虑...这就不展开了...
异常处理没问题了...那把上面的操作整理整理...套进框架里面去，做成自动化，让工具自动校验输入输出...
ok，什么工具都能玩...就看你想怎么玩...
玩够了之后，再来试试看通过自动化，建立一下场景和环境，做一下并发，看看接口服务器的承压能力，数据库的承压能力，是不是达到要求；
从而检查是不是接口代码有性能瓶颈，数据库是不是没建索引等等等等...
貌似在平常，接口测试只包涵验证业务功能的部分，性能方面就叫服务器性能测试（其实严格应该叫服务端性能测试），从招聘的 jd 得到的信息。
做过一点这方面的工作，同意恒温，其实和客户端的黑盒功能测试本质上没有太大区别，甚至要比客户端的要更好做一些（我猜，猜错别打我），因为客户端的环境类型可能更复杂一点，接口测试的自动化，集成也更好做一些。
本质就是请求（GET POST PUT 等），验证功能和各种异常情况，异常环境，啊~可能还有受到攻击的情况~
而服务器的性能测试就也跟客户端的一样，可深挖的地方多了。（懂的不多，匿了）
ps：说接口测试的自动化更好做一些因为接口的调用是依赖于 HTTP 协议的，各种语言都有它的实现，自己写都可以整出一个简单的框架来，再与其他工具整合。而客户端的自动化。。。。orz 不说了都是泪
比如各种数据算法都是服务器端提供的，基于数据驱动的接口测试也很重要，还是因公司而已，我们不做 UI 自动化只是接口测试的搬运工。
#13 楼 @13651969749 你们公司主要还是业务多吧，如果是以 APP 功能为主的（比如 xx 安卓浏览器海外版本，海外版本的不会像国内那么多业务）还是 UI 的会多点。
去看淘宝的接口测试白皮书，会给你解惑的。
#19 楼 @lihuazhang 已下，再看，谢谢
我最近也在用 JMeter 做接口方面的测试，性能方面的。功能方面它自带断言和正则，也挺好用。性能测试下来结果文件是论 G 的，基本依靠插件和 linux 命令行工具来分析。用 JMeter 的朋友们可以了解一下插件，也许能用上 http://jmeter-plugins.org/