随着工作的需要，接口测试所占比逐步增加，那么为什么要做接口测试以及怎么做接口测试，是大家一直津津乐道的话题。
为什么做接口测试？
通过自身学习以及身边大部分人的学习方式，能很迅速的掌握一种工具，但是往往自己以为掌握了工具就等于掌握了一门技能，恰恰相反，只是知道如何用工具，却不知道其原理，知其然而不知其所以然，突然想到以前面试时面试官问，你会性能测试啊，你都是怎么做的啊，而我的回答是怎么用这个工具，而本不是人家要的答案。
如何进行接口自动化？
1、接口测试的关注点，一般而言测试结果、请求地址、输入参数、输出结果、断言结果。成功和失败的标识这些是比较主要的。
2、需要准备什么：自动化测试方案，很多时候都是直接说某某任务要自动化，同志们干吧，结果就是做着做着就发现，这和预期的不一样啊，成本好大啊，所以有份方案就很重要。那么需要根据当前公司的情况，制定合理的接口测试计划或者接口测试方案，再设计方案时需要确定如下内容
3、接口测试用例的设计很多人都会存在疑惑，到底是按照功能测试用例走，还是单独设计一套，无论采用哪种都要确保接口测试用例小而精且能覆盖所有接口
1)、接口来源
开发提供接口文档
通过fiddler、HttpClient抓取
通过postman的拦截器进行记录筛选
有接口文档就很美好啦，但木有的时候就要开动脑筋去创造，虽然通过抓包不能真正的提前介入，但一旦把这些接口获取到，拿来做回归测试也是不错的嘛
postman有一个插件，支持录制，在web上的操作均会录制下来（前提你得把这个插件打开）
2)、接口如何分类，一提到接口测试很多人说我在做接口测试，但是两个人一交流，分类完全不一样，然后就疑惑了，我这到底是不是接口测试，（接口测试可以按照不同维度区分，所以不担心自己做的不是接口测试）
单接口用例如何设计：
json格式测试：
通常我们的接口一般设计的都是传递json串，那么就需要去测试
如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
默认值测试：
很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量，
默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
异常类型测试：
比如上面的count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以
转换为int类型值来测试代码是否加入判断
必传项测试：
如果接口的参数有必传项，那么需要测试在不传这个参数的时候接口返回情况，测试是否会提示
相应的error code
非必传项测试：
如果接口有非必填项，当我不传递这些参数的时候会不会正常的返回相应的结果
非空测试：
无论是必传的和非必传的参数，传递的key是正确的，但是value=null，这时候返回结果是否正确
业务逻辑测试：
传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行
增删改的操作，也需要看数据库是否同步进行了这些操作
兼容性测试：
比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
错误码测试：
通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
数据异常测试：
假如数据库设计为32位varchar类型，那么如果传33位会是什么情况，会不会抛出相应的错误码，而不会抛出数据库异常
返回值测试：
返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
加密测试：
测试参数的加密与解密，使前后端能够减少浪费这方面的时间
组合接口用例设计：
单个的接口测试通过后，需要将单个的接口组成连续的场景，比如说投资接口需要用到一个类似token的参数，而这个参数是登陆接口获取到的，所以就需要先调用登陆接口，然后再去调用投资接口。还有就是像数据权限与操作权限这些，都会依赖一些其他的接口，那么把这些依赖的接口组成一个场景来测试数据的正确性。还有一部分接口是内部调用的，比如说注册接口，在注册的时候通常需要获取一个验证码，然后输入验证码再进行提交注册的操作，在这过程中，验证验证码的操作是在注册的内部完成的，那么其实在组合场景的时候就不需要再去中间加入验证验证码的接口。
接口测试工具的选择：
