開發認為不是bug，你該如何處理？

1、需求不確定
可以找來產品經理進行確認需不需要改動，三方商量確定好后再看要不要改。
2、這種情況不可能發生，所以不需要修改
這個時候，我可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以把這個問題提出來，跟開發經理和測試經理進行確認，如果要修改就改，如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是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時，就把需求、設計截圖帶上，自然省去了大多爭議，除非開發確實覺得設計有問題，需要重新進行討論設計的）