工作中，测试人员有时会遇到类似的问题：提交了一份软件缺陷报告，可由于某种原因，无论是开发人员还是开发经理就是不愿修改程序。应如何处理这类问题呢？我认为，当对报告出现分歧意见后，测试工程师应首先做如下第一、二步分析：

　　一、问题确认与评估

　　再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：

　　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，尤其可能影响功能的，应予以说明，提醒用户绕过。