情况是这样的，我新入职了一家公司，领导让我做接口测试（以前他们没做过），我跟开发要了个接口 doc 文档，文档里面只定义了正常传参的格式和正常响应的格式，没有写异常时候的 code 和 message，然后我在测试中发现下面这些问题：
1、必填项只在前端限制必须输入，传空字符串，后台会保存成功的
2、数据类型的校验只在前端做限制，比如密码输入汉字，后台会保存成功的
3、长度的校验，有的后台没做校验，但会在入库时候失败，返回系统处理异常
4、新增用户，需要绑定组织 id，但是传个不存在的组织 id，也会保存成功的，修改删除，传 id 不存在，也会返回成功
5、修改时，参数传 null,返回成功
6、后台没判断用户的权限，比如用户没有新增的权限，但是通过接口新增可以成功
我知道不可能要求开发去对每种异常进行校验，工作量很大，但是我们测试时候应该按照什么标准去定义 “期望结果” 呢？UI 测试我们有需求作为依据，接口测试没有依据供你参考啊
请问大家的公司是怎么对待这种问题的？你们的接口协议文档会详细到定义每种异常响应吗？我上面写的那些，算是 BUG 吗？
建议根据经验先协助研发梳理一些接口通用错误，与领导沟通形成接口开发规范。
在开发规范基础上，再和研发确认好接口问题拆分，具体到哪些类型错误由前端还是后端进行处理。
基于明确的接口规范进行接口测试，要求研发进行通用错误处理，其余的异常一般是要通过测试来进行验证的。结合每次结果汇总分类后，完善接口开发规范
最重要的还是需要和对应领导/主管沟通确认，结合实际业务的情况，确定这些问题或者规范是否需要遵循，还是说前端操作不报错就成
像 4、6 这我觉得已经是逻辑漏洞了吧，其他的长度这些可以商量看看哪一方做校验就行了。
如果是提供给前端的接口，前端可加限制，后端省点活
如果是提供给其他服务的接口，那原则上所有异常都要处理并返回明确的报错原因
49875183
回复
嗯，谢谢你的答复，很详细，我同意你的说法，公司以前没做过接口测试，领导没有这方面的经验，没跟开发沟通过就单方面的要我测，开发都不理解我在干嘛
当接口规范没有一个评判标准时，我觉得需要自己根据当前的业务来判断是否需要添加一些接口层面的限制，同时还需要观察开发的抵触心态，只要觉得自己能够有理有据的说服开发进行修改，还是有必要去反馈自己发现的问题。
你可以整理一个接口测试文档，调整问题的优先级，和开发商量解决方案，从测试角度来说问题我们是都需要反馈的，但不是所有的都要修改，开发人员情绪、团队风格、业务场景、出现概率、领导的建议都需要去参考
遇到过一模一样的情况，然后后端推前端，前端推后端
单从问题来看，罗列的这些其实是平行越权、垂直越权、XSS 等安全问题，肯定是 bug。只是看你们实际情况是否容忍这些 BUG。如果应用不对外，有严格的安全策略，整个系统价值也不大，接口层不做那些验证其实也可以接受，大家都省点事。
如果有价值，可以从风险考虑，此类 BUG 被别有用心的人利用，会造成多大的后果和影响。（都这样了，估计基本属于不设防状态）
对接口测试来说，也许不会对每一个出现的异常都定义，但是对一类异常应该是有定义的。如果没有做过接口测试，可以从接口开发规范着手，建立起一套质量保障体系。
1 楼讲得很好了
不错
测试有一个小的原则，如果一个 BUG，前端能改，后端也能改，那就应该由后端改，因为后端改是最安全，前端有可能存在多处调用，不太可有所有的调用都要做类似的判断。而且，还有部分接口可能是直接给外部用的，类似 OpenApi 这类的。更不可能依赖对别人的信任来处理。
从题主的描述上看，其实更多的是研发规范上的问题，比如删除一个不存在的 ID，长度没校验导致入库失败等等，可以和研发一起确认下。
首先，这个系统的使用对象是谁，对于系统健壮的容忍度高不高；比如如果只是自己团队内部使用，一些交互或者校验可以不严格，但是既然有权限控制，那么基本的越权肯定是要处理的；
其次，如果是对外的，前端要做的拦截限制，接口也必然要做，不能只靠前端拦截，随便抓包就可以篡改，存在极大风险；
再者，对于异常，一定要进行封装再对外展示，甚至统一的内部错误的异常也好，否则你的一些报错信息会把代码细节暴露出去，导致安全问题；
概括下就是，通过现象，告知风险，不要仅仅用标准来强制要求，要让他们明白为什么要这么做，如果团队能够承担上述风险，我觉得那你也不用强求，否则你就列出风险及优化方案将问题上升处理；
CKL的思考
回复
你好，你后半部分抛出了问题 “研发不规范”，这是很多码农都存在的通病。换一个思路想，开发写的代码不规范，那测试如何用一套规范去约束呢。
我目前也是类似的问题，我看了以上的评论和回复，总结下想法：
- 接口自动化优先做核心功能，涉及核心业务的接口，必须要求开发完善接口。
- 在做接口测试的过程中，将接口问题以及可能出现的问题，详细记录，整理一份有说服力的文档。
- 先自己去认识开发，尝试推动去修复。不能推动，再找领导去推动。
我是打算这么做，不过我是已经得到大领导支持了。所以很好推动开发～
风子
回复
- 明确当下不规范的接口问题会带来什么，陈诉厉害关系；
- 找一份接口规范，团队内一起评审，做相关的取舍，达成一致（有很多成熟的接口规范，但不要直接照搬，一定要组内达成认可）
- 测试阶段做对应的测试，把不符合规范的也当成一类 BUG 记录，方便约束大家执行
- 事后总结的时候，对事不对人，用数据说话，和研发领导沟通，逐步落地
并不存在统一的规范，还是要看项目的情况和接口使用的具体场景来确定题主说的问题是否需要修改
1、如果是产品形式，要交给客户方使用和维护，某些问题就需要修改。
2、如果接口要提供给第三方调用，某些问题就需要修改。
3、如果接口只在此项目上使用，而且项目的规模不大，业务场景不负责，问题可以暂时不修改。
4、当然以上分析是要在跟团队沟通、向领导汇报前提下再确认的。
作为测试，把问题暴露出来，由管理层来做决策吧。
当然算是 bug 了 问题提出来 然后积极推动去解决。主要还是看公司对这方面重视不重视