【測試】如何處理與開發人員有爭議的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
    
    ……（可擴充）
    
    三、具體問題具體分析
    
    分析完第一、二步之後，也就基本上明確了問題的爭議焦點，然後具體問題具體分析。
    
    1、如果dev認為不好重現，則tester有責任和義務找到更簡潔有效重現規律。
    
    2、如果tester沒有說服dev認識到這是個缺陷，則需要拿出強有力的證據（測試案例、設計文檔、錯誤現象等）來證明。
    
    3、對於第三方庫函bug,或技術痛點導致的bug,則堅持原則--寧缺勿濫，必要時寧可封掉該功能。
    
    4、針對錯誤的設計、不能說服的dev主觀理解、改動隱患，以及穩定期等特殊情況，則可通過TM進行多方溝通。
    
    四、發揮TM與PM的溝通職責
    
    強調溝通
    
    TM和PM有團隊溝通的職責。在bug分類、指派和反饋過程中出現有爭議的問題時，TM和PM有責任和義務進行幹預。根據問題的重要程度和輕重緩急，採取不同的方式進行溝通。如出現“三”中3、4類較大爭議的問題，可通過會議研討等形式召集多方進行論證，並達成一致的解決意見，解決方案形成備忘錄。
    
    對因各種原因繼續保留在發布版本中的bug,尤其可能影響功能的，應予以說明，提醒使用者繞過。