這是軟體測試員面試時經常被問到的問題。看了很多答案，個人覺得作為有工作經驗的測試人員回答時不能完全照搬標準答案，技術面試官想聽的當然不止如此。畢竟這種情況在實際工作中也常常出現，具體問題要具體分析，你的答案最好能妥善解決開發認為不是bug的問題，這也能側面反映測試人員的自我判斷能力和獨立解決問題的能力。能代入自己的想法和測試理念的候選人更有優勢，所以整理了這個問題的答案。（當然，這也不是唯一答案）不足之處，歡迎留言補充。
在面經裡的參考答案通常是醬紫滴，如下：
開發人員說不是bug，有2種情況，
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時，就把需求、設計截圖帶上，自然省去了大多爭議，除非開發確實覺得設計有問題，需要重新進行討論設計的）