Android 裝置實驗室自動化：真機與模擬器 QA 流程

將少量 Android 手機和模擬器轉變為可重複的裝置實驗室，具有明確的啟動狀態、可觀察的檢查、有限的等待、故障證據以及明確的建造與購買規則。

簡短的答案：自動化操作循環，而不是貨架

當每次運行都從指定狀態開始、執行一次有界檢查、驗證後置條件並留下其他人可以查看的證據時，Android 裝置實驗室就會變得有用。電話、USB 集線器、支架和標籤只是實體層。 Android 裝置實驗室自動化是一個操作層，它將這些裝置轉變為可重複的發布、支援和本地化檢查。

如果您仍在選擇電話、電纜、電源或存儲，請從低成本 Android 設備實驗室設定指南開始。本文從硬體存在之後開始。它解釋瞭如何結合真實設備和模擬器、定義小型測試矩陣、創建設備運行卡、同步可觀察狀態、捕獲螢幕截圖和日誌，以及確定託管設備雲端何時是更好的選擇。

目標不是取代單元測試、Compose 測試、Espresso、UI Automator、Appium、Gradle 託管設備或 Firebase 測試實驗室。這些工具擁有不同的邊界。AI Android 自動化工具在這裡最有用，作為操作員、QA 審核人員和支援團隊需要理解的實際裝置檢查的可見工作流程層。

為真實設備和模擬器提供不同的工作

設備實驗室不需要對每台設備進行所有測試。模擬器可以快速建立、重置、參數化和並行運行。真實手機會暴露虛擬設備可能無法忠實再現的供應商韌體、實體攝影機、藍牙、生物辨識提示、熱行為、背景限制、通知傳遞、USB 狀態和輸入表面。利用這些差異來劃分責任，而不是爭論一個通用平台。

實用的入門模式是寬的虛擬層和窄的實體層。跨虛擬配置執行快速確定性檢查，然後透過為實際客戶風險選擇的兩到三部真實電話路由一個小型關鍵包。僅當故障資料顯示其他型號、Android 版本、區域設定或供應商行為更改了結果時才展開。

定義一個設備矩陣，每行一個原因

Firebase 測試實驗室將測試矩陣描述為所選設備和測試配置的組合。這個想法也適用於當地實驗室，但矩陣應該基於風險而不是詳盡無遺。每一行都需要一個理由、一個所有者和一個預期的決定。一款僅僅因為可用而存在的手機將悄悄消耗充電、重置和維護時間，而不會提高發布信心。

• 為主要發布路徑保留一個目前的 Android 基線。
• 保留一個較舊的受支援 API 等級以實現相容性和升級行為。
• 只有當其韌體、權限、電池策略或客戶份額產生明顯風險時，才會添加特定於供應商的真實手機。
• 當佈局和可訪問性很重要時，請新增小螢幕或高字體比例配置。
• 僅將區域設定、主題、方向、網路或帳戶狀態新增至其結果在該條件下可能變更的檢查中。
• 淘汰不再發現明顯缺陷或支援目前客戶群的矩陣行。

命名每行支援的決策：阻止發布、收集審查證據、重現支援案例或探索可疑的設備特定故障。該決定控制行需要多少可靠性、隔離性和報告。與受監督的探索性檢查相比，發布阻止程序需要更強的重置和斷言規則。

在編寫自動化之前創建運行卡

實驗室檢查的最小有用規格是運行卡。它可以防止隱藏的假設存在於操作員的記憶中，並為自動化提供穩定的契約。在選擇節點、選擇器或框架程式碼之前，用可觀察的術語編寫卡片。

不要將成功定義為一系列點擊。定義序列之後必須存在的可見或結構化狀態。 UI 佈局發生變化；業務後置條件更加持久。登入檢查成功是因為存在預期的帳戶狀態和主介面，而不是因為自動化點擊了按鈕原來所在的座標。

重置狀態而不刪除證據

共享裝置的失敗方式看起來像是應用程式缺陷：過時的帳戶、快取的同意、待更新、更改的權限、儲存空間不足、意外的鍵盤、開啟的系統對話方塊、通知覆蓋或結帳時中途留下的上一次運行。僅重置運行卡指定的狀態，並在恢復變更之前捕獲故障。

1. 在接觸狀態之前識別設備並建置。
2. 當上一次運行意外結束時捕獲當前螢幕。
3. 使用破壞性最小的重置將應用程式返回到聲明的啟動狀態。
4. 確認網頁、時間、儲存、方向、區域設定、字體比例和所需的權限。
5. 在第一個業務操作之前驗證開始狀態標記。
6. 如果多次重置失敗，則隔離設備；不要將基礎設施故障轉換為產品錯誤。

全面擦拭並不會自動變得更安全。它可能會破壞重現缺陷所需的確切狀態，並增加設定時間，從而鼓勵團隊跳過檢查。當全新安裝、升級安裝、登入、登出和復原帳戶路徑有不同風險時，請為這些狀態保留單獨的設定檔。

同步狀態而不是休眠更長時間

Android 的測試穩定性指南警告不要任意睡眠，因為裝置效能和非同步工作各不相同。對於繁忙的電話來說，固定延遲可能會太短，而對於快速電話來說，固定延遲可能會過慢。首選顯式等待有意義的條件，並在該條件從未出現時逾時和失敗工件。

• 應用程式啟動後，等待穩定的 UI 元素或螢幕狀態，而不是猜測的秒數。
• 點擊後，在發送下一個輸入之前驗證後置條件。
• 對真正需要民意調查的州使用有限重複；記錄超時的最終觀察。
• 將系統權限對話方塊、更新提示和 OEM 覆蓋視為命名分支，而不是隨機雜訊。
• 當可見狀態超出批准集時停止，尤其是在付款、刪除、同意或帳戶變更之前。

目前的萊彩 Flow合約遵循這個視覺化模型：UI觀察、OCR、範本匹配、螢幕截圖觀察狀態；輸入節點和指標節點執行一項操作；流節點處理等待、分支、有界循環、子流、返回和停止。將觀察、決策和行動分開可以使工作流程更易於審查且更安全地維護。

建造可讀的 萊彩 Flow 用於實驗室檢查

萊彩 Flow 是 萊彩投屏 內部的自動化功能。對於設備實驗室運行，請將主流程保持在 QA 審核員可以閱讀的級別：準備設備、打開目標、運行關鍵檢查、收集證據並完成。將多步驟技術細節放入小型子流程中，而不是暴露一長串匹配、選擇、點擊和等待。萊彩 Flow 指南解釋了設定檔和流程的組織方式。

1. 讀取連接的設備上下文並選擇預期的串行別名；不要假設第一個設備是正確的。
2. 在開啟或變更應用程式之前確認套件和目前的 UI 狀態。
3. 當可存取性資訊穩定時使用 UI 狀態，當可見文字是證據時使用 OCR，並且僅針對經過驗證的圖像目標進行模板匹配。
4. 在操作和隨後的螢幕相關觀察之間放置明確的等待。
5. 在更改螢幕或應用程式狀態的每個階段後檢查後置條件。
6. 僅當支援指定審核決策時才擷取螢幕截圖或錄音。
7. 傳回清晰的相位結果；噹噹前觀察結果不證明下一步操作合理時，停止運作。

在準備本指南期間，只讀來財上下文報告了 73 種可用節點類型和一部已連接的三星 Android 16 手機。這證實了目前的合約和設備感知路徑；它不是性能基準。在將設定檔視為發布基礎架構之前，請先驗證您自己的應用程式、裝置、資產和執行時間支援。

收集失敗資料包，而不是紅點

失敗的檢查應該回答運行的內容、運行的位置、系統觀察到的內容以及運行停止的原因。 Firebase 測試實驗室透過返回測試狀態以及可用的日誌、螢幕截圖和影片來公開有用的模型。本地設備實驗室需要相同的規則，即使其儲存更簡單。

• 運行 ID、時間戳記、工作流程版本、建置版本和環境。
• 裝置型號、Android 版本、穩定序列別名、螢幕尺寸、區域設定、主題和方向。
• 開始狀態，輸入夾具標識符，以及最後完成的業務階段。
• 預期的後置條件和實際選擇的 UI、OCR、影像或框架結果。
• 恢復前的螢幕截圖，僅在運動重要時進行簡短記錄，以及有限的相關日誌摘錄。
• 分類：產品缺陷、測試缺陷、設備基礎設施、資料、環境或需要手動審查。

使用穩定的檔案名稱和清單，而不是非結構化的螢幕截圖資料夾。在共享之前編輯個人或秘密資料。當故障周圍的短暫清理間隔足夠時，請勿上傳整個裝置日誌。證據應該減少下一個人的工作，而不會造成新的隱私或保留問題。

選擇能為他們贏得設備時間的支票

真實設備的分鐘數很少，因為設備需要充電、清理、更新和手動存取。將它們分配給可見或物理行為很重要的工作流程。好的第一個候選者是部署後煙霧檢查、權限和系統 UI 路徑、相機或藍牙設定、通知流、本地化證據、特定於供應商的回歸以及精確的支援複製。

使業務邏輯、解析、格式化和元件行為在更快速的測試中保持靠近程式碼。使用真實設備來證明這些測試無法實現的邊界：已安裝的版本、作業系統、外部應用程式、輸入介面、網路轉換或人類可見的組合。Android自動化測試工具比​​較有助於將每個需求分配到適當的層。

由五個可靠旅程組成的關鍵包比沒有人信任的五十個流程更有價值。從一條代表性路徑開始，測量重置和分類成本，然後僅在新檢查保護特定版本、客戶或營運決策時新增覆蓋範圍。

在擴展實驗室之前先對其進行測量

討論自託管設備場的團隊反覆返回相同的建置與購買輸入：佇列行為、峰值並發、等待時間、啟動或重置故障、維護工作以及僅出現在實體設備上的缺陷。在購買更多硬體或將所有內容遷移到雲端之前，請追蹤幾個發布週期的這些訊號。

• 按一天中的時間和工作流程優先權進行佇列等待。
• 設備利用率以及無法用於充電、更新或維修的時間。
• 按設備劃分的啟動狀態或重置故障率。
• 重新運行是由於自動化不穩定而不是產品變化引起的。
• 從失敗到有用分類的中位數時間。
• 僅在真實設備、特定供應商或特定 Android 版本上發現的明顯缺陷。
• 每次成功運行和每個維護的工作流程的操作員分鐘數。

這些是管理指標，而不是虛榮的儀表板。如果佇列等待時間很短但維護占主導地位，則託管服務可能會降低擁有成本。如果隱私、本地週邊設備、快速互動式調試或重複支援複製比廣泛的模型覆蓋更重要，那麼小型本地實驗室可能仍然是正確的重心。

使用混合構建與購買規則

本地實驗室和託管實驗室是互補的。 Gradle Managed Devices 可以在建置中定義虛擬設備並將其分組以進行測試執行。 Firebase 測試實驗室可以跨託管虛擬和實體設備擴展矩陣並返回託管工件。本地池提供即時存取、專有周邊設備、監督調試和用於定期操作檢查的穩定設備。

明智的混合在託管虛擬基礎設施上進行快速框架測試，將選定的兼容性檢查發送到託管的真實設備，並為高價值的實體或監督流保留一個小型本地工作台。正確的劃分可能會隨著並發、隱私和客戶設備證據的變化而變化。

Android 裝置實驗室自動化清單

1. 為每個設備矩陣行分配一個目的和決策。
2. 獨立的模擬器、本地真實設備、託管、框架測試和視覺流職責。
3. 建立包含建置、裝置、啟動狀態、輸入、後置條件、停止和證據的運行卡。
4. 在第一個業務操作之前驗證啟動狀態。
5. 等待可觀察到的情況，而不是增加更長的盲目睡眠。
6. 將觀察、決策和設備操作作為單獨的可檢查步驟。
7. 在重置或恢復更改故障之前捕獲證據。
8. 將基礎設施、資料、測試、環境和產品故障分別進行分類。
9. 追蹤隊列、利用率、重置可靠性、不穩定的重新運行、分類時間和純物理缺陷。
10. 當證據支持時，使用本地和託管混合策略。

從一部真實的電話、一種模擬器配置和一張關鍵業務運行卡開始。在添加其他設備或工作流程之前，使該循環可靠且可審查。當可觀察的裝置實驗室層適合您的團隊時，請使用 萊彩 Flow探索AI Android 自動化，並將實現細節保留在本地化感知流程指南中。

編者註：BeePOS LLC（萊彩投屏 背後的公司）使用下面連結的官方 Android 和 Firebase 文件、目前只讀 LaiCai 產品合約以及公共 QA 討論來研究本指南。產品功能的識別與中立的工作流程指南分開。問題或更正可以發送至support@laicaiapp.com。

• Android 開發人員：使用 Gradle 託管裝置擴充您的測試
• Android 開發者：測試穩定性
• Firebase 測試實驗室：Android 測試入門
• Reddit r/QualityAssurance：維護 Android 模擬器基礎設施
• Android Developers: UI Automator