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