1. 自動化測試落地狀況

如果讓兩個相互不認識的、來自於不同公司的測試工程師自由討論，我猜他倆寒暄的第一個問題會是：你們公司的自動化是怎麼做的？如果你去問一個來自於大廠的質量部門的測試架構師：你家的測試平臺有什麼功能？你能聽各種天花亂墜的功能、自動化能力，讓你歎爲觀止。而同時讓你去問該廠的某個業務測試工程師：你們的自動化測試做的怎麼樣？對方很有可能會告訴你：啥？自動化？哪有什麼自動化！

很有意思的現象，是吧？今天我不談怎麼寫代碼了，來聊個在絕大多數公司都存在的、而且很可能不願意被外人知曉的問題： 爲什麼我們公司/產品/項目的自動化測試做不起來？

上面提到的 自動化測試做不起來 ，本質上就是 自動化測試體系難以落地 ，那怎麼才叫落地呢，以我的經驗來看，需要同時具備以下四點：

1. 有統一的測試框架、平臺

2. 有基本的CI、CD流程，具備自動、定時觸發執行的能力

3. 自動化測試用例覆蓋度高，能切實有效地幫助測試人員迴歸，明顯地提高測試效率

4. 測試、開發人員認同自動化測試執行的結果

難嗎？感覺要求其實並不高，但你跟同行去聊聊的話，你會發現要完成這四點是件不容易的的事情。下面我嘗試從測試人員、研發體系（公司）維度來剖析下，來講講爲什麼難，爲什麼自動化測試體系落地這麼困難。

2. 測試工程師

2.1 編碼能力是稀缺技能

中國軟件測試起步比較晚，測試工程師這個職業很有可能是伴隨着“軟件外包”興起的（請勿考古）。早期的測試工程師清一色地做着功能（手工）測試，不需要有編碼能力，甚至覺得不用會編碼是理所應當的。（2019年我校招時發現還有這樣的論調）

之後逐漸出現了能用QTP或者Rational Robot做自動化的人，這些人幾乎站在了那時測試職業食物鏈的頂端，睥睨羣雄。我還記得，十幾年前讀大學那會，我在一家軟件公司實習的時候，當時的主管向我介紹QTP，一臉的崇拜的樣子。那時能應用QTP主要依賴它強大的錄製、回放能力，大部分人自動化測試依然不需要會寫代碼，能簡單修改簡單生成的vbs即可。

測試人員逐漸接受編碼技能，應該是從web2.0概念盛行後，大量的項目需要使用開源的 selenium 、 watir 進行自動化測試，自動化測試的需求越來越旺盛，一些有好奇心的測試人員開始學習編碼做自動化測試，也有部分開發人員選擇轉行做專職的自動化測試。

不過十年過去了，時至今日，編碼能力依然是普通測試工程師的稀缺技能：目前軟件測試從業人員中，還是有非常大比例的純功能測試，雖然他們大部分都想學一門編程語言，但是大多就是停留在 想學 的程度，所付出的努力並沒有帶來實質的改變。

現如今的自動化測試技術棧，不管是接口、web、移動端，絕大多數都是基於開源項目來構建，不再有 QTP 那樣 的錄製回放能力，沒有編碼能力自然無法實施自動化測試。

2.2 找不到切入點

當測試工程師掌握編碼能力後下場寫自動化測試了，會面臨下一個問題：我該怎麼從頭開始做自動化？

困惑於不知道選什麼樣的測試框架、工具，困惑於不知道從接口、Web、移動端哪一層入手。簡言之，找不到切入點。

2.2.1 框架選型

先提一個很不好的現象： 很多測試人員學習編碼是從學習測試框架切入的，比如selenium、appium，他們所具備的編碼能力只侷限於這些框架API；而不是先學習編程語言、再學習測試類庫這樣的路徑。

所以這樣來，測試人員大多隻能從自己熟悉的框架着手，而不能全盤考慮各類框架優劣勢：

• 做web自動化，只能想到Selenium

• 做移動端，大概率會選appium

• 做接口，postman、jmeter

所以這樣來，其實也不存在 框架選型 的困擾：技能點就點了一下，沒得選。

2.2.2 分層選型

然後是測試分層，其實測試分層是個比較大的話題，單元、集成、接口、UI都可以切入。大部分測試文章都推崇 金字塔 分層模型，一張經典的圖：

在你具備足夠的能力下，我當然建議你把自動化測試下沉到底層去，實現更高的ROI。

不過我覺得金字塔分層模型過於理想化，單元測試的難度也不小，在微服務架構下，我更推崇的是橄欖球分層模型，即儘可能接口測試先行：

2.3 重視框架、平臺開發，不重用例覆蓋率

再來說一個怪像：如果你留意下一些測試社區，裏面有非常多討論開發測試框架、平臺的帖子，也會有很多分享自造輪子的帖子，但如果你想找一些自動化用例設計的帖子，卻發現非常的少。

我面試過很多寫過測試平臺的候選人，這樣的面試裏我很喜歡問：你的平臺上有多少用例？測試覆蓋率怎麼樣？這個時候大部分人就卡殼了，有些支支吾吾說不上來，有些能說上來，只是自動化用例的數量比較少，幾十、一兩百，整體的測試覆蓋率非常低。

似乎大多數測試開發工程師的心態是：我能寫代碼我厲害，測試框架、平臺信手拈來，至於填充用例這種體力活跟我沒關係。

殊不知，自動化測試體系的核心資產絕對是測試用例，而不是那些爛代碼堆砌出來的測試框架、平臺。

2.4 用例代碼Bug比項目Bug還多

這又是一個讓測試工程師很尷尬的事情，因爲代碼功底問題，有時候一個簡單的用例幾行代碼裏能出一堆Bug，結果測試結果完全沒有可信度。

不要不信，我拋一個簡單的問題：如果一個分頁查詢接口，它的響應報文中 total 字段表示匹配記錄總數， data 字段值是一個數組，返回當前頁匹配記錄條數，你會怎麼校驗 total 的值的正確性？

對於這種情況，也沒什麼太多可說的，不斷去強化你的代碼能力，而且心態上有改變： 不要覺得自己是會寫代碼的測試，覺得比功能測試強；當你在寫代碼了， 應該像開發一樣要求自己，要求自己的代碼。

不僅去學測試框架，更要去學數據結構、設計模式、數據庫、中間件…

另外，在開發測試用例時，嚴格遵守FIRST原則：

2.5 自動化測試用例缺少有效維護

在完成自動化測試用例的早期積累後，你也把用例執行整合進一些CI系統中了，開始進入收穫季節了，享受自動化測試帶來的測試效率提升的紅利了。

在這個時候千萬不要覺得自動化測試落地成功了，這個時候很像在魔獸世界裏把一個職業練到60級，你不是走到了終點，而是終於跨進了真實世界的大門了。

產品、功能每個版本都發生着變化，自動化用例的期望值也隨之變化，如果不能及時、有效跟進這些變化，無效用例就像滾雪球越滾越大，讓你無法維護。

3. 研發體系

3.1 優先級不夠，沒有建設的迫切性

如果把質量範疇的各類工作用四象限法來劃分的話， 自動化體系建設 這樣的事情大概率會落到『重要不緊急』象限中。

這個判定的邏輯很簡單： 我們當然認可自動化帶來的各種價值，但是目前的手工測試也能很好的發現問題，交付的質量、效率也堪堪可行 。而且，如果你真的要全面推行自動化體系落地，短期成本還會明顯增加：

• 需要招聘有編程能力的測試開發工程師

• 普通測試工程師學會了自動化測試能力，有了更高的薪酬期望

• 越懂代碼、自動化，測試範圍越大（多層累加），不一定會縮短測試周期

另外尷尬的一點， 自動化體系建設 的成果很難量化、包裝出來：寫了多少測試用例、降低了多少人力成本、測試周期縮短多少、業務場景的覆蓋率有多少？

挖掘分析上面的指標，你甚至會發現在某些時間段，自動化建設還帶來了負作用，這就落了個喫力不討好。

所以這一堆大大小的原因加起來，結果就導致了這個事情叫好不叫座，沒多少領導願意主動承擔起這個事情來。

3.2 建設路線圖不清晰

能在公司層面推動自動化建設的不多，真正落地自動化體系的不多，願意出來分享成功經驗的不多…這麼幾個 不多 累加起來，就導致了我們在建設初期很難去 借鑑 別人。

作業抄不到，自動化體系負責人又往往是開發背景，工程能力強，但是測試的積累不夠，不一定能想清楚整個項目要怎麼推動、推進路徑是什麼；而在執行層，執行者有可能是測試背景有不錯代碼能力的工程師，按理說能補足上面提到的缺陷，但是畢竟不在一個維度，看得到局部，但缺少一些全局視角。

3.3 長線建設中干擾因素多，建設決心不夠

上面也提到了自動化是需要持續迭代的，這是一個長線建設，貫穿在整個產品的生命週期中。所以在研發過程中碰到的各種干擾因素在自動化建設中同樣會遇到。

測試人員不夠、項目週期被壓縮、需求頻繁改動、 老闆讓做的 等各種司空見慣的 意外 ，迫使你不得不放下手中的自動化測試工作，改成手工測試加速發版上線。

在版本高速迭代的並且具有 敏捷開發 能力的互聯網公司裏，這些流程不合理、資源不足的現象都是合理的，你得承認、接受，並做出妥協，但不要質疑自動化、不要放棄持續建設。

3.4 測試架構組缺乏對業務測試組的穿透能力

最後提一個很痛的問題：組織架構。

很多公司尤其是大廠，缺少公司層面的質量部門。爲了快速應對業務的變化，更喜歡採用垂直向的組織架構形式，把各個職能角色放進來，而整個業務條線負責人大多又是產品、開發背景，測試在垂直條線裏存在感、話語權都有限。

這樣的組織架構下，業務測試組缺少來自公司層面、自上而下的測試規範、行爲約束。有些公司建立了一些橫向的測試架構組嘗試解決，甚至碰瓷 中臺 ，推測試中臺或者組織中臺這樣的概念，想要緩解這樣的尷尬。

我目前直接負責整個公司的質量體系，我的主管也充分授權，但即便這樣的情況下，我依然覺得這些橫向的測試架構組的產出不容易穿透到業務測試組中：雙方考覈目標差異、業務條線壓力等都行成了厚實的壁壘，阻擋着自動化體系的落地。

4. 寫在最後

吐槽了這麼多問題，文章可以改名成 自動化測試：從入門到放棄了 ，開個玩笑：）

綜上，真正要落地自動化測試，要考慮到人員能力、成本、項目週期、組織架構等因素，這是件昂貴的事情。也正因爲昂貴，我們應該踏踏實實邁好每一步，不要把事情浮於表面。研發效率的提升、測試成本的降低、CI/CD的閉環這些指標才能驗證自動化測試體系的成果。

雖千萬人吾往矣