昨晚公衆號後臺有同學給我私信，說看了我的文章受益匪淺，希望我聊聊自動化測試或者測試開發專題的能力分層。
本來困得不行打算入睡的我，取消了明天要定時推送的其他文章，熬夜寫了這篇文章。
這篇文章結合我自己的工作經歷，談談自動化測試的成熟度模型，僅代表個人看法。
重新認識自動化測試
我從事軟件測試工作以來，第一次知道自動化是15年年底，聽大佬說QTP可以錄製腳本然後自動化回放，測試效率很高，當時心嚮往之。不過當時技術比較菜，而且對工作也比較迷茫，聽過就忘記了。
大概16年時候，測試圈子自動化測試開始火爆了起來，當時基於selenium的UI自動化測試特別火爆。圈子裏討論，培訓班推廣，很多關於基於selenium的UI自動化測試的技術文章和書籍開始不斷湧現。
我本人是17年年初纔開始學習自動化測試並且嘗試在工作中應用的，確實在迴歸測試和造數據方面，給了我很多的幫助，當然由於比較早喫螃蟹，在後面跳槽找工作時候，漲薪幅度也挺大。
大概18/19年時候，各種自動化測試平臺開始在各技術大會、技術沙龍以及技術社區被大家討論了起來。
幾個大廠的測試平臺之類的最佳實踐也開始被大家模仿借鑑學習，這一點大廠做的還是很好的，最起碼指引了部分迷茫同學的技術提升和職場發展方向。
差不多20年底21年時候，我已經是個測試圈子的老鳥了，開始帶團隊，負責部分招聘和技術面試工作，也會幫業務線的測試同學交叉面試一些候選人。
我發現自動化測試已經成了業務測試同學的面試必問技能。前幾年大家覺得功能測試最多隻負責功能+接口，自動化測試需要有專門的崗位，而近幾年，自動化測試成了業務測試的必備技能。我個人認爲原因有如下幾點：
- 軟件工程理念在實際工作中的不斷深入；
- 業務迭代加速以及系統架構不斷複雜化倒逼測試提升效率；
- 自動化測試工具/框架/技術實踐不斷豐富成熟以及求職市場的整體水平提升；
其實自動化測試的理念很早就被提出來了，國外也有很多的實踐，國內相對較慢，但近幾年測試圈子整體的基礎技術建設也在快速發展。在我現在的認知裏，自動化測試的能力可以算是測試團隊的基礎技術建設了。
因此，我的建議是，無論是剛入行的萌新，還是之前一直做功能測試的同學，爲了更好的職場發展和增強競爭力，具備做自動化測試的技術能力也需要快速提升起來。
新手落地自動化測試
在討論新手從零到一落地接口自動化測試之前，我想先拋出我的幾點建議：
- 從零開始，不要直接去學習所謂的自動化框架；
- 學習框架之前，很有必要學習網絡協議和編碼知識；
爲什麼這麼說？新手一般技術基礎不太紮實，且沒有太多編碼實踐，直接學習框架特別容易一步一個坑。
從零開始學習落地接口自動化或者其他自動化測試，我更建議從易到難的去落地實踐，這樣一方面可以在日常工作中優先保證工作的完成，提升工作效率；
另一方面就像打怪升級一樣，從易到難去學習提升自己，並不斷優化自動化測試在工作中的實踐。從易到難落地接口自動化測試，大概可以遵循如下幾個步驟：
- 學會用工具進行接口測試(如jmeter/postman)；
- 學會用持續集成工具(如jenkins)將接口測試腳本批量執行；
- 學會諸如git/gitlab等版本和源代碼管理的工具，便於團隊多人協作；
- 學習一門編程語言，利用自動化測試框架將工具腳本轉化爲代碼腳本；
- 學習將公共部分封裝，優化代碼結構，提高寫代碼腳本的效率，降低維護成本；
- 學習數據參數化管理的方法，可以從Excel——配置文件——數據庫——造數工廠這個方向迭代；
- 嘗試按照業務線和測試場景區分腳本集合，然後引入mock，降低服務間的調用依賴，提高執行效率；
- 開始畫大餅，造輪子，搞KPI，開發自動化測試平臺；
自動化測試成熟度模型
本文第二部分的內容來源於我前幾天寫的文章:《從零到一落地接口自動化測試》，這裏以從零到一落地自動化測試的幾個步驟，來談談自動化測試的成熟度模型。
初級階段-測試半自動化
先利用工具將日常費時的手工測試部分轉化爲半自動化（如postman/jmeter/jenkins），不要考慮什麼框架或者CICD等高大上的東西，先解決部分效率問題，纔能有時間和資源投入後續的建設。
當然這個階段更適用於初創企業或者小型公司的測試同學。
中級階段-迴歸測試自動化
有了前期的部分建設，接下來可以將日常的提測冒煙測試、系統測試階段的主流程迴歸測試以及部分造測試數據的過程轉化爲自動化。
這個過程中一方面需要培養提升建設團隊同學的技術能力，另一方面爲自動化測試的大範圍落地做鋪墊（畢竟很多公司自動化測試看不到短期效益就變成了純粹的KPI然後不了了之）。
注意：上面我說的都是測試自動化，並不是自動化測試。測試自動化指的是先將日常手工測試比較費時且重複度較高的部分轉化爲利用工具執行，
這樣做是爲了提高效率，解放人力資源，也是爲了打好基礎，順帶讓領導知道，做這些事對團隊有長期價值的。
高級階段-大範圍自動化測試
到了高級階段，我個人認爲就可以開展大範圍的自動化測試了。
這裏的大範圍並不是說完全不需要手工測試，而是按照自動化測試的紡錐模型(不是金字塔模型)，按照UI-10%/API-70%/UNIT-20%的佔比去不斷建設和落地。
當然，這個階段可以開始嘗試測試左移的實踐，測試同學去做更多具有創造性和探索性的工作，比如：
- 花更多時間在需求階段，包括需求分析和需求評審，做好需求階段的質量卡點；
- 設計更高效的自動化測試流程框架，提升測試用例的有效覆蓋率（正交實驗法）；
- 推動研發同學實踐單元測試，測試同學提供case並評審驗證，研發同學負責落地；
- 建設質量度量相關的事情（爲了解決問題驗證效果而度量，並非爲了度量指標而魔改自動化）；
成熟階段-自動化測試流水線
有了前面三個階段的技術建設和用例沉澱以及不同團隊間的協同配合，這個階段可以考慮將自動化測試融入到企業的自動化交付流水線中。大致思路如下圖：
關於devops的持續交付流水線相關的內容，請期待我後面的文章，目前還是草稿狀態。
最後，我個人認爲無論哪種技術體系，最終的目標還是要保障交付質量，提升交付效率。
成熟度只是一種抽象的定義，本文的內容也是我個人的一些觀點，僅供參考。