大佬们，有没有 接口提测 准入相关文档啊，，
开发现在给我们的接口，感觉只能走正向用例
异常用例 基本全部都是 500, NPE 之类
我的初步看法是，服务端不应该把 500 npe 这种后端错误抛出来，应给出比较友好的提示，
比如
{"msg":"姓名不应为空"}
而不是直接 报个 500， 我就捉摸着 接口如果出现这种情况，直接给开发打回去，为了避免和开发打架斗殴，那么就需要和开发约定一个 提测标准，不知道为公司赋能的大佬们，有没有类似的 和开发对齐的 接口提测准入 文档？
这个看具体是什么样的异常吧。
如果是本身业务逻辑中可能存在的异常（比如查询结果查不到结果之类的），那肯定应该有合适的处理。至于 NPE 这类错误，可以提议让开发同学学一下阿里代码规范，里面就有一条 防止NPE，是程序员的基本修养 。
至于是否暴露具体提示信息这个，线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户，确认下有没有配置就好了，测试环境暴露倒问题不大甚至有助于排查。
不过一个对 NPE 都不在意的开发团队，你要求接口做得很完善，很难。如果不是专门测服务端的话，建议接口保障好各个可能存在的业务场景都能处理好就差不多了，至于那些尽善尽美的东西，不建议一上来就以规范、缺陷的形式来走，容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析，让开发逐步知道这块没做好会有什么危害，对质量逐步有更高要求，再推进到规范，会比较好。
提下个人的看法：
服务端是否应该把程序的内部错误直接暴露出来。这个各有优缺点。好处就是可以比较直观的看到引发问题的根本原因是什么，方便快速定位问题，而不需要去后台查看日志。缺点就是会有安全隐患，容易被定向验证。
一般的处理方式是和前端约定好业务 code，比如 20000 表示业务成功、50001 表示用户名为空之类的，前端根据业务状态码来给出相对应的提示。这样既方便后端定位问题，前端暴露给用户的提示信息也会更友好些，一定不能把异常信息直接在页面上展示出来，太难看了。接口返回不应该只有一个 Http 状态码的。
至于接口的异常类处理，这个每个团队都有自己的做法，这里就不做评价啦。
4.接口提测准入，这个个人不是很建议，我们还是要和开发达成共识。研发中有一条提倡的规则叫 约定大于配置 ，对团队其实也适用。
这个看具体是什么样的异常吧。
如果是本身业务逻辑中可能存在的异常（比如查询结果查不到结果之类的），那肯定应该有合适的处理。至于 NPE 这类错误，可以提议让开发同学学一下阿里代码规范，里面就有一条 防止NPE，是程序员的基本修养 。
至于是否暴露具体提示信息这个，线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户，确认下有没有配置就好了，测试环境暴露倒问题不大甚至有助于排查。
不过一个对 NPE 都不在意的开发团队，你要求接口做得很完善，很难。如果不是专门测服务端的话，建议接口保障好各个可能存在的业务场景都能处理好就差不多了，至于那些尽善尽美的东西，不建议一上来就以规范、缺陷的形式来走，容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析，让开发逐步知道这块没做好会有什么危害，对质量逐步有更高要求，再推进到规范，会比较好。
