做到這幾點，你也能成為 BAT 的搶手人才（下）

測試工程師的高段位要求

計算機領域知識的通盤了解

這條範圍非常大，人不可能什麼都懂。但最最基礎的知識是不能有盲點的：

作業系統工作基礎原理與基礎操作：如 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 回報時間弧。

你推動了：bug 嚴格管理，所有重要 bug 都及時修複。

你推動了：良好的溝通和彙報機制，每天讓團隊主要幹系人清晰的知道，距離釋出還差多遠。

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

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

例子1：

你近期的工作是幫助團隊提升背景服務穩定性。你看到了 NetFlix 内部使用一個叫做 ChaosMonkey 的東西來随機對生産服務期進行攻擊，而逼迫工程師提高穩定性，是以，你也實作了類似（更溫和）的内部機制，推動團隊穩定性的提高。

你怎麼知道這個叫做 ChaosMonkey 的東西呢？因為你會習慣性浏覽一線廠商的技術部落格，參與行業大會，關注各類新技術。持續性的養成習慣。

例子2：

做大規模接口自動化好難，外部資料依賴太難搞，參數構造太費勁，assert 太難寫。如果能夠簡單的錄制回放就好了。

但是，外部依賴是個天坑，寫操作 mock 也是個天坑，assert 也是個天坑。

實際的案例是，經過幾年多個團隊持續不屑的填坑，阿裡内部已經有應用級的錄制回放工具了，數百個應用成功的是用了它，把不可能回歸的任務變成了可能（上萬數量級的 case當天生成，當天投入使用，并可以分析覆寫率），自動化測試實施需要付出的工作時間革命性降低（不足原來付出時間的 10%）。

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

其它能力

測試是個萬金油，高階一些的職位需要什麼都要會一些 ，因為越高階的職位需要解決的問題越綜合，需要打交道的人的種類越多。不然很容易變成你職業短闆，做個 List 吧（一定不全）：

很好的項目管理能力，至少與開發經理能力同級，甚至要強于他。

一定的軟體架構能力。

一定的産品 Sense：可以跟一個資深的産品經理能夠順暢的交流，明白知道他為什麼會這麼想，所要實作産品的意義，路徑；從産品品質方面的考慮要超過産品經理，給他輸出。

極好的溝通能力。

團隊管理能力（這個太重要）

目标管理能力

有一個好的核心（上面提到過）

怎麼轉型/怎麼進階？

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

熟悉你的被測系統，熟悉你的被測系統，熟悉你的被測系統

能夠從技術、業務角度做到對被測系統熟悉是做一個好 QA 的最基本職業素養，也是能力提升的最主要源泉。

自檢點：我能夠畫出系統的架構圖麼？我能夠讀懂開發的代碼麼？我熟悉常見的業務監控系統麼？熟悉日志系統麼？知道開發是如何調試和定位問題的麼？給我一個線上問題，我能定位麼？我能給别人完整的介紹這個域的核心業務麼？我能自己直接動手釋出上線一個系統麼？知道如何復原麼？灰階是如何做的？我知道所有關鍵的技術點麼，如一個交易的幂等性是如何實作的？我在團隊中有：“這家夥對系統最熟”的口碑麼？

如果自檢點全部是否定答案。。。花一年時間把它全變成肯定答案。這一過程，你一定被迫學到了很多很多，并且獲得了極為長足的成長，這是進階的必由之路，也是卡了很多人的地方。 如果說做不到，後面不用看了，前面的也全部忘掉吧。

方法：通讀所有文檔，強迫自己讀代碼，積極參與開發所有讨論，不懂的狂問，觀察開發如何上線，如何排查問題，模仿，學習，善用搜尋引擎，總結。。。

找到問題解決問題，找到問題解決問題，找到問題解決問題

你一定有一堆問題，如果你覺得自己做得挺好，沒有問題要解決，那必然是你自己有巨大的問題！

自檢點：找一支筆，寫出你覺得品質方面，你的 Team 的 10 個問題，做排序。排出最重要的 3 個。

方法：找到 Top3 的問題，選一個，列個接話，去解決。如果找不出來，使勁去觀察，然後去看看做的好的同行，比比你比人家差在哪裡。嘗試去解決這些問題，從小問題，能夠見到效果的問題入手，設定一個時間點。你真正解決了 5 個以上問題以後，感覺一定會有。

系統學習，系統學習，系統學習

自檢點：我系統的學過一門知識麼？我能講清楚我這麼操作，我寫的這行代碼的原理麼？

方法：從工作出發，确認你需要補足哪些知識。從網上找一個具體知識的學習路線圖，訂個計劃，照着來。參加學習小組，找到幫你解決難題的人，多請他吃飯，多請教他。擷取知識後，馬上回到工作中做檢驗。還是學以緻用才能有所增長。結合工作來系統學習的效果是最好的。

再舉個例子：

上家公司有個小夥伴（他應該也會泡這個社群），開始應聘的時候，他說熟悉 Jenkins，用的很多。

是以第一份工作是：把所有 CI 的日常工作交給了他，并告知 2 個月内要全部搞定。 他一下懵逼了，原來那些不深入的了解支撐不了工作要求。

後來他每天死磕，看了 Jenkins 所有的文檔（對，幾乎所有文檔通讀了一遍），翻了無數問題的解決文章，記錄了上百個問題解決的過程，寫了上百篇 Jenkins 的小 Blog（現在還沒公布出來）。

幾個月以後，他比我熟了，他的一項基礎能力成長為：可以獨自給一個小公司完整的搞定前端、後端、移動端的一整套CI解決方案。其實單憑這一套，就能找到不錯的工作了。這是依托工作，系統性學習的結果。

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

選擇有挑戰的團隊，選擇有挑戰的團隊

自檢點：在團隊裡有很多人比我強麼？周圍的同僚都是我佩服的麼？我做的事兒有挑戰麼？

方法：如果這三點都是否定的，并且你處于職業生涯的早期。也許（隻是也許），你該考慮一下換個團隊了。

總結

本篇内容偏重技能角度，講了講市場的需求和 QA 如何做如何滿足市場需求。行文倉促，認識有限，其實也并沒有什麼新東西。歡迎讨論拍磚啊：）

（文章來源于霍格沃茲測試學院）

更多優秀内容及資料可點選擷取