做接口测试做了比较久了，在这段时间里，从想到什么就写什么，到开始针对接口进行用例设计，对接口测试有了一些心得，也一直对一些问题心里有疑惑。
从外部来看，接口由三个部分组成：输入、内部逻辑、输出。因此接口测试用例设计也是从这三个角度考虑。
- 输入：一般按照参数类型进行设计。比如数值类型的参数，就考虑取值范围（等价类、边界值）、特殊值（比如 0、负数）和对于一些枚举值，需要遍历。
- 内部逻辑：一般按照业务约束条件、操作对象权限、状态转换、业务顺序几个角度进行设计，比如关系未绑定不能完成部分功能、用户不可访问非权限内的其他用户信息、当帖子关闭后不能转换为草稿状态等。
- 输出：接口处理正确有正确的返回结果，但是如果出错，可能存在很多错误异常返回（不同的错误码、错误信息显示），根据这些不同的返回结果设计用例。
这些都是从理论出发的，但是在实际测试中，经常遇到的问题是：
比如新增用户角色的接口，当用户 A 登录后，新增一个用户角色，参数权限 code 列表只能从用户 A 所对应的角色所拥有的权限 code 列表中选择，对于一个列表类型的参数，我从输入的角度会想到列表长度和列表元素，从列表长度，由于权限个数并没有规定，为 0 也不会导致不好的结果，所以这方面可以不考虑；从列表元素，可能存在非法成员、合法成员以及重复的成员，而非法成员可能又有不存在的权限 code 和该用户未拥有但是其他用户拥有的权限 code。但我通过测试发现，请求该接口时，如果权限 code 列表中有不存在的权限 code 或者存在重复的权限 code，接口仍然返回成功，而且，新增的角色中的权限 code 列表确实是异常的，去查询角色详情有未被定义的权限 code 和重复的值。
我拿着这个问题去问开发，开发说前端已经限制了用户只能在页面上勾选该用户拥有的权限 code，所以不可能出现不存在的权限和重复的权限值，这个用例不可能发生，所以这个限制后端没必要增加。我看到网上有两种观点，一种是输入参数有些在后端限制，有些在前端限制，因为有些在后端处理反而受益不高，这些就需要加强前端输入的验证，因此这个测试用例确实不可能发生，可以忽略。另一种观点是理论上这个就是 bug，因为可能 UI 有 bug 或者用户通过接口直接调用可能获取到不该获取到的利益，因此接口针对这些进行限制也是很重要的。
这种情况我就很纠结，到底应该按照开发所说，由于前端不可能存在，所以没必要去设计这条用例，还是把这个当成一个异常用例呢？
欢迎大家讨论，也希望大家针对多种接口测试中遇到的情况进行补充。
前端的限制是为了规范用户，后端的限制是为了防御
（忍不住把评论里面大佬的这句话提出来，在设计接口测试用例的时候，总是闪过这句话）
我跳出用例设计看哈~
无论什么测试，都要先从被测系统出发，限制问题的边界，特别是和开发有分歧的时候，更应该如此。
对 2C 的系统，首页一个标点符号错误也是严重问题，因为损害的是公司专业的形象，对于内部系统，部分功能阻断可能都不着急改。
对测试的系统来说，可以从基于风险的测试看，这里有缺陷会如何，影响什么。
单从你描述看，要是内部系统，也不怕有什么越权啥的，无所谓限不限制。要是越权会造成损失甚至服务失效，那就要好好掰扯下了。
另外，前端的限制是为了规范用户，后端的限制是为了防御，两者限制的目的都不一样，可以从这个角度再看用例设计。
前端和后端的由谁做限制应该找项目经理裁定
看是什么业务吧，比如 saas 那种租户隔离的，这个还是有必要做，不管是后台的还是客户端一旦有异常数据在权限里，是有可能引起前端的报错，还有就是数据也可能被越权窃取。
如果是内部自己人用的系统，有问题也不会产生损失，不做也行
设计类似的接口案例确实要考虑 ROI，理论上要验证的，但实际场景中不会触发，这种没必要做。开发修改代码，测试还要验证，实际上不会发生这种场景，这种投入属于浪费资源。
大部分情况下，服务端也是要做限制的，要不纯前端限制，绕过成本很低，会导致一些越权的安全风险。
不过这个还是看实际业务情况。如果是内部业务，外部不可能入侵，不做的风险倒还好。
主要还是看是有存在越权或者潜在的业务风险吧，如果只是加了个特殊的权限值，但是是空权限，这种直接甩给策划呗，当然潜在的风险项就是后续的业务拓展可能会有坑。
我的看法是，这个测试用例真的不可能发生吗？用户的操作千奇百怪，某种情况下可能就真的能绕过前端的限制，我觉得理论上前后端都要限制的，但是实际就。。
小小工具人
回复
您的意思是有两种情况，一种是越权的情况，另一种是加一个不存在的权限值，但是前端显示的是空权限，且由于该权限没有意义，不会对功能产生影响对吗？后者导致后续的业务扩展可能有问题是为什么呢？
我跳出用例设计看哈~
无论什么测试，都要先从被测系统出发，限制问题的边界，特别是和开发有分歧的时候，更应该如此。
对 2C 的系统，首页一个标点符号错误也是严重问题，因为损害的是公司专业的形象，对于内部系统，部分功能阻断可能都不着急改。
对测试的系统来说，可以从基于风险的测试看，这里有缺陷会如何，影响什么。
单从你描述看，要是内部系统，也不怕有什么越权啥的，无所谓限不限制。要是越权会造成损失甚至服务失效，那就要好好掰扯下了。
另外，前端的限制是为了规范用户，后端的限制是为了防御，两者限制的目的都不一样，可以从这个角度再看用例设计。
谢谢，补充一下，这个是外部系统，是给客户用的。
如果是未被定义的权限或者重复的权限值，那么对前端不会产生影响，也不会影响功能，但是查询详情的时候确实接口会返回异常的权限值列表。
如果是当前用户未拥有的权限值，对前端虽然不会产生影响，但是从功能上来说，确实可以通过接口实现创建一个当前用户未拥有的权限的角色，但刚刚看了一下，开发之所以觉得没必要改，是因为前端只会返回当前用户拥有的权限值，所以用户知道一个未知的权限值的概率比较小，所以不知道应该站在风险和投入产出的角度，应该做怎样的抉择。
醋精测试媛
回复
emm，差不多是类似的意思，假设权限对应的特权值只有 1、2，但是通过发包可以让后端写入一个不存在的 3，这个情况很多技术都会说这个情况不存在，操作不出来且无实际影响不用管，从当前的情况来看确实是没问题，但是如果产品后面又拓展个 3 出来，也就是我说的会给后续拓展带来风险了。但是通常意义上来讲，只能通过类似这种方向去推动修改或者丢给产品去 battle。
醋精测试媛
回复
这个我觉得你参考 8 楼的说明吧。
用例是否需要考虑，核心是看你们的项目对越权这块的容忍度。如果这个越权漏洞你能证明可以造成很大的问题（比如删掉某些实际这个用户没有权限删除的内容），我觉得可以把案例摆出来，大家一起决策是否需要修复，然后再进一步扩展到同类型问题，是否要处理。