接口测试 有没有大佬分享一个 接口测试的提测文档?

树叶 · 2022年04月18日 · 最后由 树叶 回复于 2022年04月20日 · 3139 次阅读

大佬们,有没有 接口提测 准入相关文档啊,,
开发现在给我们的接口,感觉只能走正向用例
异常用例 基本全部都是 500, NPE 之类

我的初步看法是,服务端不应该把 500 npe 这种后端错误抛出来,应给出比较友好的提示,
比如

{"msg":"姓名不应为空"}

而不是直接 报个 500, 我就捉摸着 接口如果出现这种情况,直接给开发打回去,为了避免和开发打架斗殴,那么就需要和开发约定一个 提测标准,不知道为公司赋能的大佬们,有没有类似的 和开发对齐的 接口提测准入 文档?

最佳回复

这个看具体是什么样的异常吧。

如果是本身业务逻辑中可能存在的异常(比如查询结果查不到结果之类的),那肯定应该有合适的处理。至于 NPE 这类错误,可以提议让开发同学学一下阿里代码规范,里面就有一条 防止NPE,是程序员的基本修养

至于是否暴露具体提示信息这个,线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户,确认下有没有配置就好了,测试环境暴露倒问题不大甚至有助于排查。

不过一个对 NPE 都不在意的开发团队,你要求接口做得很完善,很难。如果不是专门测服务端的话,建议接口保障好各个可能存在的业务场景都能处理好就差不多了,至于那些尽善尽美的东西,不建议一上来就以规范、缺陷的形式来走,容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析,让开发逐步知道这块没做好会有什么危害,对质量逐步有更高要求,再推进到规范,会比较好。

共收到 5 条回复 时间 点赞

提下个人的看法:

  1. 服务端是否应该把程序的内部错误直接暴露出来。这个各有优缺点。好处就是可以比较直观的看到引发问题的根本原因是什么,方便快速定位问题,而不需要去后台查看日志。缺点就是会有安全隐患,容易被定向验证。

  2. 一般的处理方式是和前端约定好业务 code,比如 20000 表示业务成功、50001 表示用户名为空之类的,前端根据业务状态码来给出相对应的提示。这样既方便后端定位问题,前端暴露给用户的提示信息也会更友好些,一定不能把异常信息直接在页面上展示出来,太难看了。接口返回不应该只有一个 Http 状态码的。

  3. 至于接口的异常类处理,这个每个团队都有自己的做法,这里就不做评价啦。

4.接口提测准入,这个个人不是很建议,我们还是要和开发达成共识。研发中有一条提倡的规则叫 约定大于配置 ,对团队其实也适用。

CKL的思考 回复

嗯嗯, 但是 500 我感觉不应该算做 约定好的 状态码 😂

树叶 回复

500 肯定不算呀,500 是 HTTP 状态码,需要和业务码区分开来的

这个看具体是什么样的异常吧。

如果是本身业务逻辑中可能存在的异常(比如查询结果查不到结果之类的),那肯定应该有合适的处理。至于 NPE 这类错误,可以提议让开发同学学一下阿里代码规范,里面就有一条 防止NPE,是程序员的基本修养

至于是否暴露具体提示信息这个,线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户,确认下有没有配置就好了,测试环境暴露倒问题不大甚至有助于排查。

不过一个对 NPE 都不在意的开发团队,你要求接口做得很完善,很难。如果不是专门测服务端的话,建议接口保障好各个可能存在的业务场景都能处理好就差不多了,至于那些尽善尽美的东西,不建议一上来就以规范、缺陷的形式来走,容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析,让开发逐步知道这块没做好会有什么危害,对质量逐步有更高要求,再推进到规范,会比较好。

陈恒捷 回复

就等大佬的回复了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册