每个测试人都幻想在和开发递交bug后，开发响应特别快。如果有疑问，就马上和测试人员一对一交流，尽快修复该缺陷。

理想很丰满，现实却很骨感，我们测试在工作中不免会遇到开发因为一些原因不想修改bug的情况。

往往对话会是以下这样的

测试：接口1里面的字段返回类型需要改下，不然会有精度问题。

开发：改啥啊，接口2不也是这样返回字段吗！为啥要改啊？

测试：你忘记啦，前阵子接口3就是这个情况，你当时不是改了吗？

开发：那是接口3，接口2一直是这个类型，都没问题，接口1也没发现问题啊，没必要改…...

测试：......

那一般遇到这种问题时，我们该如何去推进开发修改bug呢？

首先，要从源头上杜绝无效bug的递交

1、细化测试需求,避免递交歧义bug

开发不愿意修改的bug，大部分都是由于需求不明确或者理解歧义引起的。

所以最好在测试前，开个项目会议，细化一下测试需求，让研发去确认或项目组成员集体Review，达成一致观点。

尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。

2、把握不准的缺陷，递交以前最好讨论一下

特别是在测试初期，由于测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。

这个时候，测试会认为自己测的是对的，开发认为自己开发的是对的，互不相让，如果处理不好，很容弄得大家都不愉快，并且也很难说服开发去修改。

个人的一些做法：所有的测试缺陷相互审核后，才递交到缺陷系统上公开，是最为保险的方法。

3、清楚无歧义的描述Bug，减少随机测试，带来不可重现的Bug

测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反心里，这就让开发人员对测试人员有看法，以后递交的缺陷认可度就大大降低了。

还有就是要减少随机测试，一定要保证递交的缺陷能重现，最好要有截图、图片，让开发认识到这个问题确实存在，并且更具说服力。

4、做好版本配置管理工作，保证测试环境的准确性

有些bug只有在测试环境下重现，而在开发环境下不能重现。这样的缺陷开发人员往往是看不到的，他们很容易得出结论，说测试人员递交无效的缺陷而被拒绝，大部分情况发现是版本弄错啦！！

我们唯一能做的就是做好源代码的配置管理工作，保证测试环境版本的正确性和独立性，自己编译自己部署测试环境。这样才会减少无效缺陷的递交，避免“费劲周折”说服开发修bug。

当确定好这个bug必须要修改，要怎么和开发沟通？

有的公司测试不需要直接和开发打交道。但是对于规模较小的项目团队或者处于起步阶段的公司里面的测试来说，与开发打交道是一件不可避免的事情。

当处于这种状况时，如何和开发打交道更多的是一个沟通的技巧。

需要注意这几个细节。

1、把自己的Bug Report完善

有时候开发看到一些莫名其妙的Bug Report会很生气，这样首先就影响了你在他心目中的印象，要让别人改正，首先要保证自己是正确的、完善的。

2.、注意沟通细节

找开发的时候应该针对具体的问题，可以用“咱们的软件出现了这样的问题”，而不要说“你这里写的不对”。

3.、摆事实

对于具体的bug，可以给开发说明一些事实，例如某个样式问题其实十分影响用户体验。

4.、挖历史

如果以前有类似的问题，可以把那个问题，以及造成的后果给开发阐述一下。

5.、和开发搞好私人关系

平时遇到点头打个招呼，分根烟分分零食都是不错的拉进关系的方式，毕竟关系是基础，关系好了好说话呀！在中国就是如此。

6.、把更高层的人拉进来

很多时候都是公说公有理婆说婆有理，这时候就需要一些第三方的同事来帮忙，这个人通常要是能说事的才行，例如测试经理或者项目经理，让他们来协调。

总之：测试人员是对产品质量,而不是针对某一个人,而且也要把BUG及时提交,不要错过提交BUG的最佳时间,

因为BUG越不解决，积累的问题越多!

所以测试人员要对发现BUG要有信心和足够的时间重现BUG,让产品更具有质量性!