首先声明，我不是搬运答案，所有问题我的回答都是个人见解。
总有人忧虑自己是不是长期不跟大部队，就不知道外界的情况了，相信通过这些问答，大家会对整个行业有更清晰的认识和自我的定位。
大家若是想给我提问的，也可以在知乎上直接写问题后邀请我回答哈~
我的主页：https://www.zhihu.com/people/macfan-ren-lei
或者直接搜昵称：我去热饭
如图，为我每天的测试领域问答提醒，我会上去解答或者在公众号同步。
这个【知乎问答】系列我每次更新都会放上中间时间段的最新问题。
我们先来看时间最近的这个:
点击打开，可以看到居然是5分钟前发出的，没想到这大半夜的居然还有人在卷啊，看名字还是个女孩，这么努力的妹子真的很可贵。
咱看看我之前的回答，之前也没有答太详细，咱在公众号补全吧。毕竟公众号可是咱铁打的粉丝，所以答案自然要比公开的知乎上要完整。
接口测试的bug如何提交，这个简单的问题相信几乎所有的同学都有自己的答案，而且是大体相同的。
首先，接口测试的bug也要符合传统功能bug的提交，如果不考虑各种bug平台的话，就要有基础的几个字段：
比如bug标题 ，一句话概括缺陷。
比如bug复现步骤，要尽量详细，还要有触发的环境是什么，机器等
比如bug归属，不能提交给错误的开发同学。
比如bug实际输出/预期输出，要描述所有关键的不同输出。
比如bug的贴图
比如bug的提交人/提交日期，这是最基本的，很多bug平台都是自动填充。
比如bug关联的需求id、自动化脚本id等，这是为了修复后进行测试和追踪
比如bug影响的其他功能，这是为了之后进行周边影响法复测。
比如bug的关键数据，方便开发更好的分析和复现。
比如bug的严重等级，按照功能、后果和影响来判断等级。
比如bug的出现概率/时段等，方便开发更好的修复。
比如bug的定位，有条件的测试也要帮忙定位一下大概代码位置
比如bug的修复帮助，有条件的测试可以提供自己的修复办法给开发同事
比如bug的备注，多人或者多次可以降低沟通成本。
比如bug的最低修复时间，如果特别紧急可以申请让开发同学在时间内修复
以上基本就是一个传统普通功能bug的提交方法，那么接口测试的bug提交，其实就是在其中的 【关键数据】上有所不同，相比较黑盒功能bug，接口更注重的是数据和环境。所以提交的时候，尽量带上接口的请求/返回全部数据，越详细越好。当然如果体量太大，那么你可以只把其中引发错误的字段截取。
还有一点比较重要，就是接口如果出错，很大可能是上下游数据问题，所以你不能光看报错的那个接口，其实它很可能是无辜的，问题原因很可能在它的上游接口，所以要提交bug，尽量给它的上游接口包括其数据也放到bug报告中。
最后再说明下，开发同事虽然拿到了你所有的截图和数据，但是他们一定会亲自触发复现一下，看看是不是真的报错才会心甘。而且有些关键信息bug报告也不一定能全部完整的展现出来，这点相信群里经常帮忙回答别人问题的大佬深有感触，小白提问往往截图截不到关键点。
所以开发同学一般会费劲巴力的重新构造整个请求，或者抓包来复现。
除了复现外，亲自构造复现这个错误接口和其上游接口，也是调试自测修复的必要过程，当然这是一个极其麻烦的过程。
所以如果这时候有个人说，报错的接口和其上游都已经在 公司专属的接口测试平台上部署好了，开发同学可以直接在上面点击一下就能复现和随便调试了.... 那么整个开发流程都会提升很大，开发同学也更愿意去修复bug了。
所以通过这个问题，大家就明白一个接口测试平台的重要性了吧？它不是简简单单postman或者接口文档平台可以替代的，它的作用很多，其中之一就是多人协作，减少内耗，流程规范。
