接口测试用例设计一点点(转)

上一篇 / 下一篇  2019-05-27 17:41:27

最近在想接口测试的一个覆盖度问题。谈到覆盖度,又得回到接口测试的用例设计上面;网络上又很多接口测试用例的设计资料,无非是罗列一些维度,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+的情况,看是否有进行处理?

最后

通过结合以上的方法进行接口测试用例设计,即使参数组合再多,也能够条理很清晰地罗列出测试用例,而不缺乏覆盖度。


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2019-07-17  
 123456
78910111213
14151617181920
21222324252627
28293031   

数据统计

  • 访问量: 5198
  • 日志数: 17
  • 书签数: 21
  • 建立时间: 2016-10-11
  • 更新时间: 2019-06-25

RSS订阅

Open Toolbar