Web UI自動化測試的不穩定性有兩個層面：
- 技術層面–沒有構造健壯的能穩定運行的腳本
- 非技術層面–項目原因或者用Web UI自動化企圖達到不合適的目標，造成腳本頻繁改動，維護成本高
第一點在上一篇博文裏從代碼層面分析過了，今天主要說說第二點。
醜話說在前面，Web UI自動化不是萬金油，它不可能幹掉手動測試人員。衡量好投入產出，最大化UI自動化的效用，纔是王道！
什麼項目不適合做Web UI自動化測試？
- 我覺得沒有太多Web UI界面、不面向終端用戶的項目，它可能只涉及到後臺數據導入、處理，或者模型計算，那這種更適合接口測試，每一次開發的新代碼進入目標環境之後，讓CI自動跑一遍不帶UI界面的接口測試，看看是否有引入新BUG。一般而言，不帶UI界面的自動化測試效率以及穩定性都要更高。
怎樣使用Web UI自動化測試這個工具，以期在開發維護成本&自動化產出之間找到平衡點？
我的建議是：
- 分出輕重緩急，核心部分優先自動化。對於所有Web項目而言，合法登錄&不合法登錄，以及權限控制都是最重要最基本的。除此之外，再拎出來系統的核心部分以及用戶使用頻率最高的部分，從功能的角度進行自動化測試，也就是說，點擊這個按鈕，判斷profile頁面是否如期喚起；配置報表，最後報表是否生成，裏面是否有數據？（數據是否正確就應該交由集成測試來驗證）；做一筆trade，返回值是否是成功，是否包含exception message等等。
- UI自動化要注重邏輯功能，而非UI，不要讓自動化去真的判斷UI，否則就是作繭自縛。千萬不要被名字誤導，其實UI自動化是模擬用戶的鍵鼠操作，判斷系統功能是否有異常，它也能判斷UI，但是這麼做必死無疑！爲什麼？因爲Web項目變化快且變化大，今天這個頁面這個控件是藍色的，寬25，明天可能就會變成白色，寬15，誰說的準呢？！自動化代碼判斷的越多，維護成本越高，越不穩定。所以自動化應該着重判斷的是：這個控件功能好不好使，而不是控件的樣式。控件的樣式應交給手動測試人員去肉眼判斷。
- 在敏捷項目裏，要想做到UI自動化和開發同步，其實很難，而且也沒必要。因爲新的功能模塊不可能一步到位，同步開發自動化代碼，後面改動、維護成本會居高不下。所以應該部分自動化，等到模塊穩定之後，再加大自動化比例。
有朋友私信問我『web ui自動化實用性如何？有花時間實現的必要嗎？』
我的答覆是肯定的。從我的個人經驗出發，Web UI自動化測試實用性很強，非常強！它能捕捉到一些手動測試人員意想不到的BUG。比如開發最近在修改某一個已有的功能模塊A。手動測試人員對A模塊進行了各方面的測試，PASS。自動化測試A模塊也是PASS，但是B模塊掛了？！這就是因爲B模塊被A模塊的改動影響到了。但是這些影響，很可能連開發自己都意想不到，更不用說測試人員了。也不是說測試人員經驗不足，是因爲某些功能模塊存在隱性耦合，改了這裏，測試人員總不可能把整個系統都測試一遍吧？整個系統都測一遍這種事情就應該交給自動化來完成。
我們項目大概每8個禮拜，就會發佈一個新版本給客戶，這裏面UI自動化測試還是蠻有份量的，因爲它不負衆望，每次在發佈新版本之前，總能發現一些千奇百怪的BUG，這些BUG都會被開發第一時間fix掉。還有一次發佈新版本的時候，由於UI自動化發現的BUG，整個迭代延期，修復掉這些BUG之後才發佈新版本並開始新的迭代。據不完全統計，我們的自動化每個月大概捕捉10+個BUG，平均每3天1個BUG。而UI自動化就兩個人。我私認爲，我們的UI自動化從投入產出比來講，是非常划算的，大Boss們應該很滿意！
最後，祝大家國慶快樂，好好享受今年的最後一個長假吧！
