針對"GUI自動化測試穩定性問題"這個問題，最典型的情景就是：同樣的測試用例，在同樣的測試執行環境下，測試的結果有時是Success，有時是Fail，這嚴重降低了GUI測試的可信度，同時也是GUI層面的自動化測試位於金字塔最頂端的原因之一。
在實際的專案過程中，GUI測試幾乎不可能做到100%穩定，根據我的經驗，如果能夠做到 90% 以上的穩定性，就已經非常不錯了，這需要整個產品技術團隊的共同努力才有希望達成。
要提高 GUI 測試穩定性，首先我們需要知道到底是什麼原因引起的不穩定。我們必須找出儘可能多的不穩定因素，然後找到每一類不穩定因素對應的解決方案。
我列舉了幾種常見的造成GUI測試不穩定的因素，如下：
1、非預期的彈框
在用例執行過程中，作業系統或被測系統可能會突然彈出預期範圍之外的對話方塊，GUI自動化測試有可能就會因此而失敗。
解決方案：常用的解決方式，引入異常場景恢復模式或者採取無介面GUI自動化測試來處理。
2、頁面控制元件屬性的細微變化
如果頁面控制元件的屬性發生了變化，哪怕只是細微的變化，也必定會導致測試指令碼的元素定位失敗。這可以說是GUI自動化測試最大的痛點。
目前，一些商用 GUI 自動化測試工具，比如 UFT(原QTP)，已經整合了模糊匹配的功能。通常情況下，只需要啟用“模糊匹配”選項即可。如果某個物件的定位是通過模糊匹配完成的，那麼，測試報告中將會顯示該資訊，明確告知此次物件識別是基於模糊匹配完成的，因為 GUI 自動化工具並不能保證每次模糊匹配都一定正確。
解決方案：元素定位時採用模糊匹配技術。
3、隨機的頁面延遲造成控制元件識別失敗
隨機的頁面延遲，也是 GUI 測試防不勝防的。既然是隨機的，也就是說我們沒有辦法去控制它，解決辦法是加入重試（retry）機制。重試機制是指，當某一步 GUI操作失敗時，框架會自動發起重試。對於Robot Framework+SeleniumLirary，可以使用有wait until系列的關鍵字（智慧等待），儘量少的使用sleep。
Wait For Condition
Wait Until Element Contains
Wait Until Element Does Not Contain
Wait Until Element Is Enabled
Wait Until Element Is Not Visible
Wait Until Element Is Visible
Wait Until Page Contains
Wait Until Page Contains Element
Wait Until Page Does Not Contain
Wait Until Page Does Not Contain Element
解決方案：引入重試機制retry
4、測試資料問題
測試資料問題，也是造成 GUI 自動化測試不穩定的一個重要原因。比如，測試用例所依賴的資料被其他用例修改了。要解決此類的問題，就要回歸到第一篇中所談到的內容，必須要保證用例之間的獨立性和儘量減少對執行環境的依賴。Robot框架本身不會規定Case執行的順序，所以從某種程度上來說同一層級的Cases是隨機執行的。很典型的情況就是，測試用例在本地除錯時怎麼跑怎麼過，放到Server上所有Cases一起跑的時候就會Fail,還可能是偶發的，這種情況下就很可能是由於其他Case的痕跡影響到了它，查詢問題的根源往往比較耗時。
解決方案：保證用例之間的獨立性和儘量減少對執行環境的依賴
5、小結
介面自動化測試，它最接近使用者真實場景，也容易發現問題，但它的實現成本最高且太容易受外部依賴，容易影響指令碼成功率。總體來說，適當的介面自動化測試是有必要的，但是也大可不必在UI層投入太多精力。