iOS
Android
本頁面提供使用 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 可用的裝置數量,資料分割作業可能會延長測試的執行時間。為了避免發生這種情況,請嘗試改用其他裝置。如要進一步瞭解如何選擇其他裝置,請參閱「裝置容量 」一文。
為什麼測試開始需要很長的時間?
提交測試要求時,應用程式會先驗證、重新簽署等,以便準備在裝置上執行測試。一般來說,這個程序可在幾秒內完成,但會受到應用程式大小等因素影響。
應用程式準備就緒後,系統會安排測試執行作業,並留在佇列中,直到裝置準備好可以執行為止。在所有測試執行作業完成之前,矩陣狀態都會是「待處理」(無論測試執行是在佇列中還是主動執行)。
為什麼測試需要很長的時間才能完成?
測試執行作業完成後,系統會從裝置下載測試成果,並在處理後上傳到 Cloud Storage。這個步驟的持續時間可能會受構件的數量和大小所影響。
應用程式未傳回資料,且找不到螢幕截圖
測試執行成果 (例如螢幕截圖和記錄檔) 會儲存在 Google Cloud Storage 中,並直接轉譯到 Firebase 控制台。如果測試執行作業是在過去 90 天內執行,請確認您是否已指派專案層級的角色 (專案擁有者、專案編輯者或專案檢視者)。請確認您的專案或機構並未啟用 Cloud 稽核記錄功能。
如果執行作業超過 90 天,系統大多會自動刪除測試成果。按一下 Test Lab 資訊主頁中的「Test Results」 分頁標籤,即可查看結果值區設定。預設結果值區會設為將物件保留 90 天。
如要延長測試成果的保留時間,請執行 gcloud firebase test android run
指令並加上 --results-bucket
標記,然後傳入結果值區的名稱。詳情請參閱 gcloud firebase test android run
參考說明文件 。
為什麼我收到了部分或遺漏的檢測設備測試案例結果?
執行檢測設備測試時,您可能會看到測試錯誤,指出部分結果包含 Test run failed to complete. Expected
x tests, received y
(其中 y
小於 x
) 的訊息。此錯誤表示 Test Lab 無法剖析 Logcat 以剖析測試案例起始或結束標記,這通常是由 AndroidJUnitRunner 產生的標記。
以下是這個問題的常見原因:
問題說明
可能的解決方法
由於逾時,測試案例未執行。如果測試總時長超過您指定的逾時時間或超過逾時時間上限 ,Test Lab 就會取消其餘測試案例。
請調高矩陣的逾時時間,確保所有測試都可以完成。
如果尚未執行資料分割測試,可以讓每個資料分割在較短的時間內執行一部分的測試。
如果已啟用資料分割,請增加資料分割數量。
測試案例已提前結束或卡住,因此無法完成。由於未偵測到的例外狀況或斷言錯誤,測試案例可能會提前結束。測試案例可能會卡在無限迴圈中,或無法繼續執行,例如應用程式未顯示正確的檢視畫面,且測試案例無法在 UI 上執行動作。
請查看影片和 logcat
,調查測試停止的位置。
自訂測試執行器 (包括擴充 AndroidJUnitRunner) 意外異常終止,或將非預期的測試案例開始或結束標記寫入 logcat
。
檢查測試執行工具程式碼。
寫入過多記錄至 logcat
,導致緩衝區不堪負荷或導致 logcat
程序異常終止。
減少寫入 logcat
。
受測應用程式異常終止。
對應用程式進行偵錯。
常見問題
Test Lab 的免費配額是什麼?如果用完了,該怎麼辦?
Firebase Test Lab 提供免付費配額,可用於在裝置上測試及使用 Cloud API。請注意,測試配額使用的是標準 Firebase 定價方案,Cloud API 配額則不採用。
測試配額
測試配額取決於執行測試的裝置數量。Firebase Spark 方案有固定的測試配額,使用者無須付費。就 Blaze 方案而言,如果您的 Google Cloud 用量會隨時間增加,配額可能會增加。如果達到測試配額,請等到隔天再升級至 Blaze 方案 (如果目前使用 Spark 方案)。如果您已訂閱 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 內部儲存空間和使用者結果值區之間的複製應用程式及其他測試成果。
如何在 Test Lab 中偵測不穩定的測試?
如要偵測測試中的不穩定行為,建議您使用
--num-flaky-test-attempts
選項。如同一般的測試執行作業,Deflake 重新執行會計費或計入您的每日配額。
但請注意以下事項:
只要偵測到失敗情形,整個測試執行作業就會再次執行。無法只重試失敗的測試案例。
系統就會安排同時執行 Deflake 重試執行作業,但不保證會同時執行,例如當流量超過可用裝置數量時。
注意: 基礎架構錯誤與展開功能無關,而且不會觸發脫糖重新執行。
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
的布林值執行其他陳述式。詳情請參閱「修改後的測試行為 」。
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 級別
如何啟用涵蓋率報表?
如要啟用涵蓋率報表,請在 environmentVariables
欄位 中加入 coverage=true
。如果您使用 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
已知問題
登入人機驗證 (Captcha)
如果登入畫面需要使用者進行額外操作 (例如完成人機驗證 (Captcha),則必須輸入憑證才能登入),Rbo 測試就無法略過這類畫面。
UI 架構支援
Robo 測試最適合使用 Android UI 架構中的 UI 元素 (包括 View
、ViewGroup
和 WebView
物件) 的應用程式。如果您透過 Robo 測試來練習使用其他 UI 架構的應用程式 (包括使用 Unity 遊戲引擎的應用程式),測試可能會在第一個畫面之後結束。