做測試好幾年了，真正學習和實踐自動化測試一年，自我感覺這一個年中收穫許多。
我們更普遍的認識把“自動化測試”看做“ 基於產品或專案UI層的自動化測試”。
UI層的自動化測試，這個大家應該再熟悉不過了，大部分測試人員的大部分工作都是對UI層的功能進行測試。
例如，我們不斷重複的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重複的勞動。UI層的自動化測試工具非常多，比較主流的是QTP，Robot Framework、watir、selenium 等。
為什麼要畫成一個金字塔形，則不是長方形 或倒三角形呢？這是為了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與介面測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。
如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與介面測試階段進行。
既然UI層的自動化測試這麼勞民傷財，那我們只做單元測試與介面測試好了。NO! 因為不管什麼樣的產品，最終呈現給使用者的是UI層。
所以，測試人員應該更多的精力放在UI層。那麼也正是因為測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們“部分解放”重複的勞動。
在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的執行失敗，那麼就需要對自動化指令碼進行維護；如何控制失敗，降低維護成本對自動化的成敗至關重要。反過來講，一份永遠都執行成功的自動化測試用例是沒有價值。
什麼專案適合做自動化測試？
假如你已經決定要學習自動化測試了，如何學習是要面臨的下一個問題？首先考慮產品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。
1、軟體需求變動不頻繁測試指令碼的穩定性決定了自動化測試的維護成本。如果軟體需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試指令碼，而指令碼的維護本身就是一個程式碼開發的過程，需要修改、除錯，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。
專案中的某些模組相對穩定，而某些模組需求變動性很大。我們便可對相對穩定的模組進行自動化測試，而變動較大的仍是用手工測試。
2、專案週期較長由於自動化測試需求的確定、自動化測試框架的設計、測試指令碼的編寫與除錯均需要相當長的時間來完成。這樣的過程本身就是一個測試軟體的開發過程，需要較長的時間來完成。如果專案的週期比較短，沒有足夠的時間去支援這樣一個過程，那麼自動化測試便成為笑談。
3、自動化測試指令碼可重複使用自動化測試指令碼的重複使用要從三個方面來考量，一方面所測試的專案之間是否很大的差異性（如C/S系統和B/S系統的差異）；所選擇的測試工具是否適應這種差異；最後，測試人員是否有能力開發出適應這種差異的自動化測試框架。
選擇什麼工具進行自動化測試
假如你已經確認了XX 專案適合做自動化測試，那麼接下來你要做的就是選測試工具了。
首先要先確認你所測試的產品是桌面程式（C/S）還是web應用（B/S）。
桌面程式的工具有：QTP、 AutoRunner
web應用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium
由於B/S架構的諸多優勢，早幾年前大量C/S架構的應用轉為B/S結構。從而也推動了web開發與測試技術的發展。假如，被測試有產品是C/S架構的，那麼推薦QTP ，QTP在UI自動化測試領域佔到了一半的試用率。所以，足以說明QTP在自動化領域強大，易用性等。學習主流的工具也可以使你獲得更多的機會。市面上關於QTP的書籍也非常豐富。當然，要想學好QTP ，你必須要掌握VBS指令碼語言。
如果，被測產品是B/S 結構，那麼推薦selenium ，為什麼不是QTP 或其它工具？因為selenium 對B/S應用支援很好，更重要的一點，它支援多語言的開發，真正的試用selenium ，你所要掌握的不僅僅是一個工具而已，你還需要學習一門語言。我為什麼要選擇selenium？還要學一門語言，這無疑增加了我的學習成本。增加成本的同時，也增加的你的競爭力，而且，在這個過程中你不單單只是學會了一個自動化工具而已，你完全可以使用所學的語言去做更多的事情。
好吧！假如你決定試用selenium 了之後，你又面臨了一個新的問題，選擇一門語言。selenium 是支援java、python、ruby、php、C#、JavaScript 。
從語言易學性來講，首選ruby ，python
從語言應用廣度來講，首選java、C#、php、
從語言相關測試技術成度（及 資料）來講：ruby ,python ,java
或者你可以考慮整個技術團隊主流用什麼語言，然後選擇相應的語言。
selenium 用前須知
OK！經過上的過程，我相信你一定做出的相應的選擇，如果你選擇的是selenium 工具，那麼接著往下閱讀。
selenium學習路線
配置你的測試環境，真對你所學習語言，來配置你相應的selenium 測試環境。selenium 好比定義的語義---“問好”，假如你使用的是中文，為了表術問好，你的寫法是“你好”，假如你使用的是英語，你的寫法是“hello”。所以，同樣有語義在不同的語言下會有不同的寫法（語法）。
接著你需要熟悉webdriver API ，API就是selenium 所定義一方法，用於定位，操作頁面上的各種元素。
先學習元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能強大語法稍微複雜，在這其間你可能還需要了解更多的前端知識。xml ,javascript 等。
定位元素的目的是為了操作元素，接就要學習各種元素有操作，輸入框，下拉框，按鈕點選，檔案上傳、下載，分頁，對話方塊，警告框...等等。
經過一段時間的學習，你可以遊刃有餘的模擬手工測試來操作頁面上的各種元素了。接著你需要做的就是把這些“用例”組織起來，統一來跑。
那麼你需要做的就是學習並使用單元測試框架，單元測試框架本身就解決了用例的組織與執行。
當你寫了一些“測試用例” 之後，你會發現用例中有大量重複的操作，能不能寫到一個單獨的檔案中，需要的時候呼叫這些操作？當然可以，運用你的程式設計能力來實現這一點將非常簡單。然後，你又發現每個用例中都有一些資料，這些資料也是一樣的，但如果變化了修改起來非常麻煩，你也可以把他寫到一個單獨的檔案中進行讀取。
接著你又遇到了新的疑問，我寫的指令碼（用例）都是流水式的，我怎麼知道用例執行失敗還是成功。那麼就需要在指令碼中加一些驗證與斷言。
接著你又有了更多的想法，單元測試框架的log太簡陋了，能不能生成一張漂亮的測試報告出來。我能不能定時的來跑這個指令碼。能不能把每一次跑指令碼的測試結果直接發到我的郵箱。能不能......
為解決這些問題，你不得不學習更多的程式設計技術，然後你的“測試結構”會功能越來越強大，越來越靈活。產生了一定的通用性和移植性。一個有模有樣的自動化測試框架誕生了。
假如，有一天你不再做UI的自動化測試了，你會發現你去做單元測試 或介面測試基本沒什麼難度。開發個測試工具之類的也不在話下。