前言：
● 自動化測試不只是測試的自動化，應當是流程的自動化
● 自動化測試是一種軟件開發交付過程
● 自動化測試成敗在于自動化項目的質量與可維護性
自動化測試對于在黑盒與手工測試工作的大部分人來說，都會比較向往，因為自動化測試很有成就感； 對于直接在自動化測試行業工作的新人來說，會比較迷茫，因為這個較為新生的領域不像開發行業那么成熟；
其實，自動化測試和手工測試一樣，是一種測試方法，只是你智力與思維轉化的結果； 關鍵看你是否適合，心態是否正確。
同時，它的發展前景不亞于任何開發行業，你既可以接觸專業的自動化測試技術，又可以掌握相關的開發技術，并且可以接觸專業的測試專家。
自動化測試的范圍
一般我們很難直接限定自動化測試的內容，但以我的理解，先從不適合的方面排除之，你可以試著看一下。
在混亂的項目流程中，不適合推廣和試行自動化測試。 自動化測試也是一種項目交付過程。
如果被測項目流程不明確，過程責任不清，沒有準確公平的數據度量，
● 開展了自動化測試效果難于評估，做也白搭
● 沒有清晰的交付測試流程，自動化測試經常的變更成本，以及沒有開發支撐的自動化只能從表面下手，導致維護成本過高。
● 自動化測試能夠將流程工具化，這點體現的效果易于得到整體研發的認可與支撐，效果也是極顯著的。
打個比方，本來是在公路上（不完善的流程）運行汽車，你非要改進效率跑火車（自動化），適得其反。
自動化測試的關鍵點之一，在于流程，流程在于人去完善，去改進。然而流程在年少時人的性格，在年長時也改變不了太多，我們自動化要符合流程去做，需要完善的我們去補充完善。而完善流程，不是一味的提要求，而是合理的慣力的要求，更多的時候應該建設平臺來支撐流程，讓人做到最簡化。
一旦流程的完善，自動化隨之正規化，可量化的自動化需求，項目成員明確自動化的成本與成果，以及相關自動化約束（例如某個自動化接口實現）。 自動化的成功自然隨之而然。
所以，自動化測試不只是測試的自動化，而應當是整個流程的一種自動化與完善。
在實施自動化的時候，處理流程相關，最好遵尋：完成相關自動化項目顯示效果 -> 要求改進流程 -> 實現流程過程的自動化
這樣帶來的項目壓力較小，容易獲得所需的資源。
自動化測試的過程
有了流程不代表我們肯定會成功，更何況一般需要我們通過自動化測試的成功來帶動流程的推進。
自動化測試首先是一種軟件開發與交付過程，無論最后的執行與維護是誰！
自動化測試與軟件開發過程基本相同，也要經歷： 需求->設計->編碼->交付 四個核心過程。 與普通的開發過程不一樣的是
● 自動化需求并不是實際的強制性需求，能夠有彈性，最關鍵的是自動化項目所定下的效果，各利益相關者必須在自動化項目效果期望上達成一致。
● 一般自動化設計過程相對較為簡單，如果有可伸縮好的框架，這個設計過程可以在很短時間搞定。
● 自動化的維護周期會比較長，所以設計高維護的自動化腳本是必然的。
在實際中，從手工測試過程中學習自動化的人，甚至有對版本管理工具如何管理代碼不清楚，那么他去做自動化必然是失敗的。
當項目經理對自動化效果期望很高時（這點可以理解，一般人對自動化期望都比較高），而你沒有將實際的風險與效果評估展現與說服給他時，就算自動化再成功，這個項目依然得不到所得的效果。
我們在統計自動化成本時，往往發現執行維護階段最終會超過自動化項目開發階段。
我們應該怎么做自動化項目
看下我們的目標：
● 快速開發與交付
● 高可用維護
選擇一門語言：
根據實際自動化需求，我們選擇了ruby作為基礎開發語言。 實際運用中，推薦使用ruby或python具備完備的模塊管理與純面向對象，，有助于建設高復用的框架與平臺。
實現快速迭代：
每天日結，自動化代碼要有完備的單元測試，這點通過ruby很容易實現，通過極簡潔的單元測試框架讓任何人都愿意做自動化代碼的單元測試，這點很重要，因為你的代碼再也沒有人去手工測試了。
實現DRY與業務邏輯分離
DRY即Don't Repeat Yourself（不要重復自己）， 永遠不要讓相同的邏輯代碼復寫兩次。 一旦出現，將其分離封裝，如果是公共代碼（可能大多數項目會用），將其獨立為gem包等形式。
業務邏輯分離，將用例業務層為獨立，邏輯處理再次封裝，MVC的思想作為參考點。
實際上，自動化項目更適合做敏捷模式的開發過程，如果自動化項目都沒有“敏捷”， 你的被測項目又如何“敏捷” ？
我們應該關注什么？
除了自動化項目完成時間是重點外，我們要去關注：
1、質量問題
2、可維護性
質量關乎自動化項目的生命，
一旦自動化項目的經常跑失敗，失敗的原因經常是由于腳本引發，并且不收斂，那后果可想而知：
● 沒有人再相信自動化的運行結果
● 沒有人再愿意嘗試不斷的投入執行與分析一個無法發現有效bug的自動化測試項目中
● 沒有人再愿意投入下一個自動化過程中
可維護性是指后續的產品變更引起的自動化腳本更新快捷方便，做的好的自動化是超前完成維護的，做的爛的自動化是無法維護的。
可維護性表現可在于1，修復一處代碼即可完成相關所有邏輯的處理 2，便于增加新用例與復用代碼。
我們誰也不愿意將自動化的腳步陷入不斷的無限的維護分析的泥潭中。
總結
上面一些感悟，例子不多，但將我認為最重要的東西表達出來了，很多東西并不是死板的，呆滯的。
自動化領域更講究創新思維。
能夠將你所看到最繁瑣，最無聊的事情通過自動化解決了，這就是做好自動化項目的最核心思想。
但自動化之路不是一朝半夕可以掌握，很多彎路也許你是必須要走過。 <異類>一個觀點叫 1萬小時規律， 你不去認真做一萬小時的事情，你是不可能成為高手的。 （1萬小時大概需要5-6年）
在這里共享一些心得，也與剛入門的兄弟姐妹們共勉之。 共同進步。
最后推薦一個最近文章<測試技術專家之路的成長>，我想自動化專家的發展也與此類同：http://www.51testing.com/html/09/n-247209.html
多實踐，找出與自己公司合適的自動化發展之路，而不是好高鶩遠，更不是以技術牛人自居，只有這樣，才能腳踏實地，一步步走好適合自己的發展歷程。任何行業不都這樣嗎？
相關鏈接：
走在自動化軟件測試的道路上