软件测试人员正在逐步被自动化所替代_软件安全测试信号会被自动化测试取代-CSDN博客

本文链接：https://blog.csdn.net/zjl20200127/article/details/115758243

记得大学从计算机毕业时，班里大部分的

男同学选择了"开发工程师岗"

女同学选择了"测试工程师岗"

极个别的“产品经理岗”

部分“非计算机行业岗”

转眼间，快10年了，大家各奔东西，各为其主数年。

在各自的互联网岗位上也基本都是中坚力量了。

我后毕业，就一直在做一线开发工作。

最近这半年，我觉察到，在一线的互联网大圈里，产品研发的工程模式，已在悄悄的发生转变。

以前是这样的：

2012~2015年，移动端互联网井喷式的发展

客户端App每月一次发版，都需要几个测试工程师进行测试回归

梳理出TestCase，然后人工手动的“点点点”

把功能feature实际的全点一遍，看看好不好使。

新功能和老功能，都依赖这种“手动模式”的测试。

只有都“点点点”了，才能放心的发版。

梳理出P0级的重要checkList，进行测试回归

做的更好的，把checkList再进行拆分，让全员进行业务回归

最后把各自回归测试的结果，再统一反馈给“组织者”

组织者决定软件版本的质量，是否满足发版要求

后面发现当这个“组织者”非常耗时

又将这个owner角色， 让大家轮换着担当

就这样，让产品不断的进行版本迭代

但是在今天

在大型互联网公司中，这种原始的测试回归方式正在逐步消失。

传统的测试人员，正在被自动化、以及更完善的监控体系所逐步取代。
触发这个变化的原因主要有3点：

每次发布，都有逐步的灰度切流，新功能走灰度验证，不再“一把梭”。

    有bug不怕，只要影响面足够小，做到快速验证

技术人员，面向业务数据（埋点）的BI开发能力，被跨栈赋能

    业务的决策，越来越依赖数据说话，老产品经理也要给数据下跪

非UI交互相关的业务核心逻辑，在逐步的被单元测试所保障

    各端的发布的稳定性，正在被更科学的工程手段改造着

同时，前几年被吹很火的 ABTest，现在很少听到声音了
ABTest概念介绍：

一个已知确定的需求，需要用两种方案1和2，同时进行实现

然后再选取一伙目标人群，将这伙目标人群，无差别的一分为二成A\B两组

对A组实施方案1，对B组实施方案2

然后再通过数据监控，去判断A组和B组的业务效果。

这种思路，看着比较逻辑正确，但是在实践中并不好落地

因为没哪个产品经理敢让一个需求，既要方案1实现，又要同时方案2实现

这意味着2倍的研发资源的投入，以及更高的复杂度实现

即使技术老板不怼他（都没想清楚，就过来要研发资源了），程序员也会砍死这个产品经理的

所以大部分执行较好的场景是

线上业务有1条全量的主干功能roadmap

然后在各个具体的分支上，产品经理提出一个“尝试性”的功能feature

然后让研发人员去实现，并在这个新功能给加上完整的链路埋点

上线后业务开关默认关闭，然后通过预先实现好的流量开关，慢慢放量

一边放量一边配合埋点进行数据佐证

这其实是一种更接地气的 “A/B test方案”变种

    核心是 细灰度 + 强监控 逻辑

逐级灰度 + 强监控 + 数据大盘

这3个组合拳，应该是未来要  废掉“传统测试人员”的主要推动者

这既是工程技术的进步，也是互联网及软件工程发展到今日，一个必然的趋势。

图片取自阿里云 dataworks 简介
为什么互联网裁员的时候

往往先裁中年摸鱼的管理层，然后再裁代码能力弱的测试人员
本质裁掉的，都是使用落后生产方式的生产力提供者。

只有裁掉了这些人，才能进一步提高整体的生产方式的效率

进而提高-生产力

最终创造-竞争力

高度市场化的社会，大家在享受社会进步的同时

其实是生产力与生产关系的一茬又一茬的“再升级”

各行各业的职场不断“再进化再洗牌”，招人、裁人

最终推动了社会不断向前发展。