职场四年，关于我的测试旅程..._功能测试4年,有行程什么技术文档

软件质量保障:专注测试圈，自动化测试、测试平台开发、测试新技术、大厂测试岗面经分享。

介绍下自己的测试历程吧，邮电高校通信小硕，毕业4年，去年成功转型测试开发，周末会总结测试心得。

1.平凡的大学生活

我大学期间属于并没有什么出众的，按部就班，老实办事的那种学生，我导师对我们那届的学生比较散养，只要完成导师给的任务，毕业是问题不大的，所以学术产出一般（学术产出拿到校二等奖学金），一个专利+一个EI+一个DSP会议。

研二尾声大概4-5月份开始准备校招工作，当时的自己因为编程能力并不出众，所以决定投对于编码能力要求不高的技术支持和软件测试相关岗位。暑假就开始在实验室复习计算机网络、数据结构、C语言、操作系统、通信等知识，准备迎接8月份开始校园招聘。而同实验室也有同学去报编程辅导班的，后面校招就去了大公司。

2.误打误撞从事测试岗位

校园招聘开始了，肯定优先考虑大厂呀，像华为、中兴、腾讯、百度、阿里等都投了简历（但是当时对bat并没有报希望，自己几斤几两清楚的很，所以只是贵在参与，但是对中兴华为还是挺有信心的，主要是专业对口，而且做的准备工作充足）。果不其然，阿里简历没过，腾讯百度笔试没过，至此bat全军覆没。当然我也并不意外。接下来是华为面试，投的是技术支持岗，依稀第一轮面试问了很多通信专业知识，这个回答的没啥大问题，但是也没有亮点。本以为能进入二轮面试，可惜没给机会。说实话当时面试结束后挺失落了。毕竟准备了这么久，没想到二轮都没有进。接下来中兴测试岗位面试类似，进了二轮，但是三轮没过，所以当时大家追逐的“大厂”都与我无缘。所以也开始准备各种“小众厂”。毕竟面试多了，经验也充足了，下定决心只投软件测试。最终拿到了杭州的一家金融科技软件公司和成都的一家通信芯片公司软件测试岗位。待遇上杭州offer比成都的好，也是自己喜欢的互联网行业，加上杭州当时有高学历人才补贴，所以就去了杭州。

 

3.初入职场

毕业来到公司，被分到公司的创新业务部门，测试小组6个人，就我一个新人。刚开始工作内容web测试，也就是对着页面点点点，学习Jmeter写各种测试用例(提升测试覆盖率，为了完成组内kpi要求 )。带我的是一个工作几年的同事，至今还记得参与第一个项目时候，测出一个bug时候还有点小兴奋。

 

但是工作了2个月不到，就开始对这种工作内容产生厌倦了，重复度太高，感觉自己就是个机器人 ，除了越来越熟悉业务，看不到太多成长，完全是浪费时间。

对，这是第一次遇到瓶颈！！！

 

4.克服第一次瓶颈：养成自动化思维

虽然当时是测试，但是我当时的认知是开发只是还是要学，所以我平常下班后也会自学spring mvc，Java web编程、redis等似乎当时看起来没什么用的东西来充实自己，经常学习到凌晨，周末也花一天在家学习。(现在想想，当时也走了很多弯路，学东西都是靠百度Google，没有系统性学习。虽然也掌握了些开发技能，但是并不牢固。)

对于测试上遇到的瓶颈，我就和同组的老同事交流，问他们是否也曾遇到类似的瓶颈，如何克服瓶颈期的？有个同事的回答似乎一下子点醒了我，他说的就俩字“偷懒”。然后我就很好奇这是什么意思，怎么个偷懒法。然后就聊起来了Python，可以使用Python写测试脚本，比如造数据，结合selenium做ui自动化。这是我第一次听到Python，通过他给我看的他写的批量造数据脚本瞬间生成成百上千条数据，当时感觉这玩意肯定有用，有大用处。

然后我就下班自学Python编程，开始尝试写简单脚本，比如利用pymysql操作数据库，利用selenium做ui自动化。虽然当时老板在组内不鼓励做UI自动化，但是抱着好奇与学习的心态还是自学了下，也基于项目开发了case。但结果不出所料，需求变动频繁不适合做UI自动化，利用selenium写自动化以及维护自动化用例成本太高，所以没有解决手工测试重复度高的根本问题。

但是通过学习Python和UI自动化，提升了认知，原来很多工作是可以通过Python代码解决的，对这就是自动化思维(虽然也学习过Java，但是诚心讲，它不适合写批量的测试脚本) 。后面的工作就养成了一种思维，遇到重复度高的内容(重复度>3)，第一时间去思考是否能通过自动化手段解决。

 

5.克服第二次瓶颈：进入字节跳动

转眼工作了快一年半，虽然年中绩效还不错，而且还拿了部门的一个测试奖，但是觉得在团队里很难再提升了，因为当时能接触到的开发相关知识、运维知识自己也都熟悉一些，还有就是当时测试在项目中话语权低，部门老板不太重视，测试很难推行一些质量改进工作，所以觉得自己可以看看更大的平台。(因为我们团队测试经常出差驻场甲方爸爸，像搭环境、部署产品、问题解决都是测试一个人搞，简直把自己逼成了“全能王”)。

开始准备面试：网上找各种测试面试经验、面试问题。也针对几个中意的大厂找了面经。

然后投了xx银行、OPPO、字节跳动。对，都在上海，经常出差上海的我慢慢喜欢上了这座城市，与其出差来这里，不如工作在这里。

xx银行最早面试，周六从刚杭州坐高铁现场面试，一次性三面，当时的老板对我比较满意，给我聊了下他们团队的规划，团队的实力（有很多大厂背景的)，但是给的薪资，考虑到上海物价，扣除花销等于从杭州平移到上海，所以我放弃了这个offer。

然后就是OPPO，字节跳动，这两家公司几乎是同时在面试，最终先拿了字节跳动的offer，OPPO终面也就放弃了，和他们hr说明了原委。

6.克服第三次瓶颈：转型测开

来到字节跳动，老板也很好，他也给予很多帮助和成长机会，比如团队管理、自动化测试以及参加测开大会、对外的学习与交流。字节期间最大的成长就是承担团队自动化测试owner，推动了我们团队从手工测试向自动化测试转型。

来到字节一年，有过一次涨薪，不得不说，字节对于付出多、高产出的员工真的是很大方，真的不差钱，涨薪幅度也是挺豪气。

 

【干货】如何推动业务测试团队转型自动化测试？

 

上海虽好，但是上海这座城市购房压力太大，结合自己实际情况，还是决定去成都发展，虽然不舍字节和当时的团队以及非常nice的老板，但还是要考虑未来的生活质量和自己能承担的压力。

然后就开始寻求公司内部转岗的机会，看到成都有xx团队测开机会，就和老板沟通了一下意向，很欣慰他也遵循我的意愿同意我转岗。

第一次测开转型尝试-内部转岗XX团队，虽说是内部转岗，但是面试难度丝毫没有降低，因为前期在头条圈看到的转岗率多高多高的帖子，所以这次转岗并没有针对性XX团队侧重的技术面（偏移动端，而我工作内容web中台、工具开发，在字节几乎没接触移动端）做一些准备，最终结果也是不好的，面试没通过，至今觉得挺遗憾的，如果做足准备，转岗概率还是蛮高的。

第二次测开尝试-尝试阿里巴巴测开，第一次的失利，总结了很多经验，也为后面进入阿里打下了基础。比如多线程、高并发、leetcode、spring mvc等，这些都是测开岗必考题，一面问的技术问题更多些，二面回结合项目穿插一些技术方面的问题，例如如何利用xx技术解决高并发的问题等

 

最终如愿以偿拿到offer，在成都已经很知足了。除了薪资，更重要的是测试开发的机会，毕竟阿里在业界质量保证基础建设是相当完善的，能够在阿里接触更多成熟的测试技术和来自项目上的挑战。

 

7.开始灌鸡汤啦

1. 瓶颈普遍存在。感谢瓶颈，瓶颈就是机会。每个人在发展过程中，都会遇到各种瓶颈，有瓶颈是好事，表示你渴望成长，只要多和身边的 “高阶 “同事多沟通，多听建议，他们是可以给到你很多帮助的。

2. 选择很重要，努力更重要 没有努力谈选择等于空谈！！！选择一个平台很重要，遇到一个好老板更重要，但是前提是你要准备好给你选择机会的 “基础”，真的很感激 Z 哥，是我职业生涯的伯乐。

3. 持续学习决定你能走多远 - 养成持续学习的习惯。学历只能代表过去，工作上更重要的是要不断学习。持续学习能力决定一个人能走多远，它主要体现在：归纳分析能力；思维创造力；时间管理能力；自律能力等方面，养成这些习惯，对于一个人的成长至关重要，也是克服成长路上遇到瓶颈的 “杀手锏”。

4. 多写博客多记录工作历程。Writing is Thinking。所写即所思。你是不是有时候感觉很懂一个东西，但是给别人分享时候，却表达的不怎么样。其实根因就是你并没有想象的那样了解了一个技术。尝试把它们写出来吧。

5. “三思而行”。在大公司，牛人很多，你的所思/问别人的问题决定别人对你的看法。建议大家遇到每个问题 都先说服自己，多问一下自己这是 what、为什么是这样 why，怎么解决 How。

8.阿里测试开发旅途

 

       对测开岗位的理解：测试开发仍属于“测试”，测试工程师侧重“被动”的质量保障，即通过常规的测试手段保障业务质量，但随着公司业务场景的复杂以及研发周期的不断缩短，这种传统的质量保障手段已不能满足新研发模式下对产品质量的要求，如何在活多人少的情况下保障高质量，这就需要测试人效的提升（同样的时间做更多的活）和化“被动发现”为“主动出击”提前发现问题的能力。如何做到这些就必须借助于技术手段了， 而这也就体现测试开发中的“开发”能力了。但测开最终的目标仍是质量保障，所以我认为测开仍属于测试。

当然知乎上有类似问题的帖子：《测试开发是什么？为什么现在那么多公司都要招聘测试开发？》

 

1.阿里测开类型

大家可以在招聘网站看到阿里巴巴开放的质量岗位基本上都是测试开发岗，而入职后具体从事的工作内容是要视你面试的团队而定(面试过程会告诉你大概的工作内容的)。据我了解，阿里的测试开发可以分为两类：

• 一种是纯技术型的，专注质量工具和各种“神器”的开发，他们服务于业务团队，旨在解决业务测试遇到的各种难题（比如测试有效性，参见南门大佬的文章《阿里研究员：软件测试中的18个难题》）。

• 一种是业务测试+技术专项，基本上7/3分，偶尔业务量重的时候10/0分（当然了，团队内部的测试人员技术水平有高低，而技术相对较好的同学可能业务量稍微轻一些），因为业务测试是发现各种测试难题的先决条件，而解决业务测试难题往往要借助于技术手段，所以技术专项由此而来，而专项课题一般来自于团队内部测试人员遇到的测试难题。

2.我在阿里的工作内容

我在阿里所在的团队是承担业务测试的团队，研发/测试比大约在4:1。测试团队每个成员单独负责一块业务测试还兼做专项，例如提效工具/机器人、巡检、测试覆盖率的课题等。

• 业务测试就是功能测试，不外乎点点点。当然基于技术架构不同，阿里更侧重测试左移和右移。左移如参与code review、异常测试等；右移如重视线上监控、应急这些。（安全、性能测试这些都有专门的团队做，你只需提工单即可）

• 接口测试用例开发，一般是在提测前开始，利用团队的接口测试框架开发接口测试用例，除了增量测试用例，还要维护存量测试用例。

• 写文档，其实这块和功能测试范畴有重合，我为什么要单独拎出来呢？是因为我入职来文档统计数据显示我每天至少一篇文档的产出，而我竟然毫无察觉。

• 对外提供支持。对兄弟域联调&提供造数等工具支持

• 协调&沟通。不得不说在阿里做项目的沟通成本是比较高的，因为你的兄弟域可能分布在"五湖四海"，甚至是国外。如果你是主测，那么你就要负责全链路质量保障的责任，协调&沟通各域的测试同学的测试进度、项目风险；上线时候要紧盯线上监控和报警等问题。

• 专项测试就是我上文说到的，课题来源于测试过程遇到的难题。例如如何证明你的测试是有效的？如何尽可能快的监控到线上报出的问题？

3.重复造轮子问题

也许你会问，都在做专项、做测试平台？是不是在重复造轮子？

首先告诉你结论，确实是在重复造轮子，而且我认为是必然的。

我入职至今，已经接触（使用）多达3个接口自动化测试框架，这么多框架的由来也是有原因的，例如旧框架升级成本高，导致老业务的自动化测试用例没有完全迁移到新测试框架，进而维护多套测试框架；还有就是我们经常涉及到跨域测试(补位)，而不同域有自己的一套测试框架，所以你也要掌握。但是我对重复造轮子的态度是中立的，并不反对，我们应该从多方面看待这个事情。

1. 从阿里自身业务架构看，阿里的产品业务复杂度高，技术实现架构是微服务，不同业务模块(也称为域，例如资金、金融、支付等)是不同的测试团队负责，各域间既是合作又是独立的关系。

1. 1. 从全链路角度看，各域是相互合作的，缺一不可，任何一个域出现问题最终都会影响到用户体验。

   2. 从团队角度看，各域又是相互独立的，这是因为各域的老板（一般是8）是不同的，而不同老板对团队的管理策略可能是不同的；其次团队间也有一定的“竞争”关系（哈哈，这也可能是大家常常挂在嘴边的“内卷”吧）。

   3. 各域间的质量要求可能不尽相同。例如资金域，对资损是0容忍的。因此各域间对业务质量保障采取的测试策略和方法可能略有不同。

1. 当然从侧面说明阿里的质量基建建设已经比较完善了，在国内已经是top级别了，毕竟经过了20多年的发展。

2. 从测试(特别是小P)自身看，我认为技术产出相对业务产出来说，显得更重要。因为做好业务测试是基本工作，话说人无我有，技术产出对于衡量团队成员间绩效就显得非常重要了（不可否认一部分轮子确实生而为绩效）。

3. 客观来看，正像国家提出的“大众创新，万众创新”的口号一样，提供一种竞争氛围也未尝不可，黑猫白猫捉到老鼠就是好猫。也正是众多轮子的存在，才衬托出最终“赢家”的可贵。

当然了，重复造轮子的缺点就是人力资源的浪费，对于公司来说是一种用人成本损失，我相信国内的大厂都会有类似的问题。

9.测试工程师如何转型测开

 

1摆好心态&开放眼界

      我始终认为 掌握技术最重要，title不重要。测试工程师和测开只是title不同，工作内容并没有明确的边际，这个完全取决你对测试的看法！有可能一些公司的测试工程师做的是某些公司测开的干的活，而一些公司的测开可能做的是某些公司测试工程师的活。就像我在字节时候，title是测试工程师，工作内容是业务测试+接口测试平台开发7/3分。而在阿里则也是差不多（甚至阿里的业务还更重些）。对于我来说两家公司的工作内容是没什么区别的，只是title不一样而已。

      对于想转测开的测试工程师建议：调整心态，不要以“测开”唯是，提升自己的技术能力才是重点，要养成持续学习的习惯，多接触一些知识，拓展自己的眼界，在业务测试过程养成“偷懒”的习惯，多思考自动化手段减少手工测试工作。

 

2夯实&运用技术

 

1.编程能力要过关

至少精通一门语言。而且使用该语言开发过工具或平台最佳。一是测开通常要手写代码，这个是门槛。二是有开发经验能侧面证明你对开发语言的熟练程度。

至少掌握一个开发框架。例如spring boot、flask、Django、VueJS等。

 

2.基础算法要熟悉，学习的同时建议结合LeetCode练习。

1 快速排序算法

2 堆排序算法

3 归并排序

4 二分查找算法

5 BFPRT（线性查找算法）

6 DFS（深度优先搜索）

7 BFS（广度优先搜索）

8 Dijkstra算法

9 动态规划算法

10 朴素贝叶斯分类算法

 

3.有所专长(亮点)

前文说到过的一个道理，人无我有。在大家都掌握相同“技能”的前提下，你能做的更深入或者有别具一格的idea，则这就是你的亮点。例如擅长性能测试、擅长效率工具开发、擅长平台搭建等。当然这个因人而异，视各人兴趣点而定。

 

4.多利用技术手段解决业务问题

我认为这个是最重要的。纵然你掌握上述能力后，但是缺乏运用技术解决实际问题的能力，仍然是纸上谈兵。正如第2节所说的，测试开发岗位职责都要求解决复杂问题的能力。而我在面试中问到的最多的问题就是 为什么做这个东西？你这做的东西解决了什么问题？后面我会附上面试经验分享，里面包含所有面试题目。而如何提升解决问题的能力，第一步就是要善于发现问题，这就要求工作中大家保持怀疑心态。

 

3 “创新”意识

 

不可否认创新是属于少数人的专利。但是并非大多人不能创新。我们可以二次“创新”，可以将前人作出的成果二次创新运用到我们的业务中并解决一定的问题，我觉得对于普通人来说这就足够了。

如何保持开放心态，建议大家多参加测试沙龙和论坛，业界比较专业的测试论坛 如：每年两届的MTSC大会，议题质量是相当高的，基本都是BAT议题占了半壁江山，可以说BAT的议题成果就是国内测试界的发展标杆和方向（虽然BAT的议题可能是别人玩剩下的）。

此外，关注各大厂质量相关技术公众号，多看看他们发的文章提升眼界。

10.我的阿里测开面试题分享

技术题

1. 了解多线程吗？了解Python的GIL锁吗？

2. 说一下进程和线程

1. 进程间通信的方式有哪些？

2. 说一下什么是乐观锁和悲观锁？

1. AOP

2. 什么是IOC？

1. list和map相关

2. 解释一下工厂模式？

1. 内存泄漏

2. 会做性能测试吗？容量测试/稳定性测试？

1. Python2和3的区别？

2. DNS解释一下？

1. 用户名、密码、验证码哪个校验顺序？

2. Linux根据进程查端口/端口查进程

1. 常用的Linux指令？

2. 排序算法

围绕工具开发

1. 工具是如何开发的？

2. 为什么要开发这个工具？

1. 公司内部没有类似平台吗？

2. 效能工具包含哪些？举几个例子？

1. 介绍一下自研的接口自动化框架？

1. 1. 有哪些模块组成？

   2. 相比其他框架有哪些优势？缺点有哪些？

   3. 介绍一下框架的代码生成模块是怎样实现的？

   4. 使用你的框架测一个接口需要做哪些步骤？

   5. 接口的断言怎么做？

   6. 接口测试带来的收益？

   7. testng和junit优缺点

1. 造数据工具，如何开发、提效多少。

大数据测试

1. 怎么测试数据的准确性？

算法测试

1. 算法测试做哪些工作？

2. 如何进行算法评测？

3. 不同的算法类型，评测标准是不同的

4. 介绍一个最近的算法测试案例？

1. 如何选择测试集？测试集的特征如何选择？

2. 说一些填空题小空识别算法的badcase？

1. 如何保障算法质量？

 

编程题

1. 词频统计

2. 线程交替打印奇偶数

1. 最长回文子串

项目经历

1. 介绍一下负责的项目？

2. 针对老系统（僵尸代码）如何保证质量？

1. 做过的项目遇到的最大风险点？

2. 怎么保障项目的质量？

1. 如何处理紧急需求？

2. 项目的迭代方式？

3. 说一下最近项目推动成功的案例？

4. 说一下自己人力分配？

持续集成

1. 了解CI吗？解释一下CI

2. 如何衡量测试用例质量？

3. 说说你对测试的理解？或者说质量的理解？

团队管理

1. 团队管理上有没有什么难点？

2. 你期望一个怎样的测试团队？

1. 团队的测试开发比是怎样的？

2. 如何衡量全职/外包比例？

3. 外包的忠诚度如何保障？

4. 你能为团队带来什么？

HR问题

1. 为什么跳槽？

2. 为什么选择阿里？

3. 前几家公司收获

4. 有什么问题要问的？

5. 工作中最大的挑战（最大挫折），如何克服的？

6. 最大的优点和缺点？各自说一个？

7. 未来的职业3-5年发展规划？

 

附：测试小白到高阶测试技术栈