雲端真機：設備農場能幫什麼、我最後怎麼用它

你的測試在 Pixel 7 上跑得穩，上線後卻收到 Samsung A14 的 crash 回報。買一支回來跑？然後再來一支 Xiaomi？設備這條路沒有終點。設備農場是業界常見的解法。不過我自己最後的用法，跟一般建議不太一樣。 本機真機的維護地獄 維護幾支真機乍看簡單，機型一多就開始出問題： | 痛點 | 實際情境 | | | | | 充電管理 | 測試伺服器旁掛 10 支手機，有人拔錯線整輪 CI 少一台 | | OS 更新 | Android 14 推送，三台自動更新，Appium driver 相容性炸掉 | | USB 連線 | adb devices 回空，重插還是空，重開機才恢復 | | 機型覆蓋 | 你買得到的永遠不是使用者手上那支 | 機器一多，維護的時間很容易比寫測試的時間還多。設備農場（Device Farm）就是把這個維護責任整個轉移出去。 雲端設備農場 BrowserStack、Sauce Labs 這類平台在雲端維護上百種真機，你只要用 capabilities 指定機型，Appium session 就跑在那台實體裝置上。 關鍵設計是 用環境變數切換 endpoint 和 caps ，本機和雲端共用同一份測試程式碼： bstack:options 是 BrowserStack 的 vendor namespace，裡面的 deviceName / osVersion 對應平台的機型列表。BS USER 和 BS KEY 存進 CI secrets，不寫死在程式碼裡。 切換到不同機型只要改 deviceName 和 osVersion，不需要更動任何測試邏輯。 同一套 POM 兩邊跑 POM 和測試案例完全不知道 driver 從哪裡來，它們只接受一個 driver 物件。這正是 fixture 那篇把 driver 抽出來的好處。 把切換邏輯收進 conftest fixture： 測試和 Page Object 完全不動： 本機跑：pytest tests/ 雲端跑：USE CLOUD=1 BS USER=xxx BS KEY=yyy pytest tests/ 同一份 POM，切機型只改環境變數。 取捨 雲端也有代價，選錯場景反而更慢更貴： | 面向 | 本機 / 模擬器 | 雲端設備農場 | | | | | | 速度 | 快，session 幾秒建立 | 較慢，排隊 + 串流延遲 | | 成本 | 硬體一次性，維護自負 | 按分鐘計費，機型多時費用高 | | 機型廣度 | 受限於手上裝置 | 上百種真機隨選 | | 除錯便利性 | 直接 adb logcat，截圖本機 | 遠端 log，除錯路徑較長 | | 維護責任 | 自己扛 OS / driver 相容 | 平台維護，你只管 caps | 一般的建議是這樣分工： 開發期用本機模擬器跑 smoke ，iteration 快； CI 全機型回歸用雲端 ，覆蓋那些你不會去買的機型。 我實際的用法：拿來補手動測試的機型 上面的設定我都做過，框架裡也有一個專門標雲端測試的 marker。但老實說，我的自動化幾乎沒有在雲端跑。 雲端裝置在我手上主要的用途，是 手動測試時補機型覆蓋 。有使用者回報某個我手邊沒有的機型出問題，我就開一台雲端裝置，手動重現、手動驗證。這個用途很實在，也不需要任何腳本。 自動化這邊，我的測試跑在自己手邊的裝置上。這跟我整體的判斷有關：這套框架是我一個人維護，每多一種執行環境，就多一套要顧的東西。雲端上會有它自己的連線問題、排隊、機型差異，出了問題我得判斷是腳本、App，還是雲端平台的狀況。本機裝置的坑我已經很熟了，各種救援腳本也都寫好了。 時間太長，不是加機器的理由 大家想用雲端跑自動化，常見的另一個理由是「平行跑比較快」。這條路我也刻意沒走。 我的原則是： 全量測試超過 30 分鐘，就該回頭檢查測試本身，而不是加機器 。我會照這個順序處理： 1. 分層 ：平常只跑 p0，全量留給發版前 2. 刪測試 ：一個月沒跑過的、跟其他測試重複的，刪掉 3. 往下推 ：業務邏輯改在 API 或資料庫層驗證，不要用 UI 再測一次 加機器是最後的手段。平行跑會換來一整套新的問題：多台裝置怎麼管、每台用哪組帳號、測試之間會不會互搶資料。一個人維護，這些新問題的成本比省下來的時間還高。 這不代表雲端設備農場不好。團隊有人專門顧基礎設施，或是機型覆蓋真的是你們最大的痛點，它就很值得。只是對一個人維護的框架來說，我選擇把它用在最省事、最有價值的地方：手動測試時，借一台我手邊沒有的手機。