先说结论：软件测试的岗位不会越来越少，但是要求会越来越高。
我的整体意见是测试岗位不会变少，反而相对于其他岗位会变的更重要一些。

首先纠正一个非常错误的观念。测试和测试开发是两个岗位？No，不是的。测试开发是属于测试的。
测试开发只不过是使用类似于开发的技术和能力，来达到测试的目的，本质还是测试。
就如同一个人用人肉扫地，另一个人发明了自动扫地机来扫地，看起来后面这位更高级，但是实际目的还是扫地，不是么？

其次就要说到测试的本质，以及行业对测试愚蠢的误解上来了。
有一个朋友说，曾经去阿里面试，测试相关问题回答良好，技术原理理解力，业务熟悉度，测试框架的设计思路，都回答良好。最后考了两道算法题，回答的不是很好，最终说这个朋友技术不太好，offer给的不高。于是他很不爽的拒绝掉了。

没想到如此大厂也是对测试误解如此深，因为他们招测试的标准就是在招研发。
就如同扫地，你扫地机器人做的再牛逼有用吗？如果你的场景是擦玻璃窗，而压根不是扫地呢？
测试的本质是，理解业务，产品和需求。傻乎乎地用研发标准招一坨长得像测试，但是实际是研发的人，就无法保障测试到位。测试是非常靠软实力的，标榜自身技术能力很好，但是半个重要bug都测不出，线上事故一坨，这样的例子见的太多了。

接下来说一下测试的进阶形态。

测试有两个进阶方向，一个是理解实现原理。也就是你要明白，当前项目里面，业务需求是如何变为设计，再变为代码实现的。代码逻辑层次的耦合，数据库设计，甚至网络层如何通信，拓扑架构如何，都需要理解。注意，理解即可，不需要完全掌握。这样，任何研发行为你都可以明白其意义和风险，你就可以精确设计测试用例，不浪费自己的时间，也不会遗漏高风险场景。

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

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

最后来正经来探讨一下这个问题：

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

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

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

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

如果有对测试这个岗位想要交流讨论的，欢迎私信。