Web UI自動化測試的不穩定性有兩個層面：
- 技術層面–沒有構造健壯的能穩定運行的腳本
- 非技術層面–項目原因或者用Web UI自動化企圖達到不合適的目標，造成腳本頻繁改動，維護成本高
今天先說第一點。
首先，Web UI自動化測試是不穩定的，哪怕腳本寫的很棒！爲什麼？因爲Web應用本身就有不穩定的情況存在。以下這些情況想必我們都經歷過：
- 點擊網頁上的按鈕或者菜單沒有響應（有時候第二次點擊纔有響應…）
- 網絡延遲嚴重，頁面響應慢
面對本身就不是100%穩定的Web UI，怎樣構造高質量的自動化腳本？我的建議如下：
【關於控件定位】
定位條件多用組合，多留冗餘，不要寫死，比如：class包含form-arrow-button並且id以GroupName開頭並且子節點數量大於1
如果寫成id=GroupName-1024，那就很危險，下次在其他的測試用例裏，先去某個也有類似控件的頁面做一些事情再來這個頁面找這個控件，那這個頁面的控件可能就不是GroupName-1024了，可能是GroupName-1448。當然這不是絕對的，這是由前端代碼和項目特質來決定的。
有時候控件也定位到了，但是操作它就是沒有響應，那麼，請檢查下它的可見性，很可能我們定位到了一個很類似的控件上，而且這個控件當前是不可見的。一般是否可見放在了控件的style屬性裏。
構造腳本時考慮要全面，舉個例子，下拉菜單當前只有3個元素，都是可見的，我們的測試用例選最後一個，執行起來沒有問題。但是如果將來下拉菜單裏的元素增加到100個，我們當前的代碼能否成功選中最後一個？是不是在選中這個元素前加一行scroll to visible然後再點擊比較安全？！一般自動化測試人員也是屬於測試人員，那麼多方面考慮應該是必備的職業素質。然而這個也急不來，工作的年限越久，踩的坑越多，自然就會越全面了。
關於腳本錄製，我插播一句，那就是個笑話！大家玩玩就好了，別當真。如果Web UI自動化是基於腳本錄製來構建的，那簡直就是找死。頁面稍稍有個變動，腳本就掛了。
【關於控件操作】
UI自動化測試就是仿照人的操作，確保系統可用。所以鼠標鍵盤事件還是必不可少的。
但是，這些是不穩定的，就如上面所說的，我們自己手點操作，有時候都是沒反應的，更何況代碼去模擬！所以在能達到測試目標的前提下，少用MouseClick, typetext之類的，用Click, SetValue來代替。
【關於測試用例構成】
我認爲測試用例應該儘量短，一個動輒需要執行30分鐘或者一個小時的測試用例就應該考慮優化，或者拆分。
如何優化？舉個例子，這個用例主要測試在job裏面加入報表：帳號登錄系統 > 配置一個符合測試要求的報表 > 最後在job裏面加入這個報表。如果用例執行時間很長。那麼配置報表的過程就應該考慮提前做好setup，代碼裏用現成的即可。
做好用例的優化和拆分，能很明顯提高我們用例執行的穩定性！
【關於頁面加載】
不要隨便在代碼裏面寫sleep(5s), delay(5s)，這是非常不好的習慣。這次等5s行得通，下次網絡不好，可能得改到10s，某一天系統狀態更差，直接改20s。時間久了，測試用例裏面隨處都要等，執行起來很慢。
等待頁面加載應該調用框架的wait until page ready/wait for ajax loading/wait for element appear/wait for element disappear. 一般的Web UI自動化框架都有這些方法的，實在沒有的話，自己封裝。
另外，一定要記得給測試用例設置時間限制，如果在某一步僵死，超出一定時間限制，就強制結束。根據具體情況，一般設置幾十分鐘應該足夠了。
【關於重試機制】
正因爲Web UI測試自動化的不穩定性，很多CI工具提供了重試機制。我對此抱中立態度。在某些情況下，重試可能就通過了，也可能照樣失敗。重試機制並不是一個非常重要的策略，所以我把它放最後。
總之，Web UI自動化測試不可能不需要人照看。重試機制大概只是早看還是晚看的區別…
這纔是週末的正確打開方式 :-D
