工作中，测试人员有时会遇到类似的问题：提交了一份软件缺陷报告，可由于某种原因，无论是开发人员还是开发经理就是不愿修改程序。应如何处理这类问题呢？我认为，当对报告出现分歧意见后，测试工程师应首先做如下第一、二步分析：
一、问题确认与评估
再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：
1、设计文档范围内的功能性缺陷
2、影响到程序的安全性和稳定性缺陷
3、界面缺陷
4、一般性错误（如未考虑边界检查等）
5、边缘死角，规律不明显，不太容易重现的错误
6、兼容性错误（例如旧机型、CPUMEM,旧标准等等）
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,尤其可能影响功能的，应予以说明，提醒用户绕过。
一、问题确认与评估
再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：
1、设计文档范围内的功能性缺陷
2、影响到程序的安全性和稳定性缺陷
3、界面缺陷
4、一般性错误（如未考虑边界检查等）
5、边缘死角，规律不明显，不太容易重现的错误
6、兼容性错误（例如旧机型、CPUMEM,旧标准等等）
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,尤其可能影响功能的，应予以说明，提醒用户绕过。