场景：
测试中，我们经常遇到这样的问题，提交了个bug，开发却回复won‘t fix ，竟然说不是bug
什么bug会让开发认为不是bug？
1、测试人员描述不清晰
体现在步骤描述上有歧义，开发无法按照描述准确的复现步骤，导致可能对问题的描述理解上出现偏差
解决方法：修改bug描述步骤：做到清晰描述、无重复、无冗余，尽量附截图，截图重点位置，用红色标记，截图名字尽量符合截图内容
2、难以复现的bug
有的bug是偶现bug，难以按同样操作步骤复现&有的bug只是在测试环境出现，线上就正常了
解决方法：
难以复现的bug：保存截图和log；尽可能详细的描述进行过的操作，像我们之前测试的棋牌的项目，经常出现卡死，这样的要提供4个玩家的log，因为无法确定是否是其他玩家进行的操作，引起的bug，这种我们就尽量用真人去玩了，更容易发现问题，机器人的话，无法提供机器人log日志
测试环境下出现bug：找研发在测试环境下确认，报告中指出风险
3、有争议的bug
多出现在建议类型的bug，测试人员在测试过程中会对根据经验或者对比竞品提供一些优化的建议，这e类bug特点需求上没有详细给出，肯定开发是没有做的
解决方法：是否需要修改要根据项目的实际需要进行确认，开bug评审会，讨论解决
在时间允许的情况下，项目测试收尾时，对buglist是否修复进行明确处理；时间比较紧产品又认为有修复必要的情况下，可能会延期到下期
4、功能性bug
与需求不符、与原型设计不符。开发对需求没有深入了解可能会忽略或者弄错功能；开发成员之间沟通上的偏差
解决方法：
提bug时把需求、设计相关内容截图，指出依据，避免麻烦
5、当然也会有误提的情况
测试人员对需求理解不明确、出现偏差；环境错误
解决方法：
反复理解需求、确认需求和环境
原文地址：https://www.cnblogs.com/prince365/p/10551411.html