在我們進行具體的自動化測試之前，我們需要進行一些準備活動
一.分析項目是否適合引入自動化測試
軟件需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低于利用其節省的測試成本，那么自動化測試便是失敗的。
項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。
項目周期較長
由于自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成。這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么自動化測試便成為笑談。
自動化測試腳本可重復使用
自動化測試腳本的重復使用要從三個方面來考量，一方面所測試的項目之間是否很大的差異性（如C/S系統和B/S系統的差異）；所選擇的測試工具是否適應這種差異；最后，測試人員是否有能力開發出適應這種差異的自動化測試框架。
二 .了解自動化在項目各個階段比例分布
為什么要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低于所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。
在《google 測試之道》一書，對于google產品，70%的投入為單元測試，20%為集成、接口測試，10% 為UI層的自動化測試。
三. 選擇什么工具進行自動化測試
假如你已經確認了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
或者你可以考慮整個技術團隊主流用什么語言，然后選擇相應的語言。
考慮到我有java語言的開發基礎的話，今后相關文章可能會首先以java語言來描述
