某大厂开发和测试干了一架，用鼠标线勒脖子了？

开发写代码，测试找出代码中的bug，一言不合就红眼争执的事情时有发生。有一网友就爆料自己的公司，称某部门测试和开发动手了，吵得很凶，听说还用鼠标线勒脖子了！

围观人员表示：无线鼠标怎么破？

玩笑归玩笑，但软测人如果真的花大量时间和开发人员争斗，往往得不偿失。不如让小檬带你了解下哪些是本可以避免的雷区，一碰就炸吧~

测试提交Bug描述缺少截图

“每次提bug，开发都让清数据、清缓存、重启机器，三两下把bug整不见了，等到bug复现不出来，就说看吧，不能复现，不修复了！”

作为测试人，你是否也有这样的经历？

所以下次提交Bug描述时，记得增加辅助页面截图，一方面表达更清楚；另一方面，某些偶发bug留下“事故现场”的证据，就由不得他不信了，当然，如果有个录屏短视频更好。

测试人不专业导致描述不清楚

如果不是技术出身的测试，会被开发反驳不懂代码；不能用专业术语把bug和正确结果描述清楚到位，也会增加沟通成本，效果不好。亦或者前端、后端、设计问题在Bug中未区分，需要对于Bug做出正确的优先级排序。

想让开发挑不出来毛病，测试人要提高自己的技术能力，无论功能实现，还是代码逻辑，都需了然于心。

能熟悉至少一门语言，不管是Java，Python还是Go，掌握其中1-2个就可以。有了语言基础，测试可以更加深刻理解产品的实现，也能够更加清楚的知道bug经常会出现的模块，能够对产品进行更加充分的测试。

测试没有尽早介入，后期提新需求改动太多

测试什么时候介入好？越早越好。

在软件研发的整个过程中，需求分析、设计、编码、测试、发布维护中，都有可能引入软件缺陷，修复软件缺陷的费用随着时间的推移而增加，尽早测试并发现软件缺陷，修正时所投入的人力物力就越少。

测试有时会发现原有产品有逻辑疏漏或错误的地方、感觉某些功能有更好的实现方式。

当发生这种情况，不要急着提新需求，而是要先去和程序员们沟通、听取建议，咨询有什么方式可以在变动最小的情况下达到目的（注意不一定是结果）。

如果实在要提新需求（这是被开发怼的最多的地方之一），跟开发沟通时要注意方式，最好是纳入需求池在下个版本迭代中完成，这样的处理方式是你好我也好。如果测试的时候总提新需求，暂不提程序员的心理阴影面积，产品开发节奏也会全盘打乱。

两者思维方式不一样

开发专注程序的功能，并在现有需求和设计的指引下开展工作，往往不会从业务逻辑和使用者角度去思考。完成工作之后，他们会固执的认为自己编写的代码会运行良好。而测试人通常站在使用者角度去发现问题，通过各种不同的测试用例把软件潜在的不足之处暴露出来，这是两者思考方式的区别。

作为测试，除了坚持自己测试的角度和立场外，也要有同理心，学会站在开发的角度去看问题。

很多冲突源于大家对需求理解不一样，当测试和开发对一个bug持有不同观点的时候，不要率先很强硬的否定他，尝试解释为什么他理解的需求有不足之处。找一些可以站得住脚的论点，从用户角度出发，从安全性考虑，或者从易用性和友好性来看，说服开发接受测试的观点，而不是强加自己的观点给他们。

测试工程师要提高自己的情商，增强自己的沟通能力，懂得站在开发的角度思考问题，学会去尊重开发人员。

其他开发方面原因

其他方面还有如：

工作流程方面：没时间，问题太小（优先级低），上线时间紧急，非自己名下的bug（已离职开发人员遗留的bug）。
开发个人能力原因：找不到解决方案，技术难以实现。有的开发人员只擅长代码的功能测试和代码修复，如果程序运行正常，那么他们的测试就结束了。而测试要将应用程序拆解，从每个小块之中找寻那些不易发现的bug，并帮助开发人员了解那些特定的功能应当是怎么样的。
不可抗力的客观因素：例如系统问题，第三方SDK问题等等。
解决这些问题的方法就是，建立完善的管理流程，通过流程控制来规范开发和测试部门的工作，可以很大程度上减少冲突的发生。

最后，质量保证不仅仅是测试人员的职责，而需要整个团队齐心协力，希望开发和测试都能互相理解，互帮互助~

学习安排上

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

视频文档获取方式：

这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方进群即可自行领取。