我们要先设定一个前提就是，我们提交的故障确实是需要修改的。
首先，良好的沟通是前提。如果测试人员和开发人员一直保持良好的关系，采取合理的沟通那么，说服对方的可能就很高。
其次，需要让开发人员了解这个问题的严重性，并完全的复现这个问题。
再次，如果还是不能说服他那么只能提交项目经理，让项目经理判断问题。

首先是测试人员自己从自身角度出发,把问题的方方面面都考虑清楚,说服别人,首先要能说服自己,在自己都考虑清楚以后,最重要的是根据需求出发,一切违背需求的开发,即使做的再好,也是被认为是错误的,测试人员应牢牢把握住这一基本原则,而且自己需要在技术上有一定的见解,比如一些性能问题上,那些指标是必须达到的,在与开发人员讨论时,应围绕这些公认的技术要点讨论,说服对方,如果实在在需求或者技术实现上有分歧的,可以寻找上一级领导进行评审,让技术上更权威的人来说话,这也是迫不得已的办法,一般情况下,指双方都有相当责任心和技术能力的话,这些问题是可以自行解决的.

热忱并且耐心（Be Cordial and Patient ）
作为一个测试人员，你或许发现使开发人员信服你发现的缺陷是非常困难的。通常，如果一个测试人员找到了一个bug，程序员将准备10个理由。有时让开发人员接受他们的代码是有缺陷的（并且是其他的人发现的）这个事实是很困难的。
开发人员需要来自测试小组的支持，测试小组可以保证发现的新bug是值得关注的，健康的并且对于使产品更好是非常重要的。一个人性的方法是经常帮助测试人员更多的了解编程人员。相信我，不用多久，相同的一个人将站在你身边了并且笑着指出引起bug的错误。热忱将帮助开发人员对你的错误报告说“Yes”。这是重要的第一步。

处事老练（Be Diplomatic ）
试着巧妙地表述你的发现，并且不带任何责备地解释bug。“我确信这是一个很小的bug，你不用花多少时间就可以处理掉。到目前为止这还是一个不错的程序。”开发人员将会跳起来并且拥抱你的bug。
用一种心理方法。有时表扬一下开发人员的工作。为什么大多数开发人员不喜欢我们的错误报告的原因非常简单：就是他们认为我们在诋毁他们的辛勤工作。有些测试人员只在出现问题的时候才和开发人员沟通。对于大多数开发人员而言，软件是他们自己的孩子，而你只是一个妨碍他们的外人。我告诉我的开发人员因为他们我才存在于公司，而且由于我的存在，他们的工作才得以继续。测试人员和开发人员之间的关系是一种共生及互惠的关系。

不要害怕尴尬（Don’t Embarrass ）
没有人喜欢被指出错误。这是人类的天性。试着解释修复那个特别的bug的需要胜于只是用庞大的bug报告向开发人员开火。一连串的缺陷不只会激怒开发人员，而且会使你的辛苦工作对他们来说是无用的。
正象一个人不可能独自测试完一个程序一样，开发人员也不能设计程序没有任何错误，而且在其他事情发生之前，他们需要先了解清楚。有错误是预料之中的事，他们也是过程中的一个正常的部分。

你赢得了一些，你也失去了一些（You Win Some, You Lose Some ）
我知道有些测试人员尽可能将自己的错误报告强硬。他们甚至不听开发人员关于为什么不能修复一个错误和不能实现一个功能的解释。尝试一些可以让自己放松的方法。做到开发人员身边和他一起分析错误的优先级和严重程度。如果开发人员在其不愿变更的背后有一个合理有效的解释，试着理解他。只是确信了解了要在什么地方划定界限以保护你产品最终的质量。

谨慎一些（Be Cautious ）
外交手段和适应能力不能替代谨慎的需要。开发人员经常会找借口说因为他们没有意识到（或者你没有告诉他们）那个错误有多严重所以他们拒绝修复它。用足能够清楚展示风险和问题严重性的方法设计你的错误报告和测试文档。甚至更好的办法是召开一个会议并且向他们解释那些问题。


一个聪明的测试人员是在倾听和执行之间保持平衡的人。如果开发人员不能使你信服错误不应该被修复，那么你的责任就是使他信服要修复错误。

要说服他人认可你提交的BUG，那就需要你要执着，站在客户角度看问题，不要轻易被他人说服你。前提一定要有耐心，要尊重他们。不能说强制他们去修改。现在有很多测试人员，找到人家的问题，就态度很不好，说人家的能力不好。这样肯定说服不了的。
1、测试人员要执着，站在客户的角度看问题。
通常情况下，如果是需求明确提出的，你提交BUG后，一般开发人员都会修改，不修改情况下就找需求说明书出来。那有根有据的情况，他们肯定会修改的。
很多情况下，都是那些体验上的BUG，易用性上的，不是功能性的。开发人员如果不是很注重体验的话，就会觉得你很挑剔，就会反过来以浪费时间，项目紧之类的理由来说服你。例如，一个按钮的使用，或且一些界面上的排列，图标之类的问题。通常你提出来，他们都会以不必要修改去说服你的。
这种情况下，就看你站在哪方了。如果你从开发人员的角度出来，想着，也对，不修改也没什么问题。修改还要那么麻烦，浪费时间，而且项目又紧，那你就会反过来被他们说服的了。
但如果你站在客户的角度，想着这个不好用，会很影响一个人对这个东西的评价的。你现在不修改，到时客户提出来再修改，那后果就严重了。那你就可以从公司的利益出来，体验不好，对公司的影响，客户的影响来说服他们。特别是交接后，客户又提出这些问题的话，那就需要很大的维护成本了。通常开发人员会被你说服的。
2、从同类软件中对比来说服他们
可以从现有的同类的又优秀的软件中提出对比，让他们看到改与不改的好处。这样他们看到好的地方果真比自己做的好多了，那也会很容易接受你的BUG。
3、业务一定要很精通。
很多情况下，一个开发人员或设计人员，只负责一部分的开发或设计，对整个系统不会很清楚，所以有些东西做出来后，单独去看是不会有问题，但整体上会影响别人的模块。测试人员，很清楚业务上的东西，知道哪里受了影响，受了什么影响，那在说服他的时候就很很容易了。
4、提高自己的开发水平，提高他们对你的认可度和尊重度。
还有一些情况下，就需要你自己具备的说服力。你要使自己在开发人员中，具有说服力，也要提高自己的各方面的水平。很多情况下，开发人员总是觉得测试人员只会随便点击，其它什么都不会。所以提出一些问题，就得不到他们的重视。但如果你也具备一定的开发水平，那在找到问题时，你可以从开发的角度去说服他们，他们看到你的能力，更加容易被你说服，不会说因为看不起你而不肯去修改。

引用:

原帖由 jacky_zhuang 于 2008-4-1 12:45 发表
.  竖立团队品牌===平时提交的bug需要有良好的复现概率和清楚的复现步骤条件;    提交的bug有统一的格式和标准;   提交的bug尽量有准确的定位和现象分析,日志跟踪等;   

.  竖立制度保证===和pm及dev leader有良好 ...

里面有bug:是树立 不是竖立 呵呵

测试人员不仅仅是做测试的，她是一个服务类型的行业，前面技术支持与客户，后面才是开发人员，她是个纽带。

其实不能以偏概全，具体软件，具体公司，具体分析。

不管怎么样，我觉得如果大家都从公司投资于客户需求比较分析，得出结果。

有的问题，这样做就很浪费时间，这就需要测试人员对错误的把持度。

我认为这个要从很多方面去做，可以同开发人员先沟通，将自己测出来的BUG的图截给他看，如果他还是不认为这个是很严重的错误的时候，只能先报告测试主管，由测试主管根他们的开发主管沟通，让他们的主管去与开发人员沟通，不能根他们开发人员产生矛盾!

我也碰到过这种情况,单纯的bug倒还好说,有的是客户体验性质和人机交互信息的bug,这就比较难讲,因为没有一定的规范.我在这方面的策略如下:
1.如果公司有定义产品需求人员的话,首先和需求沟通,赢得需求的肯定,让需求再出一份补充需求出来(更改的周期比较长,估计可能要到下个版本发布才会改)
2.公司没有需求,就直接和开发人员沟通,这个比较困难的,因为如果是因为人机交互信息有问题,可能每个页面都有相似的问题,更改起来是容易,但是麻烦,很多开发都不愿意改,这时候可以和开发当面交流,告诉他,这么写,如果是客户,会造成什么样的误解,会有什么样的不方便,给他看相似的程序或者网站,告诉他通用的做法是什么,客户通用的理解是什么.
3.如果开发还是拒绝更改(事实上,很多开发都对测试有抵触情绪),可以和测试经理沟通,让测试负责人和开发负责人去说,如果他们达成了共识,改或者不改,就不是我可以决定的了,如果他们决定改,我会很开心.如果决定不改,那我也没办法,在我的职责范围内,能做到的就是如此.

首先,先解决"缺陷是需要修改的证据问题".
测试人员要参考系统需求详细说明书或者软件需求详细说明书,确信缺陷需要修改的说法可以做到有据可依,这样自己的说法才能站得住脚.

其次,解决"如何说服".
拿这个缺陷和开发人员讨论的时候,要尽量做到客观,要就事论事,不要拿人来说事,站在开发人员的角度来说,也许他自己已经意识到有错误了,但是碍于面子不愿意承认的也有,所以这时候要拿前期阶段解决缺陷和产品发布以后所带来的损失的差别来比较.

最后,其实最好的办法是处理好测试和开发的关系,经常沟通,最好一个小的打包环节就review当前的缺陷,这些问题就迎刃而解了.

和开发人员说说下面几点：
1.缺陷的合理性
2.用户的人性化
3.风险性
4.交流修改的时间长短和算法难易情况。

1.如果要靠说服来让bug得到修改，说明你公司的项目管理机制有问题。
2.其实方法上还是有有技巧。
a.问题的描述上刻意夸大(如果真的是非常小的问题话，不建议此做法）。
b.问题暴露面上扩大化，尽可能让每个相关的人知道，无形中给开发人员施加压力。
c.定时发打电话，发邮件提醒开发人员修改，让他不胜其烦，无发忍受，不得不改。
d.其实最重要的是树立强势的形象，定义自己为用户代表的角色，让整个项目的明白产品品质的重要性。

以理服人，如果不行那就欺蒙拐骗好了，只要能达到效果就行

1.自信：首先要有的就是一份自信，当然自信可能来源于很多东西，但是最应该有的确实那一份对自己的信赖产生的自信，那是你在开发人员面前说话的主心骨。你若是连自己都无法相信，那么将是灾难性的。
2.证据：自信不仅来源于对自己能力的信赖，更多的应该来源于无懈可击的证据，各种数据，个个抓图，各种场景下的反应情况，这才是最最重要的，也是最最应该展示的东西，很有可能不用你过多的废话就可以解决问题了。
3.讲话的技巧：以上两点只能是说明你已经做到了对缺陷和自己的把握，但是没有好的语言技巧那么很有可能这些都会泡汤，因为有很多的缺陷都不是很明显的，更有的是可改可不改的，这时候你只要记住一点就行了，也就是你在整个的交流过程中只要关注这点你就会稳于不败之地，那就是“你是在为客户说话的”，你只要以此为观点那么谁都只有认可你的话。

这好像是质量流程不规范的公司的通病
1.明确这是一个BUG，自己首先要对需求做到心中有数，查出缺陷时要先确认不是环境配置、版本问题（前提有完善的配置管理流程）或自己的其他原因
2.尽量重现BUG，这样开发人员易于查找原因，不会漫无目的
3.分析缺陷可能的原因，这样有可能帮助开发人员减小工作量，也能增加开发人员的好感
4.与开发人员做好沟通，明确缺陷需要修改以及修改的具体时间
5.私下与开发人员搞好关系，有利于推进问题的解决
6.通过定期不定期的缺陷汇报表明问题的严重程度，由上给开发人员一定压力
7.缺陷严重程度的划分很重要，天天去跟严重程度很低的东西，不仅会让开发人员好感降低，也可能会延误严重缺陷的解决
8.提高自己的技术素养和加深业务知识，不要说外行话，这是得到别人尊重的最起码条件
9.说到底，如果有一个完善的缺陷修改优先级体制和由上至下的质量意识，测试人员跟BUG根本不会这么麻烦。出现这些问题，就是因为测试工程师们根本没有权利去安排其他部门人员的工作量、时间安排、优先级定义等等，就是因为团队由上至下没有形成质量意识，以做出东西为优先，而不是做出高质的东西。当然，我们自己的职业素养也需要提高。

1、首先你需要把此问题的复现条件做详细的记录下来。
1、如果是按照平时很常见的功能的问题，我想我们只需要把设计规格拿出来看一下就可以了。，。。我想向这种问题应该开发人员会很少拒绝修改的.
2、在交流的时候我们是需要友好，要客观的看待这个问题，尽量少用你和我的语言，这样容易把两个人放在对立的方面，尽量使用我们或是此问题之类的。
3、开发和测试最有争议的应该是灰色地带的。比如说一些可服务性或是可靠性的，另外是一些异常用例所测试出来的缺陷，对于这种缺陷在公司应该有很明确的文档说明，如果没有相关文档指示，你就需要把这种问题的危害性说出来，如果吧修改会出现什么样的后果。
3、需要制度保证，如果缺陷在客户方面发现了，对于开发也应该负责相应的责任，这样就能保证开发很公正的对待此问题。
4、另外在公司应该有专家组成的评估团队，对于开发和测试不能达到的共同认识的问题，就由她他们决定好了。并不是测试认为的问题都是问题的。。。。有时候还是需要评估的。。。在某公司遇到的问题是问题可能到其他另外一个公司就不是缺陷了。。

1.建立良好的沟通与交流关系；
2.清晰的bug描述；
3.确保bug再现；
4.产生不可调和的“矛盾”，可向高层反映由高层来决定是否修改；

1、首先保证提交的bug确实与需求不付，且出现了问题
2、要与认真负责的态度来跟开发人员好好的沟通这里确实存在bug，在开发的实在无法理解的情况下把bug出现的情况给当场显示给开发人员看
3、测试人员应该在平常多增强自己的专业知识和沟通能力，使得开发的能更快的接受我们测试的观点

拿出数据.来证明他这么做是不合理的

看了下大家的回答，都很不错！
下面我就个人的经验总结一下：
1.多和开发人员沟通交流,保持良好的同事关系
2.BUG描述一定要清楚
3.要选择提交BUG的时间,如果开发人员手头上有很急,很多任务,这时,提交BUG给他,可能会打断他的思路.所以在提交BUG之前先问下开发人员手上工作的情况
4.当开发人员拒绝修改BUG的时候,千万不能生气或者表现得不耐烦,而和开发人员发生争执,而应该冷静对待,可以等心情好一点的时候再去找开发人员交流,以论证证明这个BUG必须需要修复.
5.要督促和跟踪BUG的修复情况,不要催的太急或者太勤,而应该根据BUG的修复难易程度给予开发人员一个合理的修复时间......

1.我们先确认这个BUG是不是真正的BUG。因为只有自己明白，我们所坚持的是正确的，才能理直气壮的去表达自己的观点。
2.要实事求是，不能针对某个人。我们在表达自己的时候，要从客观的角度出发，不能针对某个人来讲这个BUG，因为，一个BUG的产生，很可能是由各方面的  因素造成的。
3.注重交流，尊重他人。当其他人对我们提出的BUG有不同的看法时，我们首先要认真的听别人的讲述，不能一味的认为，只有自己是对的，当虽人讲完后，再对那人所提出的问题，进行讲解。
4.坚持自己的观点。既然我们认定这是个必改的BUG，我们就要有自己的坚持，用证据来证明自己的说法，正所谓“有理走遍天下”，不能因为对方是资深开发人员，或是自己的上级，就改变自己的看法。