去年春節聯歡晚會，為了那張“敬業福”，全家都卯足了勁兒“咻一咻”，連節目都顧不上看了。當時我就想，要是能自動化該多好，不停點擊屏幕，屏幕不疼手還疼呢，何況還不好分心，生怕錯過了“敬業福”。玩“咻一咻”，是靠不停點擊按鈕來檢查是否得到“敬業福”，而工作中的UI自動化，大抵也和“咻一咻”差不多，都是通過不斷地輸入，驗證系統的輸出是否正確。然而做UI自動化，效果並不好，收益低就算了，執行速度還慢。比如打開一個瀏覽器，可能就要等3-5秒，如果等瀏覽器訪問網址，返回網頁內容，就需要更長的時間。要是遇到問題，還要排除各種干擾才能定位。而要是做接口或者單元測試，不但定位問題范圍小，響應也基本都是毫秒級的，即使遇到慢的，差不多1秒鍾也能返回結果了。這么一對比，UI自動化就像是一件吃力不討好的事兒，所以去做UI自動化，大概是因為它獨特的角度：從用戶體驗來驗證系統的正確性。
要做UI自動化，以web方向來說，要是有一個好框架，就方便多了。如果編程基礎好，可以自己寫框架或者修改現有框架，封裝常用業務邏輯和代碼，提高測試效率。要是不會編寫框架，也可以使用開源的工具，比如Robot Framework，它既支持關鍵字驅動、數據驅動，也支持接口測試，在官網稍做學習，就能初步使用。要是既不會寫框架，也不會用工具，那你也可以看看吳老的《Selenium WebDriver實戰寶典》，里面有很多小實例，比如操作下拉框、輸入框等等。有了這些小實例，你就可以把它們復制到文檔，形成一個有目錄的代碼庫。這樣即使你不會封裝代碼，也能在需要的時候找到它，再修改下常用的參數，就能實現一個簡單的自動化測試了。
挑選UI自動化用例也有講究，一般都選擇比較穩定、重要的功能作為切入點，要是易於編寫就更好了。但一提到項目改版，UI經常首當其沖！可能改動特別大，有時候與其維護自動化用例，還不如重新寫。遇到這種大刀闊斧地改變，代碼庫的優勢就很明顯了，它形式靈活，可以根據需要隨時組裝，極大地加快了編寫速度。並且隨着小代碼塊的積累，組合代碼塊的經驗也不斷增長，當嘗試去封裝函數，進一步提高代碼的復用程度時，一些小的框架設計思想也會隨之出現。這樣循序漸進，在實踐中思考總結，不斷優化學習，汲取一些先進的實現思想，慢慢地，UI自動化會做的越來越好。
有朋友說：“手工測試都來不及，哪有時間做自動化？”話雖如此，但抽出時間，做一些局部自動化，提高測試效率，還是很值得的。比如准備測試數據，就要進行大量的重復操作。手工制造上百條數據，可能需要大半天。而使用自動化來實現，在編完代碼的那一刻，你就已經解放了！數據源源不斷地涌出，只要運行幾分鍾甚至更短的時間，我們就能完成目標！所以學習UI自動化，總會有用武之地。如果現在還不會，可以慢慢學，千萬不要因為現在做的不好，就半途而廢了。在工作中，我們可以和同事相互鼓勵，一起學習和探討，甚至帶動整個測試團隊一起提高，一起進步。希望大家都能使用自動化，為自己爭取到更多的福利！
---記光榮之路吳老4月9日清晨分享
作者：Flyleaves
出處：http://www.cnblogs.com/Flyleaves/
參考聲源：http://m.ximalaya.com/zhubo/44966139
本文版權歸作者、微信公眾號光榮之路和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
