三個月後我的自動化測試變成了維護地獄

三個月後我的自動化測試變成了維護地獄 目錄 1. 我把所有測試都自動化了 2. 三個月後發生了什麼 3. 自動化適合什麼，不適合什麼 4. 我現在的策略 5. 結尾 我把所有測試都自動化了 Google 工程師在 2016 年的 Testing Blog 公開指出，他們的 CI 系統每天處理數以百萬計的測試，其中約有 1.5% 是 flaky test ——這些不穩定的測試，比完全沒有測試更危險，因為它讓整個團隊對 CI 燈號失去信心。我花了三個月才親身理解這個道理。 剛接到「建立 App 自動化測試」這個任務的時候，我非常有衝勁。 我花了兩週把 Appium 架好，寫了一套能跑的腳本，然後開始把手上的測試案例一個一個搬進去。登入流程、計時種樹、森林主頁、硬幣入帳、訂閱解鎖。能動的我都自動化了，最後大概 120 個測試案例。 跑完一次全部，CI 燈全綠。 我覺得我做了一件很厲害的事。 三個月後發生了什麼 三個月後，我的 CI 每次跑完大概有 20–30 個 test 是紅的。 不是因為真的有 bug，是因為： RD 改了某個按鈕的文字，我的 XPath 抓不到 動畫沒跑完，find element timeout 模擬器跑得比真機慢，等待時間不夠 App 的某個 dialog 偶爾出現，腳本沒有處理 每次 CI 紅了，我都要花時間確認：「是真的 bug 還是 flaky test？」 慢慢地，我跟 RD 都開始不相信 CI 的結果。「又紅了，可能是 flaky 吧。」然後就繼續 merge。 自動化測試變成了背景雜訊。 Capgemini《World Quality Report 2023》指出，測試腳本的維護成本是 QA 效率最大的隱性消耗，許多團隊超過三分之一的測試工作量花在維護而非驗證上。 那個階段，我大概 60% 的 QA 時間在修腳本，40% 才是真正在測試。 適合什麼，不適合什麼 出了那段經歷之後，我才去認真想「App 自動化適合測什麼」這個問題。 適合自動化的： 穩定、重複、有明確預期結果的流程。 登入/登出（每個 release 都要跑，邏輯不會改） 核心付款流程（不能壞，每次都要確認） API 回應格式驗證（不依賴 UI，穩定） 帳號權限邊界（不同角色看到不同畫面） 這類測試的共同點： UI 結構幾乎不動、結果非對即錯、手動跑很無聊但不能跳 。 不適合自動化的： 新功能的探索性測試（UI 還會改，locator 會爛） 視覺品質（自動化很難判斷按鈕對不對齊、顏色對不對） 複雜的使用者行為情境（「用戶可能會這樣操作」這類直覺，AI 和腳本都沒有） 只跑一兩次的場景（維護成本 省下的時間） 有一篇 Medium 文章說得很準：「Tools that feel easy in week one often show their real cost months later.」我在第三個月就感受到了。 我現在的策略 現在我的 App 自動化只維護三層： 第一層：Smoke Test（每次 build 都跑） 5–8 個測試，只驗核心流程能不能動： App 能正常啟動 登入成功 首頁資料有載入 核心功能頁面能打開 這層跑完只要 3 分鐘，紅了就是真的壞了。 第二層：Core Flow（每次 release 前跑） 20–30 個測試，完整跑幾條最重要的業務流程： 計時完成 → 硬幣入帳 → 樹木出現在森林 IAP 訂閱購買 → Pro 功能解鎖 關鍵帳號狀態驗證（連結帳號 vs 本地帳號） 這層維護最花時間，所以我只挑真的不能壞的功能放進來。 第三層：探索性測試（手動） 新功能、視覺、邊界條件、奇怪的操作組合——這些我不寫腳本，我自己跑。 模擬器 vs 真機 這個選擇讓我在早期踩了很多坑。 模擬器快、免費、好設定，所以我 CI 一開始全部跑模擬器。 結果是：模擬器上全綠的東西，在真機上有時候行為不一樣。網路切換、記憶體壓力、不同 Android 廠商的 UI 差異、某些手勢——模擬器都不會有，真機才會出現。 我現在的做法： Smoke Test → 模擬器（快，夠了） Core Flow → 至少一台真機（iOS 一台、Android 一台） 出 bug 的裝置型號 → 加進 CI 的真機池 不需要覆蓋所有裝置，但必須有真機。 Flaky Test 的根本解法 我後來把那些反覆紅掉的 test 全部翻了一遍，問題幾乎只有三個： 1. 等待策略寫錯 用固定 sleep 等待是最常見的問題。頁面快的時候浪費時間，慢的時候又不夠。 2. Locator 太脆 XPath 寫死 index 或依賴 UI 層數，一改就爛。改用 resource id 或 accessibility id，跟 RD 說好加上去。 3. 測試之間有相依性 Case A 跑完留下的資料狀態影響 Case B。每個 test 要能獨立跑，跑完自己清乾淨。 解決這三個問題，我的 flaky rate 從大約 25% 降到 5% 以下。剩下的 5% 幾乎是真正的 bug。 結尾 自動化測試的投資報酬率，不是看你寫了多少支腳本，是看你維護那些腳本花了多少時間。 120 個測試但有 30 個是 flaky，還不如 30 個穩定的測試。 我現在每次要新增自動化案例之前，會問自己：「這個測試六個月後還會跑嗎？如果 UI 改了，我願意花時間更新它嗎？」 答案是否的話，就不要寫。手動跑一次，繼續下一個。 維護成本是自動化測試最常被低估的部分。寫腳本很快樂，但讓它在六個月後還能用，才是真正的工作。 參考資料 Google Testing Blog：Flaky Tests at Google — Google 對 Flaky Test 問題的研究與應對策略 Capgemini World Quality Report 2023 — 全球軟體品質現況年度報告 Martin Fowler：Test Pyramid — 自動化測試分層策略的基礎概念 Appium 官方文件 — Appium 跨平台行動測試框架 DORA 2024 研究報告 — 自動化測試與 CI 對軟體交付效能的影響