接口测试设计及接口自动化工具分享

接口测试不是单纯请求接口

举一个极端的例子：接口测试实现就是简单的把要测试的接口通过抓包实现实现自动化，入参参数值原方不动的作为入参传参，断言接口返回为200就好了。接口测试没有设计用例，如果真是这样实现接口测试，顶多就算校验接口，其实校验接口也需要根据接口定义设计用例全面覆盖接口测试。那真正的接口测试需要注意哪些方面呢？做了几年的接口自动化总结经验的我跟大家一块讨论讨论。

接口自动化测试用例设计

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.  扩展接口用例，覆盖功能场景

接口自动化测试还有一类是场景化测试，是接口自动化测试替代或着协助部分手工功能测试的意义所在。比如说我想测试删除淘宝购物车某个商品这个接口，我们要完成的就不单单是执行删除购物车商品这个接口，而是需要多个接口构造这个测试场景。如下图所示：

因此，在设计接口自动化测试用例的过程中，除了要针对每个接口单独设计用例之外，还要从功能的层面设计用例，从而达到验证产品业务逻辑的目的。

接口自动化测试工具对比

适合自己的才是最好的，依据自己要测试的复杂业务接口打造自己的接口自动化测试框架。

工具	学习成本	录制	持续集成	测试报告	用例管理	性能测试	扩展难度	最低要求
Java+rest-assured	高	否	支持	支持	难	支持	高	Java
Python+Unittest+Request	高	否	支持	支持	难	支持	高	Python
Roberframework	低	否	支持	支持	易	不支持	高	Python
Httprunner	低	是	支持	支持	易	支持	高	Python
Postman+Newman	低	是	支持	支持	易	收费支持	中	JavaScript
Jmeter+Ant	低	是	支持	支持	难	支持	中	Java
Vue+Flask&jango	高	是	支持	支持	易	支持	高	Python