接口测试不是单纯请求接口
举一个极端的例子：接口测试实现就是简单的把要测试的接口通过抓包实现实现自动化，入参参数值原方不动的作为入参传参，断言接口返回为200就好了。接口测试没有设计用例，如果真是这样实现接口测试，顶多就算校验接口，其实校验接口也需要根据接口定义设计用例全面覆盖接口测试。那真正的接口测试需要注意哪些方面呢？做了几年的接口自动化总结经验的我跟大家一块讨论讨论。
接口自动化测试用例设计
1.接口用例不能乱，目录结构很重要
接口用例不能把每个接口名称起一下放在那就完事了，还是建议大家要跟写功能测试用例一样，分模块、分功能。这样在开发用例脚本的时候也能层次清楚，一目了然，比如说要统计哪些模块有多少用例；筛选需要测试的模块用例等等，最重要的是同一个模块可能有很多共用的变量或者方法可以共享。接口用例示例如下表所示：
2.接口验证常常需要考虑的情况
· 字段是否为必需字段
字段值是否为必填，注意这一条主要是考虑参数是否可以为空值，上一条主要考虑某字段是否可不放在请求接口中。
字段值要求的类型，比如字段要求为字符串，测试用例可以设计为非字符串类型。针对字段类型为数值型，还要考虑是否可以为小数、负数、不同小数位数等等。
字段值之间的联合校验，比如接口字段中有单价、数量和总价，势必要验证一下总价=单价*数量。
返回字段是否完整以及各字段类型是否正确。
验证返回字段值时可以考虑与数据库存取的数值对比，而不是只验证返回的数字。
接口需要验签的话可以验证签名不正确的情况。
每个接口只需一条用例验证所下发字段的完整性，其他用例只需关注测试点。主要是考虑万一有某个字段缺失或者返回值修改，如果所有用例都去验证全部返回字段，则其相关接口的用例都会失败。
· 我的一个接口校验判断方法：
读接口校验：分别请求基础环境和项目环境，对比两个环境的返回结果，如果一致说明代码改动对此接口用例没有影响，进而可以判定用例校验通过。
写接口校验：一般写接口落库的数据可以通过一个或者多个读接口拿到，那么同样的写接口分别在基础环境和项目环境进行落库，只要对应环境的读接口返回结果一致，那么校验通过。
不论读写，都有一些随机字段，为了降低接入成本，需要提供计算忽略字段能力。
3.扩展接口用例，覆盖功能场景
接口自动化测试还有一类是场景化测试，是接口自动化测试替代或着协助部分手工功能测试的意义所在。比如说我想测试删除淘宝购物车某个商品这个接口，我们要完成的就不单单是执行删除购物车商品这个接口，而是需要多个接口构造这个测试场景。如下图所示：
因此，在设计接口自动化测试用例的过程中，除了要针对每个接口单独设计用例之外，还要从功能的层面设计用例，从而达到验证产品业务逻辑的目的。
接口自动化测试工具对比
适合自己的才是最好的，依据自己要测试的复杂业务接口打造自己的接口自动化测试框架。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
