在測試過程中，難免遇到開發人員因為一些原因不想修改個別bug的情況。遇到這種問題時，該如何去推進開發修改bug呢？
一、現狀分析
1、開發人員為啥不願意修復BUG？
（1）開發與測試對bug的定義理解不一致產生的問題，bug路徑較深，無法重現， 修改bug改動較大，影響范圍廣，無法理解，在生產環境不可能發生的時間，環境問題，不影響程序的實際用戶使用；
（2）工作流程方面原因，沒時間，問題太小（優先級低），上線時間緊急，非自己名下的BUG（相關人員以離職后的BUG）；
（3）個人能力原因，找不到解決方案，影響范圍大，找不到原因，技術難以實現；
（4）不可抗力客觀因素，例如系統問題，第三方應用問題等等。
2、測試人員為啥苦惱？
（1）測試人員希望上線前所有的BUG都fix（強迫症），避免在生產環境時出現問題，造成不可能挽回的損失；
（2）測試人員在說服開發修復BUG時，發現影響范圍過大時，涉及多方溝通，耗時間；
（3）測試人員技術水平低，研發人員因為在開發技術上的優勢，常常會對測試存在一定偏見，不深刻了解開發成本，難以說服開發去修復BUG，例如只需要加一個字段就解決的問題，測試不了解開發的工作量，以為很難，就輕易放棄修復BUG；
（4）測試人員不夠熟悉產品，沒說服開發的技巧。
二、如何說服開發修復BUG
1、做一個聰明的測試工程師
（1）養成良好的報告編寫習慣：將自己的bug描述的細致清晰，確保自己能重現BUG的過程，用事實和數據說明問題的風險；
（2）規范測試規范；
（3）注意和研發人員的溝通技巧，談話時，要注意溝通技巧，要有換位思維的方式，做事情對事不對人，處理事情一定要有一顆寬容的心。只有這樣，才能夠很好的說服研發去修改Bug；
（4）和研發人員搞好私人關系，做研發的聽眾；
（5）學習編程，理解BUG產生原因還有預算BUG修復成本，提高測試技術。
2、思路下手
（1）解釋問題會怎樣影響產品的正常使用？
（2）會破壞什么數據？
（3）用戶如何經常遇到這個問題？
（4）市面上類似產品的有關評論
（5）指出類似的問題給客戶帶來的麻煩
（6）多引用技術支持收集的數據
（7）以前的版本通過了這個功能的測試
（8）與其他項目干系人溝通。找出如果程序錯誤不修改受影響最大的人（或修改后受益的人），確定程序錯誤會給他們帶來多大麻煩。讓關心這個模塊的人去說服。不必堅持修改所有bug。項目經理可能會因為風險、費用等方面的原因，拒絕修改某些bug，這種情況下，我們測試員不需要堅持修改全部缺陷，除非能說明某缺陷可能引入的嚴重風險。
（9）列舉一些場景，說明合理的用戶在合理地使用程序時會遇到的程序錯誤，或產生的疑問。
（10）補充做一些后續測試，尋找該程序錯誤更嚴重的后果，或尋找比在錯誤報告中所描述的更廣環境下出現的情況。如果程序員不修改某bug而我們決定反駁，不要完全依賴自己最初測試報告中的語言和信息。盡可能做一些補充測試，或列舉更有效的例子，否則不僅浪費自己的時間，而且損害自己的信譽，影響自身的說服力。
3、人脈
（1）扭轉研發領導的思想，重視BUG，提高研發人員的響應速度
（2）與其他項目干系人溝通。找出如果程序錯誤不修改受影響最大的人（或修改后受益的人），確定程序錯誤會給他們帶來多大麻煩。讓關心這個模塊的人去說服。
三、總結
bug修不修，測試應有自己的原則，同時要權衡利弊。不能因為推不動開發，就放棄，由着bug上線，也不能揪着一個小bug不放，影響上線時間。推動開發人員修復bug需要技巧，你get了嗎？