老生常談，再談?wù)劀y試職業(yè)發(fā)展
有這么個普遍現(xiàn)象
測試招聘者，特別是一、二線互聯(lián)網(wǎng)公司的招聘者最苦惱的事兒就是招人。想找到一個合適的人難于上青天，每天各種撒網(wǎng)，簡歷看幾百份，面大幾十人，能撈到一個中意的小伙伴就謝天謝地了。但同時很多測試小伙伴發(fā)現(xiàn)找工作很難，特別是進(jìn)大一點的廠，他們特別挑：代碼要會寫，要有軟件架構(gòu)能力，問一大坨平時根本用不到的技術(shù)問題，還挑經(jīng)驗，挑溝通能力，挑這挑那，有時候還特么挑學(xué)歷、挑年齡。。。 供求總難以匹配起來，造成了雙方都很痛苦。
Why？
能力要求不匹配是最核心的問題。軟件、互聯(lián)網(wǎng)近20年來飛速成長，其實也經(jīng)歷了很多階段。行業(yè)軟件興盛階段和外包興盛階段（2000-2010年）行業(yè)進(jìn)入了大量的測試人員，當(dāng)時最主流的測試實踐是：重心放在系統(tǒng)驗收階段。測試人員的主要工作基本都投入在了基于業(yè)務(wù)的黑盒測試上，對代碼能力、系統(tǒng)理解的能力要求不多。2010年后，互聯(lián)網(wǎng)行業(yè)的真正興起讓國內(nèi)軟件開發(fā)模式開始緩慢調(diào)頭，快速迭代的模式逐步興起，開發(fā)周期越來越短，迭代越來越快，但系統(tǒng)越來越越龐大、復(fù)雜。原來的測試工作模式和工作范圍越來越無法滿足要求了。但大量從業(yè)人員技能范圍轉(zhuǎn)變是一件很難的事情，行業(yè)是有巨大慣性的。從宏觀上看大量QA技能轉(zhuǎn)變跟不上需求轉(zhuǎn)變是造成市場供求不匹配的主要原因。
So What?
三個觀點：1. 只做手工測試，不懂系統(tǒng)實現(xiàn)的測試工程師的職業(yè)發(fā)展會越來越受限。2. 能夠轉(zhuǎn)型成適應(yīng)市場需求的同學(xué)將在近幾年的時間獲得超額回報（因為市場供不應(yīng)求，企業(yè)不得不抬高價格來尋找這樣的人）。3.對于個體來說，自我成長永遠(yuǎn)最重要，自己永遠(yuǎn)要對自己的發(fā)展負(fù)責(zé)，別依賴外部環(huán)境，自己想辦法變成市場的香餑餑才靠譜。
到底什么樣的人搶手？
按照我一點理解講一講什么樣子的人會搶手吧，限于篇幅會偏重技術(shù)角度來講。個人之見，歡迎討論和拍磚。
測試的底子-項目經(jīng)驗
有比較復(fù)雜系統(tǒng)的測試實戰(zhàn)經(jīng)驗，你就超過了50%以上的應(yīng)聘者。什么叫做比較復(fù)雜系統(tǒng)呢？投入50人年開發(fā)出來的系統(tǒng)就可以稱作一個復(fù)雜系統(tǒng)了。因此，復(fù)雜系統(tǒng)并不是很罕見。但是，如果你只接觸一個簡單的模塊，甚至只是測試一個穩(wěn)定模塊的維護(hù)性開發(fā)，而不是通盤理解，不能說是測試過復(fù)雜系統(tǒng)。有從頭到尾接觸一個完整項目的經(jīng)歷很寶貴。
測試的底子-基礎(chǔ)知識
對照三本書：《ISTQB基礎(chǔ)教程》 《高級軟件測試設(shè)計》 《高級軟件測試管理》（后兩本是ISTQB的高級認(rèn)證教程）。這里邊的內(nèi)容你都能熟練應(yīng)用（真的是熟練應(yīng)用，而不只是有概念），你就能超過80%以上的應(yīng)聘者了。面試過數(shù)百人，我經(jīng)常會問幾個問題：如果測試時間不夠，你會怎么辦？ 如果讓你去測試一個你完全不熟悉的系統(tǒng)，你會怎么辦？你平時會使用那些測試設(shè)計方法？ 看似很稀松平常的問題，非?？简炄?。因為大部分從業(yè)者都沒有經(jīng)受過系統(tǒng)訓(xùn)練和學(xué)習(xí)，工作多年，依然技能不足，意識跑偏。
熟練使用一門主語言
滿足這條，你就超過了70%的應(yīng)聘者。什么叫做熟練呢？拿Java來說吧：系統(tǒng)學(xué)習(xí)過Java的教程，高頻面試50題?這樣的題可以自測一下，可以回答上35個以上；熟悉最主流的Spring框架，能夠?qū)懗鲆粋€簡單的網(wǎng)站，實現(xiàn)基礎(chǔ)的Restful 服務(wù)；讀懂過一個測試框架，如mockito或者Junit的源碼；能夠熟練實施接口測試（基于一些測試框架 如：rest-assured+Junit）；能夠讀懂開發(fā)的業(yè)務(wù)代碼，對他們的代碼進(jìn)行Code Review；
對一門語言有比較深入了解
滿足這條，你就超過了90%的應(yīng)聘者。什么叫有深入了解呢？還拿Java來說吧：熟練使用Java的常見API；深入理解基于語言特性/系統(tǒng)特性的知識，如Collections的實現(xiàn)機(jī)制、類型系統(tǒng)、I/O、網(wǎng)絡(luò)、多線程等；熟知設(shè)計模式（廣義范圍的設(shè)計模式，不局限于GOF的設(shè)計模式）；熟悉JVM的工作模式；熟練使用調(diào)試排查工具解決性能問題；熟練掌握市面上常見的腳手架；熟練掌握周邊知識（OPs相關(guān)，網(wǎng)絡(luò)知識相關(guān)）有不錯的實戰(zhàn)開發(fā)經(jīng)驗（做過真正被生產(chǎn)檢驗的東西）；對于測試開發(fā)，AOP，Java字節(jié)碼技術(shù)是很重要的知識。。。 這是一個很長的學(xué)習(xí)list，需要幾年時間來養(yǎng)成。做到這點，其實你可以勝任普通的開發(fā)崗位了，這也是高級測試開發(fā)崗位的技術(shù)底子。
在一個領(lǐng)域知識有不錯的了解
人不可能什么都懂，但工作幾年之后，會在工作的域內(nèi)一定要有積累才行。
例如，你測試一個核心電商系統(tǒng)的交易模塊三年了，業(yè)務(wù)上你一定要熟練講出來：商品列表、購物車、下單、退單、廢單、支付、發(fā)貨、庫存、退款、優(yōu)惠使用等等一坨業(yè)務(wù)流程，和可能出現(xiàn)的常見的坑（各類問題產(chǎn)生的資損、各類問題產(chǎn)生的服務(wù)不可用、邏輯矛盾），不然根本無法體現(xiàn)你經(jīng)驗沉淀和深入思考；技術(shù)角度上，你要能夠畫得出來系統(tǒng)的交互圖，熟悉最核心的接口和最核心的參數(shù)，能夠讀懂開發(fā)的代碼，熟練使用trace和監(jiān)控工具，診斷定位線上問題到代碼行。
用技術(shù)保障質(zhì)量的能力
測試開發(fā)崗一定會問到一個問題：你能夠舉一個你用技術(shù)手段提高測試效率，增強(qiáng)測試能力的例子么？這是面試時最大的一個坎。很多人會講一些自動化測試回歸的例子，但是真正成功的例子非常少，因為為什么做，怎么做都沒有想好就照網(wǎng)上一個教程攢了一個，結(jié)果變成了玩具。 做好自動化，不僅僅是會使用工具、框架，其實要對被測物特性，軟件生命周期有很深的理解并且有很強(qiáng)的開發(fā)知識才行。實際上，在環(huán)境、CI、數(shù)據(jù)、測試用例生成、數(shù)據(jù)比對的很小的一些點上，都能有不錯的提效產(chǎn)出，從這些點能夠做得好，會得到不錯的加分。有一個不錯的成功案例，你勝出的幾率就超過了80%，沒有短板，就十拿九穩(wěn)了。
技能以外的東西- 實戰(zhàn)案例
以前的工作印證了你的能力。能夠講清楚一件特別拿得出手的工作，證明你能力的工作能力是面試時候最有用的投名狀。
技能意外的東西 - 你的個人特質(zhì)
一般有如下特質(zhì)會大大加分：快速學(xué)習(xí)、系統(tǒng)性學(xué)習(xí)、學(xué)以致用、系統(tǒng)性思考、強(qiáng)大的推動力、技術(shù)思維、突出的溝通能力、條理性、抗壓性、樂觀精神、抗挫折能力、迅速調(diào)整的能力、迭代改進(jìn)的意識、ownership、愿景和規(guī)劃。這些特性體現(xiàn)人的內(nèi)核，有強(qiáng)大內(nèi)核的人，做什么都行，技能暫時不足，也一定能補(bǔ)足。所以，在招聘的時候往往對是否錄用的判斷起決定性作用
高段位要求（高級職位需求）
計算機(jī)領(lǐng)域知識的通盤理解
這條范圍非常大，人不可能什么都懂。但最最基礎(chǔ)的知識是不能有盲點的：
操作系統(tǒng)工作基礎(chǔ)原理與基礎(chǔ)操作：如linux，要通讀過linux操作系統(tǒng)的書，熟悉最基本的概念，基本命令要熟悉，shell要能寫和讀；
網(wǎng)絡(luò)知識特別是TCP/IP, HTTP知識：推薦兩本書 《圖解tcp/ip》 《圖解Http》這兩本書里的東西要懂。
數(shù)據(jù)庫知識：市面常見數(shù)據(jù)庫（redis，mysql，oracle）的常見DBA操作，問題排查；SQL的熟練使用；
Web及移動端知識：能夠懂HTML，CSS，能夠讀懂Javascript代碼，能夠讀懂Android或者iOS的代碼，做簡單開發(fā)最好。
安全知識：常見的安全防護(hù)方法、工具使用；基本的安全攻防原理；
軟件工程/開發(fā)過程管理：實戰(zhàn)中各種磨練，建議系統(tǒng)的學(xué)習(xí)PMP，敏捷開發(fā)的一些認(rèn)證課程。
在一個域的深耕
人不可能什么都懂，但在一個領(lǐng)域是需要深耕的。比如，在做了四、五年移動端測試以后。android和iOS都要具備一定的開發(fā)能力了，能讀懂開發(fā)的業(yè)務(wù)代碼是最基礎(chǔ)的，能夠代替開發(fā)實現(xiàn)部分業(yè)務(wù)功能，完成部分組件開發(fā)是個非常好的自檢點。能夠?qū)σ苿佣俗詣踊ぞ邨?、監(jiān)控工具棧（如友盟、bugly、newrelic等）、內(nèi)存泄露檢測、卡頓檢測、耗電量、弱網(wǎng)、流量、埋點、灰度、版本控制、兼容性、用戶體驗、安全等等的質(zhì)量保障方案有通盤搞定能力。
什么叫搞定呢？舉個例子：比如，使用多種手段把崩潰率降低到千分之一以下。對于一個小團(tuán)隊，這是個很不容易實現(xiàn)的坎。做到這點，你需要了解如何收集崩潰率，如何使用一系列工具來定位核心問題，如何推動開發(fā)改動，并且預(yù)防（靜態(tài)代碼掃描工具引入，阻止亂用第不成熟的第三方插件，代碼reivew防止常見pattern如空指針引發(fā)的崩潰，推動開發(fā)養(yǎng)成良好的log習(xí)慣，推動移動端防御性編程編程開發(fā)習(xí)慣，推動后端開發(fā)按照規(guī)范吐接口，幫助開發(fā)引入內(nèi)存泄露、卡頓工具，趨勢報表，警鐘長鳴，各種灰度方式設(shè)置，線上監(jiān)控。。。一個數(shù)據(jù)的改觀，背后要有大量的質(zhì)量相關(guān)工作）。
使用綜合手段來保障軟件質(zhì)量提升效能的能力。
聽起來很抽象，舉幾個例子吧。
例子1：你所在的team總在被開發(fā)抱怨測試用的時間太長。如何能縮短一下測試時間呢？
通過調(diào)研，發(fā)現(xiàn)測試小伙伴詬病的最多的就是環(huán)境不可用。環(huán)境到底多不可用呢？
你基于Grafana和Prometheus做了一個環(huán)境可用的監(jiān)控報表，使用后，發(fā)現(xiàn)環(huán)境在工作日整體可用率只有35%左右，主要原因是：幾個核心熱點應(yīng)用經(jīng)常掛了沒人管。
你拉了整個team，明確了部署責(zé)任人，約定了部署規(guī)則：只能中午飯和晚飯時間部署，并且部署后要自己看一下是不是OK。
一周后，環(huán)境可用度上升到了65%。再深入分析，發(fā)現(xiàn)2個同學(xué)不守規(guī)矩，總是他們在破壞規(guī)則，你去找他們單獨談話。
一周后，環(huán)境可用度上升到了80%。還是有少量人不守規(guī)矩。
你找SRE的同學(xué)提需求，做了部署卡點，非部署時間部署必須TL審批。
一周后，環(huán)境可用度上升到了85%。有些TL也不守規(guī)矩。
你建了個報警，環(huán)境亂部署，壞掉了，在大團(tuán)隊的群里@全體，告知誰搞壞了環(huán)境。
一周后，環(huán)境可用度達(dá)到了92%。
你加了一個feature：應(yīng)用掛了一段時間無人響應(yīng)，自動重啟服務(wù)功能，仍然有問題，就自動回滾上一版本。
你推動了開發(fā)解決了某個應(yīng)用啟動時間過長的問題。
你推動了環(huán)境分組。
你推動了測試環(huán)境版本上線的規(guī)范流程實施。
你推動了冒煙自動化用例卡點。
你推動了環(huán)境部署人備份機(jī)制。
你推動了全員基礎(chǔ)環(huán)境部署培訓(xùn)。
你總結(jié)了部署手冊。
你做了。。。。。
最后，環(huán)境可用度穩(wěn)定到了97%以上。你為測試節(jié)省了60%以上block時間（原來可用度未35%）
例子2：上面的問題，除了環(huán)境，還有一個槽點：開發(fā)提測質(zhì)量不高。測試的頭幾天，很多主流程都走不通，導(dǎo)致測試總是在等待，或者是跟著開發(fā)一起聯(lián)調(diào)。而這段時間，已經(jīng)被習(xí)慣性的認(rèn)為是測試時間了，因為：提測了。
你推動了：測試提供冒煙用例，開發(fā)必須完成一定程度的自測才能提測。
你推動了：測試和開發(fā)做自動化同期共建，在開發(fā)過程中，核心功能就被自動化用例保護(hù)起來了。
你推動了：開發(fā)切分feature提測，而不是攢一個大招一下子提一坨。
你推動了：代碼Codereview變成團(tuán)隊常規(guī)活動，QA在早期跟進(jìn)核心代碼，把問題坑殺在萌芽階段。
你推動了：外部資源聯(lián)調(diào)非常早的進(jìn)行，不會讓它在測試后期成為測試blocker。
。。。
例子3：你發(fā)現(xiàn)測試時間長，QA自己也有問題。
你推動了：有明確的測試計劃，并讓所有干系人都有明確的預(yù)期。
你推動了：測試依據(jù)風(fēng)險測試，最大的風(fēng)險得到最快的cover，科學(xué)分配時間，明顯縮短bug反饋時間弧。
你推動了：bug嚴(yán)格管理，所有重要bug都及時修復(fù)。
你推動了：良好的溝通和匯報機(jī)制，每天讓團(tuán)隊主要干系人清晰的知道，距離發(fā)布還差多遠(yuǎn)。
你推動了。。。。
你能講出自己做過5個以上這樣的成功例子，我敢保障，你會被1線大廠瘋搶。職級基本都是專家起。
持續(xù)學(xué)習(xí)能力和復(fù)雜問題解決能力
例子1：
你近期的工作是幫助團(tuán)隊提升后臺服務(wù)穩(wěn)定性。你看到了netflix內(nèi)部使用一個叫做ChaosMonkey的東西來隨機(jī)對生產(chǎn)服務(wù)期進(jìn)行攻擊，而逼迫工程師提高穩(wěn)定性，所以，你也實現(xiàn)了類似（更溫和）的內(nèi)部機(jī)制，推動團(tuán)隊穩(wěn)定性的提高。
你怎么知道這個叫做ChaosMonkey的東西呢？ 因為你會習(xí)慣性瀏覽一線廠商的技術(shù)博客，參與行業(yè)大會，關(guān)注各類新技術(shù)。持續(xù)性的養(yǎng)成習(xí)慣。
例子2：
做大規(guī)模接口自動化好難，外部數(shù)據(jù)依賴太難搞，參數(shù)構(gòu)造太費勁，assert太難寫。如果能夠簡單的錄制回放就好了。
但是，外部依賴是個天坑，寫操作mock也是個天坑，assert也是個天坑。
實際的案例是，經(jīng)過幾年多個團(tuán)隊持續(xù)不屑的填坑，阿里內(nèi)部已經(jīng)有應(yīng)用級的錄制回放工具了，數(shù)百個應(yīng)用成功的是用了它，把不可能回歸的任務(wù)變成了可能（上萬數(shù)量級的case當(dāng)天生成，當(dāng)天投入使用，并可以分析覆蓋率），自動化測試實施需要付出的工作時間革命性降低（不足原來付出時間的10%）。
你能講出自己做過5個以上這樣的成功例子，我敢保障，你也會被1線大廠瘋搶。職級基本都是專家起。
其它能力測試是個萬金油，高階一些的職位需要什么都要會一些，因為越高階的職位需要解決的問題越綜合，需要打交道的人的種類越多。不然很容易變成你職業(yè)短板，做個list吧（一定不全）：
很好的項目管理能力，至少與開發(fā)經(jīng)理能力同級，甚至要強(qiáng)于他。
一定的軟件架構(gòu)能力。
一定的產(chǎn)品sense：可以跟一個資深的產(chǎn)品經(jīng)理能夠順暢的交流，明白知道他為什么會這么想，所要實現(xiàn)產(chǎn)品的意義，路徑；從產(chǎn)品質(zhì)量方面的考慮要超過產(chǎn)品經(jīng)理，給他輸出。
極好的溝通能力。
團(tuán)隊管理能力（這個太重要）
目標(biāo)管理能力
有一個好的內(nèi)核（上面提到過）
怎么轉(zhuǎn)型/怎么進(jìn)階？
其實不難，沒有什么高端的方法。下面這4條就夠了，核心秘密就是堅持不懈。
熟悉你的被測系統(tǒng)，熟悉你的被測系統(tǒng)，熟悉你的被測系統(tǒng)。能夠從技術(shù)、業(yè)務(wù)角度做到對被測系統(tǒng)熟悉是做一個好QA的最基本職業(yè)素養(yǎng)，也是能力提升的最主要源泉。
自檢點：我能夠畫出系統(tǒng)的架構(gòu)圖么？我能夠讀懂開發(fā)的代碼么？我熟悉常見的業(yè)務(wù)監(jiān)控系統(tǒng)么？熟悉日志系統(tǒng)么？知道開發(fā)是如何調(diào)試和定位問題的么？給我一個線上問題，我能定位么？我能給別人完整的介紹這個域的核心業(yè)務(wù)么？我能自己直接動手發(fā)布上線一個系統(tǒng)么？知道如何回滾么？灰度是如何做的？ 我知道所有關(guān)鍵的技術(shù)點么，如一個交易的冪等性是如何實現(xiàn)的？我在團(tuán)隊中有：“這家伙對系統(tǒng)最熟”的口碑么？
如果自檢點全部是否定答案。。。 花一年時間把它全變成肯定答案。這一過程，你一定被迫學(xué)到了很多很多，并且獲得了極為長足的成長，這是進(jìn)階的必由之路，也是卡了很多人的地方。如果說做不到，后面不用看了，前面的也全部忘掉吧。
方法：通讀所有文檔，強(qiáng)迫自己讀代碼，積極參與開發(fā)所有討論，不懂的狂問，觀察開發(fā)如何上線，如何排查問題，模仿，學(xué)習(xí)，善用搜索引擎，總結(jié)。。。
找到問題解決問題，找到問題解決問題，找到問題解決問題。你一定有一堆問題，如果你覺得自己做得挺好，沒有問題要解決，那必然是你自己有巨大的問題！
自檢點：找一支筆，寫出你覺得質(zhì)量方面，你的team的10個問題，做排序。排出最重要的3個。
方法：找到top3的問題，選一個，列個接話，去解決。如果找不出來，使勁去觀察，然后去看看做的好的同行，比比你比人家差在哪里。嘗試去解決這些問題，從小問題，能夠見到效果的問題入手，設(shè)置一個時間點。你真正解決了5個以上問題以后，感覺一定會有。
系統(tǒng)學(xué)習(xí)，系統(tǒng)學(xué)習(xí)，系統(tǒng)學(xué)習(xí)
自檢點：我系統(tǒng)的學(xué)過一門知識么？我能講清楚我這么操作，我寫的這行代碼的原理么？
方法：從工作出發(fā)，確認(rèn)你需要補(bǔ)足哪些知識。從網(wǎng)上找一個具體知識的學(xué)習(xí)路線圖，訂個計劃，照著來。 參加學(xué)習(xí)小組，找到幫你解決難題的人，多請他吃飯，多請教他。獲取知識后，馬上回到工作中做檢驗。還是學(xué)以致用才能有所增長。結(jié)合工作來系統(tǒng)學(xué)習(xí)的效果是最好的。
再舉個例子：
上家公司有個小伙伴（他應(yīng)該也會泡這個社區(qū)），開始應(yīng)聘的時候，他說熟悉jenkins，用的很多。所以第一份工作是：把所有CI的日常工作交給了他，并告知2個月內(nèi)要全部搞定。 他一下懵逼了，原來那些不深入的理解支撐不了工作要求。后來他每天死磕，看了jenkins所有的文檔（對，幾乎所有文檔通讀了一遍），翻了無數(shù)問題的解決帖子，記錄了上百個問題解決的過程，寫了上百篇jenkins的小blog（現(xiàn)在還沒公布出來）。幾個月以后，他比我熟了，他的一項基礎(chǔ)能力成長為：可以獨自給一個小公司完整的搞定前端、后端、移動端的一整套CI解決方案。其實單憑這一套，就能找到不錯的工作了。這是依托工作，系統(tǒng)性學(xué)習(xí)的結(jié)果。
看到有同學(xué)說要裸辭，去接受培訓(xùn)。我的建議是，別這樣。裸辭你就失去了學(xué)以致用的陣地，失去了真正解決問題的機(jī)會，還失去了資金來源。依托工作，自主學(xué)習(xí)是王道。自己饒過不去坎，其實有很多網(wǎng)上教程和脫產(chǎn)培訓(xùn)班啊。
選擇有挑戰(zhàn)的團(tuán)隊，選擇有挑戰(zhàn)的團(tuán)隊 自檢點：在團(tuán)隊里有很多人比我強(qiáng)么？周圍的同事都是我佩服的么？我做的事兒有挑戰(zhàn)么？ 方法：如果這三點都是否定的，并且你處于職業(yè)生涯的早期。也許（只是也許），你該考慮一下?lián)Q個團(tuán)隊了。
總結(jié)
偏重技能角度講了講市場的需求和QA如何做如何滿足市場需求。行文倉促，認(rèn)識有限，其實也并沒有什么新東西。歡迎討論拍磚?。海?/p>
最后放一篇老文，前google測試總監(jiān)寫的，寫了快10年了，但我覺得常讀常新。
順手發(fā)個招聘廣告
我的team在招聘QA小伙伴。地點北京，技術(shù)職級P6或者P7 。 P8也有可能（只要你足夠強(qiáng)悍）
偏后端測試，有意者請郵件我啊 daohe.lxg@alibaba-inc.com
-----------------------------------------------------------我是分割線--------------------------------------------
經(jīng)營成功的測試職業(yè)生涯
(James A. Whittaker）
你是如何開始做測試工作的？
1989年，我在田納西大學(xué)讀研究生的時候，完成了從軟件開發(fā)人員到軟件測試人員的轉(zhuǎn)型。而這一轉(zhuǎn)型并非出于我自己的選擇。我命運的改變發(fā)生在一個早晨，我的教授質(zhì)問我為什么缺席那么多開發(fā)會議。我解釋說因為會議被安排在星期六早上，很不方便。
而怍為一個生平第一次離開家的新入校的研究生，這個時間段有些麻煩。十分有意思的是，等待我的懲罰并不是一紙解聘通知書，而是被判罰為該小組的唯一一個測試人員，且不能與開發(fā)團(tuán)隊有任何交流。
對于我的職業(yè)生涯來說，這是一個意義多么重大的決定啊！正是這個決定最終成就了幾十篇關(guān)于測試的論文，構(gòu)建了多得連我自己也記不清的各種工具，出版了五本書，帶來了無盡的快樂工作時間。測試一直就是我擁有的那份具有創(chuàng)造性和技術(shù)挑戰(zhàn)性的快樂職業(yè)。不過，并不是所有人都喜歡這樣?？梢哉f我最早接觸測試是在攻讀研究生期問，不可否認(rèn)，那時的高強(qiáng)度學(xué)習(xí)和工作確實讓我受益匪淺。另外，我認(rèn)為從初學(xué)者階段到專家階段之間存在著一個“測試的山峰”，人們需要通過一系列個人輔導(dǎo)、獲取信息和接受常規(guī)指導(dǎo)來翻越山峰。成為一個測試初學(xué)者是很容易的，成為職業(yè)的測試人員也并不艱難。本章的重點正是討論如何翻越那座位于職業(yè)測試人員和測試專家之間的山峰。
回到未來
在軟件測試領(lǐng)域，時間似乎已經(jīng)停滯了。我們在21世紀(jì)做事的方法與上個世紀(jì)幾乎完全相同。Bill Hetzel在1972年出版的測試知識叢書至今仍然相當(dāng)有價值。而我自己所寫，于2002年首次出版的How to Break Software(如何攻破軟件)系列，到今天仍被作為實用軟件測試技術(shù)主要資源的代名詞。
確實，如果我們可以把20世紀(jì)70年代的測試人員轉(zhuǎn)換時空用在今日，我猜想他們的的技巧足夠應(yīng)付現(xiàn)代軟件的測試。當(dāng)然，他們需要學(xué)習(xí)網(wǎng)絡(luò)和各種網(wǎng)絡(luò)協(xié)議，但是他們擁有的實際測試技術(shù)將能得到很好的應(yīng)用。如果從20世紀(jì)90年代找一個測試人員，則不幾乎不需要任何訓(xùn)練。
對于開發(fā)人員來說，卻不是這樣，他們所掌握的那些上世紀(jì)的技巧幾乎已經(jīng)完全過 時。讓一個有一段時間不寫代碼的人重新開始編程，看看會有什么樣的反應(yīng)。讓我感到很不安的是，我們可以從馬路上直接雇用人手，而雇來的這些人從第一天起就能夠測試，就能夠有收獲。事情真的有那么簡單嗎？或者是我們的期望值只有那么低？讓我更加不安的是，我們沒有任何可預(yù)測的方式將合適的測試人才從勝任工作狀態(tài)訓(xùn)練為測試專。測試真的就那么困難嗎？
這又是那個山峰了。門檻很低，但通往精通的道路卻很艱難。
在通往測試山峰的入口，我們倚仗的是這樣一個事實：測試的很多方面都很容易掌握。大多數(shù)人都可以學(xué)得有模有樣。甚至只要將一點點常識應(yīng)用于輸入的選擇,就可以找出缺陷。這個層次的測試就如同在桶里釣魚，簡單到足以讓任何人都認(rèn)為自己很聰明。然而過了入口以后，道路迅速陡峭起來，而測試知識變得越來越晦澀難懂。我們發(fā)現(xiàn)有人擅長于此，我們稱這些人為“有天賦的人”，并欣賞他們的本能。
難道一定要依靠本能么？對于那些看起來不具備特長的人們，是否存在著一條翻越山峰的途徑？是否可以以某種方法傳授測試技能以培養(yǎng)出更多的專家呢？為認(rèn)為這座山峰是可以通行的，而這一章正是我關(guān)于應(yīng)該如何走這條路的筆記，你可以在自己的職業(yè)生涯中加以應(yīng)用。這并不是一份食譜配方，一份職業(yè)生涯烹調(diào)書。不過你可以做一些事情來加速你的職業(yè)成長。但是，正如你可能已經(jīng)猜到的，真正是說來容易，做起來難。
上山
測試職業(yè)的早期階段主要是為征服測試山峰的漫長攀登做準(zhǔn)備。我所能給出的最好的建議是從兩個方面來思考問題。對于你參與的每一個項目，都有兩部分（不一定相等）的任務(wù)。第一部分的任務(wù)是保證當(dāng)前的測試項目獲得成功。而第二部分的任務(wù)是學(xué)習(xí)你應(yīng)該做些什么以便使下一個測試項目更加容易。我把它稱為“測試今天的項目，準(zhǔn)備明天的項目”。如果你做每一個項目把它都分割成為上述的兩半，那么幾乎可以保證你能持續(xù)獲得進(jìn)步。這樣，你就可以隨著每一個參與的項目逐漸成長為更優(yōu)秀的測試人員。
現(xiàn)在就讓我們來關(guān)注第二部分的任務(wù)------為下一個項目做準(zhǔn)備。我們需要注意三個概念：重復(fù)、技術(shù)和漏洞。
重復(fù)
做任何一件事，絕不要重復(fù)兩次而不意識到或質(zhì)疑這其實是個問題。我希望所有年輕的測試人員都牢記這一點。我見過很多初學(xué)者，他們在單調(diào)的任務(wù)上浪費了太多的時間，比如，設(shè)置測試機(jī)器，配置測試環(huán)境，在實驗室里安裝待測試的應(yīng)用程序，選擇一個產(chǎn)品版本來測試-這些任務(wù)列表可以變得很長，最后你會發(fā)現(xiàn)真正花在測試軟件上的時間少得可憐。
這是許多新手常犯的錯誤。他們沒能看到他們?nèi)諒?fù)一日所做的工作的重復(fù)本質(zhì)，兒當(dāng)他們意識到這種重復(fù)時，幾個小時已經(jīng)過去了，而在這幾個小時內(nèi)他們沒有做任何實際的測試工作。關(guān)注這些重復(fù)勞動，并且留意由此造成的真正的軟件測試工作時間的流逝。為了能翻過測試的山峰，必須做一個測試人員應(yīng)該做的工作，而不是實驗室管理員或者測試機(jī)管理員的工作。
測試自動化是解決重復(fù)勞動的方案，也是本章稍后的主題。
技術(shù)
測試人員常常會對軟件失效進(jìn)行分析。分析缺陷時，我們從開發(fā)人員的失敗中學(xué)習(xí)如何編寫可靠的代碼。我們也分析那些被我們忽略的缺陷。在應(yīng)用程序上市以后，客戶就會開始報告缺陷，我們將要面對處理一大堆失效的情形并尋找其中的重要缺陷。用戶報告的每一個缺陷都說明我們的流程有問題，我們的測試知識還不夠完善。
但是分析我們的成功也同樣重要，兒許多新入職的測試人員卻沒能利用這個唾手可得的資源。我們在測試中找到的每一個缺陷都說明我們的的測試流程正在有效工作，都是一次成功。我們需要緊緊抓住這種絕好的機(jī)會，只有這樣才能使成功不斷的重復(fù)下去。
運動隊常常這樣做，他們會觀看比賽錄像，并分析每一個動作為什么奏效或者為什么不奏效。我清楚地記得一個小故事，我的一個朋友拍下了我兒子踢足球的一些照片。其中一張照片記錄了她踢球的瞬間，那個球超過對方守門員成功進(jìn)球了。當(dāng)我把它給我兒子看時，我之處他站立的那條腿的姿勢非常完美，他踢球的腳尖緊繃且出球點在鞋帶間恰到好處的位置上。他盯著那張照片很長時間，從那以后他很少用不正確的姿勢踢球。他那次得分可能只是碰巧做對了，但從此以后他有意識的運用這些技術(shù)使之接近完美。
現(xiàn)在回到新手測試人員的課程上來。我們每一個人都會有得意的時刻。我們找到重要的漏洞或發(fā)現(xiàn)優(yōu)先級很高的缺陷，并為此雀躍不已。不過先花點時間考慮一下整體狀況。我們使用什么技術(shù)找到了那個缺陷？我們是否可以創(chuàng)建一種方法來找到更多這類缺陷？我們是否可以記住…些實際的測試經(jīng)驗并不斷地加以應(yīng)用來幫助提高我們的工作效率？軟件的哪些癥狀可以提示我們它具有缺陷？我們將來能否從那些癥狀中得到更多的警示？換句話說，這不僅僅是一個缺陷或是一次成功，這個缺陷教會了我們什么，是否使得我們將來成為更好的測試人員正如我兒子的進(jìn)球一樣，盡管第一個缺陷是偶然間發(fā)現(xiàn)的，但它不代表其余的成功都是偶然。理解我們成功的原因很重要，只有這樣做，成功才能被復(fù)制。對于測試人員來說，這種保證成功的原因就是一系列的測試技術(shù)、建議和工具，它們可以提高我們在未來項目中的工作效率。
漏洞
測試人員最終都會變得很擅長尋找缺陷，但是要翻過測試的高峰，我們必須更快并且更有效率：高速低阻。換句話說，我們必須擁有一種本身不含缺陷的缺陷查找技術(shù)！
我喜歡這樣來考慮問題：測試人員檢視自己的工作時也需要發(fā)揮那種尋找缺陷的能力。我們必須使用和尋找產(chǎn)品缺陷一樣的流程來尋找我們自己的測試流程，測試過程中的缺陷。我的測試流程是不是有問題？這里面是否有缺陷？這里是否存在著妨礙我提高效率的障礙？
你必須一直尋找更好的方法。有意識地去確定那些限制能力、阻礙前進(jìn)、減緩速度的東西。就像缺陷限制了軟件滿足用戶需求的能力一樣，是什么限制了測試的能力？使用你擁有的測試能力來最優(yōu)化自己的測試流程，這會幫助你在測試的山峰上快速攀登并增加你翻越山峰后成為專家的機(jī)會。
測試山峰的巔峰處是一個美好的地方。如果你成功地到了那里，恭喜你．但這并不是最終日標(biāo)。這表示你已經(jīng)成為一個杰出的測試人員。而此時的下坡路就是用你的洞察力和專家知識來幫助周圍的人也成為優(yōu)秀的測試人員。自己一個人登頂是一回事，幫助其他人（那些能力不如你的人）登頂卻完全是另外一回事。
一般來說，那些成功登上測試巔峰的人會成為使用工具的大師。那些商業(yè)工具、開開源免費工具,和自己寫的工具（我個人最喜歡的工具）是極好地提高工作產(chǎn)出、增加工作成效的方法。不過，工具只是實現(xiàn)該目標(biāo)的一種方法，但在許多其他方面它反而是一種限制，因為太多的人看不到工具的功能之外的東西。他們被限制在工具能為他們所做的事情中，沒能看到或理解對工具還有更多的需求。登頂需要真正掌握的是“信息”。因為很多工具能處理信息，并使得信息的獲取更加容易，所以測試人員變得過于依賴于他們的工具。但是信息本身以及如何利用這些信息才是真正的成功關(guān)鍵。
熟練掌握信息，指理解有哪些信息，這些信息將如何影響測試，保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關(guān)注的。這里我要談的是其中兩種：來自應(yīng)用程序的信息和來自之前測試的信息。
來自應(yīng)用程序的信息包括需求、體系結(jié)構(gòu)、代碼結(jié)構(gòu)、源代碼……甚至是關(guān)于應(yīng)用程序在執(zhí)行時做了哪些事情的運行信息。在編寫和執(zhí)行測試用例時，需要考慮這類信息，但信息的多寡在很大程度上取決于測試人員的能力，這是一種能夠使測試更高效的能力。在測試中使用這類信息越多，測試就越偏向于工程而不是猜測。
在微軟，我們有一個游戲測試組織（Games Test Organization,GTO），負(fù)責(zé)Xbox和PC游戲的測試。談到利用應(yīng)用程序的信息，他們是最優(yōu)秀的。游戲是難以想象的豐富，測試起來非常復(fù)雜。游戲中很多可測試的內(nèi)容都是隱藏的（因為讓那些玩家找尋可以交換的物品正是游戲的樂趣之一）o如果GTO的測試人員所做的僅僅是玩游戲，那么他們找到的問題不會比最終用戶更多。為了能做得更好，他們與游戲的開發(fā)人員合作創(chuàng)建了一些信息控制板，這些控制板暴露了一些基本上可以算得上作弊的信息給測試人員。這樣，測試人員就能提前知道怪物會被投放在何處、物品被隱藏在哪里，他們可以看到墻的另一邊，可以控制敵方的某些行為。他們的作弊工具（即測試工具）基本上使他們成為游戲里的神，讓他們可以控制看到的信息以便更快更巧妙地測試。這個例子給有測試人員都上了一課。
來自測試的信息意味著你必須關(guān)注在測試時所做的一切，并使用獲得的信息來影響今后的測試。你是否知道你的測試是如何與需求結(jié)合的，知道何時某一特定需求已經(jīng)得到足夠的測試？你是否使用代碼覆蓋率來影響未來的測試？你知道當(dāng)代碼更新或缺陷修復(fù)時那些測試會受到影響，還是知識重新運行所有的測試？理解測試進(jìn)行到什么程度并隨著測試調(diào)整測試策略，這是測試成熟的標(biāo)志。
我以前曾在微軟的Visual Studio的一個小組工作過，我們大量使用代碼改動量（由于添加新特性或修復(fù)缺陷而改變的代碼）和代碼覆蓋來影響我們的測試。我們花了很大的力氣將代碼覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻(xiàn)，幫助他們測試改動過的或修改過的組件。最終的結(jié)果是在代碼確實被改動時，我們清楚地知道哪些測試會被影響而只重新運行那些測試。我們還知道每個新的測試用例是如何對總體的接口，特性和代碼覆蓋率產(chǎn)生作用的，從而指導(dǎo)我們的測試人員，讓團(tuán)隊中的每個人在他們所創(chuàng)建的所有測試用例基礎(chǔ)上，寫出更有意義的測試。
你用哪些信息來指導(dǎo)你的測試？你如何保證信息是可獲取的，以便在測試中隨時可以得到？你如何使得信息變得有用，以便它能以良好的方式影響你的測試？這些問題的答案將決定你在走下專家測試山峰時的前進(jìn)速度。
下山
到達(dá)測試山峰的頂峰的時候，你已經(jīng)成為一個十分能干的測試人員了，能力也許相當(dāng)于你組里所有同事能力的總和。無論你在做什么，請不要試圖做得比你的整個團(tuán)隊都好，不管你對此感覺有多好，或是你的老板對你遏得有多緊。一旦你走在下坡的路上，就不要再去爭取“找到最多缺陷的人”或是“找到最有意義缺陷的人”這樣的榮譽頭銜。反而我推薦你減少花在測試上的時間，而把創(chuàng)新作為你的首要任務(wù)。
在測試上創(chuàng)新指不急于向前，而是仔細(xì)觀察、洞察先機(jī)、找到瓶頸并改進(jìn)團(tuán)隊中所有其他人的工作方式。你的工作變?yōu)閹椭渌诉M(jìn)步。在微軟，我們有一個專門為此而設(shè)的正式職位——測試架構(gòu)師。不過，不要因為缺少一個很酷的頭銜而讓你沮喪。無論別人怎么稱呼你，當(dāng)你在“下坡的路上，你能做的最好的事就是盡量保證更多的人能成功地爬上山峰的另一側(cè)。
