从去年决定跳出舒适区，应聘大厂，截止到目前已经将近一年，值此之际，总结下自己近一年在大厂的经历。
希望通过我的感触，能够帮助你们进一步了解大厂的测试工作。
维护上下游合作关系
在大厂，人际关系非常重要，为什么要把它放在第一位，是因为在大厂里做测试的时候，所涉及的系统错综复杂，种类繁多，经常要进行上下游的联调测试。
我刚开始的时候，测试联调找不到相关的责任人，使得自己在测试工作中浪费了大量的时间和精力，所以进入大厂之后，一定先要：
首先，梳理自己负责系统的上下游联系人，将其联系方式整理起来，方便后续查询联络，可以参考下面表格进行简单汇总即可。
其次，维护好自己与前辈的关系，保持自己的谦逊态度，无论您的工作经验多么丰富，对于新公司，您就是新人，遇到不懂的流程、业务要多问多总结。
最后，你入职后，可以通过公司指定平台学习入职规范以及后续工作展开需要的系统、工具，入职前几天，一定要珍惜机会，认真阅读，常用的功能最好自己操作一遍，会为后续工作节省时间。
遵守规范别掉队
在大厂的第二点感触是，测试流程非常规范，一般情况下都要严格按照软件生命周期的步骤进行推进，具体执行过程为：
需求分析阶段：业务先进行 BRD 评审->产品输出需求文档，在进行 PRD 评审->然后开发出相应的架构设计，且测试、研发要给出工作排期，而后项目经理推进项目立项。
需求研发阶段：而后进入到需求研发阶段，这个时候测试就要开始介入输出相应的测试计划、测试资源安排以及测试用例。
研发研发完毕，提测前要过研发的设计文档，测试的用例评审，二者都过了之后要周知项目组。
产品进入到测试阶段，测试先进行冒烟测试，冒烟测试通过则开始进行分支测试，分支测试完成进入到主干测试，然后进行预发测试，都完成后等待上线，发出上线前的测试完成报告。
项目上线完成后要进行线上验证，线上验证完成后，研发、测试要同时发出上线公告以及上线完成报告。再由项目经理要周知到业务方进行功能验收，项目进入到验收阶段。
可以看到在大厂中，每一步的测试工作都必须严格按照规范进行，不允许出现遗漏，哪一个环节没有按照要求进行，后面出了问题，第一责任人就是你。
重视业务勿放松
还有最需要强调的一点，不要一味的去追求技术而轻视业务。
技术只是解决问题的辅助手段，且技术的迭代更新快速，我们必须要切记软件测试的初衷——“user story”，用户故事。
也就是要了解业务需求，在大厂你必须了解上下游的业务，如果一味的只关注于自己测试的系统，无异于管中窥豹。
且对于业务的熟稔程度，绝不仅仅是依赖于需求文档描述中的只言片语，这里笔者将自己为了了解业务而问的问题分享给大家。
上面的产品三问如果产品回答的与自己理解有偏差或者没有彻底解决自己的疑惑，这个时候一定要深入业务，否则就会有风险。
例如我们最常见的下载功能，如果我们只按照功能测试的思路，将文件正常下载、查阅没问题就认为通过，进而觉得没必要去了解业务，到了线上用户下载的数据量巨大，数以百万计，大概率就会暴露出超时下载的异常，可能您会说这不应该是性能测试所考虑的吗？
我们要知道，我们作为系统测试的执行者，虽然不必去做全链路的性能测试，但是性能的漏洞必须要敏锐识别，这样早些了解线上实际发生的下载量以及未来一段时间的预估量，而后模拟造数，进行下载，完全可以在测试环境就将该问题进行暴露且及时解决。
技术有专攻
大厂的技术栈非常丰富，MQ、缓存、微服务、React、Mobx等等，看起来琳琅满目。
我们不可能一口吃个胖子，将所有的技术在短时间内吃透，这个时候就需要我们立足于自己的测试项目向外延伸，遇到不懂的多学习、多积累，且学习的目标以快速使用为前提，重要理论为辅助。
例如遇到测试的项目，开发采用了缓存技术，我们作为测试之前并没有接触过，这个时候必须先快速弄清楚：
缓存是什么？
我们用的是一级缓存，还是二级缓存？
具体某个缓存的 key 是什么，value 又是什么
缓存失效的条件是什么？
快速掌握住上面问题就可以了，你完全就可以去胜任测试涉及缓存的系统。
那么接下来就是你提升的时刻，你可以自己在本地仿照公司的技术栈，本地搭建一套缓存，切实使用下，那么是否有适合测试应用的场景呢？
答案是肯定的，比如我们做自动化的时候，需要将用例的预期结果与实际执行结果做判断，这个时候，我们完全可以将预期结果放置在缓存中，在和实际结果比对，这就是一个很好地应用缓存的场景，这样下来，你对缓存从无知到了解再到应用，就形成了一个完整的学习闭环，以此类推，其他新的技术你也肯定可以很快掌握。
最后无论身在大厂，亦或是想要进入大厂，都能从我的经历中有所收获，长路漫漫，我们一起加油！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
