---

前言

测试职业的天花板是不是很低？

回答这个问题前，我想请大家先想一下，当初自己为什么会选择测试这个职业？
入门门槛低？不需要写代码？工作比开发轻松？还是其他？

这个理由或许就是问题的答案。很多测试人员之所以选择这个职业，是因为觉得测试相对开发来说比较“容易”。所以，天花板其实不是别人给的，恰恰是自己给自己设定的。

不论是开发还是测试，或者 SRE、DBA 等等，他们在核心能力点上有很多共通之处，只是在末端领域方向上有所分化。测试从本质上说，只是开发的一个方向，而不是区别于开发的岗位。因此，理论上他们之间可以相互转换。

事实上，我所在的企业里，测试转岗开发的情况非常普遍，这就足以说明这个问题。即便是测试专业，做到 P9 甚至更高级别的情况，也不是没有。他们既在技术上有深厚的基础，又在业务上有独到的见解。所以，所谓的天花板，最终取决的还是自己对测试职业本身的认知和实践。

有不少人会想，自己学技术并不擅长，但可以凭借熬资历坐上管理岗位，就能绕开技术的短板。而现实中的确也有很多这类情况，管理岗位可以不用亲力亲为，只需招聘比自己技术能力更强的下属来完成任务，看起来似乎一切都很理想。

这种途径真的可行吗？
我们需要用足够长远的眼光来看待这个问题。过去几年在互联网红利的加持下，企业需要抢占地盘，达到赢者通吃的目的。这个时期业务的成败，更多依赖的是投入速度而非人员素养，因此企业才会大规模、高薪水地进行招聘。在人员数量极速膨胀的情况下，难免就会鱼龙混杂。

测试技术是不是等于写代码？

首先我比较反感现在市场上把测试岗位分为“手工测试”和“测试开发”。这种划分方式，一方面强行降低了“手工测试”的入门门槛（手工的意思不就是点点点？），造成行业能力水平的混乱；另一方面让“测试开发”产生一种不该有的优越感，为了有别于“手工测试”而脱离业务。

我们必须要明白，技术存在的意义，就是为了产生业务价值。手工测试也好，自动化测试也罢，都是为了让业务发展得更好。比如为什么要做自动化测试，一定是因为我们判断它能给业务带来好处，而不是主观上或习惯上觉得要有自动化。因此，强行将自动化测试、性能测试与业务团队剥离，只会让两个部分的人员都没有成长。

较早前我和教育行业某公司的一位测试经理交流过团队组建方法，她很惊讶于我们整个团队都在写自动化而不是构建专门的自动化团队。而我告诉她的是，只要采用合适的方法，让团队平均达到这种水平只需要三个月。我们经常过高地估计掌握技术的困难，也经常过低地估计自己学习技术的能力。

两年后，她的团队不巧遇到教育行业的调整，被迫进行人员缩减。优化掉的并不是“手工测试”，而是“测试开发”。她也很坦白的告诉我，少了这些测试开发，业务依然能够运转，但少了手工测试，团队立即就会完蛋。现实就是如此，个人的价值体现，最终还是要由业务价值做出判断。

有所谓的手工测试和测试开发，技术也并不等同于代码。我们是否学习和采用某种技术的唯一标准，就是它能够给自己的业务带来多大的帮助，仅此而已。

当然，这不是说代码不重要，而是说要明白为什么学代码，学完代码又要如何应用。代码之所以关键，是因为它是很多技术的基础。比如自动化测试需要写脚本，白盒测试需要 Code Review，开发测试工具也离不开编程等等。

每个领域也都有自己的专业知识：接口测试需要理解 HTTP 协议，安全测试需要理解攻击原理，性能分析需要理解技术架构… 技术世界浩如烟海，我们不用急于求成，可以在实践过程中，逐渐掌握各个领域需要的技术点，由点到线，再由线到面，最终发展成全面的技术体系。

下面是我整理的2022年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

经验环境和遗传造就了你的面目，无论是好是坏，你都得耕耘自己的园地；无论是好是坏，你都得弹起生命中的琴弦。

面对困难挫折挑战只要你肯相信自己，不断努力的付出，哪怕你现在的人生是从零开始，你都可以做得到。

钢是在烈火和急剧冷却里锻炼出来的，所以才能坚硬和什么也不怕。我们的一代也是这样的在斗争中和可怕的考验中锻炼出来的，学习了不在生活面前屈服。