在项目过程中，如果开发说这个不是Bug，你的第一反应是什么？
不同的人有不同的处理方式，也许是如下几点：相信开发说的，开发说什么就是什么，问题关闭；自己不能决定，啥都上升到组长或者领导决定；坚持认为这是一个Bug，但是说不出所以然，与开发死扛；
特别是一些易用性的非功能相关问题，或者用户反馈的问题，也可能是一个隐形需求问题。
不管是不是一个Bug或者无法确定，首先都需要将Bug提交到缺陷管理库中。
如果是你，在项目过程中或者面试过程中遇到这个问题，你会怎么处理呢？
下面是一些我处理的方法，也许对你有用，欢迎大家思考的同时补充。
如果是一个正常的Bug，首先看需求有没有定义，如果需求有明确的定义这就是一个严重的Bug，没有商量，开发必须解决，除非需求定义不合理，那是后话；
需求没有定义，但是对用户来说能够增加用户体验，对比设备或竞品也支持，可以找需求或产品核对是否增加该功能，如果明确不增加那就不是Bug，可以不处理；
是一个Bug，但是如果修改这个Bug风险太大，或者说修改的成本太高，结果研发说这个Bug不处理。但是如果修改可以增加用户体验，但是建议前期不修改，这个可以让开发给出风险评估，并拉上相关的人员、包括上级一起确定，是否修改或者遗留到二期需求；
是一个Bug，但是用户遇不到这种场景，例如底层的逻辑，这种如果不知道代码逻辑，或者拉上相关的人员一起评估；
以上说的都是曾对项目前期的问题处理，如果是项目快上线的阶段，这种问题处理就不一样了，毕竟为了项目按时上线，不可能所有的问题都要解决完，因为Bug是测试不完的。因此有一些Bug是可以遗留的下期解决的，这种情况的话需要拉上项目相关的所有人一起进行决策。
测试要有自己的意见和判断力，不能开发说是什么就是什么。任何问题必须要有详细的判断依据和理由，有理有据才是第一步。
所有的Bug处理都需要闭环，要有原因分析、测试建议、测试验证才能走最后的关闭或不处理的状态。
源自公众号 软件测试艺术