測試人員正在逐步被自動化取代

記得大學從計算機畢業時，班里大部分的

• 男同學選擇了"開發工程師崗"

• 女同學選擇了"測試工程師崗"

• 極個別的“產品經理崗”

• 部分“非計算機行業崗”

轉眼間，快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