背景 最近在想接口测试的一个覆盖度问题。谈到覆盖度，又得回到接口测试的用例设计上面；网络上又很多接口测试用例的设计资料，无非是罗列一些维度，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+的情况，看是否有进行处理？ 最后 通过结合以上的方法进行接口测试用例设计，即使参数组合再多，也能够条理很清晰地罗列出测试用例，而不缺乏覆盖度。
【大佬说】面试应储备的技能和如何躲避面试雷区
首先对请求参数组合进行分析： 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+的情况，看是否有进行处理？ 最后 通过结合以上的方法进行接口测试用例设计，即使参数组合再多，也能够条理很清晰地罗列出测试用例，而不缺乏覆盖度。 【大佬说】面试应储备的技能和如何躲避面试雷区
