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