目录：导读
前言
大伙普遍的看法：测试与开发天然对立，就应该是一对冤家。
以一些“行内人”的说法：测试与开发关系太好，不温不火，软件质量是提高不上去的！
从而，人为引发了一系列恩怨纠葛。
绩效考核上，开发必须少写bug，测试必须多找bug，从而把测试、开发对立起来！测试为了后面多提bug，根本不太关心 测试左移（bug预防工作），左移了，bug都没了，岂不是自掘坟墓？
开发更是人人自危，防测试如防“贼”，常常为测试咬文嚼字的bug大为光火。
这样真的能提高软件质量？如果真能，也没有后面的“测试左移”了！
测试与开发，与其说是冤家，不如说是天然伙伴、盟友，如“狼”与“狈”的关系。（貌似有点不当，不要关注这小细节_）
恰恰相反，根据我自身和其他朋友的一些经历来看，测试与开发关系不错的团队，软件质量并不差，甚至更好！
这是为什么呢？
因为测试的工作不只是找bug，还应该花更多功夫在预防、规避bug上面。这就出现了“测试左移”，如通过需求评审活动找出潜在的缺陷，如根据经验预测bug点并与开发复述确认，又如在开发中做好接口测试，从而让转测的软件尽量少出bug，最终回归到了软件测试的初衷——尽早规避缺陷降低研发成本！
因为前面测试左移活动已经尽可能帮助开发规避了做无用功，后面测试提出的bug往往真是开发思维不严谨，或者粗心导致的bug，只要不是咬文嚼字，开发也都会虚心接受。我先后问过几个开发，你们对我提的bug反感吗？
并不会啊，我也希望自己撸的码质量高些，有bug改就是了。
测试线上突发情况
常在河边走，哪有不湿鞋。
产品测试上线后，难免不出现问题。小问题，只要大家没有不共戴天之仇，在内部通气的情况下，也就低调处理和谐了。
而出现严重的问题，那该怎么办呢？互相甩锅推责？too young too simple！
不管你有没有责任，后面绝对是一起株连。
正确的应对姿势：
首先，立即、马上同开发定位、解决问题！
哪怕其他人都在互相甩锅，你也要立即说服对应开发人员，立即、马上一同定位、解决问题。哪怕解决不了，也要找出一个影响最小的解决方案，供产品负责人决策处理！
哪怕此时BOSS为此态度十分恶劣，你也要顶住压力诚恳的说服BOSS，先解决问题！没有一个BOSS希望见到一个严重的问题在那里挂起，底下的人反而为甩锅“忙”得不可开交。
以前我多次作为“敢死先锋”做了此事，虽然当时不说，事后不管是BOSS，还是同事对此评价颇高，完全超乎我的预料。
客观分析原因，从测试角度做好规避措施
解决了问题，就该追责了？NO！
针对此事，我们应该客观的分析出现问题的原因，然后做好今后的规避措施！
记住，首先从测试的原因找起，如：是否是频繁迭代后没有做checklist（迭代测试）？是不是疏忽大意，没有考虑到？是不是听了开发的保证“没问题”，就直接省事放过？
找到了问题，还要做好规避措施，如：做好checklist，加强用例的评审，切实落地测试流程等。
然后再从测试以外，客观的寻找原因，诚恳的给出一些今后的改进建议。
这样做了以后，再以邮件的方式反馈给BOSS，抄送给相关同事。
下面是我整理的2022年最全的软件测试工程师学习知识架构体系图
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
相信你做得到，你一定会做到。不断告诉自己某一件事，即使不是真的，最后也会让自己相信。
在你不害怕的时间去斗牛，这不算什么；在你害怕时不去斗牛，也没有什么了不起；只有在你害怕时还去斗牛才是真正了不起。
给自己一点掌声，让我战胜内心的怯懦；给自己一点掌声，无畏的心更加的坚定；给自己一点掌声，温暖我独自前行的路。
版权归原作者 百度测试开发 所有， 如有侵权，请联系我们删除。