“开发认为不是bug，测试如何处理？”很多面试中，测试工程师都会被问到这个问题，不仅仅是面试，工作中测试人员也会遇到这类问题，甚至可能由于某种原因，无论是开发人员还是开发经理就是不愿修改程序，那该如何处理这个棘手的问题呢？
首先，当与开发出现分歧意见后，测试工程师应首先做如下分析：
一、问题确认与评估
再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：
-
1、设计文档范围内的功能性缺陷
-
2、影响到程序的安全性和稳定性缺陷
-
3、界面缺陷
-
4、一般性错误（如未考虑边界检查等）
-
5、边缘死角，规律不明显，不太容易重现的错误
-
6、兼容性错误（例如旧机型、CPU\MEM,旧标准等等）
-
7、安全性或易用性等的修改建议
-
……（可扩展）
二、明确Dev不修改该缺陷的确切原因
比如可存在以下原因：
-
1、规律不明显，不好重现
-
2、dev认为是不影响主要功能的一般性bug,因时间处于版本的稳定期，担心牵一发动全身引起更多错误
-
3、调用了第三方组件或库函，是第三方程序存在的缺陷
-
4、存在技术难点
-
5、设计本身存在问题，程序逻辑是正确的，但实现结果并非用户所需（换言之，dev说这是设计问题，不是程序问题）
-
6、Dev的个人主观意见：
该瑕疵可以容忍，没必要修改
修改该瑕疵会引起更大的问题
-
7、Tester和dev对错误的理解有分歧：
tester理解错误，该问题并不是bug
tester没有说服dev这是个bug
……（可扩展）
三、具体问题具体分析
分析完第一、二步之后，也就基本上明确了问题的争议焦点，然后具体问题具体分析。分析什么Bug会让开发认为不是bug？
-
测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
- 难以复现的Bug
不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
- 有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
- 功能性Bug
与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。
四、发挥TM与PM的沟通职责
强调沟通
TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时，TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急，采取不同的方式进行沟通，达成一致的解决意见，解决方法形成备忘录。
对因各种原因继续保留在发布版本中的bug,尤其可能影响功能的，应予以说明，提醒用户绕过。
经验教训库：这里的每个内容都是一个你犯过的错误，你在这里也记录的总结和反思；随着系统开发不断往前迭代，BUG的内容也会越来越丰富，沉淀了越来越多的经验，帮助我们了解错误原因所在，避免再犯。必须要说的是，一个团队要强大起来，先从自己的BUG系统开始做起。
下面有我近几年的收集和整理，整体是围绕着【软件测试】来进行整理的，主体内容包含：python自动化测试专属视频、Python自动化详细资料、全套面试题等知识内容。
对于软件测试的的朋友来说应该是最全面最完整的面试备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你
关注微信公众号【程序员二黑】即可领取Python自动化测试超硬核资源啦