全国咨询热线：136-9172-9932
在我们测试接口提供的数据，支持的业务功能之前，我们非常有必要再提一下接口本身的规则，即便我们在前面的章节已经隐隐约约的提到过。
接口文档
如果让我给接口文档下个定义，文档是使用接口的人对于接口的约束。
◆ 口头协定（对，你没看错，这是我最经常见的）
◆ word/Excel/txt 文件
◆ api管理平台（rap2/yapi等等）
文档应该出现且不限于以下几点内容：
◆ 接口访问的地址
◆ 接口参数
◆ 必须传的参数
◆ 非必须传的参数
◆ 指定数据类型参数
◆ 请求方式
◆ GET请求
◆ POST请求
◆ 返回字段的含义
至于为什么是上面几条，不赘述，大家可以想一哈。
遵循接口文档
对于测试人员来讲，遵循接口文档，就是按照文档进行测试。测试也可以分为两种风格：
◆ 懒汉式
测试人员并非在文档形成之初，就按照文档进行严格的测试，而是在业务功能基本完成之时，才介入测试。然后当发现调用出错，或者功能出错时，才去翻阅接口文档，反馈给开发修改再测试。
◆ 饿汉式
文档一形成，测试人员就开始介入，抛开业务需求，变换参数组合，请求方式等对于接口本身进行测试，直至符合文档。后期功能完成后，再把重点放到功能层面。
设计测试用例
对于接口本身的测试用例，由于测试的主要目标是接口本身而非业务功能，所以我们只要针对接口文档中主要的几点进行编写即可：
◆ 使用get请求访问
◆ 使用post请求访问
◆ 必传参数为空
◆ 非必传参数为空
◆ 非指定类型参数请求
◆ 参数组合
当然，如果我们稍微了解下后端代码是如何实现接口的，还可以编写一些特定的测试用例，比如如果操作数据库，可以尝试传入部分sql语句，进行安全方面的测试，在这里暂不做过多的说明。
举个例子
仍然以上一篇中的getList为例子：
◆ 使用get请求访问 =====> 成功，无异常
◆ 使用post请求访问 =====> 失败
因为这个接口接受的请求方式是GET，没有处理请求方式是POST的情况，其他测试与此类似。
