你认为是Bug，而开发不认同时怎么办 大家出去面试的时候，应该是经常会被问到就是如果开发人员认为你提交的 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 时提供证据，需求，设计方案，省去争议