做接口测试做了比较久了，在这段时间里，从想到什么就写什么，到开始针对接口进行用例设计，对接口测试有了一些心得，也一直对一些问题心里有疑惑。

从外部来看，接口由三个部分组成：输入、内部逻辑、输出。因此接口测试用例设计也是从这三个角度考虑。

• 输入：一般按照参数类型进行设计。比如数值类型的参数，就考虑取值范围（等价类、边界值）、特殊值（比如 0、负数）和对于一些枚举值，需要遍历。
• 内部逻辑：一般按照业务约束条件、操作对象权限、状态转换、业务顺序几个角度进行设计，比如关系未绑定不能完成部分功能、用户不可访问非权限内的其他用户信息、当帖子关闭后不能转换为草稿状态等。
• 输出：接口处理正确有正确的返回结果，但是如果出错，可能存在很多错误异常返回（不同的错误码、错误信息显示），根据这些不同的返回结果设计用例。

这些都是从理论出发的，但是在实际测试中，经常遇到的问题是：

比如新增用户角色的接口，当用户 A 登录后，新增一个用户角色，参数权限 code 列表只能从用户 A 所对应的角色所拥有的权限 code 列表中选择，对于一个列表类型的参数，我从输入的角度会想到列表长度和列表元素，从列表长度，由于权限个数并没有规定，为 0 也不会导致不好的结果，所以这方面可以不考虑；从列表元素，可能存在非法成员、合法成员以及重复的成员，而非法成员可能又有不存在的权限 code 和该用户未拥有但是其他用户拥有的权限 code。但我通过测试发现，请求该接口时，如果权限 code 列表中有不存在的权限 code 或者存在重复的权限 code，接口仍然返回成功，而且，新增的角色中的权限 code 列表确实是异常的，去查询角色详情有未被定义的权限 code 和重复的值。
我拿着这个问题去问开发，开发说前端已经限制了用户只能在页面上勾选该用户拥有的权限 code，所以不可能出现不存在的权限和重复的权限值，这个用例不可能发生，所以这个限制后端没必要增加。我看到网上有两种观点，一种是输入参数有些在后端限制，有些在前端限制，因为有些在后端处理反而受益不高，这些就需要加强前端输入的验证，因此这个测试用例确实不可能发生，可以忽略。另一种观点是理论上这个就是 bug，因为可能 UI 有 bug 或者用户通过接口直接调用可能获取到不该获取到的利益，因此接口针对这些进行限制也是很重要的。

这种情况我就很纠结，到底应该按照开发所说，由于前端不可能存在，所以没必要去设计这条用例，还是把这个当成一个异常用例呢？
欢迎大家讨论，也希望大家针对多种接口测试中遇到的情况进行补充。

前端的限制是为了规范用户，后端的限制是为了防御
（忍不住把评论里面大佬的这句话提出来，在设计接口测试用例的时候，总是闪过这句话）