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

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

這應該是第三篇寫職業發展的文章啦。。。好像沒啥新東西。

有這麼個廣泛現象

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

Why？

能力要求不匹配是最核心的問題。軟件、互聯網近20年來飛速成長，其實也經歷了不少階段。行業軟件興盛階段和外包興盛階段行業進入了大量的測試人員，當時最主流的測試實踐是：重心基本放在系統驗收階段。測試人員的工做重心基本放在了基於業務的黑盒測試上，對代碼能力、系統理解的能力要求很少。2010年後，互聯網行業的真正興起讓國內軟件開發模式開始緩慢掉頭，快速迭代的模式逐步興起，開發週期愈來愈短，迭代愈來愈快。原來的測試工做模式和工做範圍愈來愈沒法知足要求了。但大量從業人員技能範圍轉變是一件很難的事情，行業是有巨大慣性的，從宏觀上看大量QA技能轉變跟不上需求轉變是形成市場供求不匹配的主要緣由。

So What?

三個觀點：1. 只作手工測試，不懂系統實現的測試工程師的職業發展會愈來愈受限。2. 可以轉型成適應市場需求的同窗可以在近幾年的時間內得到超額回報（由於市場供不該求，企業不得不擡高價格來尋找這樣的人）。3.對於個體來講，自我成長永遠最重要，本身永遠要對本身的發展負責，別依賴外部環境，本身想辦法變成市場的香餑餑才靠譜。

到底什麼樣的人搶手？

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

• 測試的底子-項目經驗
  有比較複雜系統的測試實戰經驗，你就超過了50%以上的應聘者。什麼叫作比較複雜系統呢？投入50人年開發出來的系統就能夠稱做一個複雜系統了。所以，複雜系統並非很罕見。可是，若是你只接觸一個簡單的模塊，甚至只是測試一個穩定模塊的維護性開發，而不是通盤理解，不能說是測試過複雜系統。

• 測試的底子-基礎知識
  對照三本書：《ISTQB基礎教程》 《ISTQB高級測試設計》 《ISTQB高級測試管理》。這裏邊的內容你都能熟練應用（真的是熟練應用，而不僅是有概念），你就能超過80%以上的應聘者了。面試過數百人，我常常會問幾個問題：若是測試時間不夠，你會怎麼辦？ 若是讓你去測試一個你徹底不熟悉的系統，你會怎麼辦？你平時會使用那些測試設計方法？ 看似很稀鬆日常的問題，很是考驗人。由於大部分從業者，都沒有經受過系統訓練和學習，工做多年，依然技能不足，意識跑偏。

• 熟練使用一門主語言
  知足這條，你就超過了70%的應聘者。什麼叫作熟練呢？拿Java來講吧：系統學習過Java的教程，高頻面試50題 這樣的題能夠自測一下，能夠回答上35個以上；熟悉最主流的Spring框架，可以寫出一個簡單的網站，實現基礎的rest 服務；讀懂過一個測試框架，如mockito或者Junit的源碼；可以熟練實施接口測試（基於一些測試框架 rest-assured+Junit）；可以讀懂開發的業務代碼，對他們的代碼進行Code Review；

• 對一門語言有比較深刻了解
  知足這條，你就超過了90%的應聘者。什麼叫有深刻了解呢？還拿Java來講吧：熟悉Java的常見API；深刻理解基於語言特性/系統特性的知識，如Collections的實現機制、類型系統、I/O、網絡、多線程等；熟知設計模式（廣義範圍的設計模式，不侷限於GOF的設計模式）；熟悉JVM的工做模式；熟練使用調試排查工具解決性能問題；熟練掌握市面上常見的腳手架；熟練掌握周邊知識（OPS相關，網絡知識相關）有不錯的實戰開發經驗（作過真正被生產檢驗的東西）；對於測試開發，AOP，Java字節碼技術是很重要的知識。。。 這是一個很長的學習list，須要幾年時間來養成。作到這點，你能夠經過一個普通的開發崗位了，這也是一個高級測試開發崗位的技術底子。

• 在一個領域知識有不錯的瞭解
  人不可能什麼都懂，但工做幾年以後，會在工做的域內必定要有積累才行。
  例如，你測試一個核心電商系統的交易模塊三年了，業務上你必定要熟練講出來：商品列表、購物車、下單、退單、廢單、支付、發貨、庫存、退款、優惠使用等等一坨業務流程，和可能出現的常見的坑（各種問題產生的資損、各種問題產生的服務不可用、邏輯矛盾），否則根本沒法體現你經驗沉澱和深刻思考；從技術山你要可以畫得出來系統的交互圖，熟悉最核心的接口和最核心的參數，可以讀懂開發的代碼，熟練使用trace和監控工具，診判定位線上問題到代碼行。

• 用技術保障質量的能力
  測試開發崗必定會問到一個問題：你可以舉一個你用技術手段提升測試效率，加強測試能力的例子麼？這是面試時最大的一個坎。 不少人會講一些自動化測試迴歸的例子，可是真正成功的例子很是少，由於爲何作，怎麼作都沒有想好就照網上一個教程攢了一個，結果變成了玩具。 作好自動化，不只僅是會使用工具、框架，其實要對被測物特性，軟件生命週期有很深的理解而且有很強的開發知識才行。其實在 環境、CI、數據、測試用例生成、數據比對的很小的一些點上，都能有不錯的提效產出，從這些點可以作得好，會獲得不錯的加分。有一個不錯的成功案例，你勝出的概率就超過了80%，沒有短板，就十拿九穩了。

• 技能之外的東西- 實戰案例
  之前的工做印證了你的能力。可以講清楚一項特別拿得出手的工做，證實你能力的工做。通常有以下特質會大大加分：快速學習、系統性學習、學以至用、系統性思考、強大的推進力、技術思惟、突出的溝通能力、條理性、抗壓性、抗挫折能力、迅速調整的能力、迭代改進的意識、wonership、願景和規劃。 這些特性體現人的內核，有強大內核的人，作什麼都行，技能暫時不足，也必定能補足。因此，在招聘的時候每每對是否錄用的判斷起決定性做用

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

• 計算機領域知識的通盤理解
  這條範圍很是大，人不可能什麼都懂。但最最基礎的知識是不能有盲點的：
  操做系統工做基礎原理與基礎操做：如linux，要通讀過linux操做系統的書，熟悉最基本的概念，基本命令要熟悉，shell要能寫和讀；
  網絡知識特別是TCP/IP, HTTP知識：推薦兩本書 《圖解tcp/ip》 《圖解Http》這兩本書裏的東西要懂。
  數據庫知識：市面常見數據庫（redis，mysql，oracle）的常見OP操做，問題排查；SQL的熟練使用；
  Web及移動端知識：可以懂HTML，CSS，可以讀懂Javascript代碼，可以讀懂android或者iOS的代碼，作簡單開發最好。
  安全知識：常見的安全防禦方法、工具使用；基本的安全攻防原理；
  軟件工程/開發過程管理：實戰中各類磨練，建議系統的學習PMP，敏捷開發的一些認證課程。

• 在一個域的深耕
  人不可能什麼都懂，但在一個領域是須要深耕的。好比，在作了4、五年移動端測試之後。基本上android和iOS都要具有必定的開發能力了，能讀懂開發的業務代碼是最基礎的，可以代替開發實現部分業務功能，完成部分組件開發是個自檢點。可以對移動端自動化工具棧、監控工具棧（如友盟、bugly、newrelic等）、內存泄露檢測、卡頓檢測、耗電量、弱網、流量、埋點、灰度、版本控制、兼容性、用戶體驗、安全等等的質量保障方案有通盤搞定能力。
  什麼叫搞定呢？舉個例子：好比，使用多種手段把崩潰率下降到千分之一如下。對於一個小團隊，這是個很不容易實現的坎。作到這點，你須要瞭解如何收集崩潰率，如何使用一系列工具來定位核心問題，如何推進開發改動，而且預防（靜態代碼掃描工具引入，阻止亂用第不成熟的第三方插件，代碼reivew防止常見pattern如空指針引起的崩潰，推進開發養成良好的log習慣，推進移動端防護性編程編程開發習慣，推進後端開發按照規範吐接口，幫助開發引入內存泄露、卡頓工具，趨勢報表，警鐘長鳴，各類灰度方式設置，線上監控。。。一個數據的改觀，背後要有大量的質量相關工做）。

• 使用綜合手段來保障軟件質量提高效能的能力。
  聽起來很抽象，舉幾個例子吧。
  例子1：你所在的team總在被開發抱怨測試用的時間太長。你想，如何能縮短一下測試時間呢？
  經過調研，發現測試小夥伴詬病的最多的就是環境不可用。環境到底多不可用呢？
  你基於Grafana和Prometheus作了一個環境可用的監控報表，使用後，發現環境在工做日總體可用時間爲35%左右，主要緣由是：2個核心熱點應用常常掛了沒人管。
  你拉了整個team，明確了部署責任人，約定了部署規則：只能中午餐和晚飯時間部署，而且部署後要本身看一下是否是OK。
  一週後，環境可用度上升到了65%。再深刻分析，發現2個同窗不守規矩，老是他們在破壞規則，你去找他們單獨談話。
  一週後，環境可用度上升到了80%。仍是有少許人不守規矩。
  你找SRE的同窗提需求，作了部署卡點，非部署時間部署必須TL審批。
  一週後，環境可用度上升到了85%。有些TL也不守規矩。
  你建了個報警，環境亂部署，壞掉了，在大團隊的羣裏@全體，告知誰搞壞了環境。
  一週後，環境可用度達到了92%。
  你加了一段時間無人響應，自動重啓服務功能，仍然有問題，自動回滾上一版本功能。
  你推進了開發解決了某個應用啓動時間過長的問題。
  你推進了環境分組。
  你推進了測試環境版本上線的規範流程實施。
  你推進了冒煙自動化用例卡點。
  你推進了環境部署人備份機制。
  你推進了全員基礎環境部署培訓。
  你總結了部署手冊。
  你作了。。。。。
  最後，環境可用度穩定到了97%以上。你爲測試節省了60%以上block時間（原來可用度未35%）

例子2：上面的問題，除了環境，還有一個槽點：開發提測質量不高。測試的頭幾天，不少主流程都走不通，致使測試老是在等待，或者是跟着開發一塊兒聯調。而這段時間，已經被習慣性的認爲是測試時間了，由於：提測了。

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

例子3：你發現測試時間長，測試本身也有問題

你推進了：測試依據風險測試，最大的風險獲得最快的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個。
  方法：若是找不出來，使勁去觀察，而後去看看作的好的同行，比比你比人家差在哪裏。嘗試去解決這些問題，從小問題，可以見到效果的問題入手，設置一個時間點。你真正解決了5個以上問題之後，感受必定會有。

• 系統學習，系統學習，系統學習
  自檢點：我係統的學過一門知識麼？我能講清楚我這麼操做，我寫的這行代碼的原理麼？
  方法：從工做出發，確認你須要補足什麼知識。從網上找一個某個具體知識的學習路線圖，訂個計劃，照着來。 參加學習小組，找到幫你解決難題的人，多請他吃飯，多請教他。獲取知識後，立刻回到工做中作檢驗。仍是學以至用才能

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

總結

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



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

下山

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



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