在近9年的软件测试职业生涯中，多少遇到一些奇奇怪怪的事。而最悲催的莫过于那些自己躺着也中枪的事，如果处理不好惹火烧身，直接被“毙掉”也不无可能。

下面就摆摆那些事儿(其中可能因人老记忆衰退严重，与事实间有一定的夸大成分，请大家见谅则个)。

“需求设计缺陷”与“设计如此”真特么难伺候

我们都知道测试是从需求开始的，需求也确实会存在一定的问题。可能大部分问题我们都能通过需求评审类似环节给灭掉，然而总有漏网之鱼，而这些“鱼”隐蔽至极，往往一浮出水面不啻于一枚枚鱼雷，引发大爆炸，可能项目团队中就有几人被炸的伤痕累累，而测试无疑是此时的前锋、敢死队。“你就是保证质量的，不炸你炸谁？”

就算我们拥有非凡的眼力与能力，能在测试阶段把需求中的隐蔽问题挖掘出来那么些，但往往“设计如此”这个拦路虎就得考验我们的勇气和谈判能力了，如果你被迫“屈服”，那后续出现问题也难免受波及。“你怎么不把bug告知某A、某B、…”(是不是一遇到这种问题最好公司人手一份大字报？号外，号外，今天又一设计如此bug新鲜出炉……这电影般的场面真有那么几分熟悉)

使用的框架、工具或插件突然出现了漏洞

我们信心满满的发出“测试通过”这一喜大普奔的胜利宣言，正沉浸在项目顺利发布上线运营的喜悦中，然而一段时间后突然一声冷冽的“枪响”传来，出现了重大bug！！！

“怎么会有这么严重的bug？怎么测的？！”扛着“子弹”，带着一脸的难以置信和不甘，经过废寝忘食的抽丝剥茧，层层排除，终于查出罪魁祸首“使用的框架，工具或插件出现了漏洞”。最终真相大白，测试转危为安，虽安好但已心力憔悴。(不想说话，让我在角落里坐下来静一静)

是谁悄悄动了生产环境

“千防万防，家贼难防”，在软件项目中也一样。当我们明明经过重重测试把关，最终把应用发布上线(或交付给客户)。然而不久后，不经意的某一时刻，突然又传来一生冷冽的“枪响”，当我们左右瞭望之际，最终发现自己已中枪。“这么明显的地方居然会存在bug？！！你们测试是怎么搞得@％#”

“冤啊~比窦娥还冤啊~”我们根本不相信自己会犯下如此低级的失误，自己当时绝对是测试过并确保正确的。

“事实摆在眼前，来人，拖出去砍了”，此时六月飞雪处处透着诡异般的宁静，就在上面打算补刀之际，“大人且慢，此事处处透着蹊跷”一声传来，团队中的正义之士在关键时刻挺身而出挽救下测试，不至于“魂断刀下”。

“那'元芳'你怎么看？”“依臣看，测试不至于如此胆大妄为，这么明显的地方不通过测试就让其上线，不如仔细审查下原因再做定夺”就这样，测试在有义之士的帮助下开始了洗冤行动。

最后通过服务器、版本控制系统等蛛丝马迹，发现是内部有人悄悄动了生产环境，如提交了并没经过“测试发版流程”的补丁。最终测试得以洗涮冤屈。然，可能涉及boss某员心腹爱将，也就草草了事下不为例，测试也只得含屈放下此事。

接盘侠：前辈你挖了好大一个坑！

如果身为股民，对于“接盘侠”应该不会陌生。在股市，接盘侠通常是调侃之语，认为是在高位买入的投资者，投资风险极大。这里不是讲股票投资，回到测试，接盘侠可指在项目经过多次迭代，进行到一定程度后，才介入进来的测试新进人员。往往情况是项目中主要测试负责人辞职，由新填充进来的测试人员接手。

对于接盘侠，前面一切不可考，可能因为项目团队管理混乱等原因，更是罕有文档留下，从而只能从项目其他人员的只言片语中去了解情况。而对于所测试项目，里面更是bug横飞，处处是坑。然而项目仍然在滚滚向前，每天你只能心力交瘁的在测试加填坑中艰难前行。

突然有一天，一记惊雷响起，你发现了一处大坑，从而引发了一场“大爆炸”，项目团队炸开了锅，虽然因为“历史遗留原因”你不会被“炸飞”，但难免不受波及。“不管历史不历史，你作为测试就得和开发一起填坑！”

最终“炸飞”了几波开发员，你虽侥幸“不死”。也因没日没夜的填坑弄得精疲力竭，只能无语话苍天“前辈，你们真会玩”，继续强打精神如不死小强般的做一个苦逼的接盘侠。

测试员如在枪林弹雨中前行，不时就有枪声在耳边响起，哪怕再怎么做好掩护，也难免中枪。我们需要做的就是以扎实的专业技能和过硬的职业素养武装自己，从而可以从容面对一切。

想学习却无从下手，该如何学习？

这里我准备了对应上面的每个知识点的学习资料、可以自学神器，已经项目练手。

如果我的博客对你有帮助、如果你喜欢我的文章内容，请 “点赞” “评论” “收藏” 一键三连哦！