作为测试人员应该都会遇到提出的bug在解决上经常遇到沟通问题，下面我就罗列几个我常遇到的问题
1、“这个bug我这边重现不了啊”
解决办法：这种问题首先测试要先自省，bug描述里面是否没有说清楚。bug应该简明扼要，突出重点。如果描述上有歧义，那么一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。对于开发说的我本地是好的，我开发环境是好的，尽量不要去反驳，而是给出清楚的证据，告诉他，测试环境没有问题，是程序的问题
2、“这个不是代码问题，需求这么定义的”
解决办法：需求也是人定的，如果觉得有异议， 可以找需求人员询问清楚（一般找产品经理或者研发经理），为什么这样定义。然后把自己的想法告诉他们，看他们的决定。如果被需求说服则好，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权利在他那里，但是我们可以保留交流的记录，证明曾经在这里发生过歧义。
3、“这块是别人负责的，我负责的部分没有问题”
解决办法：如果bug是由开发的项目经理拉分发到程序，那就是项目经理来面对这样的问题，而不是测试。如果是测试人员指派的，那么测试人员可以把负责相关内容的开发策划都邀请到一个讨论组里，让他们自己讨论，这样比较清楚，不必在测试这边中转。如果他们觉得代码没有问题，而我们也有强有力的截图和真相，那就只有上交给上级领导，让他们决定怎么解决。
4、“有问题吗？”
解决办法：测试人员一定比开发敏感，对bug的容忍度也低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调动。开发觉得问题很小，不影响功能，所以不认为是bug。这时，测试其实可以说点好话之类的，既然是小问题，解决起来也不难，就麻烦动动手改一下就好了。
5、“用户不会像你这样操作的！”
解决办法：用户怎么操作 ，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户出现的操作，我们都需要测试。慢慢的把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。
