從2017年6月開始接觸自動化至今，已經有2年多了，從17年接觸UI自動化（unittest+selenium）到18年接觸接口自動化（unittest+requests）再到18年自己編寫自動化平臺（後臺使用python的flask，前端使用element+vue，沒有第三方自動化框架），不斷的學習成長，加深了對自動化測試的理解，這邊就總結下自己對自動化測試的認識。
首先，吐槽一下很多實際自動化經驗不到1年的而且停留在靠度娘抄襲demo的甚至度娘抄襲的代碼都不知道問題出在哪的小白，大神忽略，本人小白，只是吐槽一下行業現狀，相信很多人從度娘上抄襲個uniitest（下文簡稱ut），pytest，testNG甚至是RF（robotframework）就說自己熟練使用自動化了，你們真的瞭解自動化麼？筆者使用的是python語言，不鄙視其他語言，任何語言都可以做自動化，只要你有能力，現在隨便找幾個python自動化相關的問題問一下，很多是企業真實實戰會遇到的場景或者企業領導的需求，也包含筆者面試的口述和手寫題。
先來些個基礎的問題，18年1月辭職面的UI自動化面試題，筆者使用ut+se，面試官的問題如下（注：不寫答案，伸手黨請自行百度或查詢資料，這些基礎問題丟羣裏問是會被人鄙視的。後面的內容可能很多人會玻璃心或者感到不適，如果感到不適，請自覺關閉本頁面，噴子請繞道，沒有必要和你爭論）：
Q1：請說出selenium常用的八大定位法。
Q2：請描述Selenium的xpath的結構。
Q3：請說明爲什麼不推薦使用xpath？
Q4：當使用xpath無法定位到一個元素時，可能的情況有哪些？
注：前4個問題只是問個基礎，最最基礎的問題，如果前4個都回答不了，直接下一位，Q5開始的問題，是確定你有基礎了，開始往深一點的問，確定你對自動化的瞭解程度。
正文
現在我們正式開始提問：
Q5：你說你使用過ut，請描述一下ut加載用例爲什麼以test_開頭？
此考驗你對自動化框架的熟悉程度，某些領導就問你，測試用例爲什麼都是以test 開頭的？
你：這是這個框架的設計。
領導：不行，必須改成以我們公司名稱的縮寫開頭。
你：？？？？？
領導：你明天不用來了。
Q6：ut執行用例的順序是以什麼規則執行的？
等等，什麼？這就難了？這纔剛起步歪 ~ ~ ~ 我天。。。整天說自己熟練甚至精通自動化的，連自動化框架原理都不知道？你好意思說你自己精通自動化？要是讓你二次開發自動化框架，優化執行效率之類的，你是不是得上天？你來面的是自動化工程師崗位，不是黑盒點點點崗位歪 ~ ~ ~ （有人說錢不到位，你能力都不夠，我怎麼給你錢？不要把順序搞返了，阿里P7的崗位，給你一年100萬的總包，你能做的了P7做的事麼？道理就是這樣，先有能力，纔有談判的資本。ut雖然在一線鄙視鏈，但是我在度娘上看到過一個帖子，改ut源碼，把執行效率提升了幾十倍，你有那能力不？）
Ok，能看到這裏的基本上也可以確定你不是玻璃心或者噴子了，現在我講述一下我今年7月面試的幾個崗位，這些崗位是真實要求你能做起自動化的，座標杭州，起薪15K，7月面試5天，由於學歷限制以及能力不足，總收穫offer8個，崗位的面試題如下：
Q7：你在上一家公司維護過多少自動化測試用例（看你簡歷上寫的UI/API/APP任意一個）。
小於100的基本上上不了場面，如果後面的問題回答不上來，你的定級就是初級自動化了。
Q8：自動化用例，你們全用例執行一次需要多少時間（考驗你框架設計時是否考慮到執行效率問題）？用例之間的關聯怎麼解決？調試單個用例或者選擇某幾個用例執行你是怎麼進行的？數量100以內的測試用例，如果用例維護量翻5倍（100以上double或者3倍），你有什麼方案優化執行時間和效率？
Q9：如果被測試環境遷移了（例子：從本地環境遷移到阿里雲機了），你用例是否要大量修改測試數據。（易維護性）
Q10：編程語言問題：
Java一般問一些線程安全，數據類型的區別，設計模式等等問題，筆者是python，故只寫python常問的問題：
Python列表和元組除了可變不可變以外的區別？
Python列表和字典的區別？
Python生成器和迭代器的區別？
請描述多線程，多進程，協程其中之一的工作原理。（後續追問一個三者的區別，主要是想聽聽你對這三者的優缺點的瞭解程度）
請描述Python的垃圾回收機制以及內存管理
Q11:數據庫相關問題（太泛，從基礎理論到手寫語句，不寫了）：
多刷度娘，多看基礎就是了。
Q12:Linux基操
Q13:網絡相關(http/https)
Q14:對接CI、CD，CI同時調用2個甚至多個環境的用例，用例數據會不會錯亂。
Q15:團隊問題，這裏重點描述一下，入職的崗位除了大廠高級自動化工程師以外，都要求帶黑盒組一起進行自動化，所以團隊問題會被着重提問：
編寫用例的複雜程度？即一個用例需要多少行代碼？（其實聽到你回答多少行代碼的時候，你已經降了一級，面試官更想要的是一個不懂代碼的小黑盒也能輕鬆上手。）
組內用例的同步問題，如果N個組員同時編寫自動化用例，組員間的用例同步問題怎麼解決。
如果使用你的自動化，組員需要具備哪些能力和知識？如果要維護你的自動化，維護人員又要具備什麼能力？（主要是看你的自動化是否簡單易維護，面試官要的是哪怕你人走了，你的代碼依然能穩定運行，維護也儘可能簡單，而不是你一走，自動化就廢了，這樣的自動化毫無意義，你面試的成功率也會大大降低，穩定和易維護，至少得滿足一個條件。）
以上，就是筆者7月面試的問題，看完這些問題，你真的還了解自動化麼？有甚者甚至與筆者爭論過使用工具做自動化，例如postman/jmeter，誠然，都可以做，筆者只有一個問題，你維護過下一家公司別人做的工具自動化麼？沒有的話，先去維護一次，體驗一下什麼叫一個頭三個大的感覺，工具始終只是一個工具，筆者混跡在一些測試羣裏，每個月都能收到N個小白問這些工具要對數據進行md5/rsa加密，要base64編碼解碼，要怎麼做？筆者只能說一句，自己寫代碼，隨後會遭到不少小白怒噴“我要是會寫代碼，我還用毛線工具”，筆者：呵呵。還有小白還在問，jme數據關聯怎麼做？jme正則提取token怎麼提取？連自己解決問題的能力都沒有，更不用談自動化了。
對自動化的想法和感受
下面筆者講述一下筆者自己對於自動化的想法和感受：
1、UI自動化在很多小公司用於簡單的迴歸是可以的，簡單的迴歸其實單純寫幾個小腳本，和你用什麼po+ut+關鍵字驅動之類的，成本上沒有多大區別，真正需要UI自動化的公司，起步也得有幾百人上千人，且滿足需要自動化的部分已經足夠穩定的場景，這種規模的自動化，大多數人涉及不到，維護成本高，受環境影響因素大也是很多公司放棄UI自動化的原因，大環境因素上，UI自動化已經開始被AI自動化和圖片識別自動化代替了，各大廠內部已經開始流行AI自動化和基於圖片識別的自動化，例如網易開源的airtest，只需要截圖即可生成自動化用例，腳本的維護也越來越簡單。
2、App自動化和UI自動化差不多，app比ui多一個兼容問題（混合開發），維護同樣非常複雜，單純的selenium，appium，ua2實現自動化，要解決的問題非常多。
3、現在很多中小公司流行接口自動化，以及接口測試左移（在接口文檔出來之後，後端開發完成之前，搭建mockserver，實現前端聯調）接口自動化的執行速度快，迴歸效率高，是目前中小公司主流的喜愛。但是接口測試要想做好，對返回結果的斷言是個非常高的要求，設計人員的能力和知識決定了斷言的健壯性，對於設計人員的能力要求相對較高。
4、大廠目前主要流行的是撥測、圖形識別、AI，撥測即錄製和回放（很多小白看到這估計笑了，這不是早就被淘汰了麼，筆者：呵呵，此操作非彼操作），筆者大概瞭解過阿里的doom系統（沒有仔細研究，能力有限，說的不對的請忽略），通過中間件錄製線上的流量數據儲存起來，在被測試環境進行重放操作，以驗證本次修改是否對線上數據產生影響，這中間涉及非常多的技術實現。圖像識別可以參考airtest，AI測試目前幾乎沒有流出，測試之家裏有一些理論文章可以參考。
5、性能自動化就不寫了，筆者的能力有限，連性能測試都不敢說會更何況性能自動化。要是會個工具隨便打個壓就算會的，當我沒說，打個壓看個報告啥的還是輕鬆的，代碼寫個性能腳本問題也不大，性能測試的精髓在於分析瓶頸、系統調優。
寫在最後，17年UI自動化剛興起的時候，會個自動化腳本能評級到中級工程師，18年中級自動化需要自帶框架了，到了19年，會個自動化腳本連初級都算不上，用第三方框架的基本上要有成熟的方案了，19年的薪資高一點的測開崗位都要你會寫測試平臺了，19年測試平臺已經開始流行了，技術行業，更新就是這麼快，不學習，不進取，僅靠度娘那點基礎的教程，在20年21年22年只會越來越難走，年紀越來越大，能力卻沒年輕的強，競爭力越來越弱，纔是你跳槽漲薪的絆腳石，總有一些工作年限久的人，自以爲自己經驗老道而對工作年限低的人嗤之以鼻，筆者面過一個8年工作經驗的人，只有一個總結，他的8年經驗，只是在重複他第一年的事，只不過做的更熟練了一點，但是他又沒能把第一年做的黑盒做到很好，這是很多老油條的常事，筆者只能送一句，要麼把黑盒做好，要麼發展自己的能力，大中華的行業情況就是如此，往後N年，好自爲之。