大綱： 自動化測試的現狀
自動化測試的發展
1、包含的領域
2、發展的思路
3、觀點： 自動化測試是一種軟件開發交付過程
自動化測試成敗在于自動化項目的質量與可維護性
自動化測試不只是測試的自動化，應當是流程的自動化
自動化的難點：
1、極強的定制性使得引入自動化成為難事
2、預言性的需求設計使得自動化需求變化極快，同時要求開發周期越短越好
3、軟件流程往往成為自動化道路中的拌腳石
我在自動化測試的計劃
未來的自動化測試在哪里？
引用
rubywindy說前面的路： 軟件行業算得上是高科技行業，“零成本”締造了N多帝國公司的神話。 這也從側面說明軟件業還不夠“成熟”，因為在“傳統”的眼里，很難出現一家獨大的局面。 在軟件業中，自動化測試要算是一個很小的分支了。 然而軟件測試往往花費了50%以上的項目周期，而自動化測試正像傳統的自動化流水線工廠一樣，試圖解決這個關鍵問題。 |
我在這個領域不長時間，算上入手開始到現在，大概有1年半有余。一直有一種想分享一些想法的沖動，然而總是感覺時機不成熟，畢竟這個領域在中國是新興的，而我也是一種新入門的感覺，然而，測試領域的混亂狀態與最近越來越清晰的思想使得我也借Ruby大會后的時間梳理一下我的想法。
自動化測試包含的理念是什么？
看了許多51testing上的文章貼子，很多人對此不清楚，我想簡單幾句表達下我的觀點。
為什么出現自動化測試？ 因為手工測試效率低下，回歸成本高昂，許多在前期應當控制的代碼質量由于手工測試介入過晚導致測試成本過高。 自動化測試的出現要求提高整體測試效率，極大降低回歸成本，通過單元自動化，接口自動化，自動化代碼檢視，編譯自動化構建，冒煙構建等立體動態的方案從而 可以盡早從測試手段控制版本開發質量，降低后續測試成本，并快速集成回歸。
我想提供一個圖看下變化過程：
這是一個傳統的，也是我們一般人使用的軟件開發模式，國外有個好聽的名字： 瀑布開發模式（你堅著看，很形象吧？）
而自動化測試應當提供什么呢？
看下圖：
我們今天不討論敏捷，這里的自動化模式是基本不改變開發模式的方式下的開展過程。（我想大部分公司很難強推行大規模的開發模式轉變：大部分原因被冠名風險與人）
這個圖是以自動化云層（叫平臺也行）依靠，提供全方面的自動化測試過程。
● 自動化測試的手段： 以自動化測試代碼為依托，提高高可用的測試方案與立體的測試體系。
● 自動化測試的目的： 讓軟件測試無事可做！
解釋下目的，充足的快速的立體多方位的自動化測試加之規范的開發流程，bug既在編碼中與之前被發現，何來傳統的測試工作？
也許較真的兄弟們會說，軟件測試覆蓋的面可多了，黑盒，模糊，場景，發散等，你怎么取代？ 我說的測試工作是特指我們平時花費最長最無味的系統測試。
解釋了自動化測試的所在的領域與基本理念后，下一個問題，
如何發展？
這里就我在工作過程中的一些思路談一談，我們知道自動化測試不具備通用性，明白這點很重要。我再解釋下，假如你在華為的路由器測試，你會使用cli操作命令進行自動化，你的平臺很可能依托在復雜的資源管理平臺上。
而如果你在人人，你會使用selenium等UI工具進行自動化，你可能直接使用了selenium與hudson作集成自動化。
如果你是做企業金融的公司，你會使用flash測試工具，autoit，甚至商業化的RFT等
另外，自動化還有一個特點，投入成本高，產出可能很緩慢。 如果你在預算投入不足時，千萬不要貌然啟動自動化，不要對其報有任何幻想。
如果明白這兩點，你們公司應該會成立專門的自動化團隊了，并且逐步的形成自動化測試的框架與相關的自動化效果產出了。
最后我想重點談談技術在自動化測試發展中的作用。
● 問題一： 選擇商業工具還是自主開發？ 商業工具一般很強大，常見的如QTP，RFT，Robot，SilkTest等，并且帶有腳本錄制與快速回放。那我們直接選好了？
No，我的建議是不要去選，至少不要輕易的去選，并不是說你家有錢不讓你去花，因為要知道，自動化測試不具備通用性，我們的產品很難說能適應測試工具，而是應該讓工具去適應產品。
自主開發？ No，我的建議也是No，世界上有一批優秀的程序員（測試員），他們開發了一批優秀的開發的自動化工具供我們使用，我們只需要動動手，整合一個框架出來就 ok了。 你會擔心，誰幫我維護？有bug找誰？ 你要記住，如果你的技術不足于達到維護這個自動化測試工具時，你的自動化測試基本也宣告失敗了，那么，發現bug提交給相關社區，或者自己去修改并 push請求。達到技術共享的目的。
Java代碼
| 少量推薦的開源項目:
watir: http://watir.com/ Wiki社區: http://wiki.openqa.org/display/WTR/Project+Home
優秀的web自動化工具,采用ruby作為底層語言. API堪稱完美. 維護速度很快
selenium: http://seleniumhq.org/ 當然,采用開源并不是成功的必然條件,你還要根據實際的產品需求逐步的形成適合的自動化測試解決方案而不僅僅是一個工具.
這個解決方案應該能適合絕大部分自動化需求,而且根據DRY原則,做到最簡潔,最易用,最穩定. |
● 問題二： 先開發框架還是先作自動化項目？ 有些人上來就想做一套框架搞自動化，生怕技術生銹了，實際上我的建議是：
先有自動化測試代碼，形成簡單的結果報告，代碼復用規范，將自動化效果展示出來。
第二步摸清需求后，進而設計一套合適的框架，這里可充分利用開源的優勢，一個技術好的人甚至花不超過1周可搞定一個框架。我們的ATT框架當時 僅花費了20*3人天完成。（一套關鍵字驅動框架，目前還沒有開源） 另外一個單元級框架花費3天完成，具備腳本規范，日志輸出，等作用。
第三步，設計框架要考慮可擴展性，要有預言性的設計在里面，比如ATT框架對外的接口是一個xmlrpc協議的接口，后來我們花了半年開發了平臺管理項目，與ATT框架完美對接。
最后，從流程上對自動化云層進行整合，梳理各項流程點，把能夠簡化的流程步驟全部由云層處理。（就像喬布斯那樣把iphone的開關都去掉了，因為實在對用戶沒有必要）
問題三：人，我的人應該具備什么樣的能力？<自動化軟件測試實施指南>這本書講的很好。
我就簡單總結下，
1、技術上不要求太精，但一定要廣，并且對新技術具備很高的熱情，我以后如果去面試，會第一個問題問，是否在業余時間開發過項目，如果用到了rails，erlang，云技術，甚至喜歡研究flex，敏捷，那么是我的首選。
2、創新思維，凡事不是第一感覺為否定，而是用研究來驗證自己的想法是否可行，能否做到把不可能自動化的東西也自動化掉。
3、團隊交流與協助，這點不用多說了。
4、改進意識，不甘于不斷的重復工作，如果沒有這點就沒有自動化。
當然，這樣的人有少量就夠了。
最后就我的里程，作一個回顧，也會以上理論的東西作一個實質的歸納，就當聽聽故事吧
大學玩了一半學了一半，學業成績稱不上優秀，但也算不錯。（至少沒有掛課~）
畢業的時候，我直接投了深圳這邊公司的簡歷，當時當然是一心投的開發職位，然而，對開發倒是一種不舒服的感覺，因為畢業設計的時候設計的那個郵件服務器始終存在一個bug，讓我決定可以試試測試職位，最終通過了現在的公司的面試。（ 主要是動手能力強， 嘿嘿）
隨便說一下，當時騰訊來過，我去面準備不足（第一次面），直接被一面bs，我就暗下決心，你bs我，我就以后bs你，所以現在聽有人進了騰訊，我就不由分說bs一番。（現在只是說說了，雖然心里知道它現在的霸主地位） 等我以后再真正bs你吧。
那時候，華為還沒有過來，但早就聽說華為的速度（無論面試還是offer）最慢，我是那種不喜歡條條框框的人，直接不等它了。
進了公司后，開始做測試，我的性格里只有兩種事情劃分，要么做好做么不做，開始的測試工作還是蠻有意思的，學習也真的很快，期間也收獲了同事們 的認可，然而時間一長，測試的重復工作和無力的成就感使得我不得不重新考慮以后的計劃，以后的幾天，我向我導師反映了我的心態與計劃，轉崗or離開。 然而，在那時候我堅持了下來，半年后我們的測試主管確定成立自動化測試部，在10年4月的某一天，我全職投入自動化，從基本上是零一直到現在。
因為公司的自動化發展特殊性，我們的自動化投入基本上是：
投入自動化項目 -> review效果 -> 剝離框架 -> 投入自動化項目
目前效果產出比較明顯，好幾個版本ROI超過了2，直逼3。 在這里我建議投入的項目是：
基本功能bvt -> 易于實現的自動化功能 -> 提高部分模塊自動化率， 期間不斷優化框架與平臺，整合出我們的自動化云端。
目前我們有5個人全職自動化，馬上會有新人繼續加入。
寫在這里，這篇已經很長了，接下來就自動化實施的難點加以分析與說明。為自己留下些成長中途的記憶。