转行测试开发，4年4“跳”年薪涨3倍，我的目标是星辰大海（附大厂面经）！
⬆️ 关注霍格沃兹测试学院公众号，回复「面试」，领取测试开发面试真题合集！
编者按：本文来自霍格沃兹测试学院优秀学员 @TesterC，从运营岗位转行外包测试，再到测试开发，从待业在家到4年4“跳”进入 BAT 大厂，年薪涨了3倍！他是如何完成如此励志的华丽转身的？
应学院的邀请，分享下我个人的测试技术和职业成长经历，仅供参考，请大家多多指教！
特别提示：跳槽须谨慎！
频繁跳槽并不适合每个人，而且通常会对简历造成一定的负面影响。本文主要是记录在被动的情况下，我是如何打好一手“烂牌”的？不推荐诸君盲目效仿。
背景信息
我本科是电子类专业（偏材料方向），2016 年毕业赶上“就业寒冬”，当时感觉找份工作就不错了，只好“喜滋滋”地拿着”白菜价”，找了一个偏运营类的岗位。
谁曾想初入职场，就由于工作环境和个人的种种原因，我经历了“几近抑郁、被迫待业 1 年多的人生困境”（往事不堪回首～）。
2 年前，抱着“我必须坚持学点什么”的简单想法，我解锁了外包测试的“成就”。
1 年前，我想证明自己，不是只能在**外包的“温室”**里才能存活，有幸加入了“中厂社畜”的行列。
今年，我更深切感受到舞台的大小对个人职业生涯的重要性，再一次选择跳槽加入了某 BAT 大厂 （Dream Company），拿到测试开发 Offer。
简单总结：一“跳”从零开始、二“跳”野蛮生长，三“跳”自我肯定，四“跳”初窥门径。年薪总包也从最初的不到 10w，到现在接近 40w，增长 3 倍有余。
而且我相信，我的职业征途，才刚刚开始。
艰难起步，摸黑前行
非科班出身 + 代码功底差，两大硬伤是我从非技术岗转行测试开发的最大阻碍。
但好在问题明确，既然落后，那就用力追赶。
狂补计算机基础知识，我一开始是从网上找视频资料入门的。但如果有时间有耐心，真的推荐大家看一看相关的书深化一下，比如下面的计算机基础四大“名著”：
而练习代码，则一定要动手敲。新手建议先用写字板，写完之后再扔进 IDE 编译运行。
在学会一些基础知识后，我逐渐能用 Selenium 勉强写点“照猫画虎，似是而非”的自动化工具。然后…，就卡在这个水平了。我深知自己的水平只是从 0 分逐渐在向“ 60 分及格”靠拢罢了，离更高段位的“测试开发工程师”还有很大差距，但苦于自学进阶太难，方向不明确，无从下手。
黑暗中的一束光
偶然在网上看到了霍格沃兹测试学院的课程介绍，我当时很激动，甚至一节公开课都没听就确认报了名。
直接打动我的，只是一张课程内容体系的介绍海报。
因为我深切体会过“纯自学的痛苦”：收集资料、学习理论、应用场景、动手调试等一系列过程中，经常会遇到各种“愚蠢”问题不知道如何解决…令人抓耳挠腮，深感“无的放矢”的乏力感。
加上测试开发所需技能之“杂”，于我而言，能坚持自学一两项已是不易，想靠业余时间，系统的自学完善整套知识架构储备，几近天方夜谭。
所以，当看到课程大纲对测试开发系统技能的全面介绍，还有多位大厂 10+ 年经验大咖讲师辅导，我感觉犹如在黑暗中看到黎明的第一束光，重新找回了技术进阶的信心。
测试开发技能体系梳理
在学院学习的这段过程中，我结合自己的工作对测试开发技能体系进行了梳理，并进一步提升认知。
在我看来，所有的测试都是依托业务（实际问题）产生的。所以，了解项目、掌握测试理论，是最基础的东西。否则再多的学习，对于测试开发工程师而言，都是无本之木，虚无缥缈。
对于前端项目的测试，“点点点”基本功属于 21 世纪生存必备，也没必要过多赘述；但在此之上，普通用户不会关注，但身处其中的种种场景，需要移动端专项测试覆盖保障。
对于服务端项目，因为隐藏在用户界面之后，并不是日常所见，面对的问题也并非移动端那么简单。所以在掌握接口测试之外，了解接口性能测试、接口安全测试也必不可少。
不管什么类型的项目，都离不开数据；那么了解数据库，了解数据库的种类、使用方法及特性，也是必备技能之一。
建立在“能够熟练地完成手工测试”的基础上，“提效”（提升效率）才成为追求的目标，这个时候，作为测试开发的价值才真正体现出来（我的个人理解，欢迎指正）。
Git 作为当下基本代码协作工具，对于测试开发工程师而言，应该就跟等价类边界值和测试工程师的关系一致。
对重复测试过程的提效，对于被测客体的不同，可以分为 Web 自动化、App 自动化和接口自动化。
对测试过程的前（数据准备、环境搭建）后（日志分析）行为，提效主要由 Shell 脚本实现。（毕竟大部分都是 Linux 做服务器的）
既然写了代码了，那进行调试，就是对自己最大的尊重；xUnit，应该是目前最通用的方案了。（有时候业务代码开发偷懒，需要测试帮写单元测试代码也说不定）
为了让自己 review/ 修改自己的代码，不至于是面对一座“屎山”；也便于其他同事一起维护，合理地设计自动化框架就需要提上议程。
再假设，真的有机会将以上全部在工作中落地，容器化（docker）和更高集成度（测试平台搭建）也是可选的方向。
除了对测试过程的各个环节进行优化，还有持续集成/交付这一业界流程优化方案。
如果把产品的设计、开发、测试周期，以时间线为轴，拉成一条自左向右的单向矢量；那么以传统测试过程为观察点，可以向前（即测试左移，测试开始之前）关注，如何协助产品明确需求、协助开发提升代码质量；也可以向后（即测试右移，测试结束之后）关注，如何在可接受时间内，发现线上问题，并快速响应。
以上各点，在学院的课程中均有涉及，可以说是特别完善了。学院的很多免费公开课，质量都着实不弱，感兴趣的同学可以去蹭一下～
学习心得
详尽学习内容，我就不再赘述；这里主要分享一下，我跟总结的一点学习经验，如有不妥，请大家指正。
1. 把书读薄了，才是读进去
以 Linux 中三大神器（sed/awk/grep）之一 awk 为例，各位大可以试想这当中任一个，都是一本厚厚的书（不信的话可以 man awk，或者上对应官网 看一下）。
我理解的第一步中，所谓“读薄”，就是把具象化为抽象，定性地去理解工具的意义。
比如，echo "123 456" | awk '{print $2}'
我就简单理解成，awk 后跟的命令，需要用 {} 包裹，并给出相应动作。
再稍微复杂一点，echo "123 456" | awk '/^1/{print $2}'
我再更新认知，在 {} 前，用 // 可以包裹定位需要执行动作的位置。
更进一步，加入 BEGIN、NR、OFS 等字段，我对 awk 工具的认知也逐步完善。
哪怕原来的认知有误，再及时调整就行；犯错不可怕，可怕的是怕犯错，希望一步到位看清并理解任一事物的全貌是极难的。
2. 再把书读厚，才是学进去
“读薄”是一种“纵向”的学习方法，通过对一点的不断实践，修改认知，再实践得以进行；那么“读厚”，我理解的就是一种“横向”的学习方法，通过类比、对比等方法，发现不同事物之间的关联和差异，打通知识点间的“次元壁”，可以更好地融会贯通。
还是掏出三大神器，共通点是什么？差异有存在于哪里？
我理解的共通点，就是都是对文本进行处理的工具；差异在于，grep 更倾向于对原文本内容的抽取，sed 更倾向于对文本内容的修改，awk 更倾向于对文本内容的分析。
那么在面对 “找到127.0.0.1开头行的上下两行” 需求时，我就不至于手忙脚乱地不知道用 grep、sed 或者 awk。（如果没用过的此类工具的朋友，可以搜索 grep –C 补充）
当然这里只是简单的举个例子，诸位也可以尝试对比 Python 和 Java 的运行机制，这种自己感兴趣的问题。
3. 多问几个为什么
思考的多了，才能知其然也知其所以然，比如：
- Selenium 到底是怎么用代码控制浏览器的？
- 为啥 App 自动化在做 iPhone 的时候，我的 Windows 打死连不上？
- awk 为什么叫 awk，不叫 bwk？
什么问题都可以。
每个人的关注点不同，所提出的问题也会不尽相同；不要觉得好像没有人提，自己提出问题就很羞耻。但问题提出了就要认真对待，努力解决，自己搜、或者在学员群里求助，都是不错的选择。
4. 课堂以外的漫天繁星
数据结构、算法等等知识，其实不是哪一个课堂可以教授完全的；而且，有些内容也不是说课程体系没有涉及，就是完全没用的。说得功利一点，面试官问的时候，可能会更杂，如果完全答不上来也挺尴尬嘛。这些需要有意识的去补充学习。
- TCP 协议，为什么是 3 次握手和 4 次挥手，2 次握手 2 次挥手行不行？
- Python 的多继承中，数个不同继承等级的祖辈，继承了相同的远古祖辈（我编的名词）时，是什么样的策略？能用伪码表达一下嘛？
除了学院的课程和论坛资料等，这里也推荐以下我个人常用的工具和网站：
- ProcessOn：免费的在线思维导图网站（限定14个文档，但真足够用了），多终端可编辑的在线导图，真的帮助我想到啥，就整理啥。
- 力扣（leetcode）：算法刷题，大厂题库你懂的（不要求快，先刷简单再逐步加难度）。
- CSDN：技术网站茫茫多，反正我看的主要是这个；需要自己过滤掉一些标题党，拿来找灵感是个不错的选择。
5. 勤学苦练
其实，无论什么形式的学习，一定不要止步于看一看；技术进阶没有捷径，即使大咖亲授武功秘诀，也得自己勤学苦练才能内化成自己的实力。就像给你了一个烤箱，可以烹饪多种美食，但如果想吃饭，还得自己动手。
大厂测试开发面试必备经验
首先是修改简历，这是一项极其重要且繁琐的“工序”，请一定要重视。学院课程体系中的面试指导相关内容，给了我很大的启发。这里也特别感谢学院的老师不厌其烦地帮我调整简历结构、内容组成及描述方式，让我顺利地迈出面试“第一步”。
不同公司，对不同职级员工的招聘，或多或少存在差异，我做了一个简单分类：
第一类：业务能力面试
这是我们常规意义上准备最多的部分，包含测试理论、代码、数据库、计算机网络等等；如何准备这些内容，请参见我在学习心得板块里的分享。
这类面试中，被面试者往往存在一个误区：简洁明了回复面试官的提问，然后再等面试官的下一个问题。虽说谈不上错误，但是我认为这样的面试是很被动的。
因为无论是技术基础知识，还是工具使用，至少于我而言，是不可能完全掌握的。如果我只跟着面试官的提问回复，那就像一份80分的卷子，答对不加分，答错扣分。因为大部分面试官不会关注“超纲”的题目。也就是说，答对了，是理所当然；答错的点多了，就顺其自然的“不匹配”了。
所以，最好的策略是：要么赌，我答错的知识点数量，在面试官心理预期线之下；要么，主动出击，尝试找到面试官感兴趣，我也擅长的点，让“提问-回答”式的面试，变成一次分享。这样，即使有扣分，我也可以想办法一点点加回来。
举个例子，“给XXX简单设计一下测试用例吧”（这应该是最常见的问题了）
很多朋友老老实实等价类边界值写完功能点，再罗列一下性能和安全两类测试。然后回答在这里就终止了，但是面试官真的觉得问题得到了逻辑清晰完备的答复吗？
其实判定标准很简单，看面试官是否有追问；如果有，就证明你的回复方案，还可以更加完善。
比如我就被追问过，性能测试用什么方案、怎么观测性能指标等等问题；后来我把这类问题逐渐整合在一起，形成一整套回复的方案，再回头对比最初的回复，确实显得高级不少。
顺带一提的是，此类面试，切记注重复盘；没有复盘，就没有提升。
第二类：匹配度面试
说的比较宽泛，其实就一件事儿：你这人靠不靠谱儿（P.S. 我感觉以我 4 年 4 跳槽的履历，来谈这事儿其实挺可笑的）。
其实，在正式面试前，请大家一定要仔细思考两个问题。
“你有什么规划？”
常规来讲，回复的是短中长期的职业规划，以及短期为达成自己目标，所付出的努力。我自己就曾比较迷茫，不知道自己要什么（要赚钱是肯定的，满大街都是要赚钱的，没啥意义），在 HR 面被拿下过 10 连斩，很痛苦。
“你为什么离职？”
这类问题的答复，在网上有很多版本；JACK 马老师的经典两段论，也被传唱已久。但我个人建议，真的好好思考一下这个问题；不仅是为了“应付”面试，更是给自己找清方向，不至于在“频繁”跳槽后，失去本心。
每个人所处环境、理想都不尽相同，这类问题并没有所谓的标准答案。我个人的建议是：源自本心，稍加修饰。在思考完这两个问题后，需要注重避开所谓的“雷点”：比如个人规划，却只想不做；离职原因，全都是公司的错。一定要修改完善回答方案。
第三类：“请你简单介绍下自己？”
之所以把这个问题，独立成一类，是因为在这个问题下，被面试者拥有最大的主动权，可以快速展示自我的优势项，拉高面试起评分；也可以突出闪光点，引导后续面试官提问的切入点。
目前我的自我简介，是按照如下思路梳理：个人信息（姓名、业务线、title）、业务方向、职业经历（工作年限、擅长业务方向）、当前工作概述（大致工作内容、怎么开展工作）、技术钻研方向（我目前主要在关注业务监控相关的，但也可以是自动化等等）、主要项目（项目背景、难点、创新点，个人作用、成绩等等）。
在设计自己的个人简介时，建议根据自己的核心竞争力（项目经历/技术理解等）酌情调整；简而言之，明确“基本盘”，辅以“加分项”。
另外，再补充一点点：
对于第一、二类面试，既有简单粗暴的直接提问，也有要你介绍下XX项目，然后再从其中挖掘的形式。
在面对以项目作为切入方式的面试时，切忌流水账，背诵简历全文；简要介绍项目情况之后，着重讲解某一环节，也可以起到第三类面试中，引导面试官提问的作用。
但技巧总归是技巧，不要妄图用战术的勤奋，掩盖战略的懒惰；就跟学生时代老师挂在嘴边的那句话一样，“不要以为，你们在下面做什么小动作，我不知道”。
只有脚踏实地的奋斗过，才不至于让面试沦为一纸空谈。
写在最后
非常感谢霍格沃兹测试学院，提供如此高质量的课程和完善的知识体系，让我受益匪浅，获得测试技术和职业发展的飞速成长。也很开心能与诸位测试同学交流，在这里也分享一句鸡汤：
种一棵树最好的时间是十年前，其次是现在！
测试开发进阶，一起加油！⛽️
更多技术文章分享及测试资料点此获取
