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 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 の割り当てに達した場合:
バックエンドに到達したトラフィックが 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 は、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
既知の問題
ログイン キャプチャ
Robo テストは、ログイン用の認証情報に加えて、その他のユーザー操作(キャプチャの入力など)を必要とするログイン画面を迂回することはできません。
UI フレームワークのサポート
Robo テストは、Android UI フレームワークの UI 要素(View
、ViewGroup
、WebView
オブジェクトを含む)を使用するアプリに最適です。Robo テストを使用して、他の UI フレームワークを使用するアプリ(Unity ゲームエンジンを使用するアプリを含む)を実行する場合、テストは最初の画面を調べただけで終了することがあります。