作为一名测试，没有背过锅的测试不是一名好测试！！！
哈哈，这当然是一个玩笑话，不过也缺失反映出了很多问题。
如果互联网是一个新型行业，那么测试就是互联网中的新型职业了！！！更新！！！
测试在互联网中的地位呢，相信我不说大家也明白
一个项目的四个环节：需求、开发、测试、运维
开发无疑是重中之重了，测试呢？好像可有可无，甚至以前根本没有这么个玩意儿，开发做完测测得了！！！
但是测试之所以独立出来，是为了什么呢，是因为他们发现开发是保证不了软件质量的，软件质量的保证需要另外一类人去保证，需要用另外一种思路，去保证，于是软件测试就应运而生！！！
开发的基准是什么，是需求，测试的基准是什么，也是需求，但是开发没有需求依然可以去开发；测试呢？测试没有需求也可以做，但是基准没了，规则没了，当然我们也可以定制规则，但是这时候成本会增加，开发成本会增加，都开发完了，你定制出一系列的规则有什么用呢，让开发去改，不可能的，就这样吧，所以没有需求的测试可以测试，但是只能凭着感觉去测试，逻辑不错OK了；这其实只是说明了一点，测试对于需求的依赖性太强了，没有需求的情况下，开发可以不背锅（除非是严重的逻辑问题，开发在任何一个公司还是很强势的，因为掌握着核心技术），但是测试就跑不了了，你为什么没有测到这个问题，我要测试干什么用的就随口而来了！！！因为没有你我可以随时再招一个人来顶替你，这就是测试的悲哀，或者说是功能测试的悲哀！！！但是大部分公司的测试核心还是功能测试！测试领域里性能测试是有地位的一群人，因为他们掌握有核心技术，我说的性能测试是可以调优的那种，只会测的不算！至于你们说的自动化测试，呵呵之前我就说过，这只是一个噱头，就是一个基本要求，但是大部分公司是用不到的，除非是那种固化的产品，在现在的互联网环境中迭代的周期是很快的！所以你懂的！至于接口测试，这个比自动化还要简单，就不说了吧！！！
话题回来，测试背锅还是要说的，怎么去避免了，首先当然是做好我们自己的事情，先把测试做好，然后再说其他，其他是什么呢？
第一点：一定要和开发沟通，一定要和开发沟通，一定要和开发沟通，重要的事情说三遍；因为只有开发知道这个项目的难点在哪，逻辑复杂的地方在哪，遵循二八原则，我们应该知道哪个地方是最容易出问题的，一定要覆盖到更多的测试点
第二点：如果公司有需求，有完整需求文档，那就太好了，这种公司对于测试人员来说简直是福利，我遇到过，在那里面测试是很有地位的，测试真的是最后一道把关者，测试是可以和任何人对着刚的，这是什么，这是有依据！这里不多说，如果有问题，你不叫背锅，这就是你的问题！！！我待过，我知道，我和开发对着干过，我和需求对着干过，我也和项目经理对着干过，但是我们项目经理依然当着整个项目所有成员说过，这是我见过最好的测试！当时真的，有一种士为知己者死的感觉！在这种公司，如果没有必须要走的理由就不要轻易离开，因为你是在干一份事业，他能给你成就感！！！
第三点：公司有需求，但是没有文档，这时候才是比较复杂的，有时候他自己定的需求转脸就变了，所以你的测试依据就是扯淡，还不如没有依据呢，这时候呢，可能公司还有一群叫运营的伙计，他们更是啥都不懂，就说你测过的功能有问题，也分不清什么是优化，分不清什么是Bug，更不知道合理不合理，反正就是你们做的东西和我想的不一样，你们就要改！这简直就是秀才遇到兵！！！这可以说是最糟糕的测试环境了，在这里，测试也是最容易背锅的，因为你不仅面临着经常变更后忘了的需求，还要面临着一帮子大兵，这时候你遇到个好领导还行，他会认可你的工作，要是再碰到个什么都不懂的领导，那就只能呵呵再见吧！我目前就是这么一个环境，所幸碰到了一个不错的领导，所以还一直呆着。。。这种环境下怎么避免背锅呢，这才是我们的重点，一定要在测试之前和需求沟通，确认的他的需求，和开发沟通，就是两边沟通确认需求，这样不可能同时反悔，记得是在测试之前！！！这个是解决内部矛盾；接着是外部矛盾，就是那帮运营，这个一定要解决好，要不免不了还是要大战300回合，怎么解决，测试是有一个环节的，叫做用户测试，就是用户最后的确认这个东西没有问题了，对我们在测试环境测完之后，把功能移交给他们，让他们做最后确认，不管是问题还是需求分类分别和需求和开发沟通，改到他们满意，然后呢，签字画押，一定要签字画押，确定这个东西没有毛病了，你看过了，至于你到底看不看，那我不管，反正你画押了，收好，这个就是依据，等到上到正式环境，再有问题，再有优化，拿出你的小本本，拿着他画过押的东西给他看，保证他无FUCK说！！！就是打脸打脸再打脸！！！！！！
作为一个测试真的不容易，哎，都是血的教训，就这样吧！！！
PASS：这里说下为什么可以和需求干，测试不仅包括测试做好的功能，测试要学会对需求文档进行测试，这样才能从根本上解决测试地位不高的问题，记着需求有的是客户提的，但是有的是要遵循一些办法，一个规范的，客户提的不一定是全部对的，规范类的文档更是根本了，所以记着需求不是全对的，我们不仅要遵循需求定义的规则，我们还要检查需求定义的规则的对错！！！
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/ZhaoXuWen23/article/details/115004532