测试人员正在逐步被自动化取代
图片取自lifeofpix
记得大学从计算机毕业时，班里大部分的
男同学选择了"开发工程师岗"
女同学选择了"测试工程师岗"
极个别的“产品经理岗”
部分“非计算机行业岗”
转眼间，快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 简介
为什么互联网裁员的时候
往往先裁中年摸鱼的管理层，然后再裁代码能力弱的测试人员
本质裁掉的，都是使用落后生产方式的生产力提供者。
只有裁掉了这些人，才能进一步提高整体的生产方式的效率
进而提高-生产力
最终创造-竞争力
高度市场化的社会，大家在享受社会进步的同时
其实是生产力与生产关系的一茬又一茬的“再升级”
各行各业的职场不断“再进化再洗牌”，招人、裁人
最终推动了社会不断向前发展。
作为一个IT家庭：
-
Beta的爸爸是开发，Beta的妈妈是测试
Beta的命名也是富含软件工程的哲学
爸爸目前在努力学习数据开发相关的技术
妈妈这边等Beta稍微大一点的时候，也要重新去工作
经过本周的分析，得出如下结论：
-
测试工程师小伙伴们
没有一点代码能力，也是越来越不好混
唯有“自动化测试”能力才是你简历上的加分项，妈妈要加油鸭~
-
开发工程师小伙伴们
是时候去锻炼你数据ETL能力了
“埋点+基于分布式数据库写SQL+可视化报表”，爸爸要加油鸭~
拓展阅读：