如何處理與開發有爭議的Bug？

 工做中，測試人員有時會遇到相似的問題：提交了一份軟件缺陷報告，可因爲某種緣由，不管是開發人員仍是開發經理就是不肯修改程序。應如何處理這類問題呢？我認爲，當對報告出現分歧意見後，測試工程師應首先作以下第1、二步分析：
    
    1、問題確認與評估
    再次論證該問題確實是程序缺陷，並評估該缺陷的重要程度並對其分類。好比可存在如下分類：
    
    一、設計文檔範圍內的功能性缺陷
    二、影響到程序的安全性和穩定性缺陷
    三、界面缺陷
    四、通常性錯誤（如未考慮邊界檢查等）
    五、邊緣死角，規律不明顯，不太容易重現的錯誤
    六、兼容性錯誤（例如舊機型、CPU\MEM,舊標準等等）
    七、安全性或易用性等的修改建議
    ……（可擴展）
    
    2、明確Dev不修改該缺陷的確切緣由
    好比可存在如下緣由：
    一、規律不明顯，很差重現
    二、dev認爲是不影響主要功能的通常性bug,因時間處於版本的穩按期，擔憂牽一髮動全身引發更多錯誤
    三、調用了第三方組件或庫函，是第三方程序存在的缺陷
    四、存在技術難點
    五、設計自己存在問題，程序邏輯是正確的，但實現結果並不是用戶所需（換言之，dev說這是設計問題，不是程序問題）
    六、Dev的我的主觀意見：
該瑕疵能夠容忍，不必修改
修改該瑕疵會引發更大的問題
    七、Tester和dev對錯誤的理解有分歧：
tester理解錯誤，該問題並非bug
tester沒有說服dev這是個bug
    
    ……（可擴展）
    
    3、具體問題具體分析
    分析完第1、二步以後，也就基本上明確了問題的爭議焦點，而後具體問題具體分析。
    一、若是dev認爲很差重現，則tester有責任和義務找到更簡潔有效的重現規律。
    二、若是tester沒有說服dev認識到這是個缺陷，則須要拿出強有力的證據（測試用例、設計文檔、錯誤現象等）來證實。
    三、對於第三方庫函bug,或技術難點致使的bug,則堅持原則--寧缺勿濫，必要時寧肯封掉該功能。
    四、針對錯誤的設計、不能說服的dev主觀理解、改動隱患，以及穩按期等特殊狀況，則可經過TM進行多方溝通。
    
    4、發揮TM與PM的溝通職責
    強調溝通
    TM和PM有團隊溝通的職責。在bug分類、指派和反饋過程當中出現有爭議的問題時，TM和PM有責任和義務進行干預。根據問題的重要程度和輕重緩急，採起不一樣的方式進行溝通。如出現「三」中三、4類較大爭議的問題，可經過會議研討等形式召集多方進行論證，並達成一致的解決意見，解決方法造成備忘錄。
    
    對因各類緣由繼續保留在發佈版本中的bug,尤爲可能影響功能的，應予以說明，提醒用戶繞過。