开发认为不是BUG？如何让解决？

1. 测试人员描述不清晰

工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。

2. 难以复现的Bug

不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。

3. 有争议的Bug

有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。

4. 功能性Bug

与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。
————————————————
版权声明：本文为CSDN博主「JLL95」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Strive_0902/article/details/82775273