1.3 從專家到高手
小艾成為軟件測試工程師加入項目團隊已有一段時間，參加的幾個開發項目給他帶來了一些實踐經驗。時常傾聽同事的經驗介紹，讓他有機會對自己所處的水平做出一個合理的判斷。隨著軟件測試基本理論及實踐經驗的積累，小艾感覺自己跟剛加入時已經有明顯的區別。這種區別體現在幾個方面，包括對組織結構的認識、對工作內容和工作方法的理解、對測試相關的專業技能的掌握等。軟件測試工程師是一個技術背景非常強的職位，因此，技術是這個職位的立足點。盡管沒有詳細實踐過不同的測試，但小艾已經對測試的來龍去脈有了比較系統的了解，對于測試的關鍵點有了清楚的認識。應該說，小艾逐漸從測試菜鳥成長為一名測試專家。
對于在技術上進一步修煉的方向，小艾依然有自己的疑惑。究竟達到什么樣的程度才算是脫離“菜鳥”頭銜而成為一名專家呢？專家是否就意味著技術上已經達到了頂峰？優秀的測試工程師應該有哪些標準？
帶著這些疑問，小艾又找到他的導師凱文。面對有著類似經歷的新人，凱文一直都是知無不言，言無不盡的。這種分享的氛圍，使軟件開發實驗室成為一個非常適合學習和交流的地方。
凱文的解釋從區分新手、專家和高手三個級別談起。
剛開始接觸一個新的領域時，對這個領域一無所知或者知之甚少，對于這個領域，我們就是新手。正如之前已經提及的，術業有專攻，同一個人，在一個領域是新手，并不妨礙他在另一個領域是專家。作為測試工程師新手，要成長為專家，需要對測試的相關專業技能進行系統的學習和實踐。在開發項目組里，測試團隊本身就包括多個角色，對于每種角色，從技能水平上也有新手和專家的區分。新手到專家的學習曲線主要包括學習測試和開發方法、測試計劃和測試設計、測試文檔的編寫、發現和解決問題的一般方法等。在從新手到專家的發展過程中，“準專家”可以在專家的指導下完成特定的測試任務，能發現和解決一些比較常見的問題。隨著經驗的積累，測試新手可以成長為測試專家。
軟件測試的關鍵考量點是軟件的質量，因此，對于軟件工程師而言，經驗積累是新手成長為專家的過程中不可缺少的環節。當測試新手對測試的相關技能都熟練掌握、經驗積累也達到一定程度之后，新手就基本上成長為測試專家。測試專家對相關的測試技能和工具都已經熟練地掌握，能夠以標準化的方式策劃并完成測試任務。專家的“專業”，主要體現在他對軟件質量的控制把握方面的專業。
而高手則是專家更進一步的發展方向。專家的特點表現在對流程的嚴格把握，通過一種控制力保證軟件的質量；而高手則比這走得更遠。有一些非常復雜的系統或復雜的應用場景，已經超出了正常流程的控制范圍。在這種條件下依然要保證系統能夠正常滿足需求，于是對測試人員提出了更高的要求。高手的價值就在這種超越一般情形的條件下體現出來了。總體而言，高手對于發現問題、解決問題，有更多超出一般步驟的靈感和直覺，這種靈感和直覺是建立在對系統的深入理解及高手本身強大的洞察力基礎上的。
如果說新手到專家的成長過程是一個學習“硬性技能”的過程，那么專家成長為高手則更在于“軟性技能”的修為。軟性技能的提高，歸根結底是思考能力和分析能力的提高。新手可以隨著經驗積累和技能學習成長為專家，然而，經驗的繼續積累只是專家成長為高手的其中一部分。專家到高手的修煉，重點在于思考的方法和技巧。
1.3.1 像外行一樣思考，像專家一樣實踐
如果拋開測試的具體技術和實現細節，只是關注測試的目的，那么測試的本質其實就是發現問題和解決問題的過程。在講述問題分析的方法時，我們介紹過自頂向下和自底向上的方法。作為對一般性問題的分析方法，這兩種方法都有助于問題的分析。但對于一些非常規性的問題，這種系統的方法卻不一定奏效，可能效率并不高。這時，需要有非常規的方法來應對。
如果讓完全沒有經驗的人員進行測試并發現問題（我們稱這個人為外行），遇到問題時，這個人可能有兩種應對情形，第一種情形是束手無策，不知發現問題和解決問題都該從何入手；第二種情形是，這個外行不受任何成規的約束，提出一些天馬行空的想法。因為沒有專業背景的限制，這些想法可能真的不著邊際，甚至擾亂了問題本身的解決，然而，這些不著邊際的想法有時卻能帶來令人意想不到的效果，或是從全新的角度發現了問題的本質，或是找到了不同的思路和方法。相對而言，一個普通的專家因為受到許多既有方式的限制，就不太可能得出這種天馬行空的點子了。外行以一種隨性的方式思考，這種方式往往會帶來意外的效果，因為隨性的思考方式不會被規則限制。
作為測試人員，在發現和解決問題時，外行的思考方式可以成為有效的切入點。好的切入點是一個不錯的開始，然而，真正的實踐還是必須以專家的嚴謹和慎重來驗證想法是否正確。像專家一樣實踐--我們倡導的還是一種小心求證的態度。軟件測試是一個非常嚴謹并且以事實說話的過程，任何假設都必須通過測試實踐的檢驗。
對測試已經有深入了解的人，想做到像外行一樣思考，并非易事。測試專家往往下意識地對一個方法的技術可行性做判斷，這種下意識能夠高效地排除許多不可行的方式方法。但在某些時候，這種下意識卻阻礙了創造性靈感的萌生。很多有意義的想法會因為可行性的判斷而被扼殺在搖籃之中。像外行一樣思考--追求的是一種新的方法或者角度，僅僅考慮某個問題是否可能存在或者某種方法是否能解決問題，不考慮方法是否有理論依據，也避免過多地考慮可行性。
其實，可行性是基于以往的經驗做判斷，但是誰也不能認定，當前不可行的方法就永遠不可行。認為科學已經進步到了終點的想法早已被證明是荒謬的。遇到棘手的問題時，測試高手能夠跳出既有的條條框框，像一個外行一樣重新審視系統的整體。當然，我們并不認為測試高手是個外行，因為這種“不受約束”的審視其實是建立在對系統的全面深入的理解基礎上的，并不是一種純粹的盲目。在這種大膽假設的前提下，即使是高手，也必須小心地求證假設是否正確。求證過程離不開反復的實驗和驗證。
面對復雜系統的問題，這種“大膽假設，小心求證”的方法往往能產生神奇的效用。以下是一個真實的例子，在對一個多節點的集群電子商務進行系統測試時，發現在高并發訪問的條件下，從應用服務器到數據庫的連接數驟然增加，并很快到達連接數的上限。數據庫連接數一旦到達上限并且沒有及時釋放時，新的請求會因為無法獲取連接而被阻塞，在表面上看，系統的性能會表現得非常糟糕。
面對這樣的問題，一般的問題分析方法可能難以在短時間內找到原因。這時候需要在現有的條件下大膽假設可能有問題的地方。“現有的條件”指的是一些表面的系統運作數據，如應用服務器日志、數據庫鎖信息、數據連接池信息等。根據這些信息，發現有種特定的操作一旦出現，系統的數據庫連接請求會急劇增加。通常情況下，因為存在系統級別的緩存，重復的訪問一般不會給系統帶來重新計算的負擔。然而，問題的表現是，反復的訪問似乎對系統產生了明顯的性能影響。
這種情況下可以大膽假設系統的緩存設置可能有問題，雖然按照正常流程安裝和配置的系統不可能存在緩存的問題。基于這個假設，接著要做的是檢查所有和緩存相關的配置內容。檢查發現，價格模塊的對象緩存并沒有設置，而這個設置正常情況下應該是激活的。如果沒有價格的對象緩存，那么相同的價格對象都不會被緩存在內存中，而是每次獲取的時候都重新計算生成。
在電子商務系統中，價格信息是使用非常頻繁的一類信息，因為缺少對象緩存，實際應用就有可能出現不斷地查找數據庫計算價格的情形，這會導致數據庫連接被大量占用。更改設置后重新測試，驗證發現使用了價格的對象緩存，數據庫的連接數不再出現被異常地大量占用的情況，問題得到解決。發現了對象緩存的設置錯誤，進一步追尋原因，發現原來是系統安裝的過程中配置腳本運行出現了異常，從而導致緩存的創建步驟并沒有被執行。如此一來，整個問題的來龍去脈就非常清晰了。解決問題以后，這種看似很復雜的問題，其原因也許很簡單。解決這個性能問題的關鍵在于假設問題的原因是緩存的設置有問題；而驗證恰好證實了假設的正確。如果僅僅使用一般的問題分析方法來尋找問題的原因，這種“意外”的問題往往是非常棘手的。
“像外行一樣思考，像專家一樣實踐”的方法是一位著名的計算機學者談及學術研究時提出的一種方法論。軟件測試雖然和學術研究有著明顯的差異，但是測試過程中需要發現和解決問題的時候，這種方法論很有借鑒意義。在軟件測試中，對待問題同樣需要開闊的視野和嚴謹的求證態度。我們認為，測試專家能夠在測試中發現絕大部分的問題并能夠使用合理的分析方法找到解決絕大部分缺陷的方案，而高手則能夠更進一步，最棘手的問題也能夠有效解決。
能否以這種收放自如的思維方式應對測試中遇到問題，是高手和專家的一個重要分野。在大部分情況下，這種分野是不明顯的，因為最困難的問題只會占所有問題的很小一部分，而這種問題在測試中不會很容易地暴露。然而這種問題被發現了之后，高手和專家在造詣上的差別就會顯現出來。
1.3.2 工欲善其事必先利其器
對于測試工程師而言，雖然發現和解決問題才是體現其價值的事情，然而測試工程師不得不花大部分時間執行測試。
從圖1-4中可以發現，對于一個普通的測試工程師來說，執行測試消耗了很大一部分時間，而常規項目 的任務把可用時間的90%都占用了，剩余可以用于提高生產效率的資源變得非常緊缺。而提高生產效率從長遠來說又能降低常規項目任務占用時間的比例。
在一個水平較高的開發團隊中，設計和代碼實現的水平通常是比較高的。在這種團隊中，測試的注意力會更多地放在驗證和問題解決方面。驗證是通過執行測試的方式完成的，真正運行一個場景，查看系統的反饋是否和預期吻合。對于結構復雜的系統和對軟件質量要求很高的軟件，需要執行多種類型的測試驗證各種場景，而每種測試都可能包括大量的測試用例。例如，在電子商務系統一個新版本的開發過程中，功能測試的用例可能多達成千上萬，涵蓋各種正常或異常的分支場景。對于如此大量的測試用例，執行的工作量之大可想而知。
如果測試工程師的絕大部分時間都被執行所占據，那么可以用來分析解決問題的時間就相對很有限了。開發水平提高不能減小測試的工作量，那么，測試工程師通過什么方法更有效地完成測試任務呢？答案是提高測試效率。對于同一個測試人員，效率的提高有兩種外在的表現，第一種方式是使用相同時間完成更多的測試用例執行；第二種方式是對于同一個或同一組測試用例，耗費的時間減少了。
相對于測試新手對測試執行的生疏，測試專家以熟練的執行更快地完成測試任務。提高技能的熟練程度，能夠提高效率。通常來說，執行一個測試，需要完成一系列操作步驟，首先需要安裝測試環境、準備測試數據，如果是使用自動化操作的方式執行的測試，則需要準備測試腳本或代碼；接著需要開啟監控測試環境的工具，然后才能開始執行測試用例；執行完畢后，需要收集必要的數據和結果，確認測試是否通過。這一系列步驟的執行效率可以隨著熟練的程度得到提高。
如果要通過提高熟練程度來提升測試的執行效率，提升的空間是有限的。對于測試高手而言，進一步提高效率，考慮的方向應該是減少對測試的人工干預，讓測試自動完成。在工業化的測試條件下，自動化水平的高低，在很大程度上衡量了一個測試團隊的水平。測試自動化指的是通過編寫程序完成執行測試用例的所有或部分步驟。自動化的優勢是減少人工的干預，把團隊中最寶貴的資源--人釋放出來；同時，由于自動化是使用程序的方式實現的，因此可以保證每次執行自動化測試程序的條件是一致的，避免了人為因素引起的不一致，影響某些缺陷的可重現性。測試自動化把許多煩瑣的步驟交給程序來完成，測試的執行對人的依賴也得到減弱，從這個角度來說，自動化可以提高測試的質量。
自動化測試工具是測試工程師提高效率的利器。對于不同的測試方法，已經有一批針對性很強的自動化工具可供使用。針對基于Java的單元測試，JUnit是最常用的測試框架。通過對JUnit進行擴展，還可以實現單元測試調度和自動結果收集等功能。功能測試的測試目標是端對端（End-to-End）的用例場景，在測試基于瀏覽器的網絡應用程序時，常用的自動測試工具有IBM Rational Functional Tester（RFT）、Selenium、JMeter等。對于胖客戶端的應用程序功能測試，IBM Rational Functional Tester也可以提供不錯的支持。系統測試的過程需要模擬更復雜的用例場景，如不同行為的虛擬用戶并發地訪問用戶界面，這種測試用例通常來說只能使用自動化測試工具來執行。
有一類性能測試工具使用結構化代碼來模擬并發的用戶行為。自動化測試工具構造測試代碼的一種常用方法是錄制操作步驟。當人工對界面進行操作時，錄制程序可以完整地記錄整個操作過程，錄制完成后，測試程序員再對錄制的內容進行標準化修改，修改后的測試代碼就能夠滿足標準的測試場景要求。具備這種功能的系統測試工具很多，如IBM Rational Performance Tester、Borland Silk Performer、Load Runner等。
對于要記錄測試頁面響應時間的性能測試用例，可以使用Firebug、IBM Page Detailer等工具。對于安裝測試，系統安裝的過程可以使用安裝測試腳本來自動完成，測試腳本同時可以驗證系統安裝的每個步驟結果是否正確。類似地，構建測試也有自動化構建測試工具完成構建的流程。作為一個成熟的團隊，為了適應產品的特點，在使用一款自動化測試工具前，往往還得對工具進行定制，使工具更符合特定的測試需求。在測試創新的章節，我們還會講述關于自動化工具定制開發的內容。
然而，自動化也會給團隊帶來額外的負擔。如果要追求全局的自動化，那么一個完善的自動化測試框架必不可少，但是搭建自動化框架本身就是一個規模不小的工程。軟件開發和測試方式隨著技術的革新不斷變化，這種變化有可能導致原有的自動化框架不再適用。另外，即使有完善的自動化測試框架，測試人員依然得完成基于自動化框架開發的測試用例，測試完成后，也還要對這些自動化執行資源進行維護。如果自動化框架實現的是部分自動化，那么執行過程中有些步驟還是需要人的參與，并不能完全脫離人工干預。可以說，沒有經過深思熟慮而倉促上馬的自動化執行方案，也許不但不能提高執行效率，反而會增加測試團隊的負擔。
脫離人工干預的程序控制在執行效率上的優越性很明顯，因此在允許的條件下，一個測試團隊應該有逐步實現測試自動化的目標和路線圖。在初期，可以僅僅使用有針對性的自動化測試工具輔助測試，而隨著自動化測試經驗的積累，可以基于這些工具開發集成化的自動化測試框架。在實現提高效率目的的同時，也降低了“過度自動化”的風險。
小艾所在的測試團隊，正是沿著這種方式逐步完成了手工測試到自動化測試的轉變。當然，由于許多測試有著明確的需求，手工測試和人工干預不可能被自動化完全取代；而不同的測試種類，使用的自動化策略也可能完全不一樣。
提高效率的方式多種多樣，提高熟練程度和測試自動化是比較常見的兩種方式。除了完成測試任務，提高測試的效率和質量，同樣是測試工程師的一個重要任務。測試高手區別于一般測試人員的關鍵在于測試高手更善于運用創新，在實踐中不斷提高。
1.3.3 從拿來主義到創新
小艾所在的電子商務系統，從技術和功能上而言，幾年來的變化非常明顯。早期的版本采用標準的Java EE技術，業務邏輯是通過命令模式實現的。隨后，基于服務的架構開始流行，服務的靈活性的確有利于提高系統的適應能力，于是，系統的實現開始從基于命令轉變為基于服務。系統的前端的早期實現主要是基于JSP的標準界面，而隨著Web 2.0的興起，許多新的前端元素逐漸被加入到前端界面中，如Ajax，Remote Widget等技術的使用，使系統的前端可擴展性和可操作性得到很大的提升。早期的電子商務系統實現的功能比較單一，而隨著社交化應用的流行，越來越多的社交元素被集成到電子商務系統中，系統的復雜性進一步提高。除了新技術的引入，電子商務系統的核心--中間件的版本同時也在不斷更新，在這個過程中，計算機的硬件配置的發展也相當迅速。一個系統似乎從來就沒有最終版本。
電子商務領域僅僅是個縮影，整個信息技術領域都是快速發展的，變化之快可用日新月異來形容。一名技術專家，如果不能緊跟技術發展的步伐，那么最終的命運很可能是被技術所拋棄。新的技術常常是伴隨著新的業務模式的流行而產生的，除了緊跟技術，有前瞻性的技術專家還應該洞察業務模式的發展。
新技術的出現也對測試提出了新的要求。因為實現的框架變了，測試模型必須做出相應的調整，在新的框架下完成測試需求。前臺技術革新了，如果繼續使用原來的技術，測試的結果可能不再準確，因此有必要引入新的前臺測試技術。隨著中間件、系統硬件的升級，測試的基線和指標也必須重新構建。業務在變化，技術在更新，測試技術同樣需要創新。
創新不是空想，它是以對現有技術和業務的清晰理解為基礎的。對于測試工程師而言，一開始往往需要學習和借鑒現有的經驗，如測試的流程、使用的測試技術、分析問題的方法等。隨著學習和實踐的深入，在特定產品中，特定的需求會逐漸顯現。因為是特定的需求，技術上很可能沒有現成的解決方案，這種需求就會被作為創新的目標。有了明確的目標，就可以開始尋找新的解決辦法，尋找的過程就是一個創新的過程。