声明：接口仅限 controller 层，不设计 service 和 dao 层接口，仅限功能测试中的接口测试，不涉及后续的自动化或者框架 。

接口测试有什么用，应该怎么做?网络帖子上的回复各有侧重点，有模式化的模拟发送请求查看响应体是否符合接口文档的、有把接口中每个参数都修改后排列组合重新发送的。下面阐述我所理解的接口测试，当然我所理解的接口测试也仅仅是一部分，各人理解不同，希望通过交流能得以补充完善。言辞拙劣，不喜勿喷。

Q:接口测试是什么？
我认为接口测试是功能测试不可或缺的一部分，抛开了前端的逻辑和限制对于服务端的功能进行了完整的测试，一个好的功能测试人员应该充分了解所测系统有多少个接口，接口的核心参数和响应，完成对接口代码走读，接口有没有白名单，防刷，内部接口 or 外部接口等。

Q:接口测试有没有作用？
当然有用，而且作用很大。从接口测发起的测试弥补了界面测试的遗漏点。界面测试起码遗漏了
1.服务器端接口参数校验
2.接口是否存在安全漏洞或者逻辑漏洞，实时性，防刷等
3.接口是否存在越权的可能 。
能将接口测试纳入功能测试的一部分并且完成，测试的完整性得到了很大的提高。

Q:接口测试怎么做？
接下来到了核心的部分，如何做好接口测试。
首先，工具的选择很重要，需要一个好的抓包工具或者代理，浏览器方面的推荐 firefox 的 firebug 和 chrome 自带的开发者工具，快捷键都是 F12。工具方面推荐 fiddle2 和
charles、postman，这几款款工具的功能还是比较齐全的，包括抓取 http 和 https 包、请求包结构、时间、断点调试、mock、重复发送请求等等，囊括了你对于一个抓包工具所有的诉求。现在抓包工具有了，我们抓取一个典型的 post 请求如下:

图一

图二

图三
图一图二是一个请求消息头与消息体，请求消息中的每个字段都有意义且可以更改，这个现象就很有意思了，测试人员应当如何去操作这个请求消息呢？

第一步:【看】
(a) 看接口的访问方式是 get、post、delete 及 header 中的 cookies 信息或者 UA 信息等重要信息，看响应头中诸如 referer 等信息
(b) 看接口的参数构成是否合理。举个例子，大家看下面截图，有个接口名称为 cancelOrder，传入参数有 3 个:原始状态、修改订单后的状态、订单 code。有没有觉得这个接口的设计师一个悖论，接口的作用已经明确确定为取消订单，还需要传入状态。你可能说，即使加上这两个参数也没错啊。这种观点是错误的，订单状态在数据库中已经有明确的定义，不需要再通过不确定的前端传入，这样会减弱程序的健壮性，增加冗余。原则是能在服务器端获取的尽量不要传，参数个数尽量精简。


图四
(c) 看所传参数有无敏感数据需要加密传输。比如说用户 userid、password 等数据如果不使用 https 进行通信，最好使用加密的方式进行传输，这也是业界通用的标准，并且入库也需是加密的。
(d) 看所测服务的代码。第一看对于传入参数的校验部分，第二是看整体逻辑处理部分。举个例子，大家在测试过程中经过会遇到如图五所示，有多个必填或者选填项、输入条件特别多、每个输入条件都需要做校验。有些测试人员会对此类问题用正交的方式一项一项测试，这类效率太慢。个人认为效率最高的方式为对于接口参数的校验，以静态测试为主，review 代码的过滤条件，页面控件实际输入测试为辅助。很多的输入界面，其中判空处理是必须的。开发代码中常用的一个判空函数是 if（xxx.isempty（））。首先界面类查找是否有控件对象未使用该函数，若未使用肯定存在 bug；其次即使使用这个函数也是有 bug，该函数并未完全满足需求。这个函数漏掉了输入空格的情况,正确的做法是 if（xxx.trimme().isempty（））。那么如果在全工程内，搜索 isempty,对比发现 bug，最后可以选择一个输入项进行测试，通过后所有输入控间判空测试均告完毕。静态测试最多只需要 10 分钟，对应所有可输入业务控件不为空以及过滤空格的功能点用例可能有几十个，执行时间至少半个小时以上。静态效率比大于 1：3。


图五
(e) 看接口的返回体是否返回一些不必要的敏感信息，返回格式是否合理等

第二步:【改】
(a) 请求体中参数的常规修改。常规修改就是通用的边界值方法，如极大值、极小值、极长值、null、空。未对这些值做校验的后果可大可小。小的方面仅仅是服务器 throw 一个统一的错误提示，如网络错误等。中等一点的为前端页面会返回如图六形式的内部错误，这种错误会泄露一些敏感信息。严重的后果可能就是影响现有或者后续业务，使得业务往不可控的方向进行。

图六

(b) 与业务强相关的参数修改。在本文中强调的一点就是接口测试是功能测试密不可分的一部分！在上段图二中，各项参数都对应了数据库中的某个业务字段。比如修改 taskid 为一个还未上线的任务 id，会不会就领取了这个任务。又或者修改 taskid 为已下线的任务 id，是不是可以领取这个任务。这一类的参数修改法无定法，需要测试人员深入到功能内部，加上对于业务源代码的走读进行用例设计。
(c) 请求消息体中的字段修改。有些人习惯在 cookie 中传输大量的信息，也是值得关注的测试点。

分享一些测试案例来印证观点：
1.
bug 描述：http://www.wooyun.org/bugs/wooyun-2010-046547(我们网站也确实存在此问题)
危害：在一个验证码有效期内，可重复使用这个验证码进行注册、登陆

2.
线上存在漏洞，有些用户的交易密码被无故修改，通过排查发现，黑客是通过调用绑定交易密码这个接口来直接修改交易密码的，由于这个接口不需要传入 oldpwd，就导致了黑客在无需知道老交易密码的情况下就可以修改交易密码，