參加ChinaTest大會期間，聽到的最多的3個問題就是：1.測試行業的前景;2.測試人員的職業規劃;3.KPI。對於第一個問題，我是充滿 信心的。現代的軟硬件系統複雜程度正在呈幾何速增長，越複雜的系統需要進行測試的強度就會越大，從近幾年測試從業人數的猛增就能看出來。在《駭客帝國》那 樣由人工智能統治人類的世界到來以前，測試仍然是大有可爲的。對於第三個問題，貌似不管是基層、中層還是高層，都會爲此頭疼，斷念最後的閃電演講中也說 道：暫時無法提供一個現成的方法，只能依照讓KPI成爲一個有很好導向的事物的原則行事。我也是現在還爲KPI苦惱的人之一，就不多說了。
關 於第二個問題，我想不管是剛入門的同學，從業幾年的測試工程師，還是大牛們，都需要面對並仔細思索。做測試的前途是什麼?如何做到卓越?也許是這個問題顯 得有些功利，也太發散，ChinaTest大會並沒有專門將其作爲一個議題。可是從目前的整個行業的人員結構來說，新人佔了絕大多數，遠方有一盞明燈就會 顯得很重要。在思考這個問題時，我想到了前一段讀的《探索式軟件測試》一書的作者 James Whittaker對這個問題做出的回答。他把測試職業發展的道路比喻爲爬山，用很好的實例講述了各個階段我們應該做什麼。我在讀閱讀過程中產生了強烈的 共鳴。現在我把這篇文章找了過來，貼給大家，希望能夠有所幫助。(如果有違反版權的地方，請通知我，我會及時刪除)。特別值得一提的是，Jame測試人員 發展的一個階段叫做“下山”，與參會的同行交流時，很多人已經把這個觀念***到骨子裏了，他們已經走在了“下山”的路上。測試在國內發展多年，我們測試界 也已經有了很多牛人，這是非常讓人欣慰的事情，沒準未來的十年會有Jame Bach這樣的大師和James Whittaker這樣的準大師出現，讓我們一起見證這個過程吧。
--------------------------------分割線------------------------------------------------------------
經營成功的測試職業生涯
(James A. Whittaker)
你是如何開始做測試工作的?
1989年，我在田納西大學讀研究生的時候，完成了從軟件開發人員到軟件測試人員的轉型。而這一轉型並非出於我自己的選擇。我命運的改變發生在一個早晨，我的教授質問我爲什麼缺席那麼多開發會議。我解釋說因爲會議被安排在星期六早上，很不方便。
而怍爲一個生平第一次離開家的新入校的研究生，這個時間段有些麻煩。十分有意思的是，等待我的懲罰並不是一紙解聘通知書，而是被判罰爲該小組的唯一一個測試人員，且不能與開發團隊有任何交流。
對 於我的職業生涯來說，這是一個意義多麼重大的決定啊!正是這個決定最終成就了幾十篇關於測試的論文，構建了多得連我自己也記不清的各種工具，出版了五本 書，帶來了無盡的快樂工作時間。測試一直就是我擁有的那份具有創造性和技術挑戰性的快樂職業。不過，並不是所有人都喜歡這樣。可以說我最早接觸測試是在攻 讀研究生期問，不可否認，那時的高強度學習和工作確實讓我受益匪淺。另外，我認爲從初學者階段到專家階段之間存在着一個“測試的山峯”，人們需要通過一系 列個人輔導、獲取信息和接受常規指導來翻越山峯。成爲一個測試初學者是很容易的，成爲職業的測試人員也並不艱難。本章的重點正是討論如何翻越那座位於職業 測試人員和測試專家之間的山峯。
回到未來
在軟件測試領域，時間似乎已經停滯了。我們在21世紀做事的方法與上個世紀幾乎完全 相同。Bill Hetzel在1972年出版的測試知識叢書至今仍然相當有價值。而我自己所寫，於2002年首次出版的How to Break Software(如何攻破軟件)系列，到今天仍被作爲實用軟件測試技術主要資源的代名詞。
確實，如果我們可以把20世紀70年代的測試人員轉換時空用在今日，我猜想他們的的技巧足夠應付現代軟件的測試。當然，他們需要學習網絡和各種網絡協議，但是他們擁有的實際測試技術將能得到很好的應用。如果從20世紀90年代找一個測試人員，則不幾乎不需要任何訓練。
對 於開發人員來說，卻不是這樣，他們所掌握的那些上世紀的技巧幾乎已經完全過 時。讓一個有一段時間不寫代碼的人重新開始編程，看看會有什麼樣的反應。讓我感到很不安的是，我們可以從馬路上直接僱用人手，而僱來的這些人從第一天起就 能夠測試，就能夠有收穫。事情真的有那麼簡單嗎?或者是我們的期望值只有那麼低?讓我更加不安的是，我們沒有任何可預測的方式將合適的測試人才從勝任工作 狀態訓練爲測試專。測試真的就那麼困難嗎?#p#分頁標題#e#
這又是那個山峯了。門檻很低，但通往精通的道路卻很艱難。
在 通往測試山峯的入口，我們倚仗的是這樣一個事實：測試的很多方面都很容易掌握。大多數人都可以學得有模有樣。甚至只要將一點點常識應用於輸入的選擇,就可 以，我出缺陷。這個層次的測試就如同在桶裏釣魚，簡單到足以讓任何人都認爲自，自己很聰明。然而過了入口以後，道路迅速陡峭起來，而測試知識變得越來越晦 澀難懂。我們發現有人擅長於此，我們稱這些人爲“有天賦的人”，並欣賞他們的本能。
難道一定要依靠本能麼?對於那些看起來不具備特長的人 們，是否存在着一條翻越山峯的途徑?是否可以以某種方法傳授測試技能以培養出更多的專家呢?爲認爲這座山峯是可以通行的，而這一章正是我關於應該如何走這 條路的筆記，你可以在自己的職業生涯中加以應用。這並不是一份食譜配方，一份職業生涯烹調書。不過你可以做一些事情來加速你的職業成長。但是，正如你可能 已經猜到的，真正是說來容易，做起來難。
上山
測試職業的早期階段主要是爲征服測試山峯的漫長攀登做準備。我所能給出的最好的 建議是從兩個方面來思考問題。對於你參與的每一個項目，都有兩部分(不一定相等)的任務。第一部分的任務是保證當前的測試項目獲得成功。而第二部分的任務 是學習你應該做些什麼以便使下一個測試項目更加容易。我把它稱爲“測試今天的項目，準備明天的項目”。如果你做每一個項目把它都分割成爲上述的兩半，那麼 幾乎可以保證你能持續獲得進步。這樣，你就可以隨着每一個參與的項目逐漸成長爲更優秀的測試人員。
現在就讓我們來關注第二部分的任務------爲下一個項目做準備。我們需要注意三個概念：重複、技術和漏洞。
重複
做 任何一件事，絕不要重複兩次而不意識到或質疑這其實是個問題。我希望所有年輕的測試人員都牢記這一點。我見過很多初學者，他們在單調的任務上浪費了太多的 時間，比如，設置測試機器，配置測試環境，在實驗室裏安裝待測試的應用程序，選擇一個產品版本來測試-這些任務列表可以變得很長，最後你會發現真正花在測 試軟件上的時間少得可憐。
這是許多新手常犯的錯誤。他們沒能看到他們日復一日所做的工作的重複本質，兒當他們意識到這種重複時，幾個小時已 經過去了，而在這幾個小時內他們沒有做任何實際的測試工作。關注這些重複勞動，並且留意由此造成的真正的軟件測試工作時間的流逝。爲了能翻過測試的山峯， 必須做一個測試人員應該做的工作，而不是實驗室管理員或者測試機管理員的工作。
測試自動化是解決重複勞動的方案，也是本章稍後的主題。
技術
測 試人員常常會對軟件失效進行分析。分析缺陷時，我們從開發人員的失敗中學習如何編寫可靠的代碼。我們也分析那些被我們忽略的缺陷。在應用程序上市以後，客 戶就會開始報告缺陷，我們將要面對處理一大堆失效的情形並尋找其中的重要缺陷。用戶報告的每一個缺陷都說明我們的流程用問題，我們的測試知識還不夠完善。
但是分析我們的成功也同樣重要，兒許多新入職的測試人員卻沒能利用這個唾手可得的資源。我們在測試中找到的每一個缺陷都說明我們的的測試流程正在有效工作，都是一次成功。我們需要緊緊抓住這種絕好的機會，只有這樣才能使成功不斷的重複下去。
運 動隊常常這樣做，他們會觀看比賽錄像，並分析每一個動作爲什麼奏效或者爲什麼不奏效。我清楚地記得一個小故事，我的一個朋友拍下了我兒子踢足球的一些照 片。其中一張照片記錄了她踢球的瞬間，那個球超過對方守門員成功進球了。當我把它給我兒子看時，我之處他站立的那條腿的姿勢非常完美，他踢球的腳尖緊繃且 出球點在鞋帶間恰到好處的位置上。他盯着那張照片很長時間，從那以後他很少用不正確的姿勢踢球。他那次得分可能只是碰巧做對了，但從此以後他有意識的運用 這些技術使之接近完美。
現在回到新手測試人員的課程上來。我們每一個人都會有得意的時刻。我們找到重要的漏洞或發現優先級很高的缺陷，併爲 此雀躍不已。不過先花點時間考慮一下整體狀況。我們使用什麼技術找到了那個缺陷?我們是否可以創建一種方法來找到更多這類缺陷?我們是否可以記住…些實際 的測試經驗並不斷地加以應用來幫助提高我們的工作效率?軟件的哪些症狀可以提示我們它具有缺陷?我們將來能否從那些症狀中得到更多的警示?換句話說，這不 僅僅是一個缺陷或是一次成功，這個缺陷教會了我們什麼，是否使得我們將來成爲更好的測試人員正如我兒子的進球一樣，儘管第一個缺陷是偶然間發現的，但它不 代表其餘的成功都是偶然。理解我們成功的原因很重要，只有這樣做，成功才能被複制。對於測試人員來說，這種保證成功的原因就是一系列的測試技術、建議和工 具，它們可以提高我們在未來項目中的工作效率。#p#分頁標題#e#
漏洞
測試人員最終都會變得很擅長尋找缺陷，但是要翻過測試的高峯，我們必須更快並且更有效率：高速低阻。換句話說，我們必須擁有一種本身不含缺陷的缺陷查找技術!
我喜歡這樣來考慮問題：測試人員檢視自己的工作時也需要發揮那種尋找缺陷的能力。我們必須使用和尋找產品缺陷一樣的流程來尋找我們自己的測試流程，測試過程中的缺陷。我的測試流程是不是有問題?這裏面是否有缺陷?這裏是否存在着妨礙我提高效率的障礙?
你必須一直尋找更好的方法。有意識地去確定那些限制能力、阻礙前進、減緩速度的東西。就像缺陷限制了軟件滿足用戶需求的能力一樣，是什麼限制了測試的能力?使用你擁有的測試能力來最優化自己的測試流程，這會幫助你在測試的山峯上快速攀登並增加你翻越山峯後成爲專家的機會。
測 試山峯的巔峯處是一個美好的地方。如果你成功地到了那裏，恭喜你.但這並不是最終日標。這表示你已經成爲一個傑出的測試人員。而此時的下坡路就是用你的洞 察力和專家知識來幫助周圍的人也成爲優秀的測試人員。自己一個人登頂是一回事，幫助其他人(那些能力不如你的人)登頂卻完全是另外一回事。
一 般來說，那些成功登上測試巔峯的人會成爲使用工具的大師。那些商業工具、開開源免費工具,和自己寫的工具(我個人最喜歡的工具)是極好地提高工作產出、增 加工作成效的方法。不過，工具只是實現該目標的一種方法，但在許多其他方面它反而是一種限制，因爲太多的人看不到工具的功能之外的東西。他們被限制在工具 能爲他們所做的事情中，沒能看到或理解對工具還有更多的需求。登頂需要真正掌握的是“信息”。因爲很多工具能處理信息，並使得信息的獲取更加容易，所以測 試人員變得過於依賴於他們的工具。但是信息本身以及如何利用這些信息纔是真正的成功關鍵。
熟練掌握信息，指理解有哪些信息，這些信息將如何影響測試，保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關注的。這裏我要談的是其中兩種：來自應用程序的信息和來自之前測試的信息。
來 自應用程序的信息包括需求、體系結構、代碼結構、源代碼……甚至是關於應用程序在執行時做了哪些事情的運行信息。在編寫和執行測試用例時，需要考慮這類信 息，但信息的多寡在很大程度上取決於測試人員的能力，這是一種能夠使測試更高效的能力。在測試中使用這類信息越多，測試就越偏向於工程而不是猜測。
在 微軟，我們有一個遊戲測試組織(Games Test Organization,GTO)，負責Xbox和PC遊戲的測試。談到利用應用程序的信息，他們是最優秀的。遊戲是難以想象的豐富，測試起來非常復 雜。遊戲中很多可測試的內容都是隱藏的(因爲讓那些玩家找尋可以交換的物品正是遊戲的樂趣之一)o如果GTO的測試人員所做的僅僅是玩遊戲，那麼他們找到 的問題不會比最終用戶更多。爲了能做得更好，他們與遊戲的開發人員合作創建了一些信息控制板，這些控制板暴露了一些基本上可以算得上作弊的信息給測試人 員。這樣，測試人員就能提前知道怪物會被投放在何處、物品被隱藏在哪裏，他們可以看到牆的另一邊，可以控制敵方的某些行爲。他們的作弊工具(即測試上具) 基本上使他們成爲遊戲裏的神，讓他們可以控制看到的信息以便更快更巧妙地測試。這個例予給有測試人員都上了一課。
來自測試的信息意味着你必 須關注在測試時所做的一切，並使用獲得的信息來影響今後的測試。你是否知道你的測試是如何與需求結合的，知道何時某一特定需求已經得到足夠的測試?你是否 使用代碼覆蓋率來影響未來的測試?你知道當代碼更新或缺陷修復時那些測試會受到影響，還是知識重新運行所有的測試?理解測試進行到什麼程度並隨着測試調整 測試策略，這是測試成熟的標誌。
我以前曾在微軟的Visual Studio的一個小組工作過，我們大量使用代碼改動量(由於添加新特性或修復缺陷而改變的代碼)和代碼覆蓋來影響我們的測試。我們花了很大的力氣將代碼 覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻，幫助他們測試改動過的或修改過的組件。最終的結果是在代碼確實被改動時，我們清 楚地知道哪些測試會被影響而只重新運行那些測試。我們還知道每個新的測試用例是如何對總體的接口，特性和代碼覆蓋率產生作用的，從而指導我們的測試人員， 讓團隊中的每個人在他們所創建的所有測試用例基礎上，寫出更有意義的測試。#p#分頁標題#e#
你用哪些信息來指導你的測試?你如何保證信息是可獲取的，以便在測試中隨時可以得到?你如何使得信息變得有用，以便它能以良好的方式影響你的測試?這些問題的答案將決定你在走下專家測試山峯時的前進速度。
下山
到 達測試山峯的頂峯的時候，你已經成爲一個十分能幹的測試人員了，能力也許相當於你組裏所有同事能力的總和。無論你在做什麼，請不要試圖做得比你的整個團隊 都好，不管你對此感覺有多好，或是你的老闆對你遏得有多緊。一旦你走在下坡的路上，就不要再去爭取“找到最多缺陷的人”或是“找到最有意義缺陷的人”這樣 的榮譽頭銜。反而我推薦你減少花在測試上的時間，而把創新作爲你的首要任務。
在測試上創新指不急於向前，而是仔細觀察、洞察先機、找到瓶頸 並改進團隊中所有其他人的工作方式。你的工作變爲幫助其他人進步。在微軟，我們有一個專門爲此而設的正式職位——測試架構師。不過，不要因爲缺少一個很酷 的頭銜而讓你沮喪。無論別人怎麼稱呼你，當你在“下坡的路上，你能做的最好的事就是儘量保證更多的人能成功地爬上山峯的另一側。