2022分析：测试岗位会越来越少吗？再不卷就吃土了......

---

前言

测试工程师职责
评估对用户的影响以及软件产品整体目标上的风险；
从用户的角度来思考质量方面各种问题；
从开发角度来看，测试编写用户使用场景方面的自动化用例代码；
从产品角度来看，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性；
产品专家、质量顾问和风险分析师。

测试工程师不是开发的拐杖
开发、测试、产品、运维在一条船上。

质量需要每一个人的贡献，而不专属于“测试”工程师。我们越不让开发考虑测试的事情，把测试变得越简单，开发就越来越不会去做测试。如果测试是一个独立的部门，这个问题更严重。

保证质量不但是别人的问题，它甚至还属于另一个部门。出问题的时候也很容易就把责任推卸给质量部门

一、测试行业现状

我的整体意见是软件测试岗位不会变少，反而相对于其他岗位会变的更重要一些。

首先纠正一个非常非常错误的观念。测试和测试开发是两个岗位？No，不是的。测试开发是属于测试的。

测试开发只不过是使用类似于开发的技术和能力，来达到测试的目的，本质还是测试。

就如同一个人用人肉扫地，另一个人发明了自动扫地机来扫地，看起来后面这位更高级，但是实际目的还是扫地。

二、测试的本质

其次就要说到软件测试的本质，以及行业对测试愚蠢的误解上来了。

我曾经前一段时间去阿里面试，测试相关问题回答良好，技术原理理解力，业务熟悉度，测试框架的设计思路，都回答良好。最后考了我两道算法题，回答的不是很好，最终说我技术不太好，offer给的不高。于是我tm就拒了，心中一万句mmp。

没想到如此大厂也是对测试误解如此深，因为他们招测试的标准就是在招研发。

就如同扫地，你扫地机器人做的再牛逼有用吗？如果你的场景是擦玻璃窗，而压根不是扫地呢？

测试的本质是，理解业务，产品和需求。傻乎乎地用研发标准招一坨长得像测试，但是实际是研发的人，就无法保障测试到位。测试是非常靠软实力的，标榜自身技术能力很好，但是半个重要bug都测不出，线上事故一坨，这样的例子见的太多了。

三、测试的进阶形态

测试有两个进阶方向，一个是理解实现原理。也就是你要明白，当前项目里面，业务需求是如何变为设计，再变为代码实现的。代码逻辑层次的耦合，数据库设计，甚至网络层如何通信，拓扑架构如何，都需要理解。

注意，理解即可，不需要完全掌握。这样，任何研发行为你都可以明白其意义和风险，你就可以精确设计测试用例，不浪费自己的时间，也不会遗漏高风险场景。

另一个方向就是自动化，也就是在简化自身的重复劳动。这个虽然非常重要，但实际上现在成熟框架很多。而且测试框架其实不像研发框架，测试框架优先关注的是易懂性，易用性，交流能力，扩展便捷性。

测试人员在选择框架和使用框架时，要灵活，要贴合业务。比如他可以去思考，是否可以把一个扫地机器人改造为擦窗机器人。

四、测试行业常见问题

1、如果你指的是业务测试外包给阿里做，那这个可以不讨论了。测试外包在十年前就有了，逐渐已经不流行了。这是因为维护一两个专职测试人员，比外包靠谱的多。自己的测试人员理解业务，外包就是瞎测，一旦换人就面临很大风险。这也说明了，测试的本质是产品。业务和需求。

2、性能测试和自动化测试是否可以外包？也不可以，但是我们确实可以有平台或者框架，来集约一下大家的知识和资源。所以最合理的模式是，阿里这样的大厂提供平台，或者开源测试框架，而其他公司的专职测试去使用。

3、测试岗位的人数确实可能会下降，不是因为提问里面的原因。而是因为：测试自动化程度变高，手工测试消失（但测试开发会变多），这是目前一个已经既成的事实；另一个原因是开发的测试意识变强，自测能力提升，运维的质量意识变强，线上测试和质量控制体系的建成，这是目前的一个趋势。

4、那么为什么我还说测试人数会变多呢？因为随着软件开发行业的体系化，运营化，质量会变的越来越重要。而测试的软实力，分析业务构建测试思路和用例，沟通作用，流程控制作用，都是更难被机器所替代的。如果说以后机器可以帮忙写代码，做项目，那么最后两个被机器代替的岗位，一个是测试，一个是产品经理。

五、总结

人生是战场，需要冲次，需要拼搏，处处布满陷井，一不小心就会中埋伏，就会遭遇失败，永无翻身之日，但我们拼搏一定要方向明确，有目标性拼搏，才会成功，幸福才会属于你。

很多时候，因为无奈，因为不公，因为受伤害，很多人放弃了自己从前坚持的信念。幸好，我们还没有放弃。

每个人的心里，都藏着一个了不起的自己，只要你不颓废，不消极，一直悄悄酝酿着乐观，培养着豁达，坚持着善良，只要在路上，就没有到达不了的远方！