【轉】聊一聊測職業發展

導言：

在作測試迷茫的適合，不妨看看這個文章，來自曉光大神，須要細細拜讀屢次，對於本身的測試職業發展會有醍醐灌頂，撥雲見霧的幫助！

 

老生常談，再談談測試職業發展

有這麼個廣泛現象

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

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，敏捷開發的一些認證課程。

• 在一個域的深耕
  人不可能什麼都懂，但在一個領域是須要深耕的。好比，在作了4、五年移動端測試之後。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個以上這樣的成功例子，我敢保障，你也會被1線大廠瘋搶。職級基本都是專家起。

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

怎麼轉型/怎麼進階？

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

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

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

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

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

• 選擇有挑戰的團隊，選擇有挑戰的團隊 自檢點：在團隊裏有不少人比我強麼？周圍的同事都是我佩服的麼？我作的事兒有挑戰麼？ 方法：若是這三點都是否認的，而且你處於職業生涯的早期。也許（只是也許），你該考慮一下換個團隊了。

總結

偏重技能角度講了講市場的需求和QA如何作如何知足市場需求。行文倉促，認識有限，其實也並無什麼新東西。歡迎討論拍磚啊：）

最後放一篇老文，前google測試總監寫的，寫了快10年了，但我以爲常讀常新。

 

-----------------------------------------------------------我是分割線--------------------------------------------

經營成功的測試職業生涯

(James A. Whittaker）

你是如何開始作測試工做的？

1989年，我在田納西大學讀研究生的時候，完成了從軟件開發人員到軟件測試人員的轉型。而這一轉型並不是出於我本身的選擇。我命運的改變發生在一個早晨，個人教授質問我爲何缺席那麼多開發會議。我解釋說由於會議被安排在星期六早上，很不方便。

而怍爲一個平生第一次離開家的新入校的研究生，這個時間段有些麻煩。十分有意思的是，等待個人懲罰並非一紙解聘通知書，而是被判罰爲該小組的惟一一個測試人員，且不能與開發團隊有任何交流。

對於個人職業生涯來講，這是一個意義多麼重大的決定啊！正是這個決定最終成就了幾十篇關於測試的論文，構建了多得連我本身也記不清的各類工具，出版了五本書，帶來了無盡的快樂工做時間。測試一直就是我擁有的那份具備創造性和技術挑戰性的快樂職業。不過，並非全部人都喜歡這樣。能夠說我最先接觸測試是在攻讀研究生期問，不能否認，那時的高強度學習和工做確實讓我受益不淺。另外，我認爲從初學者階段到專家階段之間存在着一個「測試的山峯」，人們須要經過一系列我的輔導、獲取信息和接受常規指導來翻越山峯。成爲一個測試初學者是很容易的，成爲職業的測試人員也並不艱難。本章的重點正是討論如何翻越那座位於職業測試人員和測試專家之間的山峯。

回到將來

在軟件測試領域，時間彷佛已經停滯了。咱們在21世紀作事的方法與上個世紀幾乎徹底相同。Bill Hetzel在1972年出版的測試知識叢書至今仍然至關有價值。而我本身所寫，於2002年首次出版的How to Break Software(如何攻破軟件)系列，到今天仍被做爲實用軟件測試技術主要資源的代名詞。

確實，若是咱們能夠把20世紀70年代的測試人員轉換時空用在今日，我猜測他們的的技巧足夠應付現代軟件的測試。固然，他們須要學習網絡和各類網絡協議，可是他們擁有的實際測試技術將能獲得很好的應用。若是從20世紀90年代找一個測試人員，則不幾乎不須要任何訓練。

對於開發人員來講，卻不是這樣，他們所掌握的那些上世紀的技巧幾乎已經徹底過 時。讓一個有一段時間不寫代碼的人從新開始編程，看看會有什麼樣的反應。讓我感到很不安的是，咱們能夠從馬路上直接僱用人手，而僱來的這些人從第一天起就可以測試，就可以有收穫。事情真的有那麼簡單嗎？或者是咱們的指望值只有那麼低？讓我更加不安的是，咱們沒有任何可預測的方式將合適的測試人才從勝任工做狀態訓練爲測試專。測試真的就那麼困難嗎？

這又是那個山峯了。門檻很低，但通往精通的道路卻很艱難。

在通往測試山峯的入口，咱們倚仗的是這樣一個事實：測試的不少方面都很容易掌握。大多數人均可以學得有模有樣。甚至只要將一點點常識應用於輸入的選擇,就能夠找出缺陷。這個層次的測試就如同在桶裏釣魚，簡單到足以讓任何人都認爲本身很聰明。然而過了入口之後，道路迅速陡峭起來，而測試知識變得愈來愈晦澀難懂。咱們發現有人擅長於此，咱們稱這些人爲「有天賦的人」，並欣賞他們的本能。

難道必定要依靠本能麼？對於那些看起來不具有特長的人們，是否存在着一條翻越山峯的途徑？是否能夠以某種方法傳授測試技能以培養出更多的專家呢？爲認爲這座山峯是能夠通行的，而這一章正是我關於應該如何走這條路的筆記，你能夠在本身的職業生涯中加以應用。這並非一份食譜配方，一份職業生涯烹調書。不過你能夠作一些事情來加速你的職業成長。可是，正如你可能已經猜到的，真正是說來容易，作起來難。

上山

測試職業的早期階段主要是爲征服測試山峯的漫長攀登作準備。我所能給出的最好的建議是從兩個方面來思考問題。對於你參與的每個項目，都有兩部分（不必定相等）的任務。第一部分的任務是保證當前的測試項目得到成功。而第二部分的任務是學習你應該作些什麼以便使下一個測試項目更加容易。我把它稱爲「測試今天的項目，準備明天的項目」。若是你作每個項目把它都分割成爲上述的兩半，那麼幾乎能夠保證你能持續得到進步。這樣，你就能夠隨着每個參與的項目逐漸成長爲更優秀的測試人員。

如今就讓咱們來關注第二部分的任務------爲下一個項目作準備。咱們須要注意三個概念：重複、技術和漏洞。

重複

作任何一件事，毫不要重複兩次而不意識到或質疑這實際上是個問題。我但願全部年輕的測試人員都牢記這一點。我見過不少初學者，他們在單調的任務上浪費了太多的時間，好比，設置測試機器，配置測試環境，在實驗室裏安裝待測試的應用程序，選擇一個產品版原本測試-這些任務列表能夠變得很長，最後你會發現真正花在測試軟件上的時間少得可憐。

這是許多新手常犯的錯誤。他們沒能看到他們日復一日所作的工做的重複本質，兒當他們意識到這種重複時，幾個小時已通過去了，而在這幾個小時內他們沒有作任何實際的測試工做。關注這些重複勞動，而且留意由此形成的真正的軟件測試工做時間的流逝。爲了能翻過測試的山峯，必須作一個測試人員應該作的工做，而不是實驗室管理員或者測試機管理員的工做。

測試自動化是解決重複勞動的方案，也是本章稍後的主題。

技術

測試人員經常會對軟件失效進行分析。分析缺陷時，咱們從開發人員的失敗中學習如何編寫可靠的代碼。咱們也分析那些被咱們忽略的缺陷。在應用程序上市之後，客戶就會開始報告缺陷，咱們將要面對處理一大堆失效的情形並尋找其中的重要缺陷。用戶報告的每個缺陷都說明咱們的流程有問題，咱們的測試知識還不夠完善。

可是分析咱們的成功也一樣重要，兒許多新入職的測試人員卻沒能利用這個唾手可得的資源。咱們在測試中找到的每個缺陷都說明咱們的的測試流程正在有效工做，都是一次成功。咱們須要牢牢抓住這種絕好的機會，只有這樣才能使成功不斷的重複下去。

運動隊經常這樣作，他們會觀看比賽錄像，並分析每個動做爲何奏效或者爲何不奏效。我清楚地記得一個小故事，個人一個朋友拍下了我兒子踢足球的一些照片。其中一張照片記錄了她踢球的瞬間，那個球超過對方守門員成功進球了。當我把它給我兒子看時，我之處他站立的那條腿的姿式很是完美，他踢球的腳尖緊繃且出球點在鞋帶間恰到好處的位置上。他盯着那張照片很長時間，從那之後他不多用不正確的姿式踢球。他那次得分可能只是碰巧作對了，但今後之後他有意識的運用這些技術使之接近完美。

如今回到新手測試人員的課程上來。咱們每個人都會有得意的時刻。咱們找到重要的漏洞或發現優先級很高的缺陷，併爲此雀躍不已。不過先花點時間考慮一下總體情況。咱們使用什麼技術找到了那個缺陷？咱們是否能夠建立一種方法來找到更多這類缺陷？咱們是否能夠記住…些實際的測試經驗並不斷地加以應用來幫助提升咱們的工做效率？軟件的哪些症狀能夠提示咱們它具備缺陷？咱們未來可否從那些症狀中獲得更多的警示？換句話說，這不只僅是一個缺陷或是一次成功，這個缺陷教會了咱們什麼，是否使得咱們未來成爲更好的測試人員正如我兒子的進球同樣，儘管第一個缺陷是偶然間發現的，但它不表明其他的成功都是偶然。理解咱們成功的緣由很重要，只有這樣作，成功才能被複制。對於測試人員來講，這種保證成功的緣由就是一系列的測試技術、建議和工具，它們能夠提升咱們在將來項目中的工做效率。

漏洞

測試人員最終都會變得很擅長尋找缺陷，可是要翻過測試的高峯，咱們必須更快而且更有效率：高速低阻。換句話說，咱們必須擁有一種自己不含缺陷的缺陷查找技術！

我喜歡這樣來考慮問題：測試人員檢視本身的工做時也須要發揮那種尋找缺陷的能力。咱們必須使用和尋找產品缺陷同樣的流程來尋找咱們本身的測試流程，測試過程當中的缺陷。個人測試流程是否是有問題？這裏面是否有缺陷？這裏是否存在着妨礙我提升效率的障礙？

你必須一直尋找更好的方法。有意識地去肯定那些限制能力、阻礙前進、減緩速度的東西。就像缺陷限制了軟件知足用戶需求的能力同樣，是什麼限制了測試的能力？使用你擁有的測試能力來最優化本身的測試流程，這會幫助你在測試的山峯上快速攀登並增長你翻越山峯後成爲專家的機會。

測試山峯的巔峯處是一個美好的地方。若是你成功地到了那裏，恭喜你．但這並非最終日標。這表示你已經成爲一個傑出的測試人員。而此時的下坡路就是用你的洞察力和專家知識來幫助周圍的人也成爲優秀的測試人員。本身一我的登頂是一回事，幫助其餘人（那些能力不如你的人）登頂卻徹底是另一回事。

通常來講，那些成功登上測試巔峯的人會成爲使用工具的大師。那些商業工具、開開源免費工具,和本身寫的工具（我我的最喜歡的工具）是極好地提升工做產出、增長工做成效的方法。不過，工具只是實現該目標的一種方法，但在許多其餘方面它反而是一種限制，由於太多的人看不到工具的功能以外的東西。他們被限制在工具能爲他們所作的事情中，沒能看到或理解對工具還有更多的需求。登頂須要真正掌握的是「信息」。由於不少工具能處理信息，並使得信息的獲取更加容易，因此測試人員變得過於依賴於他們的工具。可是信息自己以及如何利用這些信息纔是真正的成功關鍵。

熟練掌握信息，指理解有哪些信息，這些信息將如何影響測試，保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關注的。這裏我要談的是其中兩種：來自應用程序的信息和來自以前測試的信息。

來自應用程序的信息包括需求、體系結構、代碼結構、源代碼……甚至是關於應用程序在執行時作了哪些事情的運行信息。在編寫和執行測試用例時，須要考慮這類信息，但信息的多寡在很大程度上取決於測試人員的能力，這是一種可以使測試更高效的能力。在測試中使用這類信息越多，測試就越偏向於工程而不是猜想。

在微軟，咱們有一個遊戲測試組織（Games Test Organization,GTO），負責Xbox和PC遊戲的測試。談到利用應用程序的信息，他們是最優秀的。遊戲是不可思議的豐富，測試起來很是複雜。遊戲中不少可測試的內容都是隱藏的（由於讓那些玩家找尋能夠交換的物品正是遊戲的樂趣之一）o若是GTO的測試人員所作的僅僅是玩遊戲，那麼他們找到的問題不會比最終用戶更多。爲了能作得更好，他們與遊戲的開發人員合做建立了一些信息控制板，這些控制板暴露了一些基本上能夠算得上做弊的信息給測試人員。這樣，測試人員就能提早知道怪物會被投放在何處、物品被隱藏在哪裏，他們能夠看到牆的另外一邊，能夠控制敵方的某些行爲。他們的做弊工具（即測試工具）基本上使他們成爲遊戲裏的神，讓他們能夠控制看到的信息以便更快更巧妙地測試。這個例子給有測試人員都上了一課。

來自測試的信息意味着你必須關注在測試時所作的一切，並使用得到的信息來影響從此的測試。你是否知道你的測試是如何與需求結合的，知道什麼時候某一特定需求已經獲得足夠的測試？你是否使用代碼覆蓋率來影響將來的測試？你知道當代碼更新或缺陷修復時那些測試會受到影響，仍是知識從新運行全部的測試？理解測試進行到什麼程度並隨着測試調整測試策略，這是測試成熟的標誌。

我之前曾在微軟的Visual Studio的一個小組工做過，咱們大量使用代碼改動量（因爲添加新特性或修復缺陷而改變的代碼）和代碼覆蓋來影響咱們的測試。咱們花了很大的力氣將代碼覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻，幫助他們測試改動過的或修改過的組件。最終的結果是在代碼確實被改動時，咱們清楚地知道哪些測試會被影響而只從新運行那些測試。咱們還知道每一個新的測試用例是如何對整體的接口，特性和代碼覆蓋率產生做用的，從而指導咱們的測試人員，讓團隊中的每一個人在他們所建立的全部測試用例基礎上，寫出更有意義的測試。

你用哪些信息來指導你的測試？你如何保證信息是可獲取的，以便在測試中隨時能夠獲得？你如何使得信息變得有用，以便它能以良好的方式影響你的測試？這些問題的答案將決定你在走下專家測試山峯時的前進速度。

下山

到達測試山峯的頂峯的時候，你已經成爲一個十分能幹的測試人員了，能力也許至關於你組裏全部同事能力的總和。不管你在作什麼，請不要試圖作得比你的整個團隊都好，無論你對此感受有多好，或是你的老闆對你遏得有多緊。一旦你走在下坡的路上，就不要再去爭取「找到最多缺陷的人」或是「找到最有意義缺陷的人」這樣的榮譽頭銜。反而我推薦你減小花在測試上的時間，而把創新做爲你的首要任務。

在測試上創新指不急於向前，而是仔細觀察、洞察先機、找到瓶頸並改進團隊中全部其餘人的工做方式。你的工做變爲幫助其餘人進步。在微軟，咱們有一個專門爲此而設的正式職位——測試架構師。不過，不要由於缺乏一個很酷的頭銜而讓你沮喪。不管別人怎麼稱呼你，當你在「下坡的路上，你能作的最好的事就是儘可能保證更多的人能成功地爬上山峯的另外一側。

 

-------------------------------

https://testerhome.com/topics/16329 看到了匿名吐槽的這個帖子。

請相信我，真的不是故意挑三揀四。好多面試到的技能真的是崗位須要。在大廠，系統都會很龐大，但迭代絲絕不會比小廠慢，甚至更快，穩定性的要求上也十分苛刻。「既要、又要、還要」帶來的挑戰真正在裏邊工做的人才會體驗到。就算你是把牛刀，也不會over qualified。由於，不少時候你可能有機會，或者不得不去殺恐龍。。。

--------------------------------

https://testerhome.com/topics/16397 在這個帖子回答了 「 若是讓你去測試一個你徹底不熟悉的系統，你會怎麼辦？」這個問題的參考答案。

試着再回答另外兩個吧：

若是測試時間不夠，你會怎麼辦？

仍然沒有標準答案，但我比較滿意的點會有：

• 跳出這個問題，講如何從初期避免測試時間不夠，之前有過很成功的案例是很好加分項。
• 懂得基於風險的測試，估算時間，設計測試策略，把最有限的時間分配在項目風險最大的地方。這是項很是重要的能力（有專業知識，請參考ISTQB教程）有很是成熟的形式化方法，也有很是多的實戰checklist（作過大項目的人確定可以講出很多條）。
• 清晰讓主要干係人隨時知道如今項目的狀態，特別是質量狀況，將來可能的走勢，大概什麼可能達到發佈狀態。 QA是一個夜間走山路汽車的大燈，他的職責就是最有效的發現項目全部的大坑，並明確的告訴司機（項目主要干係人）。這裏面隱含着對溝通能力的考察，也隱含着對風險管理的能力的考察。
• 必定的項目管理能力，如何讓團隊對現狀，對如今的項目計劃是否可以有效進行下去有一個清晰的認識，而且引導團隊work smart 搞定挑戰。你不必定是TL，在系統測試階段，從某種意義上QA就是項目Leader。在關鍵時刻，項目的成敗，重要決策是否可以被作出，與負責項目的QA有重大關係。
• 軟技能：推進能力，ownership，協調能力，抗壓能力，可否激勵團隊，給團隊信心等等。
• 若是應聘者談到之前工做，可能會追問，考察其它知識點。
• 只能回答出「加班唄」，而沒有其餘思路的人，大機率只能pass了。雖然接受加班通常用人單位都比較喜歡，但沒有展現出任何QA應有的能力，技能上確定是不合格了。

你平時會使用那些測試設計方法？

主要考察作測試設計的時候是否靠譜。思路是否開闊，是否收過專業訓練，是否積累了本身的一套方法。仍然沒有標準答案。

• 若是隻能講出：我會等價類，邊界值，而後。。。。我想一想。。。想不出來了。 。。 若是再簡單引導，仍是沒法給出更多內容，大機率會被pass（不少應聘者都會這樣）。
• 若是你以爲你沒有聽懂這個問題，反問我，我會給你加分。
• 若是你熟練掌握等價類、邊界值、斷定表、狀態圖轉化、組合測試等通用方法，並可以舉出一個例子來，我會給加分（最基本的東西用了）。
• 若是可以給出基於被測物詳細分析作測試設計的案例，我會給加不少分。
• 有固定套路的人（例如 能夠使用 基於guide word的測試設計 ）會加分。
• 可以講出本身一套方法論，而且有明確案例支撐的人會大大加分。
• 可以結合本身工做侃侃而談並說到點上的人（雖然顯得比較散），也會給加分。
• 測試設計本質上要回答兩個問題：你的測試設計是有效的麼？（是否通過測試就靠譜了，覆蓋率是？）你的測試是高效的麼？（是否是可以用不太多的用例高效找出主要問題，這在大規模項目裏很是重要） 再往大里講講，「測試設計」不只僅包含了一些簡單的方法的使用，還包含了過程活動、質量意識在裏邊。不展開說了，有興趣的同窗能夠參考這本書The little black book on Test Design 通讀5遍，同時把他引用的全部連接全看了。再跟你的工做聯繫起來，再不斷的翻過來調過去揣摩、實踐裏邊的方法，半年後，你看測試會有比如今深太多的認識。別人問你測試設計，你能給他講1天。你的工做也會發生本質改變。

仍是那句話，面試主要仍是考察平時的工做經驗積累、思考積累、解決問題的能力的積累。

哈哈，我感受本身被面試啦，但願個人回答你滿意。btw，若是以爲很是對路，歡迎投遞簡歷到我這裏啊。缺小夥伴缺的厲害。

 

------------------------------------

你極可能會遇到短板。短板是：可能沒法讓團隊變成一個技術型團隊，來應對愈來愈多挑戰。若是公司轉型，會比較痛苦。
談一談個人觀察。在多年前，有不少離岸的測試中心，印度的infosys ，文思、東軟的測試外包興盛年代會有大量這樣的機會。可是離岸外包測試的崗位這幾年在大幅度收縮。傳統企業也在轉型，同研發過程結合愈來愈緊密的QA的工做範疇大了不少，技能要求也在逐步增強。只掌握黑盒技術的TL沒法帶領團隊很好應對現有的挑戰，因此這樣相似的職位是會不斷萎縮的。這是大趨勢。

可以知人善用，找專業的人來補充技術的短板，本身own起整個質量解決方案是一條路，我見過一些成功案例，一些管理型的TL可以走到比較高的位置，也能把團隊帶的很好。不過它有幾個前提：1.你能搞的定領導，他只信任你，承認你。若是你的領導只關注結果，你又能搞的定結果，這是走得通的。2.你能搞定底下的小夥伴，他們願意這樣跟着你幹，技術好，綜合能力強的人願意甘於你下（長期下來這點挺難的，若是你沒法正確做出技術決策，沒法給底下小夥伴方向上的引領，人家憑什麼服你，開心的長期跟你幹？）3.大團隊的歷史：你跟團隊長期奮戰，一同成長，團隊飛速發展，你被頂到了那個位置（若是空降，只有所謂的純管理能力，仍是挺難的，我沒有見過這樣成功的例子）。4.持續補足本身的技術短板，不見得是具體的怎麼擼代碼，而是要了解業界主流技術，他們能解決的問題，長處短處，你的團隊是否須要他們，團隊裏誰能夠撐起來。5.對你所在公司的業務要全通，尤爲是IT系統須要支撐的業務要精通（很少說，這點很重要）。6."技術管理"能力真的行（什麼是技術管理能力，能夠參考底下那本書）。

推薦的書：成爲技術領導者 最近去世的大師溫伯格寫的，系統性論述。我是幾年前讀的，對我一直影響很大。

 

------------------------------------

http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ 阿里的測試最高P的職業路線的建議。

 

----------------------------------

通用的思路：
基於風險的測試。測試的本質是抽樣，時間資源老是有限的。要把資源用在刀刃上。先看看那個模塊是幹嗎的，是否是重要，若是出問題，影響面有多大？而後具體問題具體分析。若是是核心模塊，會形成重大損失，那質量必定是不能丟的，抽調別的力量增強這塊兒投入，把風險明確的傳遞給主要干係人，必要時延期項目。若是是非關鍵模塊，識別出問題，能夠作：設定一個最小實現目標，砍feature，用運營/客服的手段補足。長效方法：自動化防禦網創建，讓迴歸的時間成本、人力投入成本低下來;在項目的初期就可以必定程度的識別這種風險，早加資源，別讓這種事兒變成到了最後：一坨毛病，deadline不變。 QA最大的一個價值就是：像探照燈同樣很早的預期到風險，並同步給主要干係人。

其實這類問題，主要是看看你之前在項目裏怎麼作的。實戰經驗很是重要，能積累不少「土方法」。

 

------------------------------------

1.都要依託。若是沒有複雜的環境和複雜的問題須要解決，時間長了人就會蹉跎，面試的時候遇到了不少這樣的同窗，被本身一成不變的工做耽誤了，在職業生涯的中早期，平臺的好壞其實更取決於它能不能製造一大堆問題讓你解決，成爲你成長的養料，而不是普通意義上的高大上就是好公司，舉個例子，前兩年有一段時間總接到一個著名外企的工程師應聘，可是存在一個通病：公司平臺把什麼都封裝了，應聘者也沒有去研究怎麼封裝的，爲何要這麼作，作了多年的"點點點"同窗，雖然有準一線大廠的背景，可是能力上幾乎喪失了競爭力。 可是，若是平臺不錯，你本身蹉跎了本身（看不到問題，不肯意解決問題），那也不行，面試時候也遇到了不少這樣的同窗，不少問題視而不見，這樣工做多年可能和工做一年沒啥區別。 仍是努力能力增加-》換更有挑戰，也回報更高的工做。這種正向循環最重要。

2.小公司更重視結果。小公司問題也每每十分多，你能把這些問題清晰的定義出來，給出改進指標，把收益說明白，而後作到了，很容易獲得承認。實際上小公司是更容易爭得話語權的，由於裏邊能人很少，稍微優秀一些就能體現出來。舉個例子：在上家公司的時候，有個測試小夥伴就作到了一點：比產品懂業務細節，全部開發的代碼作CR，懂的全部的代碼細節。慢慢的，他變成了團隊中話語權最強的人，由於他總能指出別人的錯誤，說的特別在點子上。因此每次考覈總在前邊，全部團隊成員都很佩服，重大產品方面決定不少都會諮詢他，是否能上線基本上也是他說了算。工資天然是漲了不少。 另一個建議是別給本身設限，別把本身只定位成測試，例如，若是本身是最懂產品的人，小公司很容易轉變成產品，甚至產品總監。 有準備並抓住機會的話，小公司很容易勝出，見過不少這樣的例子。

3.我以爲其實仍是問題驅動，努力解決好你眼前的問題，被承認，其實就全面發展啦。一個我很是佩服的同事的一篇文章供參考：http://www.qkey.top/ce-shi-kai-fa-gong-cheng-shi-de-career-path/ （上邊也貼過） 我十分認同
另外從市場角度看，其實：安全測試工程師、性能測試工程師這種工種的崗位需求是不多的。緣由兩點：1.小公司須要人是萬金油，啥都作。2.大公司所有平臺化服務化了，實施沒有啥技術難度，不少人依託平臺很快上手。大廠，不少性能測試是開發本身完成的，調優也是開發完成的，不須要什麼專職的性能測試工程師。

4.職級越高，須要懂的東西越多，由於懂得足夠多才能正確決策。其實在我心中質量是全部人的事兒，「測試開發」的定位是用本身的開發能力更好的保證系統質量。比較認同google團隊中的職責劃分，具體能夠參考： https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html