多台手機自動化測試怎麼規劃？從狀態機、設備實驗室到網路拓樸

先講結論：多台手機自動化測試的核心，不是讓操作「像人」或躲過平台偵測，而是讓每一次授權測試都可重現、可觀測、可回溯。當設備從幾台增加到數十台，最先失控的通常不是點擊 API，而是流程維護、網路容量與失敗定位。

本文把原本常被稱為「群控」的問題，重新放回 QA 與 Growth Engineering 的脈絡：如何建模工作流程、如何分配測試情境、如何設計設備實驗室，以及如何用數據判斷是否值得擴容。

範圍聲明：以下內容只適用於你擁有或獲得明確授權的 App、測試帳號與設備。假互動、未經同意的群發訊息、帳號農場、規避平台風控或反女巫機制，都不在本文範圍內。

為什麼線性腳本一多就難維護？

最初的測試腳本通常長這樣：開啟 App、登入、滑動、點擊、截圖、結束。只要案例少，線性流程很直觀；但當你要加入權限拒絕、網路中斷、返回上一頁或不同裝置尺寸，分支會快速膨脹。

常見症狀包括：

• 修改一個步驟，連帶影響多支腳本。
• 失敗只留下「第 37 台失敗」，沒有狀態、版本與輸入資料。
• 所有設備同時執行同一條流程，測試覆蓋率看似提高，實際上只是在重複相同案例。

這時候可以把每個畫面或業務階段視為狀態，把允許的下一步視為轉移。重點不是增加隨機，而是把規則寫清楚。

用狀態機取代寫死的流程

馬可夫鏈是一種以當前狀態計算下一個狀態的模型；在測試工程裡，更實用的做法是把它當成帶權重的狀態機。例如登入流程可以定義：

當前狀態	下一狀態	權重／條件
launch	login	App 啟動成功
login	home	憑證有效
login	permission_prompt	首次安裝
home	detail	抽到內容案例
home	offline	注入網路故障
detail	home	返回操作成功

每個轉移都應該有完成判準，例如元素存在、API 回應碼正確或畫面截圖符合基準。這讓測試控制器只負責讀取狀態與呼叫執行器，新增案例時不必複製整條流程。

用固定種子保留差異，也保留重現能力

測試需要差異化，但不能使用無法重現的真隨機。建議為每個測試案例建立 run_id，再以 suite_id + device_id + run_id 產生固定種子：

1. 測試編排器決定本輪要覆蓋的狀態與權重。
2. 種子決定可重現的選擇順序，例如先測權限拒絕，再測離線恢復。
3. 失敗時保存種子，下一輪可以精準重播同一路徑。

這和「把每台設備偽裝成不同使用者」是兩回事。差異的目的是擴大測試覆蓋率，不是躲避任何平台的偵測。

設備角色：用覆蓋率分配，不用「人設」分配

設備數量增加後，先定義角色比先買硬體重要。可以從三類開始：

• 基準設備：固定 OS、解析度與版本，作為回歸測試基準。
• 邊界設備：覆蓋低階硬體、不同螢幕尺寸、語言與輔助功能設定。
• 故障注入設備：專門驗證離線、延遲、權限拒絕與 App 被中斷後的恢復。

每個角色都要對應可量化的案例，例如「本輪至少覆蓋 4 種 OS、2 種網路狀態、100% 核心付款流程」。不要用「活躍型」「保守型」這類無法驗證的描述。

控制器、執行器與觀測層

一套可維護的架構，至少拆成三層：

1. 控制器（Controller）：排程、分配案例、管理重試與併發上限。
2. 執行器（Executor）：把抽象動作轉成 Appium、ADB 或其他授權測試介面的操作。
3. 觀測層（Observer）：集中保存日誌、截圖、錄影、效能指標與錯誤堆疊。

每筆結果至少帶上 run_id、裝置識別碼、App 版本、測試案例、狀態、開始／結束時間與錯誤分類。這些欄位讓你能回答「哪個版本在哪一類設備失敗」，而不是只知道「有幾台紅燈」。

網路拓樸：先算容量，再談設備數量

設備實驗室常見的基礎拓樸如下：

graph TD
  ISP[ISP / 光纖數據機] --> FW[防火牆或軟路由]
  FW --> MGMT[管理網段]
  FW --> SW[可管理交換機]
  SW --> VLAN1[基準設備 VLAN]
  SW --> VLAN2[邊界設備 VLAN]
  SW --> VLAN3[故障注入 VLAN]

子網與 DHCP

/24 網段通常可提供 254 個可用 IPv4 位址；/23 則可提供約 510 個。實際可用數量仍受保留位址、管理介面與 DHCP 租約影響。擴大網段前，先確認軟路由的 LAN 位址、子網遮罩與 DHCP 範圍一致；只改 DHCP 範圍而不改 LAN 子網，會造成路由與互通問題。

頻寬估算

用「同時傳輸量 × 每台平均需求 × 安全係數」估算，而不是用設備總數直接猜。假設 40 台設備同時下載，每台平均 2 Mbps，並預留 25% 緩衝：

40 × 2 Mbps × 1.25 = 100 Mbps

這只是容量模型，不是保證值。上傳影片、系統更新與日誌回傳要另外估算，並用尖峰時段的 95 百分位流量驗證。若延遲或丟包才是瓶頸，單純升級頻寬不會解決問題。

故障隔離與驗收指標

設備一多，局部故障很容易變成全域中斷。建議至少做到：

• 管理、測試與故障注入流量分 VLAN，設定明確的 ACL。
• 交換機、軟路由與供電設備記錄 CPU、溫度、封包遺失與連線狀態。
• 重試要有上限與退避，避免故障時把流量放大。
• 以「案例通過率、平均執行時間、重試後成功率、每台設備可用率」作為擴容門檻。

當失敗率上升，先用 run_id 與網路指標判斷是 App 回歸、設備資源不足，還是拓樸瓶頸，再決定要改腳本或加硬體。

何時自己做，何時買工具？

如果你只有少量回歸案例，雲端裝置農場或既有測試服務通常更快；若需要長期保留特定硬體、注入私有網路故障，才值得建置自有實驗室。評估時比較的是：

選項	適合情境	主要代價
雲端裝置服務	短期、多 OS 覆蓋	每次執行費、私網限制
自建設備實驗室	固定硬體、長期回歸	維運、供電、網路與折舊
客製控制平台	有特殊流程與權限需求	開發與觀測成本

如果你的目標是建立可轉換的產品或服務，先把測試規格、資料保留與權限流程寫進 技術實作服務，再決定採購清單，通常比先買一整排設備更省返工。

小結：把「群控」改寫成可驗證的工程問題

多台手機不是越多越好。先用狀態機整理流程，用固定種子讓差異可重播，再以設備角色、網路拓樸與觀測指標驗收，才能知道擴容到底帶來多少測試價值。

如果你正在處理跨裝置回歸、測試環境或成長產品的事件追蹤，可以從 技術分類 查看相關方法。