為什麼 App 自動化比 Web 難

公司決定導入 App 自動化的時候，這件事是從零開始的：沒有現成的框架，也沒有前人留下的腳本。入職時我先把整體架構規劃好，從測試框架、報表到 CI，再開始寫第一支測試。 第一支寫的是登入。它跑過了，然後接下來有好一段時間，我的日常是這樣的： 測試一直 flaky，今天過、明天掛，重跑又過 App 改版很快，腳本修好沒多久又壞 公司期待的時程和測試數量，我追不上 時間都花在修 flaky，根本擠不出時間寫新測試 這幾件事同時發生，而且互相加重。後來我跟主管坐下來一起討論 root cause，得到的結論有點出乎意料： 大部分的不穩定，問題不在腳本，在 App 本身。 元件不一定「看得到」 Web 有 DOM，元件的存在與可見性是結構化、可查詢的。原生 App 沒有這層保障，要靠 App 把元件資訊暴露給 accessibility tree，自動化工具才找得到。 我遇到的狀況大概分三種： 沒有 accessibility id。 元件找得到，但沒有穩定的 id，只能靠文字、XPath 或層級去抓。文案一改、多一層 layout，locator 就斷。 整頁沒有元件結構。 有一個核心頁面是整頁自己繪製的，dump 出來整頁只有一個全螢幕節點，文字、描述、resource id 全部是空的，連主要按鈕都沒有自己的節點。自動化最該保護的流程，偏偏在這裡最看不見。 WebView 和原生互換。 同一個畫面某一版從 WebView 改成原生元件（或反過來），locator 一夕之間全部失效。後來我診斷 locator 壞掉，第一步都是先看最近的 commit，確認畫面是不是換了技術。 這些都不是寫腳本的人能單方面解決的。我有推開發在元件上加 id，但排不進他們的時程，進度很慢。等不到的部分，只好自己在腳本這邊繞過去：圖片比對、OCR、座標。 繞得過，但有代價。後來盤點整個專案的 locator，靠文字、圖片、XPath 的占了一大塊，這些就是每次改版最先斷的地方，維護工時大部分花在這裡。 裝置與 OS 碎片化 Web 的主戰場是瀏覽器，Chrome 佔了大半市場，主流版本差距不大，頂多加一條 Safari 就覆蓋絕大多數使用者。 App 的主戰場是裝置。Android 要支援的 OS 版本可能橫跨三到四個大版本，不同廠商又各自改了系統，同樣的 click() 在不同品牌上的行為細節可能不一樣。有的 App 還會分成不同版本的安裝包，不同裝置要裝不同的包，裝錯包，測試從第一步就不對。 iOS 相對收斂，但有自己的坑：每次 Xcode 大版本更新，XCUITest 的底層行為就可能悄悄改變。 所以一支測試要在多組裝置上都穩定跑過，不能只靠一台模擬器驗收就放行。 非同步渲染：找到不等於可以點 iOS 和 Android 的渲染是非同步的。畫面還在組裝，accessibility tree 裡已經有節點了，但它可能還不能互動。這時 find element 找到就立刻 click()，結果是點了沒反應，或直接丟出 exception。 找到就點。畫面還沒穩，可能丟 exception，或點了沒反應。 等到「可以點」才點。等待策略後面有一篇專門講。 這種情況在 Web 上少得多，在 App 上幾乎是日常。很多 flaky 的問題出在時機，邏輯本身沒錯。 環境難搞、啟動成本高 起一個 Selenium session 大概一兩秒。起一個 Appium session，emulator 冷啟動要三十秒到一分鐘，再加上安裝 APK 和 Appium server 啟動，光是「還沒跑任何測試」就可能過了快兩分鐘。 真機比 emulator 快，但有連線穩定性的問題，放到 CI 上更難管。雲端裝置農場解決了機器的問題，卻多了網路延遲、帳號配額、計費壓力。 這個啟動成本會直接影響後面的設計：fixture 要怎麼設計，才不會每個 test 都重啟 session？哪些 case 可以共用 session、哪些必須獨立？這關係到測試能不能在合理時間內跑完。 我後來改掉的目標 跟主管討論完 root cause，我們做的第一件事不是修哪支腳本，而是重新談期待： 先求穩定，不求數量。 一套一直 flaky 的測試，數量越多，要修、要跑、要看報告的成本就越高，最後大家就不信報表了。穩定下來以後，綠燈才有意義，紅燈才會有人去看。 這套框架到現在是我一個人在維護，測試數量也就停在現在的規模。以一個人維護來說，這已經接近上限，接下來我只求守住。 這個系列會講什麼 App 自動化變數多，沒本錢靠蠻力撐。這個系列就是我這段時間用來撐住它的方法： locator 策略：在 App 沒給 id 的情況下，怎麼排定位方式的優先順序 Page Object：讓 UI 改版時只需要改一個地方 fixture 設計：把 session 啟動成本控制住 等待策略和 flaky 量測：讓「綠燈」重新變得可信 報表和 CI：讓主管和團隊看得到結果，也知道什麼時候不該相信它 下一篇先從 Appium 的運作原理講起。