接口测试用例设计的一点总结

背景

最近项目中也一直在推动接口测试，中途也遇到很多的问题；从最开始的接口文档管理，接口测试框架的选型，到后续接口测试用例的维护问题。最近在想接口测试的一个覆盖度问题。谈到覆盖度，又得回到接口测试的用例设计上面；网络上又很多接口测试用例的设计资料，无非是罗列一些维度，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+的情况，看是否有进行处理？

最后

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