接口测试实战思路分析

前言

何为接口？如果将接口定义为web服务接口就比较狭义了。我的理解上只要定义了输入方式，定义了中间的业务处理逻辑，定义了输出方式，就算是接口了。接口可以是一个函数，sdk接口，web服务接口等。对这些接口的测试称为“接口测试”。

对于测试，用例的设计决定了测试的全面和准确性，但是我们在设计用例的时经常会有遗漏的点，本文以真实案例对服务端http接口测试用例设计思路进行了总结，总结出服务端接口测试用例设计的方法论。

案例

目前存在中国用户资料补充接口，请求路径：/user/info，请求方式：post

输入：

字段	类型	必填	含义
id	Integer	Y	用户id
name	String	Y	姓名
phone	String	Y	手机号
idCard	String	Y	身份证号

输出：

code	message
0	成功
10000	系统错误
10001	参数缺失
10002	参数错误

思路

常用测试方法覆盖

按照我们通过掌握的测试方法，边界值和等价类划分法等方法进行用例设计

用例1： 正例
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:0,message:成功}

用例2： 用户id库中不存在
前置：id=2用户库中不存在
步骤：输入参数：{id:2,name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例3： 用户id为负数
步骤：输入参数：{id:-1,name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例4： 用户id为非数字
步骤：输入参数：{id:“a”,name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例5： 用户字段缺失
步骤：输入参数：{name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10001,message:参数缺失}

用例6： 用户为空
步骤：输入参数：{id:“”,name:“朱晓明”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例7： 姓名带英文
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓aaa”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例8： 姓名带数字
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓1234”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例9： 姓名字段缺失
前置：id=1用户库中存在
步骤：输入参数：{id:1,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10001,message:参数缺失}

用例10： 姓名字段为空
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“”,phone:“18126339698”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例11： 手机号11位数字中带英文
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339d98”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例12： 手机号没到达11位
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“1812633998”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例13： 手机号超过11位
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“181263399844”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例14： 手机号字段为空
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“”,idCard:“350103199709241698”}
结果：{code:10002,message:参数错误}

用例15： 手机号字段缺失
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,idCard:“350103199709241698”}
结果：{code:10001,message:参数缺失}

用例16： 身份证18位数字中带英文
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”,idCard:“3501031997s9241698”}
结果：{code:10002,message:参数错误}

用例17： 身份证没到达18位
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”,idCard:“35010319979241698”}
结果：{code:10002,message:参数错误}

用例18： 身份证超过18位
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”,idCard:“3501031997449241698”}
结果：{code:10002,message:参数错误}

用例19： 身份证为空
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”,idCard:“”}
结果：{code:10002,message:参数错误}

用例20： 身份证字段缺失
前置：id=1用户库中存在
步骤：输入参数：{id:1,name:“朱晓明”,phone:“18126339698”}
结果：{code:10001,message:参数缺失}

至此，使用等价类划分分析后得出了以上用例

根据业务经验补充用例

如果有经验的测试工程师，还要增加一些针对字段的特殊的输入，逻辑校验，业务特点相关的测试用例

测试点21：
针对name字段，由于新疆人名字里面会带有“·”，输入新疆带·名字，保证服务端可以正常解析

测试点22：
输入的汉字有全角和半角

测试点23：
name字段输入生僻字，服务端没有异常返回

测试点24：
idcard字段，数字尾位为X和x，服务端识别，解析正确

测试点25：
姓名和身份证不匹配情况

再加上上面的这部分用例集，你可能觉得这下应该很全面了，现在你可能也发现了上面所有的用例都是针对显式功能进行验证的，也就是说上面的用例都是针对接口的输入进行验证了，那么想要保证接口的质量非功能性的验证也是及其关键的。

非功能用例分析

比较常见的非功能测试，大家最常见的就是安全测试和性能测试了，针对这些测试我们可以设计相关的用例集

安全

测试点26：
由于业务性质和接口三个字段都是涉及到个人隐私的，接口字段是否进行加密

测试点27：
是否存在sql注入

性能

测试点28：
选取正例进行接口压测，qps，响应时间，内存，cpu等指标是否符合预期

其他

这部分测试过程中可能不经常关注，研发在开发的时候已经注意了这方便的处理，这个要根据具体的业务特征进行分析，有时候研发考虑不足我们帮助补充也是一种质量的保证。

缓存

测试点29：
很多服务接口都会用到缓存，特别是读频繁的接口，为了提高接口的性能，降低对数据库的访问频率。思考该接口是否需要使用缓存来增加性能指标

幂等

定义：
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。

例子：
支付业务中，一个用户提交了相同两次的订单，也就是调用了2次接口，只能扣一次钱，也就是只能生效一次。第一次调用和第二次调用结果是相同的

测试点30：
该接口是否需要幂等，如果为幂等接口，需要进行幂等测试

事务

事务是恢复和并发控制的基本单位。
事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。
原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。
一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。
隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

测试点31：
这个确实不太好测试，只能通过把服务器压爆之类的方法看看数据是否回滚。这一块主要由研发保障，一般spring中接口的事务一般加上@Transaction注解即可。

总结

以上是接口测试的一些思路总结，拿到一个接口后按照上面思路理一遍基本就可以做到比较全面的测试了。

参考资料

qxq的km《接口测试打怪升级》