测试经常遇到的交流问题

简单描述下，有时间再补充

1. 当测试觉得一个Bug需要修复，而研发童鞋觉得没必要修改或者改动成本高时如何解决？

先相互沟通理由，实在无法说服对方，和项目负责人（产品或者项目小leader）沟通，看是增加排期或者本次修复。

2、遇到调用外部接口时根据开发描述接口特征测试，上线发现一堆异常情况（例如小数点事件）？

       这种情况要求外部接口提供方提供详细接口文档。

1. 产品没有需求，或者需求只是几句话几个图

 

1. 需求讨论、需求变更不通知测试。

 

1. 需求文档没有得到保存、延续

 

1. “这个bug我这边重现不了啊~~~”

解决办法：这种问题首先要自省，查看自己提交的bug描述里面是否没有说清楚，根据公司项目管理系统要求描述Bug是否简明扼要，重点突出。如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。对于开发说的我本地是好的，我开发环境是好的，尽量不要去反驳，而是给出清楚的证据，告诉他，测试环境没有问题，是程序的问题！

1. “这个不是代码问题，需求这么定义的”（小数点）

解决办法：需求也是人定的，如果觉得有异议，可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。

1. “这块是别人负责的，我负责的部分没有问题”

解决办法：如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。

1. “有问题吗？”（也就是开发不认为这是个问题）

　　解决办法：测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用

　　户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。

1. “用户不会像你这样操作的！”

　　解决办法：用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。除了bug上的问题，还有测试安排上的问题，有时候小功能没有做好，或者某个文档、图片没有上传，等小功能做好了文档上传之后，很可能开发忘记告诉测试。所以，平时的工作中，一定要主动记录问题，主动沟通和督促，并反复确认，不要怕麻烦。

　　总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。