本篇文章內容來源TesterHome。著作權歸原作者所有。

作者：skytraveler (劉曉光)

來源：https://testerhome.com/topics/16354

有這麼個普遍現象

測試招聘者，特別是一、二線網際網路公司的招聘者最苦惱的事兒就是招人。想找到一個合適的人難於上青天，每天各種撒網，簡歷看幾百份，面大幾十人，能撈到一個中意的小夥伴就謝天謝地了。但同時很多測試小夥伴發現找工作很難，特別是進大一點的廠，他們特別挑：代碼要會寫，要有軟體架構能力，問一大坨平時根本用不到的技術問題，還挑經驗，挑溝通能力，挑這挑那，有時候還特麼挑學歷、挑年齡。。。 供求總難以匹配起來，造成了雙方都很痛苦。

Why？

能力要求不匹配是最核心的問題。軟體、網際網路近20年來飛速成長，其實也經歷了很多階段。行業軟體興盛階段和外包興盛階段（2000-2010年）行業進入了大量的測試人員，當時最主流的測試實踐是：重心放在系統驗收階段。測試人員的主要工作基本都投入在了基於業務的黑盒測試上，對代碼能力、系統理解的能力要求不多。2010年後，網際網路行業的真正興起讓國內軟體開發模式開始緩慢調頭，快速疊代的模式逐步興起，開發周期越來越短，疊代越來越快，但系統越來越越龐大、複雜。原來的測試工作模式和工作範圍越來越無法滿足要求了。但大量從業人員技能範圍轉變是一件很難的事情，行業是有巨大慣性的。從宏觀上看大量QA技能轉變跟不上需求轉變是造成市場供求不匹配的主要原因。

So What?

三個觀點：1. 只做手工測試，不懂系統實現的測試工程師的職業發展會越來越受限。2. 能夠轉型成適應市場需求的同學將在近幾年的時間獲得超額回報（因為市場供不應求，企業不得不抬高價格來尋找這樣的人）。3.對於個體來說，自我成長永遠最重要，自己永遠要對自己的發展負責，別依賴外部環境，自己想辦法變成市場的香餑餑才靠譜。

到底什麼樣的人搶手？

按照我一點理解講一講什麼樣子的人會搶手吧，限於篇幅會偏重技術角度來講。個人之見，歡迎討論和拍磚。

• 測試的底子-項目經驗
  有比較複雜系統的測試實戰經驗，你就超過了50%以上的應聘者。什麼叫做比較複雜系統呢？投入50人年開發出來的系統就可以稱作一個複雜系統了。因此，複雜系統並不是很罕見。但是，如果你只接觸一個簡單的模塊，甚至只是測試一個穩定模塊的維護性開發，而不是通盤理解，不能說是測試過複雜系統。有從頭到尾接觸一個完整項目的經歷很寶貴。
• 測試的底子-基礎知識
  對照三本書：《ISTQB基礎教程》 《高級軟體測試設計》 《高級軟體測試管理》（後兩本是ISTQB的高級認證教程）。這裡邊的內容你都能熟練應用（真的是熟練應用，而不只是有概念），你就能超過80%以上的應聘者了。面試過數百人，我經常會問幾個問題：如果測試時間不夠，你會怎麼辦？ 如果讓你去測試一個你完全不熟悉的系統，你會怎麼辦？你平時會使用那些測試設計方法？ 看似很稀鬆平常的問題，非常考驗人。因為大部分從業者都沒有經受過系統訓練和學習，工作多年，依然技能不足，意識跑偏。
• 熟練使用一門主語言
  滿足這條，你就超過了70%的應聘者。什麼叫做熟練呢？拿Java來說吧：系統學習過Java的教程，高頻面試50題 這樣的題可以自測一下，可以回答上35個以上；熟悉最主流的Spring框架，能夠寫出一個簡單的網站，實現基礎的Restful 服務；讀懂過一個測試框架，如mockito或者Junit的源碼；能夠熟練實施接口測試（基於一些測試框架 如：rest-assured+Junit）；能夠讀懂開發的業務代碼，對他們的代碼進行Code Review；
• 對一門語言有比較深入了解
  滿足這條，你就超過了90%的應聘者。什麼叫有深入了解呢？還拿Java來說吧：熟練使用Java的常見API；深入理解基於語言特性/系統特性的知識，如Collections的實現機制、類型系統、I/O、網絡、多線程等；熟知設計模式（廣義範圍的設計模式，不局限於GOF的設計模式）；熟悉JVM的工作模式；熟練使用調試排查工具解決性能問題；熟練掌握市面上常見的腳手架；熟練掌握周邊知識（OPs相關，網絡知識相關）有不錯的實戰開發經驗（做過真正被生產檢驗的東西）；對於測試開發，AOP，Java字節碼技術是很重要的知識。。。 這是一個很長的學習list，需要幾年時間來養成。做到這點，其實你可以勝任普通的開發崗位了，這也是高級測試開發崗位的技術底子。
• 在一個領域知識有不錯的了解
  人不可能什麼都懂，但工作幾年之後，會在工作的域內一定要有積累才行。
  例如，你測試一個核心電商系統的交易模塊三年了，業務上你一定要熟練講出來：商品列表、購物車、下單、退單、廢單、支付、發貨、庫存、退款、優惠使用等等一坨業務流程，和可能出現的常見的坑（各類問題產生的資損、各類問題產生的服務不可用、邏輯矛盾），不然根本無法體現你經驗沉澱和深入思考；技術角度上，你要能夠畫得出來系統的交互圖，熟悉最核心的接口和最核心的參數，能夠讀懂開發的代碼，熟練使用trace和監控工具，診斷定位線上問題到代碼行。
• 用技術保障質量的能力
  測試開發崗一定會問到一個問題：你能夠舉一個你用技術手段提高測試效率，增強測試能力的例子麼？這是面試時最大的一個坎。 很多人會講一些自動化測試回歸的例子，但是真正成功的例子非常少，因為為什麼做，怎麼做都沒有想好就照網上一個教程攢了一個，結果變成了玩具。 做好自動化，不僅僅是會使用工具、框架，其實要對被測物特性，軟體生命周期有很深的理解並且有很強的開發知識才行。實際上，在環境、CI、數據、測試用例生成、數據比對的很小的一些點上，都能有不錯的提效產出，從這些點能夠做得好，會得到不錯的加分。有一個不錯的成功案例，你勝出的幾率就超過了80%，沒有短板，就十拿九穩了。
• 技能以外的東西- 實戰案例
  以前的工作印證了你的能力。能夠講清楚一件特別拿得出手的工作，證明你能力的案例是面試時候最有用的投名狀。
• 技能以外的東西 - 你的個人特質
  一般有如下特質會大大加分：快速學習、系統性學習、學以致用、系統性思考、強大的推動力、技術思維、突出的溝通能力、條理性、抗壓性、樂觀精神、抗挫折能力、迅速調整的能力、疊代改進的意識、ownership、團隊合作、願景和規劃。 這些特性體現人的內核，有強大內核的人，做什麼都行，技能暫時不足，也一定能補足。所以，在招聘的時候往往對是否錄用的判斷起決定性作用

高段位要求（高級職位需求）

• 計算機領域知識的通盤理解
  這條範圍非常大，人不可能什麼都懂。但最最基礎的知識是不能有盲點的：
  作業系統工作基礎原理與基礎操作：如linux，要通讀過linux作業系統的書，熟悉最基本的概念，基本命令要熟悉，shell要能寫和讀；
  網絡知識特別是TCP/IP, HTTP知識：推薦兩本書 《圖解tcp/ip》 《圖解Http》這兩本書里的東西要懂。
  資料庫知識：市面常見資料庫（redis，mysql，oracle）的常見DBA操作，問題排查；SQL的熟練使用；
  Web及移動端知識：能夠懂HTML，CSS，能夠讀懂Javascript代碼，能夠讀懂Android或者iOS的代碼，做簡單開發最好。
  安全知識：常見的安全防護方法、工具使用；基本的安全攻防原理；
  軟體工程/開發過程管理：實戰中各種磨練，建議系統的學習PMP，敏捷開發的一些認證課程。
• 在一個域的深耕
  人不可能什麼都懂，但在一個領域是需要深耕的。比如，在做了四、五年移動端測試以後。android和iOS都要具備一定的開發能力了，能讀懂開發的業務代碼是最基礎的，能夠代替開發實現部分業務功能，完成部分組件開發是個非常好的自檢點。能夠對移動端自動化工具棧、監控工具棧（如友盟、bugly、newrelic等）、內存泄露檢測、卡頓檢測、耗電量、弱網、流量、埋點、灰度、版本控制、兼容性、用戶體驗、安全等等的質量保障方案有通盤搞定能力。
  什麼叫搞定呢？舉個例子：比如，使用多種手段把崩潰率降低到千分之一以下。對於一個小團隊，這是個很不容易實現的坎。做到這點，你需要了解如何收集崩潰率，如何使用一系列工具來定位核心問題，如何推動開發改動，並且預防（靜態代碼掃描工具引入，阻止亂用第不成熟的第三方插件，代碼reivew防止常見pattern如空指針引發的崩潰，推動開發養成良好的log習慣，推動移動端防禦性編程編程開發習慣，推動後端開發按照規範吐接口，幫助開發引入內存泄露、卡頓工具，趨勢報表，警鐘長鳴，各種灰度方式設置，線上監控。。。一個數據的改觀，背後要有大量的質量相關工作）。
• 使用綜合手段來保障軟體質量提升效能的能力。
  聽起來很抽象，舉幾個例子吧。
  例子1：你所在的team總在被開發抱怨測試用的時間太長。如何能縮短一下測試時間呢？
  通過調研，發現測試小夥伴詬病的最多的就是環境不可用。環境到底多不可用呢？
  你基於Grafana和Prometheus做了一個環境可用的監控報表，使用後，發現環境在工作日整體可用率只有35%左右，主要原因是：幾個核心熱點應用經常掛了沒人管。
  你拉了整個team，明確了部署責任人，約定了部署規則：只能中午飯和晚飯時間部署，並且部署後要自己看一下是不是OK。
  一周後，環境可用度上升到了65%。再深入分析，發現2個同學不守規矩，總是他們在破壞規則，你去找他們單獨談話。
  一周後，環境可用度上升到了80%。還是有少量人不守規矩。
  你找SRE的同學提需求，做了部署卡點，非部署時間部署必須TL審批。
  一周後，環境可用度上升到了85%。有些TL也不守規矩。
  你建了個報警，環境亂部署，壞掉了，在大團隊的群里@全體，告知誰搞壞了環境。
  一周後，環境可用度達到了92%。
  你加了一個feature：應用掛了一段時間無人響應，自動重啟服務功能，仍然有問題，就自動回滾上一版本。
  你推動了開發解決了某個應用啟動時間過長的問題。
  你推動了環境分組。
  你推動了測試環境版本上線的規範流程實施。
  你推動了冒煙自動化用例卡點。
  你推動了環境部署人備份機制。
  你推動了全員基礎環境部署培訓。
  你總結了部署手冊。
  你做了。。。。。
  最後，環境可用度穩定到了97%以上。你為測試節省了60%以上block時間（原來可用度未35%）

例子2：上面的問題，除了環境，還有一個槽點：開發提測質量不高。測試的頭幾天，很多主流程都走不通，導致測試總是在等待，或者是跟著開發一起聯調。而這段時間，已經被習慣性的認為是測試時間了，因為：提測了。

你推動了：測試提供冒煙用例，開發必須完成一定程度的自測才能提測。
你推動了：測試和開發做自動化同期共建，在開發過程中，核心功能就被自動化用例保護起來了。
你推動了：開發切分feature提測，而不是攢一個大招一下子提一坨。
你推動了：代碼Codereview變成團隊常規活動，QA在早期跟進核心代碼，把問題坑殺在萌芽階段。
你推動了：外部資源聯調非常早的進行，不會讓它在測試後期成為測試blocker。
。。。

例子3：你發現測試時間長，QA自己也有問題。

你推動了：有明確的測試計劃，並讓所有干係人都有明確的預期。
你推動了：測試依據風險測試，最大的風險得到最快的cover，科學分配時間，明顯縮短bug反饋時間弧。

你能講出自己做過5個以上這樣的成功例子，我敢保障，你會被1線大廠瘋搶。職級基本都是專家起。

• 持續學習能力和複雜問題解決能力

例子1：
你近期的工作是幫助團隊提升後台服務穩定性。你看到了netflix內部使用一個叫做ChaosMonkey的東西來隨機對生產服務期進行攻擊，而逼迫工程師提高穩定性，所以，你也實現了類似（更溫和）的內部機制，推動團隊穩定性的提高。
你怎麼知道這個叫做ChaosMonkey的東西呢？ 因為你會習慣性瀏覽一線廠商的技術博客，參與行業大會，關注各類新技術。持續性的養成習慣。

例子2：
做大規模接口自動化好難，外部數據依賴太難搞，參數構造太費勁，assert太難寫。如果能夠簡單的錄製回放就好了。
但是，外部依賴是個天坑，寫操作mock也是個天坑，assert也是個天坑。

你能講出自己做過5個以上這樣的成功例子，我敢保障，你也會被1線大廠瘋搶。職級基本都是專家起。

• 其它能力 測試是個萬金油，高階一些的職位需要什麼都要會一些 ，因為越高階的職位需要解決的問題越綜合，需要打交道的人的種類越多。不然很容易變成你職業短板，做個list吧（一定不全）：很好的項目管理能力，至少與開發經理能力同級，甚至要強於他。一定的軟體架構能力。一定的產品sense：可以跟一個資深的產品經理能夠順暢的交流，明白知道他為什麼會這麼想，所要實現產品的意義，路徑；從產品質量方面的考慮要超過產品經理，給他輸出。極好的溝通能力。團隊管理能力（這個太重要）目標管理能力有一個好的內核（上面提到過）

怎麼轉型/怎麼進階？

其實不難，沒有什麼高端的方法。下面這4條就夠了，核心秘密就是堅持不懈。

• 熟悉你的被測系統，熟悉你的被測系統，熟悉你的被測系統。 能夠從技術、業務角度做到對被測系統熟悉是做一個好QA的最基本職業素養，也是能力提升的最主要源泉。
  自檢點：我能夠畫出系統的架構圖麼？我能夠讀懂開發的代碼麼？我熟悉常見的業務監控系統麼？熟悉日誌系統麼？知道開發是如何調試和定位問題的麼？給我一個線上問題，我能定位麼？我能給別人完整的介紹這個域的核心業務麼？我能自己直接動手發布上線一個系統麼？知道如何回滾麼？灰度是如何做的？ 我知道所有關鍵的技術點麼，如一個交易的冪等性是如何實現的？我在團隊中有：「這傢伙對系統最熟」的口碑麼？
  如果自檢點全部是否定答案。。。 花一年時間把它全變成肯定答案。這一過程，你一定被迫學到了很多很多，並且獲得了極為長足的成長，這是進階的必由之路，也是卡了很多人的地方。 如果說做不到，後面不用看了，前面的也全部忘掉吧。
  方法：通讀所有文檔，強迫自己讀代碼，積極參與開發所有討論，不懂的狂問，觀察開發如何上線，如何排查問題，模仿，學習，善用搜尋引擎，總結。。。

• 找到問題解決問題，找到問題解決問題，找到問題解決問題。 你一定有一堆問題，如果你覺得自己做得挺好，沒有問題要解決，那必然是你自己有巨大的問題！
  自檢點：找一支筆，寫出你覺得質量方面，你的team的10個問題，做排序。排出最重要的3個。
  方法：找到top3的問題，選一個，列個接話，去解決。如果找不出來，使勁去觀察，然後去看看做的好的同行，比比你比人家差在哪裡。嘗試去解決這些問題，從小問題，能夠見到效果的問題入手，設置一個時間點。你真正解決了5個以上問題以後，感覺一定會有。

• 系統學習，系統學習，系統學習
  自檢點：我系統的學過一門知識麼？我能講清楚我這麼操作，我寫的這行代碼的原理麼？
  方法：從工作出發，確認你需要補足哪些知識。從網上找一個具體知識的學習路線圖，訂個計劃，照著來。 參加學習小組，找到幫你解決難題的人，多請他吃飯，多請教他。獲取知識後，馬上回到工作中做檢驗。還是學以致用才能有所增長。結合工作來系統學習的效果是最好的。
  再舉個例子：
  上家公司有個小夥伴（他應該也會泡這個社區），開始應聘的時候，他說熟悉jenkins，用的很多。所以第一份工作是：把所有CI的日常工作交給了他，並告知2個月內要全部搞定。 他一下懵逼了，原來那些不深入的理解支撐不了工作要求。後來他每天死磕，看了jenkins所有的文檔（對，幾乎所有文檔通讀了一遍），翻了無數問題的解決帖子，記錄了上百個問題解決的過程，寫了上百篇jenkins的小blog（現在還沒公布出來）。幾個月以後，他比我熟了，他的一項基礎能力成長為：可以獨自給一個小公司完整的搞定前端、後端、移動端的一整套CI解決方案。其實單憑這一套，就能找到不錯的工作了。這是依託工作，系統性學習的結果。

看到有同學說要裸辭，去接受培訓。我的建議是，別這樣。裸辭你就失去了學以致用的陣地，失去了真正解決問題的機會，還失去了資金來源。依託工作，自主學習是王道。自己饒過不去坎，其實有很多網上教程和非脫產培訓班啊。

• 選擇有挑戰的團隊，選擇有挑戰的團隊 自檢點：在團隊里有很多人比我強麼？周圍的同事都是我佩服的麼？我做的事兒有挑戰麼？ 方法：如果這三點都是否定的，並且你處於職業生涯的早期。也許（只是也許），你該考慮一下換個團隊了。