接口测试分两步走：通过接口设计用例 + 结合业务逻辑来设计用例
通过接口设计用例
1、通过性验证： 首先要保证这个接口功能是可用的，也就是正常的通过性测试。紧接着我们按照接口文档上的参数，正常传入，观察是否可以返回正确的结果。
2、参数组合： 现在有一个操作商品的接口，有个字段type，传 1 时 代表修改商品，商品id、商品名称、价格中有一个必传的。type 传 2时的时候是删除商品，商品id 是必传的，紧接着我们就要测参数组合（俗话说就是分情况）了，type 传1 的时候，只传商品名称能否修改成功，id 、名称、价格都传的时候能否修改成功。
3、 接口安全
- 绕过验证
举个栗子比如说，购买了一个商品，它的价格是300元，那在提交订单时，将这个商品的价格修改为0 元，并且后端也没有做校验。那么我们将"零元购"！这对商家来说是极大的损失
- 绕过身份验证
以修改商品信息接口为例，必须是卖家才有权限修改
情况1： 那如果我们普通用户从接口中传入自己的身份id 为卖家，此时后端没有相应的逻辑校验 ，那么我们普通用户将获得卖家的权限。
情况2： 如果我们将普通用户id 传入，若后端没有相应的动作权限限制，我们普通用户也可以修改商品信息
- 参数是否加密
比如说我们登录的接口，用户名和密码是否加密，如果不加密的话。别人使用抓包工具时拦截到我们的请求，就可以轻易的获取我们的信息 此外加密规则也要进行检验，查看它是否容易被破解
- 密码安全规则，密码复杂程度的校验
4、 异常验证：
异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
结合业务逻辑设计用例
根据业务逻辑来设计的话，具体要看自己的业务是怎样的。每个人的业务不同，设计的用例也不同。但其实这也和功能测试设计用例是一样的。
以贴吧举例，假设贴吧的需求是这样的：
- 登录失败5次， 就需要等待15 分钟之后再登录
- 新注册的用户需要过了观察期才能发帖
- 删除帖子扣除积分
- ...
像这样需要把这些测试点列出来，然后再去造数据测试对应的测试点