一、为什么要做接口测试？
①.越底层发现bug，它的修复成本是越低的。
②.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
③.检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。
前端的输入输出很多时候都是提供固守的值让用户选择（如下拉框），在这种情况下测试的边界范围就非常有限，但接口测试就不存在这方面的限制，相对来说接口可以覆盖的范围更广，同样的，接口出现问题的概率也更高。
④.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
⑤. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
⑥. 现在很多系统前后端架构是分离的。
从安全层面来说：
(1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。
二、接口测试测什么？
1.参数必填、非必填，以及value=null、为空
2、默认值测试：
很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
正向用例:带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其它不填写
3、参数类型：
(类型不合法容易遗漏NULL型)
逆向用例:针对每个参数都设计1条参数值类型不符的逆向用例;
4、测试每个参数取值范围不合法的情况、上下限、参数超长
5. json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
6.业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作
7.错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
8.数据异常测试： 假如数据库设计为32位varchar类型，那么如果传33位会是什么情况，会不会抛出相应的错误码，而不会抛出数据库异常