Firebase Test Lab

解決する課題

多様な端末・OS バージョンの組み合わせでアプリが正しく動くかを、物理端末を自前でそろえることなく検証できます。リリース前の機種依存の不具合やクラッシュを、クラウド上の実機・仮想デバイスを使って早期に発見できます。

• 手元にない多数の機種・画面サイズ・OS バージョンでアプリの動作を確認したい
• テストコードを書く前でも、まずクラッシュや基本的な操作の破綻を機械的に洗い出したい
• 端末ラボの物理端末の購入・維持・充電・OS 更新といった運用負担をなくしたい
• CI/CD パイプラインに自動テストを組み込み、push やリリース前に機種横断の検証を回したい
• 不具合の再現に必要なスクリーンショット・動画・ログを、機種ごとに自動で集めたい

主要概念と用語

• テストマトリックス（test matrix）: 1 回のテスト実行で対象にする「デバイス × OS バージョン × ロケール × 画面の向き」の組み合わせの集合。多くの機種を一度にまとめて検証できる
• 物理デバイス / 仮想デバイス: Google のデータセンターに置かれた実機（physical）と、エミュレーター相当の仮想デバイス（virtual）。実機は実環境に近く、仮想デバイスは並列に多数を回しやすい
• Robo テスト（Robo test）: テストコードを書かずに、アプリの画面を**自動でクロール（巡回）**して操作し、クラッシュや遷移の異常を検出する Android 向けのテスト。同じ動作を再現できる
• 計装テスト（instrumentation test）: Android の Espresso や UI Automator などで書いた自前の UI/ロジックテストを実機・仮想デバイス上で実行する方式
• ゲームループテスト（Game Loop test）: ゲームのデモループを通してアプリを動かし、フレームレートなどを確認するテスト方式
• XCTest: iOS 向けに、Xcode の XCTest で書いたテストをクラウド上のデバイスで実行する方式
• テストマトリックスの結果: 各実行で得られるスクリーンショット・動画・ログ（logcat）・スタックトレース・パフォーマンス指標の集合

仕様・制限・クォータ

• 対応プラットフォームは Android と iOS。Android では Robo テスト・計装テスト・ゲームループテストが、iOS では XCTest 系のテストが実行できる
• 1 回の実行はテストマトリックスとして複数のデバイス・OS・ロケール・画面の向きをまとめて指定でき、各組み合わせが並列で実行される
• 各テスト実行には**1 件あたりの最大実行時間（タイムアウト）**があり、長すぎるテストは打ち切られる
• 同時に走らせられるテスト数や 1 日あたりの実行量には**割り当て（クォータ）**があり、無料枠と有料（従量）で上限が異なる
• 利用できるデバイスのラインアップ（機種・OS バージョン）は時期によって入れ替わるため、対象機種は実行時点で利用可能なものから選ぶ

内部の仕組み

Firebase Test Lab は、Google が管理するデータセンター内の実機と仮想デバイスのプール上でアプリを起動し、指定したテストを実行して結果を回収する仕組みです。利用者は端末そのものを意識せず、テスト対象アプリ（APK/AAB や iOS のビルド）とテスト構成を渡すだけで済みます。

• 実行を依頼すると、テストマトリックスで指定した各デバイス・OS の組み合わせにアプリが配置され、並列にテストが走る
• Robo テストは、アプリの UI 要素を解析しながら画面を自動巡回して操作を加え、その過程でクラッシュや異常を検出する。実行ごとに同じ巡回を再現できる
• 計装テスト・XCTest は、利用者が書いたテストコードをそのままデバイス上で実行し、合否を集計する
• 実行中はスクリーンショット・動画・logcat・スタックトレースなどが自動で記録され、終了後に結果として参照できる
• 終了後、デバイスは初期化されて次の利用者に再利用される。テスト間で状態が持ち越されない前提で扱う

AWS でいえば、クラウド上の実機・仮想端末でモバイルアプリをテストする AWS Device Farm が最も近い相当サービスです。多機種を並列にテストして結果（動画・ログ）を回収する考え方は共通します。Firebase Test Lab は Firebase / Google Cloud のエコシステムや gcloud CLI との統合、テストコード不要の Robo テストが使える点が特徴です。

設計パターン / ベストプラクティス

• リリース前は主要機種＋極端な画面サイズ・古い OS を含むテストマトリックスを組み、機種依存の問題を網羅的に拾う
• まず Robo テストでクラッシュや明らかな破綻を機械的に洗い出し、重要フローは Espresso / XCTest の計装テストで厳密に検証する、と役割を分ける
• CI/CD（Cloud Build や GitHub Actions など）から gcloud CLI で実行し、push やリリース時に自動で機種横断テストを回す
• 仮想デバイスは並列性とコストに優れるので広く浅い確認に、実機は実環境依存の検証に、と用途で使い分ける
• Robo テストにはログイン情報などの事前入力値を渡し、認証後の画面まで巡回できるようにする
• 失敗時の動画・スクリーンショット・ログを成果物として保存し、不具合の再現と切り分けを速くする

運用・監視

• テスト結果は Firebase コンソールで機種ごとに確認でき、スクリーンショット・動画・ログ・スタックトレースをたどって失敗原因を切り分ける
• CI から実行する場合は gcloud CLI の終了コードで合否を判定し、失敗時にパイプラインを止める
• 結果やアーティファクトは Cloud Storage バケットに出力させ、後から参照・保管できる
• 同時実行数や 1 日の実行量がクォータ上限に当たっていないかを確認し、必要なら有料枠やクォータ引き上げを検討する
• デバイスのラインアップ変更で特定機種が使えなくなった場合に備え、利用可能デバイス一覧を都度取得してマトリックスを組む

コスト

無料枠の範囲内であれば 1 日あたり一定数のテストを実行でき、それを超える分は従量課金（デバイスの利用時間ベース）になります。一般に実機（物理デバイス）の方が仮想デバイスより単価が高い傾向で、課金はおおむね「使ったデバイス時間」に比例します。多機種を同時に走らせるほど総時間が増える点に注意します。

セキュリティ

• アクセス制御は Cloud IAM。テストの実行や結果（アーティファクト）の閲覧を、最小権限で必要な主体だけに絞る
• 結果やアーティファクトの保存先 Cloud Storage バケットの公開設定・権限を見直し、テストで生成された動画やログが意図せず外部に露出しないようにする
• テストにログイン情報などの秘密値を渡す場合は、ソースに直書きせず安全な受け渡しを用い、不要になったテスト用アカウントは無効化する
• テストデバイスは実行後に初期化されて再利用される前提で、本番の機密データを使わずダミーデータでテストする
• 保存データは Google Cloud の標準として保存時に暗号化される

関連サービス・比較

ハンズオン / CLI例

# 1. 現在テストに使える Android 実機の一覧を確認
gcloud firebase test android models list

# 2. Robo テストを実行（テストコード不要・APK を渡すだけ）
#    対象デバイスと OS バージョン・ロケール・画面の向きを指定
gcloud firebase test android run \
  --type robo \
  --app app-release.apk \
  --device model=redfin,version=30,locale=ja_JP,orientation=portrait \
  --timeout 5m

# 3. Espresso 計装テストを複数デバイスで並列実行
gcloud firebase test android run \
  --type instrumentation \
  --app app-release.apk \
  --test app-debug-androidTest.apk \
  --device model=redfin,version=30 \
  --device model=oriole,version=33

# 4. 結果のアーティファクト（動画・ログ）を保存する GCS パスを指定
gcloud firebase test android run \
  --type robo \
  --app app-release.apk \
  --results-bucket=gs://my-test-results-bucket \
  --results-dir=run-001