软件测试工程师发展的 3 个方向

大家好，我是亦无，见字如面。

关注我比较早的同学应该知道，我之前写过几篇关于软件测试发展的文章： 《做软件测试有前途么？》 《做软件测试到底要不要学编程？》 《技术导向下的业务测试何去何从？》 《全自动化测试离我们还有多远？》

几年时间过去了，最近又有同学问起这个问题，刚好我也换个角度更新下自己的看法哈（茹老师最近在极客时间上也聊了这个话题，具体见我朋友圈转发的视频）。

目前软件测试同学的发展，可以分为三个方向，分别是业务专家、测试开发、效能平台开发。

下面详细解释下这三个方向。

一、业务专家

目前大部分公司都还是手工测试为主。

这个大家应该都知道，就是传统的测试工程师，绝大部分都是手工操作，所以有人自嘲为「点工」。

这是目前最庞大的一个群体，大部分以黑盒测试为主。

随着现在到处鼓吹的测试左移、测试右移、DevOps 的概念，这部分同学的危机感最强，感觉被替代的可能性更高。

事实也的确如此，自动化、机械化、AI 化本就是奔着这个目标来的。

但这部分需求也不是马上就会消失，还有一定的时间来过渡，哪得多久呢？

这个一方面依赖于流程上游的质量保障程度，如果需求质量和提测质量都得到了很好保证，基础性测试的需求就会大大减少，手工测试工程师的需求量也会随之减少了。

还有一方面是取决于前沿科技实用化的速度，比如 AI 真的够智能了，肯定是一部分工作要被替代的。

当然，仍然会有一些机会被保留下来。

比如业务逻辑复杂，又是业务逻辑强关联的行业（大部分是关乎生命或财产安全的），会需要业务专家的角色，比如银行业（也不完全是哈）。

业务专家再扩展下，如果对实现逻辑也很了解，还可以做测试设计。

人之所以重要，就在于他的稀缺性，好的测试设计需要发挥人的主观能动性，做的好，可以让质量保证事半功倍。

二、测试开发工程师

不知道大家有没有印象，早几年的时候很流行一个叫做「自动化测试」的方向。

特别是面试的时候，要么将来做性能测试方向，要么就是自动化测试方向。

这个自动化测试，就是现在的测试开发。

现在根据公司要求不同，测试开发还可以再细分为两种情形。

一种是跟随业务测试，接收测试同学的自动化需求，进行需求的工具化、系统化、脚本化，或者就统称自动化吧。

另一种也是跟随业务测试，但是需要自己去挖掘和提炼当前业务中，可能存在的提效点，这些提效点也包括工具化、系统化、脚本化，以及相关的优化类工作。

看起来工作内容没什么区别，主要的区别就是谁去提炼自动化的需求。

可别小看这一点，这个直接关乎到自动化实现后的应用效果，也关乎个人在这个过程中的收获。

比如第一种，更像脚本工程师，就是把手工操作脚本化。

第二种，更像一个独立开发者，从需求调研、需求研发、产品推广、产品优化，全流程参与跟进实施，这经验是绝无仅有的，当然，做起来也更难。

我更推荐第二种。

目前测试同学的业务压力都比较大，一下切到第二种会有困难，建议的方式是，做业务的同时，培养这种独立开发者的意识，在业务中不断的挖掘和提炼需求，项目间隙或额外花时间去实现（先有，再优化）。

过程很困难，但是看到自己创造的东西被实际应用时，眼前飘过五个字，「那都不是事」。

三、效能平台开发

最后说下「效能平台开发」，这个方向其实就是开发，只是他们不直接负责业务质量，他们的目标是效能提升。

他们接收全流程的通用效能提升需求，支持开发、测试、产品和运营等全流程的角色。

他们做的就是开发的工作，只不过开发的产品是内销（做好了也可以开源转外销），是为了质量和效率服务的。

比如我们公司的开测平台、IOS 预审平台，都是由效能平台的同学开发的，并且对外开放。

为什么把这个开发职责的事情，作为测试的发展方向，而没有说是开发的呢？

因为「没有说」嘛，这本来也是开发同学的一个发展方向。

那这个方向和前面说的独立开发者类型的测开什么区别呢？

测开的产出重在业务，实用性为主。

效能平台的产出重在通用，平台开发为主。

好了，概念都说完了，我再简单做个总结。

1、测试发展可以有三个方向：业务专家、测试开发、效能平台开发； 2、测试开发又可以细分为两种：1是把需求/用例脚本化的测开；2是有独立开发者意识的测开； 3、我们可以根据当前的角色，以及对于测试的理解，选择深耕业务，亦或加强技术； 4、这三个方向也不是绝对的，所有的目标都是让更少的人干更多的活，所以，你懂的；

希望对你有启发。

就这，回见。