Firebase で AI 搭載アプリを構築して実行する方法のデモを、2024 年の Demo Day でご覧ください。ぜひご覧ください。

Test Lab のトラブルシューティング & よくある質問

このページでは、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 Audit Logs が有効になっていないことも確認してください。

実行が 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 未満）のようなメッセージを含む部分的な結果を示すテストエラーが表示される場合があります。このエラーは、通常は AndroidJUnitRunner によって生成されるテストケースの開始マーカーまたは終了マーカーについて、Test Lab が logcat を解析できなかったことを意味します。

この問題の一般的な原因を以下に示します。

問題の説明	考えられる解決策
タイムアウトによりテストケースが実行されなかった。テストの合計所要時間が、指定したタイムアウト時間より長い場合、または最大タイムアウトより長い場合、Test Lab は残りのテストケースはキャンセルされる。	すべてのテストを完了できるように、マトリックスのタイムアウトを長くする。まだ行っていない場合はテストをシャーディングし、各シャードがテストのサブセットを実行して、短時間で完了するようにする。シャーディングをすでに有効にしている場合は、シャードの数を増やす。
テストケースが早期に終了したかエラーになったため、完了できなかった。キャッチされなかった例外またはアサーションエラーが原因で、テストケースが早期に終了することがある。たとえば、アプリに正しいビューが表示されず、テストケースが UI でアクションを実行できない場合、テストケースが無限ループに陥ったり、続行できなくなったりすることがある。	動画と`logcat` を確認して、テストが停止した場所を調べる。
カスタムテストランナー（AndroidJUnitRunner の拡張を含む）が予期せずクラッシュしたか、予期しないテストケースの開始マーカーまたは終了マーカーを `logcat` に書き込んだ。	テストランナーのコードを確認する。
`logcat` に過剰なログが書き込まれたため、バッファが溢れたか、`logcat` プロセスがクラッシュした。	`logcat` への書き込みを減らす。
テスト対象のアプリがクラッシュした。	アプリをデバッグする。

よくある質問

Test Lab の無料の割り当てについて教えてください。割り当てを使い切った場合はどうなりますか？

Firebase Test Lab には、デバイスでのテストと Cloud APIs 使用に関する無料割り当てが用意されています。テストの割り当てでは標準の Firebase 料金プランが使用されますが、Cloud APIs の割り当てでは Firebase 料金プランは使用されないことに注意してください。

テストの割り当て

テストの割り当ては、テストの実行に使用されるデバイスの数によって決まります。Firebase Spark プランでは、テストに対する割り当てが固定されています（無料）。Blaze プランでは、時間の経過とともに Google Cloud の使用量が増加した場合、割り当て量を増やすことができます。現在 Spark プランをご利用で、テストの割り当て上限に達した場合は、翌日まで待つか、Blaze プランにアップグレードしてください。すでに Blaze プランをご利用の場合は、割り当ての増加をリクエストできます。詳細については、割り当てのテストをご覧ください。

テストの割り当て使用量は、Google Cloud コンソールでモニタリングできます。
Cloud Testing API の割り当て

Cloud Testing API には、プロジェクト 1 件の 1 日あたりのリクエスト数と、プロジェクト 1 件の 100 秒あたりのリクエスト数という 2 つの割り当て上限があります。使用状況は Google Cloud コンソールでモニタリングできます。
Cloud Tool Results API の割り当て

Cloud Tool Results API には、プロジェクト 1 件の 1 日あたりのクエリ数と、プロジェクト 1 件の 100 秒あたりのクエリ数という 2 つの割り当て上限があります。使用状況は Google Cloud コンソールでモニタリングできます。

API の上限の詳細については、Test Lab の Cloud APIs の割り当てをご覧ください。API の割り当てに達した場合:
- Google Cloud コンソールで直接割り当てを編集して、割り当て上限の引き上げのリクエストを送信してください（ほとんどの上限はデフォルトで最大値に設定されていることに注意してください）。
- Google Cloud コンソールのリクエストフォームに記入するか、Firebase サポートにお問い合わせのうえ、API 割り当ての引き上げをリクエストしてください。

バックエンドに到達したトラフィックが Test Lab から来たものであるかを判断するにはどうすればよいですか？

バックエンドで、IP 範囲と送信元 IP アドレスを照合することで、トラフィックの発信元が Firebase にホストされているテストデバイスかどうかを判断できます。

Test Lab は VPC-SC と連携しますか？

Test Lab は VPC-SC では機能しません。そのため、Test Lab の内部ストレージとユーザーの結果バケット間でのアプリとその他のテストアーティファクトのコピーがブロックされます。

Test Lab で不安定なテストを検出するにはどうすればよいですか？

テストにおける不安定な動作を検出するには、 --num-flaky-test-attempts オプションの使用をおすすめします。デフレークの再実行は、通常のテスト実行と同様に、1 日の割り当てに対して課金またはカウントされます。

次の点にご注意ください。

障害が検出されると、テスト実行全体が再び実行されます。失敗したテストケースのみを再試行することはできません。
デフレークの再試行は、同時に実行されるようスケジュール設定されますが、トラフィックが使用可能なデバイスの数を超えている場合などには、同時に実行される保証はありません。

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 Console でリリース前レポートのテストを実施する場合は、MainActivity ファイル内のシステムプロパティ firebase.test.lab を確認することで、Firebase にホストされているデバイスでテストが実行されていることを検出できます。そのうえで、testLabSetting のブール値に基づいて追加のステートメントを実行できます。詳しくは、テスト動作の変更に関する説明をご覧ください。

Test Lab は、Appium、Flutter / FlutterDriver、ReactNative / Jest、Cucumber に対応していますか？

これらのアイテムの一部は Google のロードマップに含まれていますが、現在のところ、これらのテストプラットフォームやアプリ開発プラットフォームのサポートを明言することはできません。ただし、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 プロダクトとは異なり、Test Lab を使用するために Firebase SDK を追加する必要はありません。まだアプリがない場合は、APK をオンラインでダウンロードするか、AndroidX GitHub リポジトリ内のいずれかのサンプルからアプリとテスト APK を構築できます。Robo テストを実行するには、アプリの APK ファイルのみが必要ですが、インストルメンテーションテストでは、ソースコードから構築したアプリとテスト APK の両方が必要です。詳細については、インストルメンテーションテストをご覧ください。

Test Lab 機能の詳細については、Firebase Test Lab を使用した Android 向けテストのスタートガイドをご覧ください。

どのデバイスがスクリーンショット差分テストに適していますか？

スクリーンショット差分テストでは、テストの実行中に取得した画面イメージと、想定される動作を表すゴールデンイメージとの比較に基づいてテストアサーションを行います。このようなテストにおいては、デバイスの種類によって結果が安定しないことがあります。この種のテストでは 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

既知の問題

UI フレームワークのサポート

Robo テストは、Android UI フレームワークの UI 要素（View、ViewGroup、WebView オブジェクトを含む）を使用するアプリに最適です。Robo テストを使用して、他の UI フレームワークを使用するアプリ（Unity ゲームエンジンを使用するアプリを含む）を実行する場合、テストは最初の画面を調べただけで終了することがあります。