在项目过程中，如果开发说这个不是Bug，你的第一反应是什么？

不同的人有不同的处理方式，也许是如下几点：相信开发说的，开发说什么就是什么，问题关闭；自己不能决定，啥都上升到组长或者领导决定；坚持认为这是一个Bug，但是说不出所以然，与开发死扛；

特别是一些易用性的非功能相关问题，或者用户反馈的问题，也可能是一个隐形需求问题。

不管是不是一个Bug或者无法确定，首先都需要将Bug提交到缺陷管理库中。

如果是你，在项目过程中或者面试过程中遇到这个问题，你会怎么处理呢？

下面是一些我处理的方法，也许对你有用，欢迎大家思考的同时补充。

如果是一个正常的Bug，首先看需求有没有定义，如果需求有明确的定义这就是一个严重的Bug，没有商量，开发必须解决，除非需求定义不合理，那是后话；

需求没有定义，但是对用户来说能够增加用户体验，对比设备或竞品也支持，可以找需求或产品核对是否增加该功能，如果明确不增加那就不是Bug，可以不处理；

是一个Bug，但是如果修改这个Bug风险太大，或者说修改的成本太高，结果研发说这个Bug不处理。但是如果修改可以增加用户体验，但是建议前期不修改，这个可以让开发给出风险评估，并拉上相关的人员、包括上级一起确定，是否修改或者遗留到二期需求；

是一个Bug，但是用户遇不到这种场景，例如底层的逻辑，这种如果不知道代码逻辑，或者拉上相关的人员一起评估；

以上说的都是曾对项目前期的问题处理，如果是项目快上线的阶段，这种问题处理就不一样了，毕竟为了项目按时上线，不可能所有的问题都要解决完，因为Bug是测试不完的。因此有一些Bug是可以遗留的下期解决的，这种情况的话需要拉上项目相关的所有人一起进行决策。

测试要有自己的意见和判断力，不能开发说是什么就是什么。任何问题必须要有详细的判断依据和理由，有理有据才是第一步。

所有的Bug处理都需要闭环，要有原因分析、测试建议、测试验证才能走最后的关闭或不处理的状态。

想学习却无从下手，该如何学习？

这里我准备了对应上面的每个知识点的学习资料、可以自学神器，已经项目练手。

世界的模样取决于你凝视它的目光，自己的价值取决于你的追求和心态，一切美好的愿望，不在等待中拥有，而是在奋斗中争取。
如果我的博客对你有帮助、如果你喜欢我的文章内容，请 “点赞” “评论” “收藏” 一键三连哦！