接口测试

接口测试，狭义来讲，就是针对系统组件间接口的测试。广义角度，可以拓宽至某个模块、功能，甚至单独某个方法，设计测试用例时，都可相互借用，从如下不同角度考虑，避免遗漏。
1、入参
主要针对参数的长度、类型、非空，甚至参数的个数、顺序，设计测试用例
2、出参
出参主要分两种情况：
一种是无结果，比如接口超时（该点与4、业务整体链路-超时类似，但再次强调，本文仅是从不同角度设计测试用例，而不是最终输出的测试用例）时，是否有重试机制、多次执行时是否有业务上的问题，比如因多次触发发券导致的资产损失等。
另外一种就是有结果，包括正常的结果与错误的结果。正常的结果即返回诸如success，表示接口执行了我们预期的功能，属于最最基本的正向验证。错误的结果是对一般问题的容错兼容，能使得接口或者功能、方法更加完善尽可能的罗列全，并对每一种错误码进行覆盖验证。
3、内部逻辑
此处主要针对接口的内部逻辑进行验证（若是接口，画出对应流程图；若是方法，了解对应分支判断逻辑），涉及各个不同的分支以及基本功能。比如用户满足15积分可兑换一张券。设计出满足、不满足15积分以及超过15积分可否频繁兑换等。
4、业务整体链路
从业务流的角度来讲，每个接口，都是这个流中的一环，在这个串行结构中，既有上游的调用方，也有下游的依赖方。这个角度，主要考虑当接口不能正常执行（如超时）或者重复执行，对上下游以及整体业务的影响。
5、安全性
此处主要分两个方面：一是接口输入脚本，如js脚本，html脚本等时是否能正常处理（测试用例最终设计出来，可能和1、入参中类型重合）；还有就是整个请求、响应过程中，针对敏感数据，是否做了脱敏处理。
二是鉴权方面的验证，比如一个方法作用是删除文件，但如果没有删除权限时是否做好了兼容。
6、性能&并发
该点为接口面对大量请求时，其瓶颈上限在哪里。此外，并发也是需要考虑的一点，如秒杀、爆款之类因库存数量限制，只能部分请求成功，其他均失败不会出现“超售”的现象。
ps:个人认为，并发更多是偏功能性验证，但因大多时候需要用到工具辅助，与性能很类似，此处放在一起考了。
7、其他
此处主要针对接口包含的内容、参数是否满足预期要求，是否冗余或缺少字段；其次，就是接口是否新实现，有没有老的接口实现类似功能，若有，做如何处理。
ps：受个人水平所限，暂时想到这些，后续会持续更新