处理方式
我们公司的处理方式是:有测试组长进行过滤测试员提出的bug,测试组长将bug指派给PM,PM再进行过滤,最终指派给开发组长,进行bug的最终的处理,如果过程中,对于是否是个bug发生争执,必须有测试组长,开发组长,PM进行共同讨论,最终决定是否是bug,当然测试组长要有足够的理由说明那个问题是个bug,以及不修改带来的后果 首先，是bug提出的无误和简明然后就是公司的缺陷管理流程的问题了
一个良好的工作流程，一般是不会出现这样的问题 如果bug本身不重要的话，并不是非要修改度达到100%，才能发布的，
这个不是测试员要求改 程序员不肯改的问题，需要有个完善的测试制度，这个问题完全可以由“软件在什么阶段可以发布”对应规范来解决 管理问题，不是技术问题。 不是BUG应该要通过审核 我认为沟通的技巧很重要！真的！
这也是一种社会交际能力的体现，不要死板板的丢给程序员说：这个不行！你给我改！
会影响别人的情绪的话自然就矛盾了。
我觉得还是需要沟通，真的不一样！ 敢不改！揍他们！！^_^ 不改可以，让他直接和项目经理说去，有项目经理决定改不改 改不改跟你测试人员有什么关系？ 为什么要头痛？
你只管submit 你认为的 bug，如果它被 fix 了，
你再检测，确认。
如果没有, 那就不是你的事情了，问都不用问。 这跟测试人员没关系，这应该是测试制度的问题，如果有一个明确的测试制度，就不会出现这种问题。
我们公司处理的方法如下：测试员先将缺陷提交给产品经理，产品经理看此缺陷是不是缺陷，如果是缺陷，它将此缺陷分配给相关的开发人员，如果认为不为错误，就和测试人员进行协调，将此缺陷管理；如果认为是缺陷，但是因为时间紧张或其他原因，将此缺陷推迟，将此缺陷状态置为respond状态。 这要看开发组的项目经理怎样说了；他硬是不改那就把责任归他们罗，有什么好烦；我们只有把认为BUG或不合理的地方找出来提交了，责任已经到位；开发的不改也没办法。
当然这应该是少数者吧。而且公司也应该有制度来监督呀，如果还没有制度就建立，要保护自己的权益呀！ 我也经常碰到这种问题，关键是测试人员能从用户的角度陈述问题的严重程度，如果还不改，我们会通知其直接上一级人员或者是PM来决定是否修改。 楼上的说的很对，测试的确要从用户的角度去考虑，不仅仅要考虑到所有需求上的功能点、用户潜在的需求有没有都实现，业务流程有没有矛盾的地方，甚至连用户使用的方便与否，界面设计的合理不合理都是测试的范围。
关于提出的bug程序员不修改的情况，我觉得这个应该是测试工作流程方面的问题，需要测试部门的领导和开发人员的领导之间的沟通。有了明确的工作流程，这些问题就很好解决了。
还有一点比较重要，如果我们测试出有价值的bug，软件质量有了明显的提高，开发人员会很欢迎测试人员的。
当Bug处理有争议时，
应该进行Bug评审。不应该是谁说了算。嫁给他！让他后悔一辈子！
楼上的，厉害！！ 我同意bill_hen的观点 沟通虽然重要，但不应该作为唯一手段
不可能某测试人员和开发人员关系好，他提的bug就更能够得到解决，这样不是做公司，是在过家家。
应该由制度进行保证。
明确测试人员提出的bug由谁来决定是否更改（比如CCB或者开发经理），开发人员可以拒绝，但这个拒绝的过程应该在CCB和开发人员之间进行，如果CCB决定不进行修改，或者不在本版本中修改，那就放到下一版本去，测试人员需要做的，是保证提交的这个bug不丢失。
软件发布通常是由于时间到了，而不是bug都改完了。 记录下来交上去就可以了其他的交给公司制度去管理吧。 增加我们沟通能力，把问题讲清楚。开发人员会尊重你的测试结果的
