sun_0910同学，收到那么多鲜花，答题确实很有水平
高手总归是高手呀！！经验丰富、思路清晰，很值得我们测试界的同行学习或研究。 根据我个人经历和工作经验来说1，首先确认这的确是一个BUG，BUG分为两种，一种软件本身存在设计或编码缺陷。这个一般开发都会主动改，因为直接影响软件质量。
第2种，测试人员认为会设计影响用户操作或功能不符合用户要求的功能。这种情况很可能被拒绝。
2，上报测试经理，在提交缺陷时，写清楚缺陷等级和真实环境什么情况下必定或可能引发这个缺陷，会造成什么样的后果，甚至多大的经济损失。让测试经理去和开发经理开会争论，实际后果大的BUG一般都能通过讨论决定要改。
3，依靠个人口才，跟开发人员讲道理。讲用户使用难处，可能引起产品损失，造成他的奖金蒸发。开发人员如果考虑到改动难度不太大，可能会克服懒惰思想改正。
4，强行争论，吵架，是没什么用的，毕竟以后还要合作。那样以后他不会给你帮助的。
发表一下我的看法吧。
工作当中经常会遇到这种情况，测试人员发现bug，但是开发人员却并不承认这是个bug而找理由不去修改。虽然上报经理让经理命令开发人
员修改bug是有效的方法，但是如果找经理的次数过多必然会引起经理
的反感，那么怎么班呢？我认为可采取如下几个步骤：
1.首先你要跟开发沟通，讲明需要修改的必要性。当然要注意沟通的
方式，切忌强行争论，要注意说话的语气等，如“您能告诉我不需要
的修改的原因吗？...”
2.如果开发坚决认为不用修改，那么你要再次分析此bug是不是真正的
bug，如果你觉得是要修改的，那么你写好一个bug备忘单，然后再找
开发沟通（同样是和平商讨），如果他不改，那么让他在bug单上签名
，让他来负责。一般情况下只要让他签字负责，他就会自愿去修改的
。
3.如果你觉得此bug需要上报经理，那么你同样要与开发沟通，商议一
起去找经理，让经理决定该bug是否要修改，或确定修改的优先级。（
你要确保开发人员知道你去找经理，切忌背着开发找经理，这样会影
响你们的合作。） 由于我做过两年的开发，5年的测试，在测试过程中，自己也做过些测试工具，也有测试人员对我的测试工具来进行测试的经历，所以我首先站在一个开发人员的角度来看，什么样的bug与测试人员能说服我呢？要说这个问题，我们首先要有有一个假定：假定开发人员不是一个神经病（多数其实都不是，如果是，那么应该由人力资源部负责），既然开发人员不是神经病，那么你一定要相信他对于自己所做的模块也是抱着认真负责的态度，希望把功能顺利实现，而不会出现什么意外状况的，所以当有人给我提出一个bug是我确实没有想到的，而又实在的影响到这个模块的功能，我做为一个开发人员会考虑修改这个问题，如果这个问题还有一点点深度，我会更加开心，抱着挑战的态度，也抱着赶快把此功能搞定的急迫心情去修改它，由此得到一个好的绩效与认同，所以像这样的bug，需要测试人员来说服我么？当然不需要。然后再看看什么样的问题我不喜欢，曾经我做过一个测试工具，新来的测试人员对我的工具进行了测试，在测试的同时，也使新人学习了各种业务知识，在这些测试者中，我就很明显的对那种能提出功能性错误，或者我考虑不周造成的错误（这一定要用专业的测试方法才能测出的）的新人，我会报着一种对他的欣赏的态度去修改他提出的问题，而对那些，没事找事，总是按自己的主观意愿提出一些使用上问题的人，给以鄙视，比如新来的测试负责人，在我修改完所有问题后，叫我把下拉框改成tab页，嘿嘿，你喜欢tab页，我就喜欢下拉框，测试部难到没有别的事情做了吗，做这么无聊的事，也就是说，有关操作习惯问题本就是你有你的习惯，我有我的习惯，凭什么就说你的习惯是代表了广大人民群众呢？是吧？
看了上面一段，相信大家就知道了什么样的问题会得到认同，这样的问题，根本不用你去说服谁，但是，这个世界如果如此简单，就不会有战争了，是吧，所以，我刚才说的只是开发人员的立场，说这些只是让大家明白一个心理特性，并不意味着，开发人员的这种立场在任何场景都是正确的。
所以，还有一个测试人员的立场问题，对测试而言，我们有各种测试方法去发现bug，有时有的测试方法做出来的测试结果确实发现了问题，但这个问题可能会引发开发人员的反感，这是因为开发人员对测试的工作不了解造成的，比如，我们用边界测试发现一个问题，但开发人员会说，谁会去输入这样的数值呢，在实际工作中，人家是不会这样操作的，所以拒绝修改这样的问题，怎么办呢？这个时候，其实如果一味的让每个测试人员去与每个开发人员讲道理做宣传，其实效率是低下的，而应该把这一类问题记录下来，由测试部门进行一个评估，然后与项目负责人进行沟通，在一个适合的时间点（致命问题、严重问题都改得差不多且还有时间的时候），对此类问题进行一个全面的修改，如果是一个好的公司与部门，还会就此类问题进行总结归类，并对此类问题定义出严重程度与修改的优先等级，如此就完成了一项过程改进，当下个项目出现类似的问题时，一个制度化的结果已经在这里了，开发人员再次见到类似问题，自己就会在已经把致命与严重问题修改完成的情况下，对此种等级的问题再进行修改，而不需要再次做没有必要的沟通了。再比如使用操作性问题，其实就是一种体验测试，如果这种问题由每一个测试人员零星提出，不但没有科学调查与说服力，也会得到开发人员的白眼，所以有关使用方便的问题，也应该单独的当成一个整体事件去做，而立下科学调查的标准化决议，当项目组与测试部与市场都搭成统一标准后，做这些事，还会有阻力吗？
我看有的人的解决方法是人情世故，有的人的方法则是权利压人，还有的人的方法是每回都去以理服人（以德服人，怎么感觉测试总是低声下气的？难怪人家不改你的问题），还有总总方法，但不是有后遗症，就是回回都要如此，搞得效率低下，所以真正的方法应该是，把一项不太受到开发人员重视，但又确实是不可小视的那些问题，想办法通过外交努力，搭成统一的科学的标准化的制度化的行业规范，当一个制度在这里时，没有人会觉得你是和他过不去，只会觉得，这是制度的要求，我们本就都该这样做，就好像你迟到了，你不会认为是人事MM对你有偏见，也不会认为人事MM水平低，不懂得以人为本的道理吧？当然不会，因为几点上班是一项制度。有人见过搞人力资源的人在网上发贴问：请问人事如何更有效的说服员工们不要迟到呢？呵呵，一家之言哈！
至于那些根本就不是问题的问题，求求你们千万不要用你和开发人员的好关系，把不是问题的问题给修改了（还好有问题审核与软件配置管理），我的主呀，阿米托佛！
[ 本帖最后由 zengyixun 于 2008-11-1 01:30 编辑 ]
回复 1# 的帖子
1、征询需求分析人员的意见因为需求分析人员接触真实的用户操作信息更多，他们可以帮助鉴别部分在业务角度看来确实不可能发生的情况。这种情况下，测试人员即使觉得有从逻辑严密性而言有漏洞，但发生概率很小，而修改比较麻烦或者有风险，开发人员不改动代码更合适。
2、冷处理
如果不是影响很大的问题，不用一定这次要一决雌雄，让对方说服自己。有时简单地定一下，这次就不修，看看上了线之后的一段时间有没有问题。没有人永远都是对的，也许你觉得自己很有道理，但这次经过事实的检验，你的判断不尽准确，亡羊补牢再修bug好了。
3、让高一级的人来决定
如果对于这个bug是重要还是不重要的性质难以取得共识，而一个开发人员和一个平级的测试人员争论不休是很难得到结论的，此时可以让PM或者测试经理介入，看看他们决定怎么做。 吸取各方精华，顶一下 呵呵 拿出你的理由让，开发人员低头！
这是我的做法！
