背景
最近在想接口测试的一个覆盖度问题。谈到覆盖度,又得回到接口测试的用例设计上面;网络上又很多接口测试用例的设计资料,无非是罗列一些维度,e.g.参数组合,业务场景等,但都不够系统和结构化,没法快速做到用例有效却不冗余,尤其是在接口参数较多的情况下。
接口测试用例设计关注点
●前提条件:比如一个发帖接口,前提是需要登陆
●参数是否必填
●参数间是否存在关联
●参数取值范围
●业务规则
单接口用例设计方法
接口测试其实可以等同于功能测试,只是被测对象是接口,无界面交互而已;所以用例设计的方法是通用的。
等价类划分法
边界值分析
因果图判定法
场景分析法
具体示例
一个简单的登陆接口为例,假设文档如下:
首先对请求参数组合进行分析:
phoneNumber参数可分为如下几种情况:
1.类型为String,且长度不超过11位
2.类型为String,且长度超过11位
3.类型不为String
4.不带参数
password参数可分为如下几种情况:
1.类型为String
2.类型不为String
3.不带参数
4*3组合总共会有12种情况,得到判定表如下:
根据等价类划分的原则,一个参数错误和两个参数错误是等价的,所以把两个参数错误的去掉,精简后的判定表如下:
综合判定表,我们进行用例转换得到如下用例:
1.phoneNumber和password参数正确,登陆成功
2.phoneNumber参数正确,password类型不为String,登陆失败
3.phoneNumber参数正确,password参数缺失,登陆失败
4.password参数正确,phoneNumber超过11位,登陆失败
5.password参数正确,phoneNumber不为String,登陆失败
6.password参数正确,phoneNumber参数缺失,登陆失败
参数组合的情况考虑完后,我们结合业务场景和接口返回码进行分析,比如,可得到如下几种情况:
1.用户名密码正确,返回登陆成功
2.用户未注册,返回登陆失败
3.密码错误,返回登陆失败
目前通过参数组合和场景分析的情况,可得到9条用例;由于参数组合第一条和场景分析第一条是同一个情况,去重后,我们得到实际有效的8条用例:
备注
在实际接口测试中,在传参方面有时候还需要考虑以下两种情况,e.g.
1.参数故意传入空字符串或null,可看是否有进行处理?
2.参数故意传入超过取值类型的最大值,如int,传入2147483647+的情况,看是否有进行处理?
最后
通过结合以上的方法进行接口测试用例设计,即使参数组合再多,也能够条理很清晰地罗列出测试用例,而不缺乏覆盖度。
对软件测试感兴趣的也可以关注我的公众号:程序员二黑,专注于软件测试分享,主要分享测试基础、接口测试、性能测试、自动化测试、TestOps架构JmeterLoad、Runner、Fiddler、MySql、Linux、简历优化、面试技巧以及大型测试项目实战视频资料,感兴趣的可以关注一下
精彩的内容要和朋友分享哦