寫UI自動化測試的腳本不難難的是讓它穩(wěn)定跑三個月還不怎么花錢維護(hù)。但很多剛接觸這個方向的人上來就找框架、寫腳本結(jié)果用例跑起來綠油油一換環(huán)境就紅一半最后整個項(xiàng)目組對自動化失去信心。今天我把這些年做UI自動化測試的完整思路和實(shí)操經(jīng)驗(yàn)拆開聊一遍從要不要做、框架選型到元素定位、用例分層、失敗排查一次性講清楚適合剛從功能測試轉(zhuǎn)自動化的小白也適合正在折騰腳本穩(wěn)定性的測試開發(fā)。1. 動手之前先盤一盤UI自動化這筆賬1.1 什么項(xiàng)目真正適合UI自動化我想先說一句可能不太中聽的話不是所有項(xiàng)目都適合做UI自動化。UI自動化在測試金字塔里處于最頂層執(zhí)行成本、維護(hù)成本、不穩(wěn)定概率都比單元測試和接口測試高得多。它最適合的場景是那些核心流程穩(wěn)定、版本迭代頻繁、需要頻繁做回歸驗(yàn)證的項(xiàng)目。反過來看如果你的產(chǎn)品還在原型期UI每周都在動頁面結(jié)構(gòu)經(jīng)常推倒重來那現(xiàn)在投入寫UI自動化基本是白燒錢。你可以先把核心業(yè)務(wù)邏輯沉淀成接口自動化等UI穩(wěn)定了再補(bǔ)一層界面級回歸。我之前見過一個團(tuán)隊(duì)在產(chǎn)品改版最頻繁的時候硬著頭皮維護(hù)了80條UI用例結(jié)果每天光修腳本就花掉一個專職人力這成本完全不劃算。判斷要不要做可以從三個角度評估第一核心流程是否已經(jīng)連續(xù)多個版本沒有大改第二是否每個版本都需要花幾個工時手工反復(fù)點(diǎn)同一個流程第三團(tuán)隊(duì)有沒有CI環(huán)境能把用例定時跑起來。三個條件都占齊了才值得投入做UI自動化。1.2 投入產(chǎn)出比怎么算UI自動化最容易被忽略的問題就是算不清賬。一個UI用例的編寫成本從分析頁面結(jié)構(gòu)、寫定位、處理等待、加入工程框架到最后穩(wěn)定跑通通常要花半天到一天。如果這個用例覆蓋的業(yè)務(wù)流程手工執(zhí)行三分鐘搞定那這錢花得沒有意義。我一般會按這個邏輯去估算首先計(jì)算手工回歸一次當(dāng)前核心流程需要多少時間然后預(yù)估接下來一年會發(fā)多少個版本把“手工回歸總時長”和“自動化腳本的編寫維護(hù)總時長”放在一起對比。自動化腳本還存在一個優(yōu)勢就是可以晚上跑、早晨看結(jié)果這是手工測試做不到的。只要項(xiàng)目再存活大半年這套賬基本都能回本關(guān)鍵是別把范圍鋪太開優(yōu)先覆蓋主流程、高風(fēng)險(xiǎn)模塊、頻繁回歸區(qū)域。另外要把維護(hù)預(yù)算考慮進(jìn)去。頁面結(jié)構(gòu)不會永遠(yuǎn)不變你需要預(yù)留每周一到兩個人時的維護(hù)時間。如果一個版本的UI改版會導(dǎo)致超過十條用例大改那就說明自動化用例寫得太貼近頁面細(xì)節(jié)了解法不是硬扛而是調(diào)整設(shè)計(jì)把容易變化的部分收斂到Page類里用例本身只保留業(yè)務(wù)步驟。1.3 做之前先定三層防線很多人有個誤解覺得做了UI自動化就可以把手工測試大部分干掉。實(shí)際操作下來你會發(fā)現(xiàn)UI自動化最適合當(dāng)“最后一道防線”而不是主力防線。我比較推薦的分工方式是底層邏輯用單元測試覆蓋業(yè)務(wù)接口用接口自動化覆蓋UI層只跑冒煙和高優(yōu)先級回歸用例。UI自動化主要負(fù)責(zé)一條主流程從入口到結(jié)束能否走通比如注冊登錄、下單支付、設(shè)置保存這種端到端驗(yàn)證。它不像接口測試那樣可以精準(zhǔn)定位是哪個服務(wù)出了問題但它能驗(yàn)證頁面控件交互、前端渲染、異步請求整合起來是否正常這是接口測試覆蓋不到的。這個定位也決定了你的用例數(shù)量不應(yīng)該太多。一個小團(tuán)隊(duì)維護(hù)120到200條UI用例已經(jīng)算很大了再多就會開始互相牽扯、執(zhí)行時間失控、失敗分析困難。與其追求量不如把核心路徑打磨得足夠穩(wěn)。2. 框架選型機(jī)器跑腿也得有趁手的工具2.1 主流框架對比與選擇邏輯選框架這件事沒有最好只有最合適。我按Web端、移動端、接口配合三層拆開說。先看Web端。Selenium是生態(tài)最大、踩坑資料最全的選擇幾乎所有瀏覽器都有對應(yīng)Driver團(tuán)隊(duì)里隨便一個測試開發(fā)都多多少少寫過。它的缺點(diǎn)是API偏底層等待機(jī)制需要自己搭但用熟了完全夠用。Playwright是這幾年的新寵最吸引我的幾點(diǎn)是自動等待機(jī)制、iframe處理簡單、自帶移動端模擬而且能直接把截圖和視頻作為測試報(bào)告附件排查問題非常方便。如果你所在的項(xiàng)目是綠色起步?jīng)]有歷史包袱我推薦直接從Playwright入手。移動端目前還是Appium為主。它沿用了WebDriver協(xié)議意味著你如果已經(jīng)熟悉Selenium的寫法轉(zhuǎn)過來成本很低。缺點(diǎn)是環(huán)境配置煩瑣Android和iOS的驅(qū)動依賴不少而且真機(jī)機(jī)型的適配問題會讓你瘋掉。使用Appium時記得優(yōu)先用WebView元素定位少用坐標(biāo)點(diǎn)擊坐標(biāo)是最后的手段。接口層配合方面pytest是繞不開的底座。它本身不是UI測試工具但作為測試框架非常稱手fixture管理資源、參數(shù)化跑多組數(shù)據(jù)、斷言失敗自動截圖、配合Allure出報(bào)告都能干凈利落地實(shí)現(xiàn)。下面所有示例我都用Pythonpytest來寫。2.2 pytest如何管理UI資源的生命周期用pytest做UI自動化核心是管理driver的啟動和退出。我習(xí)慣把所有公共的fixture放在conftest.py里這樣所有用例文件都能直接使用不用每個文件重復(fù)寫。比如最基礎(chǔ)的driver管理可以用類似下面這樣的寫法pytest.fixture(scopefunction) def driver(): options webdriver.ChromeOptions() options.add_argument(--headlessnew) driver webdriver.Chrome(optionsoptions) driver.implicitly_wait(5) driver.set_window_size(1920, 1080) yield driver driver.quit()這里有幾處細(xì)節(jié)值得多說一句。scopefunction意味著每條用例前后各啟動、退出一次瀏覽器。這樣做的好處是每個用例都絕對干凈不受到前面用例遺留狀態(tài)的影響壞處是執(zhí)行時間會拉長所以適合用例數(shù)不多的場景。如果你用例很多可以考慮scopemodule同一個文件里的用例共用一個瀏覽器但用例間的session隔離就要自己做比如每一條用例啟動前先清理cookie、清空本地存儲。headless模式適合CI環(huán)境跑但本地調(diào)試我不建議一開始就無頭因?yàn)槟憧床坏巾撁娴降资裁礃印Ｎ医?jīng)常犯的錯就是無頭模式下定位寫對了有頭模式跑起來反而因?yàn)轫撁驿秩緯r機(jī)不同而失敗。后來養(yǎng)成一個習(xí)慣本地先有頭調(diào)試跑穩(wěn)了再上無頭參數(shù)。2.3 多瀏覽器兼容怎么落地如果你的產(chǎn)品需要兼容Chrome和Firefox靠人工在兩三個瀏覽器里反復(fù)點(diǎn)太浪費(fèi)了。pytest內(nèi)置的fixture參數(shù)化可以解決這個問題。先定義一個配置文件把需要執(zhí)行的瀏覽器類型傳進(jìn)去# conftest.py def pytest_addoption(parser): parser.addoption(--browser, actionstore, defaultchrome, choices[chrome, firefox]) pytest.fixture def driver(request): browser request.config.getoption(--browser) if browser chrome: driver webdriver.Chrome(...) elif browser firefox: driver webdriver.Firefox(...) yield driver driver.quit()然后將用例標(biāo)記成多瀏覽器執(zhí)行pytest.mark.parametrize(browser, [chrome, firefox], indirectTrue) def test_login(driver): ...實(shí)際跑的時候命令行直接指定--browserfirefox就能針對單個瀏覽器執(zhí)行。這套方案的核心思路很簡單把“在哪個瀏覽器跑”和“測試是什么”分離跑的時候再傳參決定。3. 定位器策略UI自動化的命門3.1 元素定位的優(yōu)先級排序UI自動化里翻車率最高的環(huán)節(jié)就是元素定位。我見過太多腳本掛在NoSuchElementException上而這個異常九成能靠選對定位策略避免。我自己的優(yōu)先級排序是這樣的首先用id這是最穩(wěn)定的定位方式因?yàn)橛星岸艘?guī)范約束一個頁面里id通常是唯一的。沒有id再用name、class等屬性然后才用CSS Selector最后才考慮XPath。XPath雖然最強(qiáng)能通過文本、層級關(guān)系找元素但它最大的問題是脆弱——只要頁面層級稍微變動表達(dá)式就廢了。這里分享一個很容易懂的生活類比定位元素就像在人群里找人。如果你要找的人穿了一件獨(dú)一無二的紅衣服那你就按這個特征找如果整個會場所有人都穿一樣的工服你只能靠“站在第二排最左邊”這樣的相對位置來認(rèn)。唯一屬性就是“紅衣服”層級結(jié)構(gòu)就是“排和列”前者穩(wěn)后者一換座位就抓瞎。實(shí)際工作中還需要注意動態(tài)值。如果id是類似user_1679529291這樣每次刷新都會變的值那這個id等于廢了需要用[id^user_]這樣的前綴匹配。小心動態(tài)生成的值是所有定位策略里的第一條鐵律。3.2 等待策略別讓你的腳本跑得比頁面快腳本跑得比頁面快這是UI自動化新手最容易忽視的坑。頁面還沒渲染完腳本就去點(diǎn)按鈕結(jié)果要么點(diǎn)不到要么報(bào)錯。等待策略大致分三種強(qiáng)制等待、隱式等待、顯式等待。強(qiáng)制等待就是sleep(3)在腳本里硬等三秒。這個辦法簡單粗暴但坑也在這里界面快的時候白等三秒界面慢的時候三秒又不夠。它只能作為臨時的調(diào)試手段長留在正式用例里是定時炸彈。隱式等待是給webdriver對象設(shè)置一個全局等待時間只要查找元素時沒有立刻找到就輪詢等待。這個機(jī)制的短板在于它只管元素“存在”不管元素“可點(diǎn)”。一個元素如果還在灰化狀態(tài)disabled隱式等待并不會幫任何忙照樣報(bào)錯。所以我強(qiáng)烈推薦優(yōu)先用顯式等待把事情說清楚你要等什么等到什么狀態(tài)才繼續(xù)。下面是我常用的等待封裝from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def wait_and_click(driver, locator, timeout10): element WebDriverWait(driver, timeout).until( EC.element_to_be_clickable(locator) ) element.click()這里的element_to_be_clickable會同時檢查兩個條件元素在DOM里存在、元素是可見且可交互的。用它來點(diǎn)擊按鈕要比直接找元素再click穩(wěn)得多。等待的超時時間我一般設(shè)10秒如果頁面卡頓比較嚴(yán)重的業(yè)務(wù)場景會放寬到15到20秒。但不要無腦設(shè)大因?yàn)槊恳粭l用例的失敗檢測都會等待這么長時間失敗一多整體執(zhí)行耗時就很嚇人。如果頁面本身有異步請求光等待元素可點(diǎn)還不夠。更穩(wěn)的做法是額外等待接口完成——你可以在Network里看到某個請求返回再去操作UI。這個做法在Selenium里實(shí)現(xiàn)起來有點(diǎn)復(fù)雜需要開啟日志捕獲但收益很大。等接口而不等界面能規(guī)避掉大部分因?yàn)殇秩竟?jié)奏不一致產(chǎn)生的偶發(fā)問題。3.3 動態(tài)元素和復(fù)雜結(jié)構(gòu)的處理套路前端現(xiàn)在普遍用Vue、React這類數(shù)據(jù)驅(qū)動框架很多頁面的DOM結(jié)構(gòu)是動態(tài)生成的。最典型的情況是列表項(xiàng)一個列表有十行數(shù)據(jù)每一行的刪除按鈕id可能是delete_1、delete_2、delete_3。這種動態(tài)元素該怎么定位套路是不要直接定位每個具體元素而是先定位到列表容器的穩(wěn)定部分再沿層級往下找。比如先通過XPath找到包含“第幾行”的唯一文本節(jié)點(diǎn)然后從該節(jié)點(diǎn)往上找數(shù)量按鈕。這個思路是把定位拆成兩層穩(wěn)定的容器可變的子項(xiàng)變化的部分盡量放在相對路徑里。iframe是新手的另一個大坑。很多時候元素在DOM結(jié)構(gòu)里清楚得很但Selenium就是找不到。先檢查一下這個頁面是不是嵌套了iframe如果是需要先switch_to.frame()切進(jìn)去操作完再switch_to.default_content()切回來。這個動作如果漏掉后面所有定位都會失敗。我有一個排查習(xí)慣元素找不到時第一步就查看當(dāng)前頁面有多少個iframe、當(dāng)前焦點(diǎn)在哪個frame往往問題就水落石出。4. 從零搭建一套可復(fù)用的用例工程4.1 Page Object模式別把頁面細(xì)節(jié)散落在用例里寫UI自動化最怕什么怕的是頁面一改版幾十條用例跟著一起改。避免這個問題的最經(jīng)典方案是Page Object模式POM。這個模式的設(shè)計(jì)思想很好理解把每個頁面封裝成一個類頁面上元素的定位方式、操作方法都放在類里面用例代碼只關(guān)心業(yè)務(wù)動作不關(guān)心頁面細(xì)節(jié)。打個比方看菜單點(diǎn)菜的時候你只需要告訴服務(wù)員“來一份宮保雞丁”不用知道后廚具體用什么火候、什么配料。用例就是顧客Page類就是前臺菜單頁面DOM就是后廚。后廚改配方了你換菜單說明就行顧客不用改需求。一個簡單的LoginPage可以這么寫class LoginPage: def __init__(self, driver): self.driver driver self.username_input (id, username) self.password_input (id, password) self.login_button (id, login_btn) def login(self, username, password): self.driver.find_element(*self.username_input).send_keys(username) self.driver.find_element(*self.password_input).send_keys(password) self.driver.find_element(*self.login_button).click()然后在用例里只寫page LoginPage(driver) page.login(user, passwd) assert driver.current_url.endswith(/dashboard)如果登錄按鈕id從login_btn改成了login_submit你只改LoginPage里一行所有調(diào)用登錄的用例都不受影響。頁面變化和用例邏輯之間的解耦全靠這一層遮斷。4.2 測試數(shù)據(jù)怎么準(zhǔn)備測試數(shù)據(jù)是UI自動化中最麻煩的環(huán)節(jié)之一。數(shù)據(jù)不變用例就穩(wěn)定數(shù)據(jù)一變用例就開始花式失敗。我總結(jié)下來有三類方案按優(yōu)先級排序。最脆弱的是直接在UI上創(chuàng)建數(shù)據(jù)比如注冊一個用戶然后去登錄。這種方式完全依賴UI如果頁面有問題數(shù)據(jù)就造不出來用例沒法繼續(xù)。最常用的是通過數(shù)據(jù)庫或接口直接準(zhǔn)備數(shù)據(jù)把前置條件在setup里完成用例本身只做驗(yàn)證。比如我要測登錄就在數(shù)據(jù)庫里先插入一條已知密碼的用戶記錄然后UI層直接登錄。這種方式的優(yōu)點(diǎn)是快、穩(wěn)但要求測試環(huán)境有對應(yīng)權(quán)限。純隨機(jī)數(shù)據(jù)生成適合用在驗(yàn)證輸入校驗(yàn)的場景比如用戶名長度限制、特殊字符過濾。但要注意隨機(jī)數(shù)據(jù)可能導(dǎo)致斷言不同比如頁面展示的是隨機(jī)字符串?dāng)嘌詴r就要通過參數(shù)化去比對。我自己的習(xí)慣是所有測試數(shù)據(jù)都通過fixture統(tǒng)一準(zhǔn)備讓數(shù)據(jù)準(zhǔn)備和業(yè)務(wù)測試解耦。用例只聲明“我需要一個已登錄用戶”至于這個用戶是數(shù)據(jù)庫造的、接口造的還是UI注冊的由fixture去決定。4.3 斷言粒度別把自己的命根子綁死在UI細(xì)節(jié)上斷言寫得好不好直接決定你的用例穩(wěn)定性。我很早之前吃過一個虧斷言一個列表頁的總數(shù)顯示為共100條結(jié)果產(chǎn)品改版把文案改成了100 records一條本來通過的用例突然全掛了而且是因?yàn)槲淖终故咀兞送耆簧婕斑壿媶栴}。從那以后我對UI斷言特別謹(jǐn)慎。我現(xiàn)在的原則是盡量斷言業(yè)務(wù)結(jié)果少斷言UI細(xì)節(jié)。登錄成功可以斷言跳轉(zhuǎn)后的URL包含期望路徑或者斷言頁面出現(xiàn)了只有登錄用戶才能看到的用戶名信息。支付成功可以斷言訂單狀態(tài)從“待支付”變成“已支付”而不是斷言某個按鈕顏色變了。當(dāng)然有一些UI特性本身就是測試對象比如按鈕在特定條件下是否可用、錯誤提示文案是否按預(yù)期出現(xiàn)這時候直接斷言這些細(xì)節(jié)是合理的。關(guān)鍵是區(qū)分清楚你在做業(yè)務(wù)驗(yàn)證還是在做樣式驗(yàn)證。一般來說業(yè)務(wù)驗(yàn)證的優(yōu)先級遠(yuǎn)高于樣式驗(yàn)證。4.4 失敗證據(jù)鏈截圖、日志、視頻一個都不能少用例失敗不可怕可怕的是失敗了不知道怎么失敗的。一條沒有證據(jù)的失敗用例就只是一張紅牌你得花大量時間恢復(fù)現(xiàn)場、猜原因。所以我在項(xiàng)目落地時一定會搭建一套失敗自動取證機(jī)制。最基礎(chǔ)的是失敗自動截圖。用pytest的fixture可以直接實(shí)現(xiàn)pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs[driver] driver.save_screenshot(fartifacts/{item.name}_failure.png) with open(fartifacts/{item.name}.html, w, encodingutf-8) as f: f.write(driver.page_source)這里保存了兩樣?xùn)|西截圖和當(dāng)前頁面HTML。截圖能看出視覺上的狀態(tài)HTML能讓你分析DOM結(jié)構(gòu)兩者結(jié)合基本能定位八成的失敗原因。Playwright就更方便了直接內(nèi)置了page.screenshot()和page.video()的支持把上下文存成視頻失敗之后整個操作過程都能回放。再往前一步把Allure報(bào)告接進(jìn)來給每個用例掛上截圖、日志、執(zhí)行步驟。配合CI定時任務(wù)跑完之后直接打開報(bào)告看附件排查效率會提升一個量級。4.5 CI集成無人值守跑用例才算自動化UI自動化跟CI結(jié)合才算真正發(fā)揮價(jià)值。我是把用例定時任務(wù)放在每天晚上第二天早上團(tuán)隊(duì)上班前執(zhí)行然后把結(jié)果報(bào)告自動推到團(tuán)隊(duì)的溝通群里。如果有失敗優(yōu)先看失敗用例的截圖和堆棧五分鐘內(nèi)就能定位是環(huán)境問題、數(shù)據(jù)問題還是代碼問題。執(zhí)行策略上我建議分兩套計(jì)劃一套是冒煙測試每次代碼合并到主干前手動觸發(fā)或合并時自動跑十分鐘到二十分鐘跑完核心流程另一套是完整回歸每天晚上跑全部用例用于隔夜驗(yàn)證。兩套計(jì)劃共用同一個測試工程只是通過pytest的-m標(biāo)記篩選不同的用例組。# 冒煙 pytest -m smoke --browserchrome --maxfail5 # 全量回歸 pytest -m regression --browserchrome --browserfirefox --alluredirallure-resultsmaxfail這個參數(shù)很關(guān)鍵它控制在遇到第幾個失敗時停止。通常我會設(shè)成5否則環(huán)境一旦出問題幾十條用例排隊(duì)失敗白白浪費(fèi)大量執(zhí)行時間。5. 實(shí)戰(zhàn)問題排查手冊5.1 偶發(fā)失敗先懷疑時序再懷疑定位偶發(fā)失敗是UI自動化最大的敵人也是最磨人心態(tài)的。一條用例有時候過有時候不過這時候很多人第一反應(yīng)就是去換定位表達(dá)式但其實(shí)大部分偶發(fā)問題不是定位問題而是時序問題。我總結(jié)的排查順序是先看失敗截圖頁面停在哪一步再分析這一步之前執(zhí)行了什么動作、有沒有異步請求沒完成。通常的規(guī)律是頁面里某個區(qū)域是接口返回后動態(tài)渲染的腳本點(diǎn)擊時接口還沒回來于是界面處于中間狀態(tài)。解決方案是把隱性等待拉長或者增加顯式等待條件針對特定元素等到期望狀態(tài)。如果時序加了還是偶發(fā)那就要從數(shù)據(jù)層面懷疑了這條用例跑的時候前置數(shù)據(jù)是否存在是不是與其他用例共享了數(shù)據(jù)導(dǎo)致被清理或變更。我經(jīng)常在數(shù)據(jù)集里發(fā)現(xiàn)一條用例把另一條用例需要的數(shù)據(jù)刪掉了結(jié)果兩條用例單獨(dú)跑都穩(wěn)定一起跑就一死一活。5.2 環(huán)境差異為什么你本地過了CI掛了“我本地明明過了CI里就掛”這句話可能是測試工程師每天說得最多的一句話。環(huán)境差異亙古存在無法消除只能盡量控制變量。首先是網(wǎng)絡(luò)差異。CI機(jī)器的網(wǎng)絡(luò)帶寬和延遲跟本地不一樣尤其是頁面引用了大量外部資源時加載時間會差很多倍。應(yīng)對方案是核心的顯式等待盡量放寬并且把頁面加載策略設(shè)置好比如忽略不必要的資源加載。其次是瀏覽器差異。CI通常跑headlessheadless模式下字體渲染、窗口尺寸、滾動條行為都和真實(shí)瀏覽器不完全一致頁面里某些元素的位置、尺寸甚至可見性都會有細(xì)微差別。應(yīng)對方案是統(tǒng)一設(shè)置窗口大小不要依賴某個具體分辨率下的坐標(biāo)。再次是系統(tǒng)差異。Windows和Linux下的字體不同可能導(dǎo)致文本換行位置不同、元素高度變化布局一變化某些依賴相對位置的定位就會失效。這就需要盡量少用絕對坐標(biāo)定位多用元素相對關(guān)系。5.3 維護(hù)成本失控的三類信號任何一套自動化系統(tǒng)都會面臨維護(hù)成本上升的問題但它通常是緩慢累積的不回頭復(fù)盤根本感覺不到。我建議定期關(guān)注三個信號用例總量是不是只增不減失敗率是不是長期超過3%到5%每次版本改動后需要修改的用例是不是集中在同一批頁面。三條里占了兩條就說明你的自動化資產(chǎn)開始“沉淀壞賬”了。處理辦法是主動做自動化用例的“年度大掃除”。每過一兩個季度我會全線跑一遍用例不看執(zhí)行結(jié)果而是逐條審查用例本身還有沒有人在關(guān)注它的運(yùn)行結(jié)果如果一條用例連續(xù)一個月沒有失敗過同時覆蓋的業(yè)務(wù)也沒有變化它很可能已經(jīng)淪為僵尸用例刪掉也不可惜。與其維護(hù)一百條沉睡的用例不如留下三十條每次都真正有價(jià)值的核心用例這可能是UI自動化項(xiàng)目維護(hù)中最容易被忽視但最重要的一課。5.4 常見的Timeout類錯誤速查報(bào)錯信息常見原因處理建議NoSuchElementException定位表達(dá)式過期元素被動態(tài)渲染或iframe遮擋優(yōu)先檢查iframe其次用相對定位或contains模糊匹配ElementClickInterceptedException元素被彈窗、浮層、遮罩遮擋先關(guān)閉彈窗或改用ActionChains點(diǎn)擊ElementNotInteractableException元素存在但不可交互常因頁面還在加載動畫增加顯式等待等待元素可點(diǎn)擊StaleElementReferenceException頁面刷新后之前保存的元素引用失效重新獲取元素避免長時間保存元素引用TimeoutException等待條件在超時時間內(nèi)未滿足檢查前置接口是否正常數(shù)據(jù)是否到位等待條件是否設(shè)對這一張表是我日常排查問題的默認(rèn)清單絕大多數(shù)腳本穩(wěn)定性的問題都能在里面找到對應(yīng)項(xiàng)。真到了排查不出來的地步也不要硬撐視頻回放加接口日志基本能把每一幀交互過程還原出來。6. 最后想說的幾句話做UI自動化這幾年我最大的感受是它拼的其實(shí)不是寫腳本的能力而是對穩(wěn)定性和可維護(hù)性的理解。只有用例穩(wěn)定執(zhí)行、失敗能快速定位、維護(hù)成本被控制住自動化才能在團(tuán)隊(duì)里真正被信賴否則很容易淪為大家口中的“花架子”。如果你剛起步建議從一條主流程用例開始練手先跑通再談鋪量。過程中一定要養(yǎng)成記錄問題的習(xí)慣尤其是那些偶發(fā)失敗每解決一個就沉淀進(jìn)自己的排查清單。日積月累你會發(fā)現(xiàn)很多看起來玄乎的問題在經(jīng)驗(yàn)面前其實(shí)都有跡可循。