测试人员正在逐步被自动化取代

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

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

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

• 极个别的“产品经理岗”

• 部分“非计算机行业岗”

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

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

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

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

以前是这样的：

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

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

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

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

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

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

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

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

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

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

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

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

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

但是在今天

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

传统的测试人员，正在被自动化、以及更完善的监控体系所逐步取代。

触发这个变化的原因主要有3点：

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

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

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

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

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

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

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

ABTest概念介绍：

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图片取自阿里云 dataworks 简介

为什么互联网裁员的时候

• 往往先裁中年摸鱼的管理层，然后再裁代码能力弱的测试人员

• 本质裁掉的，都是使用落后生产方式的生产力提供者。

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

• 进而提高-生产力

• 最终创造-竞争力

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

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

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

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

原文转自：http://mp.weixin.qq.com/s?__biz=MzIwMjE3MDIwMA==&mid=2247485823&idx=1&sn=721ceb766629008d92f18396ee89f2e1&utm_source=tuicool&utm_medium=referral