什麽是自動化測試？
首先理清自動化測試的概念，廣義上來講，自動化包括一切通過工具（程序）的方式來代替或輔助手工測試的行為都可以看做自動化，包括性能測試工具（loadrunner、jmeter）,或自己所寫的一段程序，用於生成1到100個測試數據。狹義上來講，通工具記錄或編寫腳本的方式模擬手工測試的過程，通過回放或運行腳本來執行測試用例，從而代替人工對系統的功能進行驗證。
當然，我們更普遍的認識把“自動化測試”看做“ 基於產品或項目UI層的自動化測試”。

分層的自動化測試
這個概念最近曝光度比較高，傳統的自動化測試更關註的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。

相信測試同學對上面的金字塔並不陌生，這不就是對產品開發不同階段所對應的測試麽！我們需要規範的來做單元測試同樣需要相應的單元測試框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，幾乎所有的主流語言，都會有其對應的單元測試框架。
集成、接口測試對於不少測試新手來說不太容易理解，單元測試關註代碼的實現邏輯，例如一個if 分支或一個for循環的實現；那麽集成、接口測試關註的一是個函數、類（方法）所提供的接口是否可靠。例如，我定義一個add()函數用於計算兩個參數的結果並返回，那麽我需要調用add()並傳參，並比較返回值是否兩個參數相加。當然，接口測試也可以是url的形式進行傳遞。例如，我們通過get方式向服務器發送請求，那麽我們發送的內容做為URL的一部分傳遞到服務器端。但比如 Web service 技術對外提供的一個公共接口，需要通過soapUI 等工具對其進行測試。
UI層的自動化測試，這個大家應該再熟悉不過了，大部分測試人員的大部分工作都是對UI層的功能進行測試。例如，我們不斷重復的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。UI層的自動化測試工具非常多，比較主流的是QTP，Robot Framework、watir、selenium 等。
為什麽要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。
既然UI層的自動化測試這麽勞民傷財，那我們只做單元測試與接口測試好了。NO! 因為不管什麽樣的產品，最終呈現給用戶的是UI層。所以，測試人員應該更多的精力放在UI層。那麽也正是因為測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們“部分解放”重復的勞動。
在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的運行失敗，那麽就需要對自動化腳本進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都運行成功的自動化測試用例是沒有價值。
至於在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google 測試之道》一書，對於google產品，70%的投入為單元測試，20%為集成、接口測試，10% 為UI層的自動化測試。


我為什麽要做自動化測試？

根據51testing的《中國軟件測試從業人員調查報告》，手工測試占到的89% ，相對開發來說，測試的門檻底，薪資普遍較底，所要求的知識面雖然有一定廣度，但缺乏深度。這是測試的普遍現狀。
正因為手功測試人門檻不高，使大量的畢業生，甚至是非專業人員湧入這個行業。從而增加了這個行業的激烈競爭。對於工作幾年扔處於手工測試的人員來說都會有強列的危機感。由於工作的技術含量不高，薪資的漲幅遇到瓶頸，另一方面受到新進入者的威脅，同樣的工作公司花5K招來的人就可以做，那麽就不會花8K 的招。
好吧，這個問題不應該出現討論技術的話題中，但他的確是大多測試人員不得不面對的一個問題。所以，從測試人員自身的發展來說，我其實非常需要通過自動化技術來增加自己有競爭力。當然，做到一定年限測試人員會選擇轉管理或其它崗位，這又是另一個話題了。
從測試行業的發展來說，國內產品由於產品特點，世界級的產品不多，技術含量相對不高，質量要求相對要求不高，外包國外項目，測試人力成本低廉，所以需要大量的手工測試人員。
所以，在不遠的未來，我認為純的工手測試人員的需求是遞減，公司更需要更高技術能力的測試。質量需要測試，測試行為永遠不會消失，但純的手工測試人員是否消失是有可能的。
好吧，你可以說測試多朝陽的行業，我純屬在危言聳聽。不管未來如何，我們都需要提升自身的技能對吧！

什麽項目適合做自動化測試？

假如你已經決定要學習自動化測試了，如何學習是要面臨的下一個問題？這個問題以被測試產品為出發點進行分析，假如你所學的技術不能得到應用（驗證），將會使你的學習過程寸步難行。
首先考考慮產品是否適合做自動化測試。這方法比較普遍的共識是從三個方面進行權衡。

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
或者你可以考慮整個技術團隊主流用什麽語言，然後選擇相應的語言。

自動化測試基礎知識