Test Lab 疑難排解資訊(&A)；常見問題

iOS Android

本頁面提供疑難排解說明，並針對使用 Firebase Test Lab 執行測試的常見問題提供解答。並記錄已知問題。如果找不到所需資訊或需要進一步協助，請加入 Firebase Slack 的 #test-lab 頻道，或是與 Firebase 支援團隊聯絡。

疑難排解

為什麼測試執行時間這麼長？

在 Test Lab 目錄中選取容量等級較高的裝置時，測試可能會更快開始。如果裝置容量較低，測試可能需要更長的時間才能執行。如果叫用的測試數量遠大於所選裝置的容量，測試可能需要更長的時間才能完成。

在任何裝置容量層級執行的測試可能會因為下列因素而耗時較久：

• 流量，會影響裝置可用性和測試速度。
• 裝置或基礎架構故障，隨時都可能發生。如要查看是否有已回報的 Test Lab 基礎架構，請參閱 Firebase 狀態資訊主頁。

如要進一步瞭解 Test Lab 中的裝置容量，請參閱 Android 和 iOS 的裝置容量資訊。

為什麼我收到不明確的測試結果？

測試結果不確定通常是因為取消測試執行或基礎架構錯誤。

基礎架構錯誤是因內部 Test Lab 問題 (例如網路錯誤或裝置發生非預期行為) 所致。Test Lab 會在回報結果不確定之前，內部退回多次產生基礎架構錯誤的測試執行作業；不過，您可以使用 failFast 停用這些重試。

如要找出錯誤的原因，請按照下列步驟操作：

1. 前往 Firebase 狀態資訊主頁查看是否有已知的中斷情形。

2. 在 Test Lab 中重試測試，確認可重現問題。

   注意： Test Lab 不會針對基礎架構錯誤向您收費。

3. 請嘗試在其他裝置或裝置類型上執行測試 (如適用)。

如果問題仍未解決，請在 Firebase Slack 的 #test-lab 頻道中與 Test Lab 團隊聯絡。

為什麼分割作業會讓測試執行時間變長？

如果您指定的資料分割數量超過 Test Lab 中可用的裝置數量，資料分割可能會導致測試執行時間變長。為避免這種情況，請嘗試改用其他裝置。如要進一步瞭解如何選擇其他裝置，請參閱「裝置容量」一文。

為什麼測試需要很長的時間才能開始？

提交測試要求時，系統會先驗證應用程式、重新簽署等，為在裝置上執行測試做好準備。這項程序通常會在幾秒內完成，但可能會受到應用程式大小等因素的影響。

應用程式準備就緒後，系統會排定測試執行作業，並將其保留在佇列中，直到裝置準備好執行為止。在所有測試執行作業都完成之前，矩陣狀態會是「未放送」(無論測試執行作業是否在佇列中或正在執行)。

注意： 測試等待可用裝置的時間不會計入帳單時間。

為什麼測試需要很長的時間才能完成？

測試執行作業完成後，系統會從裝置下載測試構件、處理，然後上傳至 Cloud Storage。此步驟的時間長度會受到遺留物的數量和大小影響。

應用程式未傳回資料，且無法找到螢幕截圖

測試執行構件 (例如螢幕截圖和記錄檔案) 會儲存在 Google Cloud Storage 中，並直接轉譯至 Firebase 控制台。如果您是在過去 90 天內執行測試，請確認您已指派專案層級角色 (專案擁有者、專案編輯者或專案檢視者)。請確認專案或機構未啟用 Cloud 稽核記錄。

如果執行作業已超過 90 天，測試構件很可能已自動刪除。如要查看結果值區設定，請按一下 Test Lab 資訊主頁中的「測試結果」分頁。預設結果值區塊已設為保留物件 90 天。

如要保留測試構件更久的時間，請搭配 --results-bucket 標記執行 gcloud firebase test android run 指令，並傳入結果值區的名稱。詳情請參閱 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 配額：

  • 如要申請增加配額，請直接在 Google Cloud 控制台編輯配額 (請注意，大部分的限制預設為最高值)，或

  • 如要申請提高 API 配額，請在 Google Cloud 主控台中填寫申請表單，或與 Firebase 支援團隊聯絡。

如何判斷到達後端的流量是否來自 Test Lab？

您可以透過後端，檢查來源 IP 位址是否符合我們的IP 範圍，判斷流量是否來自 Firebase 代管的測試裝置。

Test Lab 是否可與 VPC-SC 搭配運作？

Test Lab 不適用於 VPC-SC，因為後者會在 Test Lab 的內部儲存空間和使用者的結果值區之間，封鎖應用程式和其他測試構件複製作業。

如何在 Test Lab 中偵測不穩定的測試？

如要偵測測試中的不穩定行為，建議您使用 --num-flaky-test-attempts 選項。Deflake 重播作業的計費或計入每日配額的方式，與一般測試執行作業相同。

但請注意以下事項：

• 偵測到失敗時，整個測試執行作業會再次執行。系統不支援只重試失敗的測試案例。
• Deflake 重試執行作業會排定在同一時間執行，但無法保證會並行執行，例如當流量超過可用裝置的數量時。

注意： 基礎架構錯誤與 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 是否支援 Appium、Flutter/FlutterDriver、ReactNative/Jest 或 Cucumber？

雖然我們已將其中部分項目納入路線圖，但目前無法承諾支援這些測試和應用程式開發平台。不過，如果您使用支援 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},
]

如果我沒有應用程式，可以試用 Test Lab 嗎？

與其他 Firebase 產品不同，您無須新增 Firebase SDK 即可使用 Test Lab。如果您還沒有應用程式，可以透過網路下載 APK，或是從 AndroidX GitHub 存放區的其中一個範例建立應用程式和測試 APK。請注意，您只需要應用程式的 APK 檔案即可執行 Robo 測試，但檢測設備測試則需要應用程式和從原始碼建構的測試 APK。詳情請參閱「檢測設備測試」。

如要進一步瞭解 Test Lab 功能，請參閱「開始使用 Firebase Test Lab 為 Android 進行測試」。

哪些裝置最適合進行螢幕截圖差異測試？

螢幕截圖差異測試：測試斷言會比較執行測試時取得的螢幕截圖，與代表預期行為的黃金圖片。這類測試在某些裝置類型上可能會比較不穩定。建議您針對這類測試指定 Arm (*.arm) 模擬器裝置。Arm 模擬器裝置使用的映像檔與 Android Studio「一般」模擬器非常相似，甚至完全相同。

我們也建議您研究可在預期變更發生時，讓螢幕截圖測試更穩健的測試程式庫。

Test Lab 會更新虛擬裝置嗎？

當然可以！虛擬裝置會在下列變更時更新：

1. 現有圖片的更新
2. 淘汰早期 API 級別
3. 新增 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

已知問題

登入人機驗證 (Captcha)

Robo 測試無法略過登入畫面，因為登入畫面需要使用者輸入憑證以外的其他動作，例如完成人機驗證。

支援 UI 架構

Robo 測試最適合使用 Android UI 架構中的 UI 元素 (包括 View、ViewGroup 和 WebView 物件) 的應用程式。如果您使用 Robo 測試來測試使用其他 UI 架構的應用程式 (包括使用 Unity 遊戲引擎的應用程式)，測試可能會在未探索第一個畫面以外的內容就結束。