一、自動化測試落地狀況
如果讓兩個相互不認識的、來自於不同公司的測試工程師自由討論，我猜他倆寒暄的第一個問題會是：你們公司的自動化是怎么做的？
如果你去問一個來自於大廠的質量部門的測試架構師：你家的測試平台有什么功能？你能聽各種天花亂墜的功能、自動化能力，讓你嘆為觀止。
而同時讓你去問該廠的某個業務測試工程師：你們的自動化測試做的怎么樣？對方很有可能會告訴你：啥？自動化？哪有什么自動化！
很有意思的現象，是吧？今天我不談怎么寫代碼了，來聊個在絕大多數公司都存在的、而且很可能不願意被外人知曉的問題：為什么我們公司/產品/項目的自動化測試做不起來？
上面提到的自動化測試做不起來，本質上就是自動化測試體系難以落地，那怎么才叫落地呢，以我的經驗來看，需要同時具備以下四點：
1、有統一的測試框架、平台2、有基本的CI、CD流程，具備自動、定時觸發執行的能力3、自動化測試用例覆蓋度高，能切實有效地幫助測試人員回歸，明顯地提高測試效率4、測試、開發人員認同自動化測試執行的結果
難嗎？感覺要求其實並不高，但你跟同行去聊聊的話，你會發現要完成這四點是件不容易的的事情。
下面我嘗試從測試人員、研發體系（公司）維度來剖析下，來講講為什么難，為什么自動化測試體系落地這么困難。
二、測試工程師
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原則：
FIRST
2.5 自動化測試用例缺少有效維護
在完成自動化測試用例的早期積累后，你也把用例執行整合進一些CI系統中了，開始進入收獲季節了，享受自動化測試帶來的測試效率提升的紅利了。
在這個時候千萬不要覺得自動化測試落地成功了，這個時候很像在魔獸世界里把一個職業練到60級，你不是走到了終點，而是終於跨進了真實世界的大門了。
產品、功能每個版本都發生着變化，自動化用例的期望值也隨之變化，如果不能及時、有效跟進這些變化，無效用例就像滾雪球越滾越大，讓你無法維護。
三、 研發體系
3.1 優先級不夠，沒有建設的迫切性
如果把質量范疇的各類工作用四象限法來划分的話，自動化體系建設這樣的事情大概率會落到『重要不緊急』象限中。
這個判定的邏輯很簡單：我們當然認可自動化帶來的各種價值，但是目前的手工測試也能很好的發現問題，交付的質量、效率也堪堪可行。
而且，如果你真的要全面推行自動化體系落地，短期成本還會明顯增加：
- 需要招聘有編程能力的測試開發工程師
- 普通測試工程師學會了自動化測試能力，有了更高的薪酬期望
- 越懂代碼、自動化，測試范圍越大（多層累加），不一定會縮短測試周期
另外尷尬的一點，自動化體系建設的成果很難量化、包裝出來：寫了多少測試用例、降低了多少人力成本、測試周期縮短多少、業務場景的覆蓋率有多少？
挖掘分析上面的指標，你甚至會發現在某些時間段，自動化建設還帶來了負作用，這就落了個吃力不討好。
所以這一堆大大小的原因加起來，結果就導致了這個事情叫好不叫座，沒多少領導願意主動承擔起這個事情來。
3.2 建設路線圖不清晰
能在公司層面推動自動化建設的不多，真正落地自動化體系的不多，願意出來分享成功經驗的不多…這么幾個不多累加起來，就導致了我們在建設初期很難去借鑒別人。
作業抄不到，自動化體系負責人又往往是開發背景，工程能力強，但是測試的積累不夠，不一定能想清楚整個項目要怎么推動、推進路徑是什么；而在執行層，執行者有可能是測試背景有不錯代碼能力的工程師，按理說能補足上面提到的缺陷，但是畢竟不在一個維度，看得到局部，但缺少一些全局視角。
3.3 長線建設中干擾因素多，建設決心不夠
上面也提到了自動化是需要持續迭代的，這是一個長線建設，貫穿在整個產品的生命周期中。所以在研發過程中碰到的各種干擾因素在自動化建設中同樣會遇到。
測試人員不夠、項目周期被壓縮、需求頻繁改動、老板讓做的等各種司空見慣的意外，迫使你不得不放下手中的自動化測試工作，改成手工測試加速發版上線。
在版本高速迭代的並且具有敏捷開發能力的互聯網公司里，這些流程不合理、資源不足的現象都是合理的，你得承認、接受，並做出妥協，但不要質疑自動化、不要放棄持續建設。
3.4 測試架構組缺乏對業務測試組的穿透能力
最后提一個很痛的問題：組織架構。很多公司尤其是大廠，缺少公司層面的質量部門。為了快速應對業務的變化，更喜歡采用垂直向的組織架構形式，把各個職能角色放進來，而整個業務條線負責人大多又是產品、開發背景，測試在垂直條線里存在感、話語權都有限。
這樣的組織架構下，業務測試組缺少來自公司層面、自上而下的測試規范、行為約束。有些公司建立了一些橫向的測試架構組嘗試解決，甚至碰瓷中台，推測試中台或者組織中台這樣的概念，想要緩解這樣的尷尬。
我目前直接負責整個公司的質量體系，我的主管也充分授權，但即便這樣的情況下，我依然覺得這些橫向的測試架構組的產出不容易穿透到業務測試組中：雙方考核目標差異、業務條線壓力等都行成了厚實的壁壘，阻擋着自動化體系的落地。
四、 寫在最后
吐槽了這么多問題，文章可以改名成自動化測試：從入門到放棄了，開個玩笑：）綜上，真正要落地自動化測試，要考慮到人員能力、成本、項目周期、組織架構等因素，這是件昂貴的事情。
也正因為昂貴，我們應該踏踏實實邁好每一步，不要把事情浮於表面。研發效率的提升、測試成本的降低、CI/CD的閉環這些指標才能驗證自動化測試體系的成果。
以下文章來源於質量價值 ，作者質量價值