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

Test Lab カタログから大容量のデバイスを選択すると、テストの開始が早くなる場合があります。デバイスの容量が少ない場合、テストの実行に時間がかかることがあります。呼び出したテストの数が、選択したデバイスの容量を大幅に上回る場合、テストの完了に時間がかかることがあります。

デバイスの容量レベルにかかわらず、次の要因によりテストに長時間かかる場合があります。

• トラフィック。デバイスの可用性とテスト速度に影響します。
• デバイスやインフラストラクチャの障害（いつでも発生する可能性があります）。Test Lab で報告されているインフラストラクチャを確認するには、Firebase ステータス ダッシュボードをご覧ください。

Test Lab のデバイスの容量については、Android および iOS のデバイスの容量情報をご覧ください。

有意なテスト結果が得られないことは、テスト実行のキャンセルやインフラストラクチャ エラーが原因でよく起こります。

インフラストラクチャ エラーは、ネットワーク エラーや予期しないデバイスの動作など、Test Lab の内部の問題が原因で発生します。Test Lab は有意な結果が得られないとのレポートを返す前に、インフラストラクチャ エラーが発生するテスト実行を内部で複数回再試行します。ただし、failFast を使用してこれらの再試行を無効にできます。

エラーの原因を判別するには、次の手順を実施します。

1. Firebase ステータス ダッシュボードで既知のサービスの停止を確認します。

2. Test Lab でテストを再試行し、再現可能であることを確認します。

3. 該当する場合は、別のデバイスまたはデバイスタイプでテストを実行してみてください。

問題が解決しない場合は、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 を解析できなかったことを意味します。

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

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 割り当ての引き上げをリクエストしてください。

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

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

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

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

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

はい。Test Lab は Google Pixel Watch をサポートしています。そのため、Google Pixel Watch のスタンドアロン Wear アプリでテストを実行できます。Test Lab デバイスの詳細については、利用可能なデバイスでテストするをご覧ください。

はい。Test Lab は Google Pixel Tablet と Google Pixel Fold に対応しています。スタンドアロンの実機でテストを実行できます。Test Lab デバイスの詳細については、利用可能なデバイスでテストするをご覧ください。

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

これらのアイテムの一部は Google のロードマップに含まれていますが、現在のところ、これらのテスト プラットフォームやアプリ開発プラットフォームのサポートを明言することはできません。ただし、Espresso をサポートするフレームワーク（Flutter など）を使用してアプリを作成した場合は、Espresso を使用してインストルメンテーション テストを作成し、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 コマンドを実行します。

$ 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},
]

$ 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},
]

他の Firebase プロダクトとは異なり、Test Lab を使用するために Firebase SDK を追加する必要はありません。まだアプリがない場合は、APK をオンラインでダウンロードするか、AndroidX GitHub リポジトリ内のいずれかのサンプルからアプリとテスト APK を構築できます。Robo テストを実行するには、アプリの APK ファイルのみが必要ですが、インストルメンテーション テストでは、ソースコードから構築したアプリとテスト APK の両方が必要です。詳細については、インストルメンテーション テストをご覧ください。

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

スクリーンショット差分テストでは、テストの実行中に取得した画面イメージと、想定される動作を表すゴールデン イメージとの比較に基づいてテスト アサーションを行います。このようなテストにおいては、デバイスの種類によって結果が安定しないことがあります。この種のテストでは Arm（*.arm）エミュレータ デバイスを対象にすることをおすすめします。Arm エミュレータ デバイスは、Android Studio の「汎用」エミュレータとよく似た、または同一のイメージを使用します。

また、変更の可能性がある状況でスクリーンショット テストの安定性を高めるのに役立つテスト ライブラリを調査することもおすすめします。

はい。仮想デバイスは、次の変更が行われると更新されます。

1. 既存の画像への更新
2. 以前の API レベルのサポート終了
3. 新しい 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

詳細なデバイス情報は API を介して確認できます。これは、describe コマンドを使用して gcloud クライアントからアクセスできます。

gcloud firebase test android models describe MODEL

Robo テストは、ログイン用の認証情報に加えて、その他のユーザー操作（キャプチャの入力など）を必要とするログイン画面を迂回することはできません。

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