一、首先，需要分析當前項目是否適合自動化測試：
測試需求明確，不會頻繁變動
迴歸測試爲主的項目
軟件系統界面穩定，變動少
每次迭代需要在多平臺（或多OS、多Browser）上運行重複的case。
軟件維護支持週期長
手工測試無法模擬的場景。如壓力測試、併發測試等
具備基礎的自動化測試平臺
二、以下是曾經參與過的一個項目的自動化測試框架
實現了自動更新代碼、編譯、打包、部署、重啓服務、定時執行腳本任務，日誌報告輸出，自動發送郵件通知。
在自動化開始前需要確定預期，需要達到怎樣的目的。而不是抽象的減少人力成本，儘可能多地發現Bug或節省時間等等。自動化測試應該是發現那些可以被工具化自動化的重複性活動而後實現的，並非100%的Case都可以自動化，測試人員的經驗，邏輯判斷和探索性的測試方法都不能被有效自動化。
在一般的項目中，需要保證被測版本的基本質量，可以進行大量的功能測試和壓力測試。
（1）發現環境層級的缺陷。
項目系統測試階段發現的很多缺陷，都會聽到開發人員自測時沒問題的，甚至在本地測試時無此缺陷 ，直接將Bug打回，標註爲無法重現。這就是環境問題了，曾經遇到過一個一級菜單點選時導致子菜單錯亂的問題（與其他一級菜單的子菜單混淆顯示了）。經排查才知是，開發將菜單的座標值寫死了，導致換環境後無法正常識別菜單信息。這是典型的環境問題，只有通過複測才能發現。另一種就是開發自測時是在本地，而自己機器上利用管理員權限部署了一些安裝包或工具，自測時也無法清楚地知道被測版本是否依賴了這些包或工具。而部署到測試環境時才發現一些問題。類似於以上的問題如果及時構建了被測版本，且自動執行了基本功能，會在正式測試前發現這些環境問題，而不是等到系統測試階段纔去排查 。
（2）儘快發現集成階段的錯誤。
集成測試階段的缺陷若未暴露出或不影響到正常流程，無法確定錯誤是哪個開發人員負責的模塊，同時開發人員因時間問題，不能測試出大部分的潛在的集成缺陷 ，導致部署到系統測試階段暴露出的錯誤，無疑更增加了開發測試的時間。如果每次構建都可以自動化執行到基本功能 ，使開發能及時地發現集成錯誤 ，同時也可彌補單元測試的不足，快速提供系統級的測試反饋。