眾所周知，如今無論是大廠還是中小廠，自動化測試基本是標(biāo)配了，畢竟像雙 11、618 這種活動中龐大繁雜的系統(tǒng)，以及多端發(fā)布、多版本、機型發(fā)布等需求，但只會“寫一些自動化腳本”很難勝任。這一點在招聘要求...

眾所周知，如今無論是大廠還是中小廠，自動化測試基本是標(biāo)配了，畢竟像雙 11、618 這種活動中龐大繁雜的系統(tǒng)，以及多端發(fā)布、多版本、機型發(fā)布等需求，但只會“寫一些自動化腳本”很難勝任。這一點在招聘要求中就能看出來。

然而，現(xiàn)實卻很難招到一個成熟的自動化測試工程師。

最近我面試了不少來自大廠的測試工程師：華為、沃爾瑪、騰訊、字節(jié)……等等，每次都以為穩(wěn)了，尋思在大廠應(yīng)該都參加過自動化測試吧，實際卻是很多工作 10 年的測試工程師，仍然在做功能測試，或是以功能測試為主。

為什么自動化測試人才稀缺？我歸納了 3 點：

對自動化測試領(lǐng)域局限在工具和框架的使用，缺乏整體認(rèn)知；對于自動化測試設(shè)計理解不深入，一些方法、套路停留在概念理解，無法靈活運用；測試工作的價值被低估，長期發(fā)展受限，被迫和開發(fā)人員一起內(nèi)卷技術(shù)工具。

做性價比最高的自動化測試

先思考下，我們自動化測試的“終點或價值”是什么？

是自動化跑起來嗎？這個要求太初級了；是領(lǐng)導(dǎo)滿意嗎？有時因為換了一個領(lǐng)導(dǎo)，項目就半道中卒；是 100% 自動化嗎？高度自動化也并不一定會帶來高質(zhì)量；

好像一時半會很難說清，自動化測試的價值是什么。直到我看到了下面這張圖，完全顛覆了我的認(rèn)知 —— 自動化測試項目的最終交付價值是它產(chǎn)生的效益，也就是投入回報率比 ROI。

乍一聽，有點難理解，但仔細(xì)一想，可不就是這么回事嗎。

打個比方，在年終述職報告中時，用 ROI 的方式表達業(yè)績：“老板，我做的自動化測試案例，去年一年被 n 個場景使用，重復(fù)運行 x 次，發(fā)現(xiàn) bug y 個，節(jié)省手工工作量 z 人月”。

是不是很直觀？要想成為高手，就必須要看到并解決更有價值的問題，對更高的結(jié)果負(fù)責(zé)。

成為自動化測試高手

這個方法來自「原甲骨文高級開發(fā)經(jīng)理」柳勝的專欄《自動化測試高手》，比起 80% 的測試工程師熟知的從“代碼能力→工具能力→架構(gòu)能力”的認(rèn)知路線，這種新的模型，一下子打穿了測試高手工作的本質(zhì) —— 要懂業(yè)務(wù)、懂技術(shù)、懂架構(gòu)，而不是局限在工具和框架上。

比起市面上只聊工具與框架、代碼等像操作說明書一樣的資料不同，專欄最吸引我的，是作者獨創(chuàng)了很多「自動化測試」在業(yè)內(nèi)第一次出現(xiàn)的方法論（下面詳細(xì)說），帶你跳出工具和框架的層面，重新審視自動化測試設(shè)計。

像專欄中老師和一位同學(xué)所探討的：

現(xiàn)在很多測試人員都學(xué)習(xí)應(yīng)用層上面的工具，很少從底層和架構(gòu)上面思考問題

就導(dǎo)致只能寫一些自動化腳本跑，但是無法了解問題本身的原因，特別是性能問題，很多測試人員都只知道加壓跑起來，卻不知道系統(tǒng)，網(wǎng)絡(luò)，應(yīng)用之間的關(guān)系。

專欄中涉及度量數(shù)據(jù)分析、代碼邏輯和 Job 建模，也對應(yīng)著軟件開發(fā)里的數(shù)據(jù)、算法和建模，他還在 GitHub 上創(chuàng)建了一個 repo 放入專欄所講到的整體代碼和相關(guān)文件，方便大家動手運行。

當(dāng)然，雖然 80% 的內(nèi)容在于「認(rèn)知」上的拔高，但他也會列出業(yè)界主流工具和框架，以及選擇策略和落地實踐，并附上全棧自動化測試工具列表。但這部分只占 20% ，畢竟這些東西網(wǎng)上都能搜得到。

柳勝是誰？

其實，之前就讀過柳勝的文章，立刻被他新鮮的角度吸引，可以感受到他對測試崗位的理解非常透徹，這也源自于他獨特的經(jīng)歷：

曾就職于摩托羅拉、甲骨文中國，歷任測試經(jīng)理、高級開發(fā)經(jīng)理、測試總監(jiān)等職位帶領(lǐng)團隊設(shè)計分布式自動框架 Automation Center，填補了甲骨文 20 多年來在視頻會議系統(tǒng)自動化測試領(lǐng)域的空白；Qcon 全球軟件開發(fā)大會的講師；

日常測試人的工作中，只能接觸到“造輪子”的局部，視野受限。而像柳勝這樣的實戰(zhàn)專家，能讓你從更高層次認(rèn)識測試崗位，這才是最難得的。

為什么值得推薦？

一、顛覆認(rèn)知

柳勝在專欄中提出了不少新的方法論，而且是業(yè)界第一次出現(xiàn)：

“微測試 Job 模型”，在這個 Job 模型里，沒有 TestSuite 和 TestCase 的概念，也沒有具體工具和框架的依賴，而是面向測試需求和自動化測試 ROI 要求設(shè)計；它可以幫你厘清測試的場景、工作流、需要代碼實現(xiàn)的案例原子等等；“ 3KU 矩陣”，用于梳理 UI 測試、接口測試和單元測試每個截面的測試能力；3KU 測試金字塔，分層測試各層有自己的關(guān)注點，但又能在整體上實現(xiàn)互相配合、補償；案例 DM 分析表，可以分析不同類型的自動化測試開發(fā)成本和維護成本；工具四維度成熟度模型，用于框架選型分析決策；……

這些還只是冰山一角，已經(jīng)讓我大開眼界、期待不已了。

二、內(nèi)容體系化

柳勝把整個專欄拆分為了 4 個階段：

第一模塊帶你重新審視自動化測試的基本概念，掌握自動化測試效益的量化思維方法——投入產(chǎn)出比 ROI 模型。

第二模塊從一個訂餐系統(tǒng)的例子出發(fā)，從單體應(yīng)用升級到微服務(wù)集群，來觀察測試需求的變化，通過逐層測試來全面驗證需求。

第三模塊一起推演模型設(shè)計。像開發(fā)的設(shè)計模式一樣，自動化測試設(shè)計也應(yīng)該有自己的方法論。

第四模塊會提供一些度量模型和驅(qū)動改進的流程樣例，一起思考怎么讓一個項目始終可觀測、可控，有反饋。保證項目始終在預(yù)定軌道上推進，即使有偏離，也能第一時間發(fā)現(xiàn)糾正回來。

下面是專欄的具體內(nèi)容：

授之以魚，不如授之以漁。這個專欄不會讓你撲到工具技術(shù)的茫茫大海里，等過幾年之后，有一種學(xué)不完、學(xué)不精、用不好的絕望，而是帶著你了解魚的規(guī)律，帶著導(dǎo)航駛?cè)氪蠛?，有方法地探索，最后滿載而歸。更多自動化測試請百度“特斯汀軟件測試騰訊課堂”或公眾號“特斯汀軟件測試”。