首先，我說一句：培訓出來的，優秀學員大有人在，我不希望因為帶著培訓的標簽而無法達到用人單位和候選人的雙向匹配，是非常遺憾的事情，
最近，在網上看到這樣一個留言，引發了程式員這個圈子不少的轟動，
“幫公司面試了一個32歲的程式員，只因這一個細節，被我一眼看穿是培訓班出來的，沒啥作業經驗
培訓出來的程式員總被誤傷
不知道從什么時候開始，大家是越來越看不上培訓出來的程式員了，主要是嫌棄他們：基礎不行、學歷低、水平不行、學習能力弱、簡歷造假，
有些培訓機構出來的程式員確實有問題，但是不能因為“只是很多表現不好的程式員恰好都有過培訓經歷”，就一棍子打死所有培訓出來的程式員，
其實在很多軟體、互聯網公司里都有培訓機構出來的程式員，這其中很多人干的還是不錯的，
我自己就是培訓出來的前浪，我不會跟風無腦的嫌棄后浪，上面說的那些“嫌棄”，準確的說應該是：
大家不嫌棄培訓機構出來的程式員，而是嫌棄那些參加了培訓沒好好學、基礎差、干活不行、不上進還造假的程式員，
畢竟想通過努力獲得更高的收入，追求更好的生活，這沒毛病，
但是呢，作為前浪也不能無視后浪們的缺點，對一些培訓出來程式員的做法，我自己也看不下去，
就拿簡歷造假、專案造假來說吧，我面試過不少人，這里邊包括很多培訓出來的程式員，有的時候面試真的很無語，
明明只有半年作業經驗，非得包裝寫成 2 年作業經驗，你是天天加班，把加班時間都算成作業的年頭了嗎？
明明沒做過專案，非要虛構專案，很多人簡歷中的專案都大同小異，甚至一模一樣，比如不少人說做過電商專案，介紹的時候非常流暢，乍一聽說的頭頭是道，但是不能問細節，比如問資料庫大概多少張表？都用了哪些開源 jar 包？日志是怎么寫的？這種最基礎的細節，一問就露出破綻了，
這一看就是培訓老師幫著準備面試的話術，讓學員提前背熟練的……這種程式員誰敢招啊？
如果你造假，我造假，他也造假，大家都造假，造假一時爽，但是老話說得好：好事不出門，壞事傳千里，慢慢的大家就會認為培訓機構出來的程式員都是水貨，招聘的時候都不愿意要，
現在已經有一些公司不愿意招聘培訓出來的程式員了，為什么？
誰都想招聘一個優秀的程式員對吧，但是想招到一個優秀人才要花很多時間精力，
假設從 30 個科班程式員里能挑出一個優秀程式員來，由于能力和造假的原因，從 50 個培訓程式員里才能挑出一個優秀程式員，誰都愿意節省時間精力，從前者里面招人
現在 IT 行業最火熱的時候已經過去了，程式員沒那么緊缺了，恨不得幾百個人競爭一個崗位，這種情況下，用人單位反正也不缺簡歷，肯定優先從高學歷、科班的人里選了——既省時間，良品率又高，
作為程式員來說，最重要的還是你的學習能力和技術水平，英雄可以不問出處
不管你是來自于北大清華，還是來自于北大青鳥，
如果你是培訓出來的程式員，既然已經選擇了一條道路就堅持走下去，可能初期會坎坷一些，別太在意大家怎么看你，
同時，也是在警醒我們：這個時代，沒有什么是確定的，也沒有什么是容易的，我們只有努力奮斗，跳出舒適區，能能獲得真正意義上的鐵飯碗，
想知道自學自動化測驗怎么學，首先要明白值不值得學？
我談一下幾點，如果你處在這個行業，一定能體會到我說的對不對，
1、表面"衰落"的測驗行業鑒于過去的大形勢變化
不懂技術的測驗工程師會逐漸被淘汰出局，
一波測驗工程師的失業潮是在所難免的.雖然早期我也呼吁身邊的人趕緊脫離落后的業務體系, 脫離落后的測驗技能, 但是看到很多人越來越生活艱難, 也是挺心痛的，包括測驗工程師的需求越來越少, 招聘職位也越來越少, 典型的新崛起的巨無霸公司比如facebook早期都沒有QA，甚至前幾年一度有QA團隊是否值得存在的爭論，表面看起來是測驗行業衰落了，有趣的是大家討論QA團隊是否值得存在的初衷, 是為了更好的保證質量，這還是挺耐人尋味的，
絕大多數的公司, 都是非常支持QA部門的存在的, 問題在于QA團隊的存在的價值到底是大還是小. 過去陳舊的測驗體系, 落后的測驗人員能力, 冗長的測驗流程是被整個IT行業詬病的一個關鍵.當研發的生產力在逐漸的提升, 運維的部署在逐漸的自動化, QA所帶來的價值和耗費的成本就越來越不能忽視了， 甚至成為了一個專案的最大的成本. 這是任何一家公司都無法忽視的問題，
早年阿里巴巴的高管曾經集體去硅谷拜訪新崛起的巨無霸, 得到的結論就是他們的流程和執行力比國內強很多. 甚至facebook早年都沒有QA就成長為大公司了，所以阿里就迅速推動了流程的裁剪，這部分包括裁撤SQA, 裁撤需求分析師, 裁撤專案經理, 削減QA名額，進入產品, 研發, 測驗三足鼎立的最簡模式，QA會不會被撤掉也取決于這個部門的價值，所以不要想當然的覺得"存在即合理",
現在部分的公司已經在試驗"無QA"的模式了，互聯網唯一不變的就是變化比如一個典型的例子, 在搜索, 推薦, 機器學習等方向的演算法測驗是很重要的領域, 是需要專業的測驗工程師參與的，這個行業能容納很多的測驗團隊，但是測驗行業這些年就沒形成對這個領域的正確測驗方法, 結果最后丟失了這個市場，
現在都是研發自己保證了. 因為找不到合格的測驗工程師去保證這個業務.同樣在性能測驗領域也是如此, 隨著性能測驗平臺, 全鏈路壓測, 性能監控, AB Test, 云壓測這類技術和服務的出現, 性能測驗工程師的需求也會縮小. 越來越多公司里的性能測驗都已經變成研發主導了. 丟失了這塊的業務, 性能測驗QA的需求量自然會受影響，
一定要記住, 業務空間決定QA的生存空間, 這是所有行業都通行的道理. 如果你不能滿足業務需求, 就會被淘汰出局, 要么選擇退守防御要么選擇勇于接受挑戰，
那測驗行業的未來是什么樣的呢, 很多人會擔心. 不過我還是整體樂觀的.因為我喜歡整個行業, 這些年也一直在進行不斷的思辨. 說下我的看法
2、測驗從業人員的規模
從業人員規模跟生產力負相關, 跟業務規模正相關. 以后能有多大取決于技術和業務規模的雙重因素.
首先是大環境因素, 隨著各種行業的互聯網化, IT行業在擴大, 外賣, 美甲, 甚至是無人機汽車航天產業都將成為科技公司. 研發的隊伍會擴大, QA的隊伍自然也會整體擴大.
前提是QA自己要跟得上時代.其次是隨著生產力提升自然就不會需要這么多人的. 哪個行業都這樣, 測驗行業并不特殊. 就跟汽車行業一樣. 早年堆人, 然后堆工具, 堆技術, 上機器人, 改進流程. 行業技術改進, 測驗技術改進, 測驗工具和測驗服務的改進, 都會一定程度提高了測驗效率, 減少了成本.
這種改進會導致QA的團隊更精煉高效. 人數多意味著大家的價值跟富士康工廠里的工人一樣廉價. 追求高附加值才是正確的路. 這對公司和測驗團隊都是雙贏的.
第三個因素是行業地位， devops的流行是推動了研發和運維的密切合作. 一旦這個階段完成, 產品的生產部署會非常的流暢. 隨之而來的就是問題會越來越早的暴露, 大家對質量會更加的重視. 到時候就會進入一個新的時代, DevQA運維逐漸會管道化, Dev和QA會成為新的主角. 只是到時候能撐大局的不一定是現在的軟體測驗工程師了 會是新時代的測驗工程師.測驗行業會越來越專業. 人才, 技術, 工具, 開源平臺, 服務會越來越多. 越來越完善. 術業有專攻, 專業化分工仍然是大趨勢. 技術層面上也會有創新. 以前的測驗只能留下測驗用例和業務知識檔案 沒有什么連續性積累. 隨著介面測驗, 質量監控, 覆寫率分析, 業務建模等技術的突破, QA也會形成自己穩定可積累的業務資料, 并逐漸形成自己的平臺和業務. 業務空間+技術門檻的雙重因素是我堅信QA部門能長期存在的一個核心因素.
3、測驗行業的管理會逐漸扁平化
幾乎大部分的互聯網公司都在分拆業務和QA團隊從而提高執行力. 所以管理上百人的總監職位會越來越少, 而管理百人以下的總監會越來越多. 不排除少量的巨無霸仍然沒有改變. 或者有些燒錢的初創公司倒行逆施. 其中這些測驗管理者會遇到一些新的挑戰, 比如更高層是研發出身居多. 不懂研發體系幾乎沒有發展空間了. 測驗管理體系失去了上層建筑, 對未來的影響還是深遠的. 會有陣痛, 但是結果肯定會是好的
4. 測驗技術人才需求增多原因是多方面的
大公司因為分拆的問題. 不再有統一的測驗技術支撐部門, 所以分拆之后的每個團隊都需要組建對應的職能團隊, 對測驗技術人員的需求反而會增多. 中小型公司也苛求質量保證效果, 不止是要好, 而且要求更快, 也需要大量的技術人才， 這幾年通過各種招聘網站的招聘job的描述也能看得出來
5. 外包測驗的災難和新生
原來做歐美日韓外包業務的公司會因為國內互聯網的發展逐漸式微, 他們需要轉型做國內.但是國內對外包業務也大多排斥, 而且外包業務在效率溝通管理上都有諸多弊端. 其自身也無法承載對測驗工程師的培養和長期發展. 所以這幾年會有大量的外包測驗工程師轉型. 這方面需要有新的優秀的外包服務公司.能做到有自己的測驗服務, 測驗技術和高級的測驗研究工程師才行. 比如東軟也開始做自己的各種云測平臺之類的, 就是一種為了迎合新時代的變更.
6、不懂開發的測驗工程師已經是新時代的文盲
第一個是作業上已經沒有太大的晉升空間. 第二個是也很難跳槽. 最好的結果是憑借多年的經驗轉管理. 我跟行業的很多測驗經理交流過, 大部分作業超過6年的人, 在測驗執行上會倦怠, 在測驗技術的改進上已經無法入門, 還不如招實習生. 相對來說, 有技識訓礎的人在作業8年以上仍然會保持自己的學習熱情.所以未來測驗團隊的架構基本會是多數業務測驗工程師+少數測驗專家+測驗經理的管理模式. 以前不識字的是文盲, 后來是不識英文的是文盲, 在繼各國呼吁加強對IT技術的重視后, 新時代的文盲就已經快是不懂開發的人了.testerhome社區的成立的初衷就是希望喚醒整個行業對測驗技術的重視.
7、測驗行業的門檻增加以前處于發展期
行業對人才的苛求是第一位的. 現在隨著大公司發展穩定, 招人已經穩定了.他們基本只在211院校校招. 社招也看學歷. 初創公司多是融資燒錢為主, 在學歷上和閱歷上也是看的很高. 能夠不拘一格降人才的公司會越來越少. 我之前推薦了不少同學去其他優秀的公司, 其中有一部分同學就是技術不錯, 但是學歷未過關. 所以希望大家技能和學歷上能夠好好的重視這個問題. 除了學歷門檻, 如上一條所說技術門檻也存在. 所以加油吧, 少年！
8、測驗行業的薪資在提高
測驗行業經過自身的凈化洗滌會有新生.典型的變化就是薪資從以前的3k-15k的范圍, 整體提升到1w-3w之間. 技術含量的提升, 責任的提升必然會帶來整體的回報. 現在只要技術好, 學歷沒問題. 作業3年拿個兩三萬的月薪是很平常的.后面會詳細說薪資的方面，
9、研發工程師進入測驗領域
這些年整個行業對測驗行業的發展非常不滿意, 通俗點講, 大家都覺得測驗很Low, 但是又不能沒有，研發提交專案給測驗的心情就跟以前過年要去火車站排隊買票一樣. 要申請測驗資源, 給測驗講解業務和實作, 遇到比較low的或者新入職的, 連搭建環境都不會還得手把手教. 研發只是修改一行代碼, QA或者測驗那邊就炸鍋了.各種流程足以讓研發頭發都能掉好幾根. 作為參考對比, 再思考下運維. 當年部署個環境跟提交測驗很像. 要申請運維的介入, 要申請機器資源, 然后提交部署檔案, 還要明確基礎環境, 依賴庫等各種細節的版本號. 遇到本地行發布環境不行之類的問題還得跟運維撕逼. 當年運維行業還流行著一句, "人"才是最關鍵的發布保證者. 而現在隨著持續交付和devops的流行. 發布都已經做到"絲般柔滑"了, 一鍵發布,自由選擇灰度,平時的發布甚至都不需要運維參與. 嘗試了新模式的甜頭后, 對測驗行業的弊端已經很難忍受了. 所以在優秀的測驗工程師和架構師難找的情況下, 已經有越來越多的公司選擇直接用研發工程師來頂了. 他們的追求很簡單. 單測->介面測驗->基礎的冒煙測驗, 能夠做到自動化就可以了. 如果能像運維那樣做成測驗即服務就更完美了.搞明白了測驗行業的現狀，明確了前景，那就要詳細說說要學習哪些內容了，
自動化測驗要學習哪些內容？
首先，自動化測驗，很好學！但是要記住，一定要明確學習的方向，不要劍走偏鋒，白花力氣，
第一，學習一門語言，至于學習什么語言的話，很簡單，不用糾結，第一看你是否有編程基礎，沒有/編程能力弱選python，有的話選java（難度較高）、python都可，
第二，需要看你們的開發用的什么語言，和開發用同一門語言能在學習自動化測驗的同時，降低你和開發之間溝通的門檻，提升你在公司的話語權，
第三，學習哪個方向？我建議：web ui自動化=》介面自動化=》App自動化/小程式自動化，當然，著重學習介面自動化，ui自動化要學，但是沒太大必要深究，
1、蓋樓之前先打好地基，首先需要學習一門語言
在上面我們也提到了，自動化要想做得好，必須要學習至少一門編程語言，當然至于學習語言要到什么程度了？我不可能一直學下去吧？答案是，會用就行！
掌握大部分的語法基礎，已經能夠滿足你的自動化的日常需求了，因為我們寫腳本并沒有像開發那么難！
語言你需要學習，for回圈，if判斷，資料型別，運算子，面向物件編程等等，不管是java還是python，這些都是需要的，其實也差不多，會一門語言，其他的都類似，
2、語言入門后，正式踏上開始自動化成神之路，入門篇Selenium
selenium作為自動化的老祖宗，已經被玩爛了，基本上只要是做自動化的，無人不知無人不曉，為什么要先學習selenium？
它能幫助你快速理解，自動化到底是個什么東西，并且能直觀的在頁面上面反饋給你，咱當初也是，看著selenium的api，一點一點啃下來的，幾乎每個方法都去嘗試了一下，
selenium有1.0 2.0 3.0,建議你學習之前，先去了解以下它的歷史，以及它的運行原理，這樣可以勾起你的學習興趣，你學習selenium，需要去安裝瀏覽器，強烈建議使用Chrome而不是FireFox，前者兼容的更好，
安裝好Chrome，你需要去安裝驅動，恭喜你，這時候你就會踩到自動化的第一個坑了！大部分原因還是因為你的驅動版本和瀏覽器版本對不上，等能訪問百度后，這里印象很深的su和kw（具體是什么等你學了就知道了）
你會再去嘗試各種selenium的方法，去操作瀏覽器，這時候仿佛打開了新世界的大門，奧！原來自動化測驗是這么個東西！真神奇！
3、玩膩了Selenium
等你玩了幾天，或者幾個星期之后，你好像對Selenium提不起什么興趣了，腳本也寫的越來越6，能寫出一些線性的自動化腳本了，這個時候，有點驕傲自滿，自動化不過如此，就這？
我想說的是，不要高興的太早，你僅僅只是剛跨入自動化測驗的大門，走了一小步而已，此時，你可以開始嘗試，把專案中一些重復的操作，寫成腳本去跑，滿滿的成就感有木有！自動化的成效初步形成，仿佛你開始懂得如何用自動化提升效率了，
4、開始接觸自動化框架unittest/testNG
等你學會單元測驗框架unittest/testNG，當你學會了selenium后,你會發現大部分的線性腳本，很難去管理，并且每個腳本需要去一個個run，而且還無法統計測驗結果，這個時候，就需要單元測驗框架登場了！
你會開始學習，單元測驗框架的用法，如何創建一個測驗類，如何寫測驗方法，如何把你的腳本寫成測驗用例，如何校驗測驗是否通過，用例的執行順序怎么去控制，斷言怎么去寫，這些都是你要去探究學習的，
5、不滿足于單元測驗框架的功能
等你腳本寫的很6，用例也會組織了，然后每次領導告訴你，跑一下測驗，然后把測驗結果發給他，要總結成測驗報告的形式，
你這時候，屢次打開你的編輯器，run test，然后刷刷刷的跑完測驗，一條一條的統計測驗結果，累得半死，發給了領導，
第二天領導又說，下班前你再跑一下測驗，給我份報告，想死的心都有了，那么你開始去逛百度，逛論壇，想要得到解決方法，那么“框架”一次就會映入眼簾，
6、學習自動化框架
此時，你已經開始琢磨如何寫一個自動化框架出來了，那么說明你的自動化已經開始入門了，并且往著中級的方向發展，你開始研究框架的結構，發現有用例管理，日志，測驗報告，郵件，基礎封裝類等等，還有一種框架的設計模式（經典PO模式）
你開始對你的用例進行整理，封裝基類，撰寫頁面類，封裝日志，郵件模塊等等，經過了幾個星期的打磨，你的第一個自動化框架誕生了！
此時你可以去各個技術群去炫耀了，自動寫出了一個自動化框架，很多小白也開始吹捧你，叫你大神了，
7、初始介面測驗
以上結束了UI自動化的學習，那么下面到介面這邊，一般公司用的都是http介面，那么你就從http協議開始學習了，了解它的結構，請求頭，請求引數，請求地址，請求方式等等等，嘗試學習一些抓包工具
如fiddler,chales,wireshark或者瀏覽器的開發者工具等等，去抓包獲取一些介面，慢慢的觀察它的請求構造，但是這時候還是云里霧里，對介面一知半解，于是下載了一個介面測驗工具，嘗試把引數錄入到工具中，手動發起呼叫，
當工具回傳200 code時，奧，原來是這么回事，好像就是和服務端來傳遞和接受資料的，然后前端頁面會把資料展示到前臺！
8、嘗試學習Request/HttpClient庫發起請求
在用完postman后，就會想到，那么我怎么用代碼去發起一個請求呢？這時候就需要去學習這兩個東西，pip install & import requests后，就開始了你的介面自動化之旅，
你嘗試也是把之前ui自動化的增刪改查，用介面來實作，你把抓包的請求引數拿過來，一個一個方法的呼叫，然后一鍵運行！一綠三紅！為什么？然后發現介面回傳了401，無權限！奧！我沒有登入啊，那么怎么才能登入呢？？
抱著很多的疑惑開始研究，這時候你需要去了解cookie和token的作業機制，再配合你的代碼，去快取cookie，達到登入，等解決了這個問題，但是介面還是報錯了啊，洗掉介面提示我沒有這條資料！
查來查去，原來是我那條資料已經用掉了，那么怎么可以保證我每次錄入的引數都是新的呢？這時候就需要去了解介面關聯，如何把引數從上個介面的回應提取出來，給下個介面用，
9、request/HttpClient結合unittest/testNG+allure
一樣的，等你學會了 request/HttpClient,自然也會想到用單元測驗框架把他們集成起來，然后又發現了一個高大上的allure測驗報告，再結合一些日志模塊列印引數，輕車熟路的這么一個介面框架就出來了，和之前的差不多！小意思，
10、嘗試用yaml/Excel管理測驗用例
等你拿自己的框架，重復枯燥的寫著測驗用例，這時候你想了，我為啥每次都要request.post，方法都是一樣的，只是資料不一樣，為什么我要一直寫代碼呢，很累啊！為什么不用一些檔案來讀取測驗資料，做引數化呢？
這時候你開始研究讀寫excel/yaml了，你想把所有的測驗用例都放在檔案里管理，就不用每次去寫代碼了，然而事情并沒有那么簡單！那么我在檔案里如何去處理關聯資料呢？如何去快取cookie呢？如何做斷言呢？如果做一些動態的輸入呢？
11、高級貨？git?jenkins?docker容器？分布式？
走到這一步，你已經寫過好幾個框架了，并且基于自己的框架做了優化，那么你此時發現一個很嚴重的問題，我的代碼居然只能在我本地運行，如果要給別人用，還需要去別人電腦上配置環境，copy代碼給他，
那么為什么不用一些代碼管理工具去管理我的腳本呢？那么就會需要去學習git，了解如何add commit push推送我的代碼到公司的gitlab，這樣別人也可以使用，那么有了gitlab，我想做一些定時任務，讓它自動執行呢？
學jenkins，再更多，要是我想多個用例一起跑呢？學習selenium grid，docker等等
12、自動化頂端之測驗平臺/工具開發
等你搭建好公司的自動化生態，你還是不滿足，我為什么不把這些東西可視化管理呢？做個平臺？管理用例，管理任務，管理測驗報告？我還可以把公司的一些部署任務也集成過來？
想法很好！此時的你已經不僅僅是一名優秀的自動化工程師了，已經邁向了測驗開發的道路！開始學習，了解了測驗框架httprunner，開發框架django/flask/springboot，懂得了介面開發的流程，了解了mybatis,shiro,quartz等等，開始學習前端vue/react，懂得了什么是組件開發，父子組件傳值，開始了解很多東西，甚至運維方面的知識，開始了解k8s docker，微服務，，那么你越來越往著大神的方向去了，希望你還沒有禿頭，此時的你可以驕傲的稱自己為一名合格的測驗開發，或者叫全堆疊開發了有木有！到此告一段落，
以上就是我個人，也相信是大部分學習自動化測驗的一個學習路線，當然本次沒提到一些App端/小程式端的自動化測驗，其實也都大致類似，
總結
軟體測驗是IT相關行業中最容易入門的學科~不需要開發人員燒腦的邏輯思維、不需要運維人員24小時的隨時待命，需要的是細心認真的態度和IT相關知識點廣度的了解，每個測驗人員從入行到成為專業大牛的成長路線可劃分為：軟體測驗、自動化測驗、測驗開發工程師 3個階段，
最后感謝每一個認真閱讀我文章的人，作為一位過來人也是希望大家少走一些彎路，在這里我給大家分享一些自動化測驗的學習資源，如果你用得到的話可以直接拿走，希望能給你前進的路上帶來幫助，（包括Python編程、WEB自動化測驗、app自動化測驗、介面自動化測驗、測驗框架、持續集成、自動化測驗開發、性能測驗、安全測驗、大廠面試真題、簡歷模板等等、當然還有一些測驗基礎、工具、app測驗、介面測驗、linux、mysql資料庫等基礎知識），相信能使你更好的進步！這些學習資料我都放在我的測驗學習交流裙：1033482984 里面了，同時還有幾千個行業大佬相互進行技術交流、經驗分享，如果你也感興趣，那么期待你的加入，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552236.html
標籤：其他
下一篇：返回列表