入行测开5年，年薪50W，门槛也没那么高吧···

Posted 2021-08-12 软件测试小dao

入行测开，马上就要5年了。创业公司待过，大公司也待过，工作这一路走来，一些心得，转变，职场体会，早就想写出来分享一下。 这个历程包含了技术的提升，工程师的素养和对这个行业的点滴感悟。

自动化测试vs测试开发

记得刚入行那会，我的title是自动化测试工程师。 那时对这两者的区别还没那么明显，面试时候两者的问题也都比较类似。当时招聘"会写代码的测试人员"比较偏向称之为"自动化测试工程师"； 不过现在很多企业的招聘都变为"测试开发工程师"了。

究其概念，其实自动化测试工程师更偏向于业务方向的效率提升； 而测试开发则更偏向于基础架构方向的效率提升。打个简单的比方，测试开发工程师产出的框架可以认为是父类，自动化测试工程师按业务线不同， 可以理解是继承自父类的不同子类。
测试开发到底在做什么？

测试开发，最早起源于《Google软件测试之道》这本书， 里面第一次提出了SET(Software Engineer in Test)。不过不同的公司称谓也不一样，像国内很多时候还是统称为QA。

那么SET具体在做什么呢？在我看来，SET偏向于测试部门的基础架构开发和流程的设定，比如前面说到的自动化底层框架搭建，或者改写一些开源的类和方法， 去提供给组内其他的测试人员使用；再比如，我们所熟知的CICD，单元测试or集成测试的覆盖率统计，以及自动化部署发布的脚本，都可以归到测开的工作范畴里；还有，我们常说测试也需要新技术的引入， 现在常见的Docker跟k8s也在逐渐普及到测试团队，因为测试最大的一个障碍是"测试环境众多"，而容器化可以很好的解决这一点。

当然不同的公司情况多有差异。一般来说， 越是大型的企业，它的测试流程越规范，测开的作用也就越明显，对应的产品测试效率，也就越高。
质量保障的终极任务

我相信现在很多测试工程师，其实都有足够的共鸣， 就是"我们不是测bug的，我们是产品的质量保障员"。但是很多不成熟的企业和团队还是会有误区。 比如，bug数目确实可以代表你工作的产出，但如果你的团队或领导把bug数目作为唯一指标，我觉得你是时候考虑跳槽了。质量保障，在我看来涵盖很多东西，是一个很庞大的概念， 大概可以包括四点：

1.正确的流程

现在很多都是敏捷开发模式了。在需求评审阶段， 测试同学参与并对需求or产品有一定的理解和初步的测试计划

2.基础的质量

开发代码的规范度，基础代码的走查， 监督单测覆盖率的稳步提升，毕竟基础决定上层

3.业务的覆盖

确切可以拆分成服务接口的测试/前端UI测试/性能测试/稳定性测试/系统集成测试/回归测试， 这一点可以说是测试同学交叉最多的地方。

4.产品终端的保证

协同制定灰度发布策略/规范线上的操作/了解用户使用过程中常见的风险点/制定止损策略

简单来说，测试保障质量，质量决定产品。 测试应该是对需求，对产品逻辑最最了解的那个角色。所以，只要关于产品变更的，测试同学都应该下意识去跟进。

而以上的任何一点，都可以深究， 去做的更好。
工程师文化

我相信再牛逼的测试开发，也要从业务抓起， 你不了解业务，不了解一些开发代码或者的话，有些东西也是扯淡。业务测试在我看来一点都不low，反而是一个很考验人的事情。不管是测试工程师也好，测试开发也好，我们都是工程师，都服务于产品。 既是工程师，就该有工程师的素养，我认为完成一个好的测试任务，大概需要同时做到以下几点：

1.对测试结果负责

我们是产品的最后一道关卡，我们对产品发布与否有绝对的话语权，同时，我们也要对自己的测试结果负责。

2.测试到最终场景

现在很多产品链路都很长， 这就需要测试同学主动去塑造自己产品的大局观，而不局限在某个单元的测试，不考虑全局，有时会造成致命的线上灾难。

3.对日志敏感，能够精准定位问题

如果开发流程足够规范的话，有完整的日志系统， 其实定位问题并不难；我们每发现一个bug，都可以尝试去追溯它的根源，时间久了，你会对工程代码或逻辑摸的很清楚，这对你接下来的测试工作简直如虎添翼。

4.对相似问题和漏洞的归纳

不管是前方客户的问题，PM发现的问题还是自己的bug库， 经常归纳可以节省很多时间，会让你对自己的工作产生一种"直觉"，但这种直觉有时很准哦。
面对不同的产品该怎么办？

开发技术或框架可能是通用的， 但测试可能会随着产品形态而产生"独特"的调整，我称之为"测试形态"。比如，现在的人工智能测试，因为每次模型迭代，测试所需的数据量很大，你用传统的并发去请求可能就不行，那你可能就需要学一些分布式技术； 再有就是云服务测试，这种绝大部分是纯后端服务测试，或者SDK测试，没有前端去assert你的预期，那么你就需要足够熟悉curl命令，网络命令等，甚至去生成一些shell脚本，来执行你的测试请求； 还比如手机端的测试，那它的兼容和稳定性呢怎么保证，则又是一门学问；最后还有比较火的智能硬件，盒子啊TV啊这些，怎么保证它的质量，则又是另一种路子。

但，归根结底：测试思想不会变，以不变应万变。
总结：

测试是一门大学问，它入门门槛并不高，但是越深入，你发现自己了解的越少。 作为一个职场人员，不随业务转变而转变，有自己的沉淀和技术底子，才能更长久。 而测试开发这个行业，鄙人认为未来也会愈加重要，它是衔接产品/测试/开发的一根纽带，它在背后默默支撑着整个测试体系有条不紊的进行，某种程度上说， 算是一个隐者吧。

最后
为了帮助大家迅速建立测试思维能力，早日斩获大厂Offer、掌握职场话语权，下面这份《软件测试全栈学习路线图》应该会对你很有帮助

从测试概念到最后的测试开发，希望大家能照着这个体系，在3-4年内完成这样一个体系的构建，可以说，这个过程会让你痛不欲生，但只要你熬过去了，以后的生活就会轻松很多，正所谓完事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好：不积跬步无以至千里，等到完成之后在回顾这段路程的时候，你肯定会感慨良多，掌握了以上技术，在任何一线互联网大厂测试岗位都能独挡一面。

特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括，软件学习路线图，50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享，还有2021软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助……

关注我公众号：【软件测试小dao】即可获取这份资料了！