自动化测试系列（四）--实战：如何设计接口自动化测试用例

导读

上一篇跟大家一块讨论了怎么样去选择适合自己的接口自动化测试工具，想必大家也已经有所了解。这一篇还是实战，主要跟大家讨论如何设计接口自动化测试用例。

接口自动化不是单纯请求接口

有些TX可能觉着接口自动化用例无需设计，大不了就把要测试的接口罗列一下，填几个参数值看看接口返回是不是200就好了。非也非也，如果用例真是这样的话，充其量也就是个接口校验。我只是举了一个最为极端的例子，相信做接口自动化测试的TX们肯定不会简单的这么做。那真正的接口测试用例，需要我们注意哪些方面呢？下面就跟大家一块讨论讨论。

接口自动化测试用例设计“真经”

其实，心里优点虚，我这点东西也算不上什么真经（要不能用引号嘛。。。），只是做了几年的接口自动化总结出来的一些经验。大家将就将就，该提出疑问的大家尽管提。

1. 接口用例不能乱，目录结构很重要
   接口用例不能把每个接口名称起一下放在那就完事了，还是建议大家要跟写功能测试用例一样，分模块、分功能。这样在开发用例脚本的时候也能层次清楚，一目了然，比如说要统计哪些模块有多少用例；筛选需要测试的模块用例等等，最重要的是同一个模块可能有很多共用的变量或者方法可以共享。接口用例示例如下表所示：

模块	功能	测试点	参数配置	结果验证
登录模块	快捷登录	正常快捷登录	phone=10086；smsCode=123456	statusCode=200；token=123456
		快捷登录手机号为空	phone=；smsCode=123456	statusCode=200；isSuccess=false
		快捷登录短信验证码为空	phone=10086；smsCode=；	statusCode=200；isSuccess=false
	账密登录	邮箱账号登录	。。。	。。。
注册模块	手机号注册	正常注册	。。。	。。。

2. 接口验证常常需要考虑的情况

• 字段是否为必需字段
• 字段值是否为必填，注意这一条主要是考虑参数是否可以为空值，上一条主要考虑某字段是否可不放在请求接口中。
• 字段值要求的类型，比如字段要求为字符串，测试用例可以设计为非字符串类型。针对字段类型为数值型，还要考虑是否可以为小数、负数、不同小数位数等等。
• 字段值之间的联合校验，比如接口字段中有单价、数量和总价，势必要验证一下总价=单价*数量。
• 返回字段是否完整以及各字段类型是否正确。
• 验证返回字段值时可以考虑与数据库存取的数值对比，而不是只验证返回的数字。
• 接口需要验签的话可以验证签名不正确的情况。
• 每个接口只需一条用例验证所下发字段的完整性，其他用例只需关注测试点。主要是考虑万一有某个字段缺失或者返回值修改，如果所有用例都去验证全部返回字段，则其相关接口的用例都会失败。
  后边想起其他的情况，我再追加，也欢迎各位提供

3. 扩展接口用例，覆盖功能场景
   在之前的自动化测试系列（二）–分层自动化测试中我提到接口自动化测试还有一类是场景化测试，这个其实是个大头，是接口自动化测试替代或着协助部分手工功能测试的意义所在。比如说我想测试删除淘宝购物车某个商品这个接口，我们要完成的就不单单是执行删除购物车商品这个接口，而是需要多个接口构造这个测试场景。如下图所示：
   
   因此，在设计接口自动化测试用例的过程中，除了要针对每个接口单独设计用例之外，还要从功能的层面设计用例，从而达到验证产品业务逻辑的目的。

总结

这一篇主要根据自己的经验跟大家介绍了一下关于接口自动化用例设计的tips，个人之言，仅供参考。欢迎大家评论分享更多的经验。