前言&摘要
工作中總難免遇到一些不想見到的問題，但是遇到問題總需要去解決。解決問題的時候我們不提倡一條路走到黑，但是也絕不鼓勵「朝三暮四」、「朝秦暮楚」等各種淺嘗輒止。就像我們在做自動化測試的過程中，有些問題是始終無法迴避的，如：測試工具缺陷、測試資料使用難以及開發人力投入較多等諸多妖魔鬼怪。我們若不去逐個鬥過，也不知道自己戰鬥力到底有多強，最終也無法取得真經、修成正果。
閱讀關鍵字
自動化測試qtp selenium 測試資料測試工具
擺一擺自動化測試中的問題
大約前幾天，一位同事為了selenium處理模態視窗問題而糾結，而她之前是常年與qtp為伍的，她悻悻地說：這破玩意，以前用qtp的時候根本就不會存在這個問題！我奸笑一聲，對她狠狠地說：既然qtp那麼好用，那你之前還不好好寫你的指令碼，現在領導覺得qtp在你的系統可能不適用了才開始推行selenium，你還抱怨……那你得怨恨到什麼時候呢？作為乙個習慣了我「叫獸」風格的同事，她對我給予的挖苦不以為意，嘿嘿一笑繼續忙她的了。當然，她最終搞定了這個問題，自然地，歡呼雀躍一下也是在所難免的。我後來跟她說：其實你之前只要多花一點時間把你的qtp開發質量提高乙個檔次，現在也不會有人逼著你花時間來解決這個問題，而且接下來前面還有什麼問題等著你誰也不知道；現在是花很多時間，以前也要花很多時間，什麼時候花都一樣，自動化測試在我們這裡絕不是應付了事，所以，我們始終都得面對開發投入這個現實！而且，早一點投入，產出效益也會更加明顯一些。
再往前一兩年的樣子，部門裡有個qtp技術仔同事私下裡和我**，他對qtp執行環境要求高和執行速度慢、物件經常莫名其妙不識別等等問題深惡痛絕。他問我：據說lr執行不是基於頁面的，你懂嗎？我說：略懂，lr是基於協議的，靠模擬客戶端請求去執行測試的。他立馬來了勁，興奮地說：那就是不受頁面物件變化的影響咯？如果這樣，你覺得我們如果用lr去寫指令碼做回歸測試會不會很爽？至少速度快，受環境影響非常小。我一身冷汗，心想別讓我又造了孽，誤導了別人吧，趕緊勸阻：千萬別，要是這樣，web頁面最基本的js控制項都被可以忽略了，測試結果根本不可信啊。看他將信將疑，我趕快找了幾份生產缺陷事件報表發給他看，後來他研究了很久，好歹總算把這個想法給否定了。同樣，我們可以看得出，無論技術是否過硬，測試工具本身的弱點是無法迴避的，但是既然被稱為工程師，我們始終要面對這些問題，並且必須要嘗試解決它們。否則，就算是換一種測試工具那又能如何，這世界上存在完美的東西麼？
該如何面對自動化測試的學習
其實稍微想一下我們就知道，自動化測試的學習和研究也是我們不得不面對的問題之一。《師說》有云：「人非生而知之者，孰能無惑？」所以我們在自動化測試學習或者實施的過程中也難免會遇到很多不可預知的問題，遇到問題的時候是該「求魚」還是該「求漁」，是該自力更生還是求助於人，是該谷歌還是谷歌，工具和技術應該學到什麼水平……這些都是應該事先弄清楚的。
平常閒逛的時候，經常在罈子裡面看到有人在那裡喊：「來個高手來教我qtp啊」，「廣州有自動化測試的高手嗎？帶帶我吧」——哦喲，拜託你們不要再賣萌了啦，人家會受不了的啦！在我看來這基本上都是不肯面對現實，不願意主動去學習的表現，到罈子裡只是找個傾訴的物件或者說精神的寄託而已。因為你真的不知道哪位菩薩心腸的大師會去主動找到你，給你傳道授業解惑。如果自己都沒有仔細的去動手嘗試，沒有去找到自己的困惑點在**，再高的高手也無法三兩句話能給你解釋清楚，你還真以為可以隨隨便便移植一下記憶麼？就像乙個虔誠的信徒在**求上帝：上帝啊，求求你，讓我中大獎吧！上帝回答他：那你（***，語氣助詞）也得先買注彩票先！道理很簡單：若要得到別人幫助，必須先保證在求助於別人之前自己已經盡了最大的努力了；不願意一點點把基礎打牢的人是浮躁的人，若無神奇因緣，指望別人將他們的問題一掃而光基本是不可能的事情。
我熟悉的測試工具不多，但是也了解不少，我比較討厭比較這這那那的工具，在抵制工具至上論的同時，我也不介意反覆再三地宣揚我的觀點：我們是做測試的，但絕大多數不是做測試工具的測試的，所以沒必要為了工具的好壞去爭論；我們以我們的被測系統為核心，我們以滿足自己的測試需求為根本目標，一切工具都只是整個測試過程中的一些手段而已，沒有什麼事情是以手段為核心而對根本目標置之不理的。我們部門有位對web開源測試工具比較熟悉的同事，他自己出了一本關於selenium實踐經驗的書，據說口碑還不錯，只可惜他在封面上就開始痛批qtp的種種不是，我看了之後感覺五味雜陳，不知該以之為榮還是該為之傷心。之所以該傷心，並不單單是因為他對qtp工具本身的貶低，因為他這麼說恰恰說明我可能在qtp的使用上比他熟悉得多。我主要是對這種妄下結論，排斥性太強的看法與做法很不以為然，說難聽一點，簡直是死腦筋嘛，這不是我們學習自動化測試工具與方法所應有的態度。我覺得要想全面學習自動化測試，一定要拋開測試工具的門戶之見，否則很容易陷入偏執的僵局，真的會被一葉障目。
乙個人如果對自動化測試若只是初窺門徑或者尚未入門則罷了，若是要熟練掌握一種測試工具的使用，那就該從基本的功能到框架的搭建都能了然於胸。熟練之後，如果有精力的話，就可以去深入研究和分析自動化測試拋開形形色色的工具之後又該是什麼一種意識形態，有什麼規律和章法。若非如此，我們對自動化測試的認識始終停留在對一種測試工具的理解上，而不是對測試的理解上。這樣，你把qtp的錄製、引數化叫做你的測試框架，把selenium使用junit的框架叫做你的測試框架，把我們建設起來的自動化測試管理平台工具叫做你的測試框架。可惜對真正幫助組織我們的自動化測試開發、執行，優化我們的自動化測試開發、執行的一套方法沒有去摸索，或者沒有將之與我們的系統測試結合起來落地執行，更沒有去做方**上的提煉昇華與例項化的開發。如此這般，我們就錯過了很多凌駕於測試工具本身的，有價值的、有趣的一些東西，而得到這部分東西，哪怕只是其中的一部分，我們就會明白，只要是做測試，核心的東西還是操作描述、測試資料、預期結果那點東西；知道這一點，就會知道用什麼工具來做自動化，差別只是在手段上而已。真正精通自動化測試的人，其實並不見得他們對測試工具本身使用或者編碼的技術是最強的人，但他們至少是懂得如何把「測試」和「自動化」這兩個關鍵字有機結合的一些人；在他們看來，在自動化實施過程中，規劃和需求要比技術和工具本身重要得多。
可能有人會說：先莫唱高調，你覺得我們該如何學習和研究呢？我的回答是：很簡單，就是把自己實踐得到的經驗加上別人實踐得到的經驗揉合一下，其實總結起來有三點（當然如果你願意的話，你可以去分成十三點、二百五十小點去說）：
不停的實踐：使用一兩種工具在不同型別、不同架構、不同行業的系統上去實踐。真能用心學習和實踐，一年半載便足夠了，至少工具駕馭上應該不輸現在90%的人，但像qtp的使用，能夠堅持數年錄製、引數化而不改變的人，不在我們討論的範圍之內。我見到過有位仁兄，09年的時候還在在論壇詢問一些很簡單很基礎的qtp工具使用問題，10年就已經自己搞了一些很有技術含量的專題講座了，學習速度讓我很驚訝也很佩服。這都是他通過一點點摸索嘗試獲得的成果，相信將來更大的成就對他來說也不會很遠。
多聽多看：聽別人如何說，看別人如何做。除了要多於自己身邊的同事多學習溝通之外，平時抽空多到網上去看看別人的說法和做法，結合自己在實踐中的感受和困惑進行思考總結。拿句套話來說，這是乙個「去偽存真」的過程，面對海量的資訊，如果缺了有效的鑑別，很可能就會被別人的觀點所迷惑或者造成更多的困惑。其實無論作者觀點的對與錯、是否有價值並不在於他這篇文章本身，我們只有認真地讀了、想了、實踐了，有所斬獲了，才能不枉作者碼字的一番心血。
看書不如看幫助文件：無論是誰寫的書，寫的什麼書，書中所講述的觀點都是依照作者的知識、閱歷去陳述的。而最可悲的是有些作者著書的動機可能會不單純，或為名、或為利，而知識共享與傳承神馬的對他們來說都是次要的。這樣一來，書中可能會充斥著「絕對」、「一定」這類字眼，將一些不成熟甚至是錯誤的觀點灌輸給讀者。時過境遷，作者未必不知道當初自己錯了或者有疏漏，但是鮮有人肯出面勘誤澄清，所以說：讀書有風險，購買須謹慎。別的行業我不敢說，但是關於自動化測試，我見過這樣的工具說明書，好幾本，讀起來感覺就是花幾十塊錢僱了個蹩腳的翻譯，把英文的幫助文件給丟三落四的翻譯了一通。至於英文的著述如何，我就沒再研究了，總之學的過程中若想看參考說明書，我還是建議配上一本詞典，去看幫助文件吧。如果剛入門就想憑藉一本書變精通，那麼觀念裡面有些東西可能以後很難改變了，無論它是對的還是錯的。
例行總結
最後，我想說句話與大家共勉：不要盲目崇拜什麼權威、什麼技術專家，只要能夠勇於面對你本該面對的問題，並且努力解決它，很快你就是專家。當然，你這個專家與其他專家一樣，都是可以被很快超越的，所以也不要迷戀自己專家的頭銜；繼續虛心學習，方能立於不敗之地。這些都是很俗套、很簡單的道理，看得開，一切都是風輕雲談、海闊天空；看不開，則有可能走火入魔、害己害人！
武俠崇尚的是：天下武功，唯快不破！同樣，在自動化測試領域中，要想做高手，那麼你要快快地工作，快快地遇到問題，快快地解決問題，快快地進步吧；然後快快地被賞識，快快地漲薪公升職吧。
你不得不知道的六大自動化測試技巧
測試自動化有助於提高開發速度，同時減少成本和工作量。在本文中，將分享如何進行自動化測試，以幫助保持測試自動化活動在正確的軌道上，以及測試執行 設計和維護大型企業應用程式的關鍵技巧。每個自動化測試專案都有其自身的特定需求。正確的工具可以顯著減少測試時間並提高測試團隊的效率。錯誤的工具會引入不必要的複雜...
軟體測試崗技術面試，那些你不得不知的
在某種程度上來說，技術面試重要到能夠決定你是否被聘用。在技術崗位方面，在個人品德沒有問題的前提下，招聘公司對技術是最關心的。我現在並不能給你分析具體的面試題，因為與筆試題相比，面試題千變萬化，不同的公司有不同的技術方向，即使是在乙個公司內，技術面試題也會因為專案 崗位 面試官的不同而不同。下面我說一...
自動化測試的那些事兒
什麼是自動化？編寫軟體去測試其他軟體 編寫驅動被測試應用程式的測試指令碼以執行鍵盤 滑鼠動作和後台程序並驗證應用程式響應和行為。手工測試的侷限性 無法做到覆蓋所有 路徑 機械 重複，工作量大 許多與時序 死鎖 資源衝突 多執行緒等有關的錯誤，通過手工測試很難捕捉到 進行負載 效能測試，很難通過手工測...