GUI 自動化測試穩(wěn)定性，最典型的表現(xiàn)形式就是，同樣的測試用例在同樣的環(huán)境上，時而測試通過，時而測試失敗。
造成 GUI 測試不穩(wěn)定的因素
一、非預計的彈出對話框
1.1、GUI 自動化測試用例執(zhí)行過程中，操作系統(tǒng)彈出的非預計對話框
比如，GUI 測試運行到一半，操作系統(tǒng)突然彈出殺毒軟件更新請求、病毒告警信息、系統(tǒng)更新請求等對話框。這種對話框的彈出往往是難以預計的，但是一旦發(fā)生就有可能造成 GUI 自動化測試的不穩(wěn)定。
1.2、被測軟件本身也有可能在非預期的時間彈出預期的對話框
比如，被測軟件是一個電子商務網(wǎng)站，在網(wǎng)站上進行操作時，很可能會隨機彈出“用戶調查”對話框。雖然這種對話框是可知的，但是具體會在哪一步彈出卻是不可預期的。而這，往往會造成 GUI 自動化測試的不穩(wěn)定。
解決方案：
1、當自動化腳本發(fā)現(xiàn)控件無法正常定位，或者無法操作時，GUI 自動化框架自動進入“異常場景恢復模式”。
2、在“異常場景恢復模式”下，GUI 自動化框架依次檢查各種可能出現(xiàn)的對話框，一旦確認了對話框的類型，立即執(zhí)行預定義的操作（比如，單擊“確定”按鈕，關閉這個對話框），接著重試剛才失敗的步驟。
注：這種方式只能處理已知可能出現(xiàn)的對話框。
而對于新類型的對話框，只能通過自動化的方式嘗試點擊上面的按鈕進行處理。每當發(fā)現(xiàn)一種潛在會彈出的對話框，我們就把它的詳細信息（包括對象定位信息等）更新到“異常場景恢復”庫中，下次再遇到相同類型的對話框時，系統(tǒng)就可以自動關閉了。
對于非預期的彈框也可以通過檢查置頂窗口是否是預期軟件窗口，從而確定是否被第三方彈框影響
二、頁面控件屬性的細微變化
比如，“登錄”按鈕的 ID 從“Button_Login_001”變成了“Button_Login_888”，那么如果 GUI 自動化測試腳本還是按照原來的“Button_Login_001”來定位“登錄”按鈕，就會因為 ID 值的變化，定位不到它了，自動化測試用例自然就會失敗。
解決方案：
1、通過控件類型（Button）縮小了范圍
2、通過屬性值中的關鍵字（Login）進一步縮小范圍
3、根據(jù)屬性值變化前后的相似性，最終定位到該控件
采用“組合屬性”定位控件會更精準，而且成功率會更高，如果能在此基礎上加入“模糊匹配”技術，可以進一步提高控件的識別率。
“模糊匹配”是指，通過特定的相似度算法，控件屬性發(fā)生細微變化時，這個控件依舊可以被準確定位。
但是，開源的 GUI 自動化測試框架，目前還沒有現(xiàn)成的框架直接支持模糊匹配，通常需要你進行二次開發(fā)，實現(xiàn)思路是：實現(xiàn)自己的對象識別控制層，也就是在原本的對象識別基礎上額外封裝一層，在這個額外封裝的層中加上模糊匹配的實現(xiàn)邏輯。
如果是 selenium 的話，建議優(yōu)先使用 xpath，這樣就算 id、clases、name 等控件屬性改變，只要不是頁面改版，應該不會影響自動化穩(wěn)定性。
三、被測系統(tǒng)的 A/B 測試
A/B 測試，是互聯(lián)網(wǎng)產(chǎn)品常用的一種測試方法。它為 Web 或 App 的界面或流程提供兩個不同的版本，然后讓用戶隨機訪問其中一個版本，并收集兩個版本的用戶體驗數(shù)據(jù)和業(yè)務數(shù)據(jù)，最后分析評估出最好的版本用于正式發(fā)布。
A/B 測試通常會發(fā)布到實際生產(chǎn)環(huán)境，所以就會造成生產(chǎn)環(huán)境中 GUI 自動化測試的不穩(wěn)定。
解決思路：在測試腳本內部對不同的被測版本做分支處理，腳本需要能夠區(qū)分 A 和 B 兩個的不同版本，并做出相應的處理。
四、隨機頁面延遲造成控件識別失敗
加入重試（retry）機制，當某一步 GUI 操作失敗時，框架會自動發(fā)起重試，重試可以是步驟級別的，也可以是頁面級別的，甚至是業(yè)務流程級別的。
對于開源 GUI 測試框架，重試機制往往不是自帶的功能，需要自己二次開發(fā)來實現(xiàn)。
注：對于那些會修改一次性使用數(shù)據(jù)的場景，切忌不要盲目啟用頁面級別和業(yè)務流程級別的重試。
重試機制確實是個好辦法，但是如果用例都是因為重試才執(zhí)行正確，有可能會漏出和緩存相關的問題，因為重試應該算一個獨立測試場景了，現(xiàn)在是把它作為主要測試場景了。
五、測試數(shù)據(jù)問題
比如，測試用例所依賴的數(shù)據(jù)被其他用例修改了；再比如，測試過程中發(fā)生錯誤后自動進行了重試操作，但是數(shù)據(jù)狀態(tài)已經(jīng)在第一次執(zhí)行中被修改了。
構造自動化數(shù)據(jù)時要特別注意，構造一些帶特殊字段的數(shù)據(jù)庫信息，最好是超出常人操作的數(shù)據(jù)信息，這樣可以有效避免數(shù)據(jù)被誤修改的風險，當然，還有一個處理辦法就是先檢查測試數(shù)據(jù)是否存在/異常，不存在或異常都進行重建即可，這部分也算是測試代碼的兼容處理吧。
