开发认为不是bug，测试怎么办？

这也是测试同学面试时经常被问到的问题。

我也看了很多关于这方面的答案，个人觉得作为有工作经验的测试，这种情况在实际工作中也常常出现，需要具体问题具体分析，你的答案最好能妥善解决开发认为不是bug的问题，这也能侧面反映测试人员的自我判断能力和独立解决问题的能力。能代入自己的想法和测试理念的候选人更有优势，所以整理了这个问题的答案。（当然，这也不是唯一答案）不足之处，欢迎留言补充。

分析为什么开发认为不是bug

1、测试人员描述不清晰

工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。

解决方法：

修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。

（重要的是：有图有真相，带有清晰说明的截图比一大推描述来得直观，易懂。注意对问题区域以强调色（如红色）标识，并配以名字说明）

2、难以复现的Bug

不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。

解决办法：

针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。

3、有争议的Bug

有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。

解决办法：

这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。

（在时间允许的情况下，在项目测试接近收尾时开一个bug清除会议，对于剩余bug是否修复做明确处理）

4、功能性Bug

与需求不符、与原型设计不符。有时候开发对需求没有深入了解可能会忽略或者搞错个别功能。

解决办法：

拿证据（需求、设计说明书）给他看，这种bug自然合情合理。（最好在提bug时，就把需求、设计截图带上，自然省去了大多争议，除非开发确实觉得设计有问题，需要重新进行讨论设计的）

其中，因为需求不明确问题，开发不改不管的事经常发生，很多问题都是需要测试沟通协调。我们要做的就是把bug提到bug管理平台，做好备注，并且每天check一遍这些问题如何进行解决。