報到前我畫了 16 個元件的自動化架構，最後只做了 3 個

報到前我畫了 16 個元件的自動化架構，最後只做了 3 個 還沒報到，我就先畫了一張圖。 那時候我知道新團隊的自動化是零：有人研究過 Katalon，還在初學階段；iOS 工程師用原生語言自己寫一些 UI testing。我想讓新主管在我報到前就知道「我打算怎麼做」，所以把我知道的工具全部擺上去：腳本工具兩套、實機加雲端裝置、CI、AI 視覺測試、案例管理平台、報表、Grafana、寄信服務、自己寫的測資微服務……數一數，16 個元件。 現在回頭看，真正跑起來的只有 3 塊。如果你剛被丟一句「我們來做自動化吧」，可以直接跳到第五段。 本文地圖 一、藍圖：16 個元件，每個都想解決一個問題 照用途分： | 層 | 元件 | 原本想解決的問題 | | | | | | 腳本 | Katalon、pytest | Katalon 給還不熟程式的人錄流程，pytest 負責核心功能 | | 執行 | Appium 實機、BrowserStack 雲端裝置 | 自己的手機跑日常，雲端補機型 | | CI | GitHub Actions | 填版號就能跑完整輪，不用每次開終端機 | | 執行輔助 | Proxyman、裝置管理平台 | 攔封包看 API；集中管裝置、收 log | | 測資 | Python FastAPI 微服務、PostgreSQL | 統一產測資（隨機資料、翻譯、圖像辨識），存測試場景要的資料 | | 報表 | ReportPortal、Grafana | 收集與分析測試結果；算腳本數量、做長期趨勢 | | 通知與儲存 | 寄信服務、檔案儲存（minio） | 寄自動化結果；存截圖錄影 | | 管理 | 案例管理平台 | 管案例、標記哪些是手動、哪些已自動化 | | 其他 | AI 視覺測試、服務健康度檢查 | 用 AI 比對畫面；Web 服務掛了先通知 | 每一格單看都合理。問題是全部加起來，一個人要顧 16 個系統的安裝、升級、帳號、權限，還有它們之間的串接。 藍圖的用途是讓主管知道你的方向，不是施工清單。 二、真正落地的 3 塊 圖說：我交出去之前實際在跑的架構。虛線框是藍圖上有、但沒做的部分。 ① 一台 Mac mini 接實機 一台 Mac mini，上面接 2 台 Android、1 台 iPhone。pytest 腳本和 Appium Server 都在這台機器上跑。 沒選雲端裝置，是因為月費太貴。實機的代價是要自己顧（後面講坑），但至少是一次性的成本。 ② Self hosted GitHub Actions Mac mini 同時是 GitHub Actions 的 self hosted runner。觸發方式是手動 workflow dispatch，帶兩個參數：版號、平台。 拿到 build、填版號、按下去，一輪跑完大概 1～2 小時。 ③ ReportPortal ReportPortal 用 docker 自架，由 DevOps 負責維運，我只管測試這一端怎麼接。 三塊裡面我覺得它最值得。我要的是一個主管和團隊打開就看得懂的 dashboard。只有我看得懂的 HTML 報告，等於沒有報告。失敗截圖、歷史趨勢、失敗分類都放在同一個地方。 三、其他的為什麼沒做 | 元件 | 為什麼不做 | | | | | Katalon | pytest 統一開發，不要維護兩套 | | 雲端裝置 | 月費太貴，實機夠用 | | Grafana | ReportPortal 的 dashboard 已經能看趨勢和通過率 | | 案例管理平台 | 案例已經在別的工具管了，不需要再多一個 | | 檔案儲存（minio） | ReportPortal 本身就能附截圖 | | AI 視覺測試、裝置管理平台、測資微服務、健康度檢查 | 規模還沒大到用得上 | Katalon 原本想讓不熟程式的人錄流程，跟 pytest 分工。但兩套工具就是兩份 locator、兩套環境要顧，後來決定 pytest 統一開發。 其他的理由幾乎都是同一句：規模還沒大到用得上。三台實機不需要裝置管理平台；一個 ReportPortal 就看得到趨勢，不需要再架 Grafana。 工具加一個，維護成本就多一份：安裝、升級、帳號、故障排除。 四、實機自己顧，這四個坑都踩過 省下雲端月費的代價，是下面這些都要自己處理： | 坑 | 症狀 | 先查什麼 | | | | | | WDA 跑不起來 | iOS session 建不起來，卡在 WebDriverAgent build 或啟動 | xcodebuild 的第一個簽署錯誤、裝置信任、Developer Mode | | iOS 憑證過期 | 昨天還好好的，今天 WDA 裝不上去 | Xcode 的 Team、provisioning profile 到期日 | | 裝置斷線 | 跑到一半 session 掉了 | adb devices、Xcode 裝置清單、USB 線和 hub | | Runner 卡住 | workflow 一直 queued 或跑不完 | runner 服務狀態、上一輪有沒有殘留的 Appium／WDA process | 四個裡面 WDA 最痛。Android 接上線、開 USB 偵錯就能跑；iOS 要過簽署、信任、Developer Mode 好幾關，Xcode 或 iOS 一升級，常常又要重來一次。 後來我的做法是兩件事： 固定 Xcode 版本 ，不跟著自動更新； WDA 預先 build 好 ，跑測試時直接用（XCUITest driver 的 appium:usePrebuiltWDA），不讓每次建 session 都重新 build。環境不動，WDA 就少出事。 五、從零開始，我會照這個順序 如果重來一次，我會直接畫最小可行版，其他元件標成「規模到了再加」： 1. 先讓一條腳本在一台實機上跑通 不管 CI、不管報表，先證明 Appium 能穩定操作你的 App。 2. 接上報表 結果能被別人看見，自動化才開始有價值。 3. 串進 CI 讓「填版號、按按鈕」就能跑完整輪，不用每次手動開終端機。 4. 再根據痛點加元件 機型不夠才考慮雲端裝置；案例多到管不動才考慮管理平台。每加一個，都要回答「現在的哪個痛點會因此消失」。 六、心法 那張 16 個元件的圖沒有白畫。它讓新主管在我報到前就知道我要往哪走，也讓我自己想清楚每一塊在解決什麼問題。 一個人從零扛 App 自動化：從 16 個元件的藍圖，到「先求穩定」 三個月後我的自動化測試變成了維護地獄 Appium 搭配 pytest 完整實務：從 fixture 設計到 CI 執行 QA 工程師的第一條 GitHub Actions Pipeline 我用技術語言跟老闆報告自動化測試，他聽了三分鐘就去開別的會 參考資料 ReportPortal Documentation — ReportPortal 官方文件，含 docker 部署與 pytest agent About self hosted runners — GitHub 官方 self hosted runner 說明 workflow dispatch 事件 — 手動觸發與 inputs 參數 XCUITest Driver：Real Device Configuration — iOS 實機與 WDA 簽署設定