- 📢专注于分享软件测试干货内容，欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
- 📢交流讨论：欢迎加入我们一起学习！
- 📢资源分享：耗时200+小时精选的「软件测试」资料包
- 📢 最困难的时候，也就是我们离成功不远的时候！
目录
- “这个bug我无法重现”
- “这不是代码问题，需求就这么定的”
- “用户不会像你这样操作的”
- “这块是别人负责的，我负责的部分没有问题”
- 最后
作为一名软件测试工程师，日常工作中最常打交道的肯定就是开发和产品经理。有沟通就会问题，有问题难免会有争执。那么你肯定听过这些话：
“这么弱智的bug你都测不出来吗？”
“为啥这个功能还没测完就上线了？”
“研发时间不够，你压缩一下测试时间”
“这个bug和开发没关系，注意看需求”
听到这些话，分分钟高血压，要说谁是超级背锅侠，那测试肯定当仁不让（要求追加“背锅费”）
问题的关键来了：作为测试的核心不是看人家的代码写的错不错，本质上要更关注需求。
在开需求评审会的时候，开发和产品往往很容易忽略了测试，他们下意识会认为和下游没有关系。
可是，熟悉业务，熟悉功能，熟悉各种设计是整个研发团队都需要达成信息共同的，而且测试需要站在用户的角度来去考虑他们的设计是否有不合理的地方，并提出自己的建议。
上面说的工作，需要测试去主动，积极参加，多提建设性意见，让其他岗位的人认识到测试的重要性。其次，除了需求评审会沟通之外最频繁应该还是关于bug的讨论。
下面列出几个比较常遇到的沟通问题，仅供大家参考。
“这个bug我无法重现”
解决方式：
先检查自己提交的bug描述，看看是否准确，bug重现步骤是否没有说清楚。bug应该简明扼要，重点突出。
如果描述存在让人误解的表意，最好改过之前再给对方，如果还是无法解决就当面沟通，事后根据沟通内容来表述内容。遇到概率性的bug，一定要告诉开发概率是多少，尽可能多的提供重现条件。
“这不是代码问题，需求就这么定的”
解决方式：
需求也是人定的，如果觉得有异议，可以找需求人员了解清楚，为什么这么定，然后把自己的想法告诉他们，看他们怎么决定。
如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。不过我们可以把沟通结果备注在这个bug下，以后也能有证可查。
“用户不会像你这样操作的”
解决方式：
测试过程中，我们可以要把客户想象成“儿童”，用户会如何操作，我们无法列出所有的操作选项，只有尽可能的去覆盖到位。不过也不用过分担心，毕竟用户都是成年人。
开发的思考角度其实仅在于功能是否实现，而测试人员需要考虑的更多，所以也理解开发会说这样的话，但是为了更好的产品体验，多多提出来这类的问题，也是帮助开发进步的一个方式。
双方沟通的多了，也习惯了双方的工作方式和思维模式，那么下一次出现这个问题的时候，会更快更好的解决。
总之：一切站在用户的角度看问题。达成这样的共识，很多问题就不会是问题了。
（但是最后还是没能说服他，第一向领导反映，第二做好沟通的记录，将来备注在测试报告里。）
“这块是别人负责的，我负责的部分没有问题”
解决方式：
如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。
当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施，这样才能在职业生涯上一步一个脚印。
最后
如果你想学习自动化测试，那么下面这套视频应该会帮到你很多
如何逼自己1个月学完自动化测试，学完即就业，小白也能信手拈来，拿走不谢，允许白嫖....
最后我这里给你们分享一下我所积累和整理的一些文档和学习资料，有需要直接领取就可以了！
以上内容，对于软件测试的朋友来说应该是最全面最完整的备战仓库了，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。
