本頁面提供疑難排解說明,以及使用 Firebase Test Lab 執行測試的常見問題解答。已知問題也會記錄在內。如果找不到所需資訊或需要其他協助,請加入 Firebase Slack 的 #test-lab 頻道 ,或與 Firebase 支援團隊 聯絡。
疑難排解
為什麼測試要這麼久才能執行?
在 Test Lab 目錄中選取容量等級較高的裝置,測試可能會更快開始。如果裝置容量不足,測試可能需要較長時間才能執行。如果叫用的測試數量遠大於所選裝置的容量,測試可能需要較長時間才能完成。
在任何裝置容量層級執行的測試,都可能因下列因素而需要較長時間:
流量,這會影響裝置可用性和測試速度。
裝置或基礎架構故障,隨時可能發生。如要查看 Test Lab 是否有回報的基礎架構問題,請前往 Firebase 狀態資訊主頁 。
如要進一步瞭解 Test Lab 的裝置容量,請參閱 Android 和 iOS 的裝置容量資訊。
為什麼我會收到不明確的測試結果?
測試結果不確定通常是因為測試執行取消或基礎架構錯誤。
基礎架構錯誤是由內部 Test Lab 問題引起,例如網路錯誤或非預期的裝置行為。Test Lab 會在內部重試多次產生基礎架構錯誤的測試執行,然後才回報不確定的結果;不過,您可以使用 failFast 停用這些重試。
如要找出錯誤原因,請按照下列步驟操作:
在 Firebase 狀態資訊主頁 查看已知的服務中斷情形。
在 Test Lab 中重試測試,確認是否可重現。
注意: Test Lab 不會針對基礎架構錯誤向您收費。
如果可以,請嘗試在其他裝置或裝置類型上執行測試。
如果問題仍未解決,請在 Firebase Slack 的 #test-lab 頻道 中與 Test Lab 團隊聯絡。
為什麼資料分割會導致測試執行時間變長?
如果指定的資料分割數量超過 Test Lab 中可用的裝置數量,資料分割可能會導致測試執行時間延長。如要避免這種情況,請改用其他裝置。如要進一步瞭解如何選擇其他裝置,請參閱
裝置容量 。
為什麼測試要很久才會開始?
提交測試要求時,系統會先驗證應用程式、重新簽署等,為在裝置上執行測試做好準備。一般來說,這項程序會在幾秒內完成,但可能會受到應用程式大小等因素影響。
應用程式準備就緒後,系統會排定測試執行作業,並將其保留在佇列中,直到裝置準備好執行為止。在所有測試執行作業完成前,矩陣狀態都會是「Pending」(無論測試執行作業是在佇列中,還是正在執行)。
為什麼測試需要很長時間才能完成?
測試執行完畢後,系統會從裝置下載測試構件,處理後上傳至 Cloud Storage 。這個步驟所需的時間可能會受到構件數量和大小的影響。
Android 專屬疑難排解
應用程式未傳回資料,且找不到螢幕截圖
測試執行構件 (例如螢幕截圖和記錄檔) 會儲存在 Google Cloud Storage 中,並直接顯示在 Firebase 控制台中。如果測試執行是在過去 90 天內執行,請確認您已指派專案層級角色 (專案擁有者、專案編輯者或專案檢視者)。此外,請確認專案或組織未啟用 Cloud 稽核記錄。
如果執行作業是在 90 天前進行,測試構件很可能已自動刪除。如要查看結果 bucket 設定,請按一下 Test Lab 資訊主頁中的「Test results」(測試結果) 分頁標籤。預設結果 bucket 設為保留物件 90 天。
如要延長測試構件的保留時間,請執行 gcloud firebase test android run 指令並加上 --results-bucket 旗標,然後傳入結果 bucket 的名稱。詳情請參閱 gcloud firebase test android run 參考文件 。
為什麼我收到的檢測設備測試案例結果不完整或有缺漏?
執行檢測設備測試時,您可能會看到測試錯誤,指出部分結果包含 Test run failed to complete. Expected
x tests, received y 等訊息 (其中 y 小於 x)。這項錯誤表示 Test Lab 無法剖析 logcat,找出通常由 AndroidJUnitRunner 產生的測試案例開始或結束標記。
以下是這個問題的常見原因:
問題說明
可能的解決方法
測試案例因逾時而未執行。如果測試總時間長度超過您指定的逾時時間,或超過逾時時間上限 ,Test Lab 會取消其餘測試案例。
請增加矩陣的逾時時間,確保所有測試都能完成。
如果尚未將測試進行資料分割,請先完成這項操作,讓每個資料分割執行一部分測試,並在較短時間內完成。
如果已啟用資料分割,請增加 shard 數量。
測試案例提前結束或卡住,因此無法完成。
測試案例可能會因未偵測到的例外狀況或斷言錯誤而提早結束。測試案例可能會卡在無限迴圈中,或無法繼續執行,例如應用程式未顯示正確的檢視畫面,且測試案例無法在 UI 上執行動作。
查看影片和 logcat,調查測試停止的位置。
自訂測試執行工具 (包括擴充 AndroidJUnitRunner) 意外停止運作,或將非預期的測試案例開始或結束標記寫入 logcat。
請檢查測試執行工具程式碼。
寫入 logcat 的記錄過多,導致緩衝區超載或 logcat 程序異常終止。
減少寫入 logcat。
受測應用程式異常終止。
為應用程式偵錯。
常見問題 (FAQ)
Test Lab 的免付費配額為何?如果用完了,該怎麼辦?
Firebase Test Lab 提供免付費配額,可用於在裝置上測試及使用 Cloud API。請注意,測試配額採用標準 Firebase 定價方案,而 Cloud API 配額則不採用。
測試配額
測試配額取決於用於執行測試的裝置數量。Firebase Spark 方案提供固定的測試配額,使用者無須付費。如果採用 Blaze 方案,配額可能會隨著 Google Cloud 用量增加而提高。如果達到測試配額,請等到隔天,或從 Spark 方案升級至 Blaze 方案。如果已採用 Blaze 方案,可以申請提高配額。詳情請參閱「測試配額 」。
您可以在 Google Cloud 控制台 中監控測試配額用量。
Cloud Testing API 配額
Cloud Testing API 有兩項配額限制:每項專案每日要求數,以及每項專案每 100 秒要求數。您可以在 Google Cloud 控制台 中監控用量。
Cloud Tool Results API 配額
Cloud Tool Results API 有兩項配額限制:每個專案每天的查詢次數,以及每個專案每 100 秒的查詢次數。您可以在 Google Cloud 控制台 中監控用量。
如要進一步瞭解 API 限制,請參閱「Test Lab 的 Cloud API 配額 」。如果已達 API 配額上限:
如何確認傳送至後端的流量是否來自 Test Lab ?
在後端,您可以根據我們的 IP 範圍 檢查來源 IP 位址,判斷流量是否來自 Firebase 託管的測試裝置。
Test Lab 是否能與 VPC-SC 搭配使用?
Test Lab 無法與 VPC-SC 搭配使用,因為 VPC-SC 會禁止在 Test Lab 的內部儲存空間和使用者的結果 bucket 之間複製應用程式和其他測試構件。
如何在 Test Lab 中偵測不穩定測試?
如要偵測測試中的不穩定行為,建議使用
--num-flaky-test-attempts
選項。Deflake 重新執行作業的計費方式和每日配額計算方式,與一般測試執行作業相同。
但請注意以下事項:
偵測到失敗時,系統會再次執行整個測試執行。不支援僅重試失敗的測試案例。
系統會排定在同一時間執行 Deflake 重試,但不保證會平行執行,例如流量超過可用裝置數量時。
注意: 基礎架構錯誤與消除不穩定功能無關,不會觸發消除不穩定重新執行。
iOS 專屬常見問題
雖然其中部分項目已列入我們的藍圖,但目前無法承諾支援這些測試和應用程式開發平台。
哪裡可以找到裝置詳細資料,例如解析度等?
您可以透過 API 取得詳細的裝置資訊,並使用 describe 指令 從 gcloud 用戶端存取這些資訊:
gcloud firebase test ios models describe MODEL
我可以在 iOS 測試中使用資料分割功能嗎?
iOS 版 Test Lab 原生不支援資料分割。不過,您可以使用 Flank 用戶端對 iOS 測試案例進行資料分割。
注意: 使用 Flank iOS sharding 功能,會為每個 shard 建立個別的測試矩陣。 方法是在 .xctestrun 檔案中設定 OnlyTestIdentifiers 鍵和值。詳情請參閱 xcodebuild.xctestrun 的 man 頁面。
為什麼 iOS 測試結果中沒有影片?
iOS 18 以上版本不支援在搜尋結果中顯示影片。
Android 專屬常見問題
Test Lab 是否支援穿戴式裝置?
當然可以!Test Lab 支援 Google Pixel Watch。現在可以在 Google Pixel Watch 上測試獨立 Wear 應用程式。如要進一步瞭解 Test Lab 裝置,請參閱「在可用裝置上測試 」。
Test Lab 是否支援最新的 Google 裝置?
當然可以!Test Lab 支援 Google Pixel Tablet 和 Google Pixel Fold。您可以在獨立實體裝置上執行測試。如要進一步瞭解 Test Lab 裝置,請參閱「在可用裝置上測試 」。
如何在 Test Lab 中偵測執行中的測試?
如果您在 Firebase 測試應用程式,或在 Play 管理中心執行正式發布前測試報告 ,可以檢查 MainActivity 檔案中的系統屬性 firebase.test.lab,偵測測試是否在 Firebase 託管的裝置上執行。接著,您可以根據 testLabSetting 的布林值執行其他陳述式。詳情請參閱「修改後的測試行為 」。
雖然其中部分項目已列入我們的藍圖,但目前無法承諾支援這些測試和應用程式開發平台。不過,如果您使用支援 Espresso 的架構 (例如 Flutter) 建構應用程式,可以使用 Espresso 編寫檢測設備測試,然後在 Test Lab 中執行測試。
Test Lab 是否支援測試經過模糊處理的應用程式 (例如使用 ProGuard 或 R8)?
Test Lab 並未明確支援模糊化或去模糊化。雖然應用程式可能會執行,但任何經過模糊處理的應用程式資料 (例如堆疊追蹤) 都會在記錄中顯示為模糊處理。
在 Test Lab 上測試時,我可以使用摺疊式裝置的不同摺疊狀態和型態嗎?
當然可以!您可以在摺疊狀態和型態 中測試摺疊式裝置。
折疊式裝置可能處於各種不同的折疊狀態,如 FLAT (完全展開) 或 HALF_OPENED (介於完整展開和完全關閉之間)。
另一方面,型態則包含特定裝置方向和摺疊狀態。例如,桌面型態是水平方向的 HALF_OPENED 狀態,而書本型態則是垂直方向的 HALF_OPENED 狀態。
如果您正在執行檢測設備測試,可以使用 Jetpack WindowManager 程式庫,並按照在摺疊式裝置上測試應用程式 說明文件,在不同狀態和姿勢下進行測試。
此外,可用狀態因裝置而異,可使用 adb
shell command cmd device_state 進行互動。
如要列出目前狀態,請執行 adb shell cmd device_state state。
如要設定或覆寫目前狀態,請執行 adb shell cmd device_state state <IDENTIFIER>。
如要重設狀態,請執行 adb shell cmd device_state state reset。
如要查看可用狀態,請在摺疊式裝置上執行 adb shell cmd device_state print-states 指令。
Google Pixel Fold (型號 ID:felix)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{ identifier = 0 , name = 'CLOSED' , app_accessible = true} ,
DeviceState{ identifier = 1 , name = 'HALF_OPENED' , app_accessible = true} ,
DeviceState{ identifier = 2 , name = 'OPENED' , app_accessible = true} ,
DeviceState{ identifier = 3 , name = 'REAR_DISPLAY_STATE' , app_accessible = true} ,
]
Samsung Galaxy Z Fold4 (型號 ID:q4q)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{ identifier = 0 , name = 'CLOSE' , app_accessible = true} ,
DeviceState{ identifier = 1 , name = 'TENT' , app_accessible = true} ,
DeviceState{ identifier = 2 , name = 'HALF_FOLDED' , app_accessible = true} ,
DeviceState{ identifier = 3 , name = 'OPEN' , app_accessible = true} ,
]
哪些裝置最適合進行螢幕截圖差異測試?
螢幕截圖差異測試 :測試斷言會比較執行測試時取得的螢幕圖片,以及代表預期行為的黃金圖片。在某些裝置類型上,這類測試可能比其他裝置更容易出錯。建議您指定 Arm (*.arm) 模擬器裝置進行這類測試。Arm 模擬器裝置使用的映像檔,與 Android Studio「一般」模擬器非常相似或完全相同。
我們也建議您研究測試程式庫,這有助於在預期變更的情況下,提高螢幕截圖測試的穩定性。
Test Lab 會更新虛擬裝置嗎?
當然可以!虛擬裝置會在下列情況更新:
更新現有圖片
淘汰舊版 API 級別
新增 Android API 級別
如何啟用涵蓋率報表?
如要啟用涵蓋率報表,請將 coverage=true 新增至 environmentVariables 欄位 。如果您使用 Android Test Orchestrator,則必須提供目錄來儲存涵蓋率結果:
-- environment - variables coverage = true , coverageFilePath =/ sdcard / Download /
如果您不是使用 Orchestrator,可以指定檔案路徑:
-- environment - variables coverage = true , coverageFile =/ sdcard / Download / coverage . ec
哪裡可以找到裝置詳細資料,例如解析度、支援的 ABI 等?
您可以透過 API 取得詳細的裝置資訊,並使用 describe 指令 從 gcloud 用戶端存取這些資訊:
gcloud firebase test android models describe MODEL
如何在沒有手機的情況下登入 Wear 應用程式?
如果應用程式支援 Google 登入,測試帳戶應會自動運作。否則,如果應用程式通常需要手機才能登入,您可以建立建構變化版本,略過登入程序,並使用測試版本中嵌入的權杖,或從磁碟上的檔案讀取,通常使用 --other-files option 推送。詳情請參閱「使用 Robo 測試自訂登入和文字輸入 」。
已知問題
登入人機驗證
Robo 測試無法略過需要使用者採取額外動作 (例如完成 CAPTCHA 驗證) 才能登入的登入畫面。
iOS 專屬已知問題
自動登入
iOS+ 機器人測試 (Beta 版) 不支援自動登入 Google 帳戶。
Android 專屬已知問題
UI 架構支援
Robo 測試最適合使用 Android UI 架構 (包括 View、ViewGroup 和 WebView 物件) 中 UI 元素的應用程式。如果您使用 Robo 測試來測試採用其他 UI 架構的應用程式 (包括使用 Unity 遊戲引擎的應用程式),測試可能會在探索第一個畫面後結束。