前言
大家出去面试的时候，应该是经常会被问到就是如果开发人员认为你提交的 bug 不是一个 bug，这时候你怎么办？
其实这个问题面试官想要考察的就是大家对于 Bug 有没有自己的判断，还有就是在工作当中的一些软实力，比如说处理问题的思路。
那遇到这个问题可以用什么思路去回答呢？
回答思路
首先可以先来分析一下什么样的 Bug 会让开发认为不是 bug
- 测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现 Bug 不知所云，搞错了问题所在。
看我们怎么判定我们发现的问题是一个 Bug 呢？其实是有一定的判断标准的：
1). 软件未达到客户需求文档的功能和性能
2). 软件出现客户需求不能容忍的错误
3). 软件的使用未能符合客户的习惯和工作环境
4). 软件超出需求文档的范围
只要是符合了这几个标准其中的一条，就可以断定它是一个 bug。
描述不清晰的解决方法：
- 修改 Bug 操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个 Bug，也能按照你的操作步骤复现。
- 有图有真相：带有清晰说明的截图比一大推描述来得直观，易懂。注意对问题区域以强调色标识，并配以文字说明
- 难以复现的 Bug
不是所有的问题都能用同样的操作步骤来复现的，有的 Bug 概率出现甚至偶现，或者是只在测试环境里出现。
难以复现的解决办法：
- 针对难以复现的 Bug，需要保存截图或者记录 log 保留证据
- 对于只在测试环境下才会出现的，找研发在测试环境进行确认
总之，这类 Bug 要慎重对待，重点要规避风险。
- 有争议的 Bug
有争议的 Bug 多发生于建议类型的 Bug，比如易用性、美观性等类型的 Bug。
有争议的解决办法：
- 开会讨论：这种问题是否要修改需要根据公司的项目类型进行讨论。在时间允许的情况下，可以在项目测试接近收尾时开一个 bug 清除会议，对于剩余 bug 是否修复做明确处理
- 功能性 Bug
这类 Bug 就是与需求不符、或者与原型设计不符。因为有时候开发对需求没有深入了解可能会忽略或者搞错个别功能。
功能性问题解决办法：
- 拿证据：提 Bug 时，把需求、设计截图带上，可以省去了大多争议
- 开会讨论：如果开发确实觉得设计有问题，需要重新进行讨论设计
总结
所以如果大家出去面试被问到这个问题，大家最重要的是展现自己解决问题的思路。
- 测试人员描述不清晰：提高自己的业务水平
- 难以复现的 Bug：留好截图和 log，保留证据，做好记录
- 有争议的 Bug：建议类问题开会讨论
- 功能性 Bug：需求理解不一致时，提 Bug 时提供证据，需求，设计方案，省去争议