Firebase Test Lab からデベロッパー デバイス プラットフォームへのコマンドとフラグの変換

Developer Device Platform(DDP)は、従来の Firebase Test Lab コンソールと Test Lab CLI ワークフローを、統合された高性能で安全なGoogle Cloudファーストのテスト CLI(gcloud beta device-run)に置き換えます。

このガイドでは、Test Lab(または Flank)から DDP へのコマンドラインの変換とフラグのマッピングについて説明します。このガイダンスを使用して、テストを手動で移行します。自動化ツール、メリット、主な違い、移行のヒントについては、Firebase Test Lab から Developer Device Platform への移行をご覧ください。

シャーディングの移行

DDP は、Flank の複雑な Cloud Storage ベースのスマート シャーディングと Test Lab の均一シャーディングの両方をネイティブに置き換えることで、シャーディング構成をモダナイズします。

均一シャーディング

  • --sharding-option=uniform を設定します。
  • --uniform-sharding-count={count} を設定します(物理の場合は 1 ~ 20、仮想の場合は 1 ~ 200)。

  • 以前の Firebase Test Lab: --num-uniform-shards {N}

  • DDP CLI: --sharding-option=uniform --uniform-sharding-count={N}

スマート シャーディング

  • --sharding-option=smart を設定します。
  • --smart-sharding-target-duration={duration} を設定します(例: 2m、10m、1h。有効な範囲: 2m~1h)。
  • --smart-sharding-record-name={record_name} を設定します(automation/smart-sharding/ の --bucket-name 内の YAML トラッキング レコードを指します)。
  • --smart-sharding-max-shard-count={max_count} を設定します(省略可能な上限: 物理デバイスの場合は 0 ~ 20、仮想デバイスの場合は 0 ~ 200)。

過去 30 日間のタイミング メタデータを使用する:

  • 従来の Flank:

    max-test-shards: 10
    shard-time: 120
    smart-flank-gcs-path: gs://my-bucket/smart-sharding/timing-record.yaml
    
  • DDP CLI:

    --sharding-option=smart \
    --smart-sharding-max-shard-count=10 \
    --smart-sharding-target-duration=2m \
    --smart-sharding-record-name=timing-record \
    --bucket-name=my-bucket
    

宣言型 YAML 構成(--flags-file)

複雑な構成の場合や、長いターミナル コマンドではなくバージョン管理されたファイルを維持することを好むチームの場合、gcloud はユニバーサルな --flags-file 引数プリプロセッサを提供します($ gcloud topic flags-file を参照)。

Android

gcloud beta device-run sessions submit instrumentation --flags-file=device-run-flags.yaml

iOS

gcloud alpha device-run sessions submit xctest --flags-file=device-run-flags.yaml

以下に、複数値のリストフラグと辞書フラグの例を示します。

Android

# device-run-flags.yaml
--device:

    -   mediumphone-arm-32
    -   shiba-36
--apps:
    -   app-debug.apk
    -   test-helper.apk
--test: app-debug-androidTest.apk
--bucket-name: my-bucket
--sharding-option: smart
--smart-sharding-target-duration: 2m
--smart-sharding-record-name: timing-record
--paths-to-pull:
    -   /sdcard/screenshots
    -   /sdcard/coverage.ec
--additional-test-options:
  coverage: "true"
  clearPackageData: "true"

iOS

# device-run-flags.yaml
--device:

    -   iphonese3-18-4
    -   iphone16pro-18-3
--test: MyTests.zip
--additional-apps:
    -   helper-app.ipa
--xcode-version: '16.4'
--xctest-timeout: 15m
--other-files-to-push:
  /local/path/test-config.json: com.example.app:/Documents/test-config.json
--paths-to-pull:
    -   com.example.app:/Documents/screenshots
--labels:
  env: staging
  team: mobile-qa

エンドツーエンドのコマンド変換の例

具体的な例については、標準的な翻訳と複雑な翻訳をご覧ください。

例: 標準のインストルメンテーション テストを実行する

以前の Firebase CLI:

gcloud firebase test android run \
  --app=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --device model=shiba,version=36 \
  --timeout=5m \
  --num-flaky-test-attempts=2 \
  --directories-to-pull=/sdcard/screenshots \
  --environment-variables key=value

DDP CLI の変換:

gcloud beta device-run sessions submit instrumentation \
  --device=shiba-36 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --instrumentation-timeout=5m \
  --flaky-test-attempts=3 \
  --paths-to-pull=/sdcard/screenshots \
  --additional-test-options key=value

例: 複雑な Flank YAML 構成を移行する

以前の Flank 構成:

app: app-debug.apk
test: app-debug-androidTest.apk
device:
  -   model: shiba
    version: 36
shard-time: 120
smart-flank-gcs-path: gs://my-bucket/smart-sharding/timing-record.yaml

DDP CLI の変換:

gcloud beta device-run sessions submit instrumentation \
  --device=shiba-36 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --bucket-name=my-bucket \
  --sharding-option=smart \
  --smart-sharding-target-duration=2m \
  --smart-sharding-record-name=timing-record

実行後と結果の取得

DDP は、以前の Firebase コンソールのようなグラフィカルなウェブ UI で起動しないため、デベロッパーは CLI またはプログラムによる REST API を使用して、結果を直接管理、記述、検査する必要があります。

# 1. List active and completed test sessions
gcloud beta device-run sessions list

# 2. Get a summary and direct Cloud Storage bucket link of a session's results
gcloud beta device-run sessions describe session-number

# 3. Get detailed metadata and print full results
gcloud beta device-run sessions describe session-number --full

# 4. Cancel a running session (replaces console cancellation)
gcloud beta device-run sessions cancel session-number

フラグ マッピング リファレンス

Flank または gcloud firebase test android/ios run から新しい DDP の gcloud beta device-run sessions submit instrumentation コマンドと gcloud alpha device-run sessions submit xctest コマンドにテスト構成を移行するためのフラグ マッピングは次のとおりです。

コアパラメータとアセット

以前のパラメータ(Test Lab / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
側面 --project --project 標準の Google Cloud グローバルフラグ(--project=PROJECT_ID)またはアクティブな Google Cloud CLI 構成。
--client-details --labels テスト セッションに接続する key=value ペアの辞書。
--other-files --other-files-to-push Dictionary にあります)を使用する、フレーズの改行区切りリストで構成されます。テスト実行前にデバイスに push する補助ファイル。従来の DEST=SOURCE の順序を SOURCE=DEST(Android では SOURCE=DEVICE_PATH、iOS では SOURCE=BUNDLE_ID:DEVICE_PATH)に反転します。

デバイス設定とターゲティング

以前のパラメータ(Test Lab / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
--device model={M},version={V} --device={M}-{V} 必須。モデルと OS バージョンを 1 つの --device ID 文字列にマッピングする文字列。DDP の --device フラグには、カンマで区切った複数のデバイス ID を指定できます(例: --device=shiba-34,tokay-36 または --device=iphone16pro-18-3)または複数の --device フラグ(それぞれ異なるデバイス ID を指定。--device=shiba-34 --device=tokay-36)。

実行制御と不安定性

以前のパラメータ(Test Lab / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
--async --async Boolean。1 対 1 でマッピングされます。コマンドはデフォルトで同期的に実行されます。すぐにターミナルに戻るには、これを渡します。ファイルのアップロード直後に終了し、オペレーション ID とセッション ID を出力します。
--num-flaky-test-attempts {R} --flaky-test-attempts {A} 整数。テストシャードあたりの最大実行試行回数。再試行回数 R を合計試行回数 A の上限に変換します。A = R + 1(デフォルトは 1)。

出力とストレージ

以前のパラメータ(Test Lab / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
--results-bucket --bucket-name 文字列。ローカル入力ファイル、テスト出力ファイル、スマート シャーディングのタイミング レコードなどのテスト アーティファクトがアップロードされる Cloud Storage バケット(指定しない場合はデフォルトで gs://[PROJECT_ID]-devicerun になります)。
--results-dir 自動管理 サポート対象外。サブパスは、Cloud Storage の automation/sessions/{session_id}/ の下に自動的に整理されます。
--directories-to-pull --paths-to-pull リスト。テスト実行後にデバイスからダウンロードするファイルまたはディレクトリ(Android の場合は DEVICE_PATH、iOS の場合は BUNDLE_ID:DEVICE_PATH)。

シャーディングの構成

以前のパラメータ(Test Lab / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
--num-uniform-shards {N} --sharding-option=uniform --uniform-sharding-count={N} String と Integer。結合フラグ構成では、均一シャーディング戦略を有効にし、最大シャード数を設定します(有効なカウント範囲: 物理 1 ~ 20、仮想 1 ~ 200)。
側面 --max-test-shards {N} --sharding-option=smart --smart-sharding-max-shard-count={N} String と Integer。結合フラグ構成は、スマート シャーディング戦略を有効にし、最大シャード数を設定します(有効なカウント範囲: 物理 0 ~ 20、仮想 0 ~ 200)。
側面 --shard-time {S} --sharding-option=smart --smart-sharding-target-duration={S} 必須。文字列。スマート シャーディングを目標実行時間で有効にします(例: 2m、10m、1h)。有効な範囲: 2m~1h。
側面 --smart-flank-gcs-path --smart-sharding-record-name={name} --bucket-name={bucket} 必須。文字列。Cloud Storage の smart-sharding/ の --bucket-name 内にあるシャーディング レコード YAML の名前(ファイル拡張子を除く)。

Android 固有のフラグ

この表を使用して、以前の gcloud firebase test android run フラグと Flank Android フラグを、同等の新しい gcloud beta device-run sessions submit instrumentation フラグにマッピングします。

テストタイプ 特徴グループ 以前のパラメータ(firebase android / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
共通の Android コアパラメータとアセット --app --apps リスト。複数のアプリケーション APK / AAB が提供されている場合は、デバイスにインストールする順序ですべてを --apps に渡します。パスはローカルまたは Cloud Storage(gs://...)にあります。
共通の Android コアパラメータとアセット --additional-apks --apps リスト。追加のリスト値をメインの --apps リストに直接マージします。
共通の Android コアパラメータとアセット --obb-files --other-files-to-push 辞書(SOURCE=DEST 形式)。OBB ファイルを対象デバイスのパス(/sdcard/Android/obb/{package_name}/)に直接 push します。
共通の Android デバイス設定とターゲティング --device locale={L} --locale={L} 文字列。デバイスの言語 / 地域を最上位の --locale フラグ(language-region、例: --locale=en-US)を指定します。
共通の Android デバイス設定とターゲティング --device orientation={O} --orientation={O} 文字列。デバイスの向きを最上位の --orientation フラグ(portrait または landscape)にマッピングします。
共通の Android デバイス設定とターゲティング なし --coordinates 文字列。デバイスの GPS 位置座標をモックします(例: --coordinates=37.4220,-122.0841)。
共通の Android 実行制御と不安定性 --grant-permissions 自動デフォルト 自動化。実行時の権限は、デフォルトで自動的に付与されます(--grant-permissions=all と同等)。
共通の Android 出力とストレージ なし --dumpsys 文字列。dumpsys を使用してシステムの状態を収集します(値: always、on-failure)。
共通の Android 出力とストレージ なし --bugreport 文字列。デバイスから完全な bugreport を収集します(値: always、on-failure)。
共通の Android 出力とストレージ --record-video --video 文字列。テスト実行中にデバイスの画面を録画するタイミング。有効な値は always または on-failure です。
Android インストルメンテーション コアパラメータとアセット --type=instrumentation sessions submit instrumentation テストタイプは、--type フラグではなく、サブコマンド構造によって決まります。
Android インストルメンテーション コアパラメータとアセット --test --test 必須。文字列。インストルメンテーション テストを含むテスト APK へのパス(ローカルまたは Cloud Storage)。
Android インストルメンテーション 実行制御と不安定性 --timeout --instrumentation-timeout 再生時間(例: 10m、20s、1h)。有効な範囲: 1m~3h(デフォルトは 5m)。
Android インストルメンテーション 実行制御と不安定性 なし --flaky-test-parallel-retry Boolean。テストの不合格を並行して再試行するかどうか(デフォルトは順次実行の false)。
Android インストルメンテーション 実行制御と不安定性 なし --flaky-test-retry-level 文字列。shard レベルで再試行するか、個々の test レベルで再試行するかを定義します(デフォルトは shard)。
Android インストルメンテーション テストランナーとターゲット --test-runner-class --test-runner-class 文字列。完全修飾のインストルメンテーション テストランナー クラス(例: com.foo.MyRunner)を指定します。指定しない場合、デフォルトのランナー クラスは、アプリのマニフェストを調べることで決定されます。
Android インストルメンテーション テストランナーとターゲット --test-targets --test-targets 実行するテスト ターゲットまたはターゲット フィルタの辞書。各ターゲットは、package、notPackage、class、notClass、annotation、notAnnotation、size などのキーをサポートするパッケージ名またはクラス名で完全修飾する必要があります。testfile 形式または notTestfile 形式はサポートされていません。
Android インストルメンテーション テストランナーとターゲット --use-orchestrator --orchestrator-version Android Test Orchestrator を使用するかどうか。auto(デフォルトのオーケストレーター)または特定のバージョン文字列(例: 1.6)。利用可能なバージョンは gcloud beta device-run software-versions list を使用してクエリできます。
Android インストルメンテーション テストランナーとターゲット --environment-variables --additional-test-options インストルメンテーション テスト ランナーに渡されるオプションの辞書。--test-targets でサポートされている形式は、ここでは使用できません。

iOS 固有のフラグ

次の表を使用して、以前の gcloud firebase test ios run フラグと Flank iOS フラグを、対応する新しい gcloud alpha device-run sessions submit xctest フラグにマッピングします。

テストタイプ 特徴グループ 以前のパラメータ(firebase ios / Flank) ターゲット DDP パラメータ 形式 / 変換ロジック
一般的な iOS コアパラメータとアセット --additional-ipas --additional-apps テスト実行前にデバイスにインストールするヘルパー .ipa ファイルのリスト。
iOS XCTest のみ コアパラメータとアセット --type=xctest sessions submit xctest --type フラグの代わりに、サブコマンド構造でテストタイプを決定します(gcloud alpha を使用)。
iOS XCTest のみ コアパラメータとアセット --test --test 必須。文字列。iOS アプリと XCTest ファイルを含む ZIP ファイルのパス(ローカルまたは Cloud Storage)。
iOS XCTest のみ 実行制御と不安定性 --timeout --xctest-timeout 再生時間(例: 5m、15m、1h)。有効な範囲: 1m~1h(デフォルトは 5m)。
iOS XCTest のみ 出力とストレージ --record-video --video 動画を録画するタイミング: always または on-failure。UI テストケースごとに 1 つの動画が録画されます(iOS 17 以降)。
iOS XCTest のみ テストランナーとターゲット --xctestrun-file --xctestrun-file 文字列。カスタム .xctestrun ファイルのパス(ローカルまたは Cloud Storage)。
iOS XCTest のみ テストランナーとターゲット --xcode-version --xcode-version 文字列。使用する Xcode のカタログ ID またはバージョン文字列(例: xcode-16-4 または 16.4)。利用可能なバージョンは gcloud beta device-run software-versions list を使用してクエリできます。

フィードバックと質問

バグや機能リクエストの報告、ディスカッション フォーラムへの参加については、お問い合わせください。