このページでは、Developer Device Platform でのテスト実行に関するよくある質問と回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、お問い合わせください。
トラブルシューティング
テストの実行に長時間かかるのはなぜですか？
Developer Device Platform カタログから大容量のデバイスを選択すると、テストの開始が早くなる場合があります。デバイスの容量が少ない場合、テストの実行に時間がかかることがあります。呼び出したテストの数が、選択したデバイスの容量を大幅に上回る場合、テストの完了に時間がかかることがあります。
デバイスの容量レベルにかかわらず、次の要因によりテストに長時間かかる場合があります。
- トラフィック。デバイスの可用性とテスト速度に影響します。
- デバイスやインフラストラクチャの障害（いつでも発生する可能性があります）。Developer Device Platform で報告されているインフラストラクチャを確認するには、Google Cloud Personalized Service Health ダッシュボードをご覧ください。
デベロッパー デバイス プラットフォームのデバイス容量の詳細については、デバイスカタログをご覧ください。
有意なテスト結果が得られないのはなぜですか？
有意なテスト結果が得られないことは、テスト実行のキャンセルやインフラストラクチャ エラーが原因でよく起こります。デベロッパー デバイス プラットフォームは、PASSED と FAILED に加えて、ERROR、TIMED_OUT、CANCELLED を返すことがあります。
インフラストラクチャ エラーは、ネットワーク エラーや予期しないデバイスの動作など、Developer Device Platform の内部の問題が原因で発生します。Developer Device Platform は、有意な結果が得られないとのレポートを返す前に、インフラストラクチャ エラーが発生するテスト実行を内部で複数回再試行します。
エラーの原因を判別するには、次の手順を実施します。
- Google Cloud Service Health ダッシュボードで既知のサービス停止を確認します。
デベロッパー デバイス プラットフォームでテストを再試行し、再現可能であることを確認します。
該当する場合は、別のデバイスまたはデバイスタイプでテストを実行してみてください。詳しくは、デバイス カタログをご覧ください。
シャーディングによってテストの実行時間が長くなったのはなぜですか？
シャーディングを行うと、指定したシャードの数が Developer Device Platform で使用できるデバイスの数を超えた場合に、テストの実行時間が長くなることがあります。この状況を回避するには、デバイス数をシャード数に制限します。別のデバイスの選択について詳しくは、デバイス カタログをご覧ください。
テストの開始に時間がかかるのはなぜですか？
テスト リクエストを送信すると、デバイスでテストを実行する準備として、まずアプリの検証、再署名などが行われます。通常、このプロセスは数秒未満で完了しますが、アプリのサイズなどの要因の影響を受ける可能性があります。
アプリの準備が完了すると、テスト実行がスケジュールされ、デバイスがテストを実行できるようになるまでキューに残ります。
テストが完了するまでに時間がかかるのはなぜですか？
テスト実行が完了すると、デバイスからテスト アーティファクトがダウンロードされ、処理を行った後に Cloud Storage にアップロードされます。このステップの所要時間は、アーティファクトの量とサイズに影響されることがあります。
Android 固有のトラブルシューティング
アプリがデータを返さないため、スクリーンショットが見つからない
テスト実行アーティファクト（スクリーンショット、ログファイルなど）は Cloud Storage に保存され、 Google Cloud コンソールに直接レンダリングされます。プロジェクト レベルのロールが割り当てられていることを確認します。
また、Developer Device Platform には、ユーザーの認証情報ではなく独自の認証情報を使用して次の処理を行う専用のサービス エージェントがあります。
- Cloud Storage バケットとオブジェクトの読み取りと書き込み
- Cloud Storage の入力ファイルを内部システムにダウンロードする
- 内部システムから Cloud Storage 出力バケットにファイルをアップロードする
Cloud Storage バケットとファイルにアクセスできる場合でも、そのバケットが DDP で使用されているプロジェクトとは異なるプロジェクトに属している可能性があります。 Google Cloud そのため、Developer Device Platform サービス アカウントにはアクセス権がありません。
個々のバケットにアクセス制御を追加することもできます。テストにファイルを含める方法については、デバイス実行をご覧ください。
返されるインストルメンテーション テストの結果が部分的であるか不足しているのはなぜですか？
インストルメンテーション テストを実行すると、テストケースの合計数が想定よりも少なくなることがあります。これは、通常は AndroidJUnitRunner によって生成されるテストケースの開始マーカーまたは終了マーカーについて、デベロッパー デバイス プラットフォームが logcat を解析できないことが原因で発生することがよくあります。
この問題の一般的な原因を以下に示します。
| 問題の詳細 | 考えられる解決策 |
|---|---|
| タイムアウトによりテストケースが実行されなかった。テストの合計所要時間が、指定したタイムアウト時間より長い場合、または最大タイムアウトより長い場合、Developer Device Platform は残りのテストケースをキャンセルします。 |
|
| テストケースが早期に終了したかエラーになったため、完了できなかった。キャッチされなかった例外またはアサーション エラーが原因で、テストケースが早期に終了することがある。たとえば、アプリに正しいビューが表示されず、テストケースが UI でアクションを実行できない場合、テストケースが無限ループに陥ったり、続行できなくなったりすることがある。 |
動画とlogcat を確認して、テストが停止した場所を調べる。
|
カスタム テストランナー（AndroidJUnitRunner の拡張を含む）が予期せずクラッシュしたか、予期しないテストケースの開始マーカーまたは終了マーカーを logcat に書き込んだ。 |
テストランナーのコードを確認する。 |
logcat に過剰なログが書き込まれたため、バッファが溢れたか、logcat プロセスがクラッシュした。 |
logcat への書き込みを減らす。 |
| テスト対象のアプリがクラッシュした。 | アプリをデバッグする。 |
よくある質問
デベロッパー デバイス プラットフォームの料金に関する情報はどこで確認できますか？
詳しくは、料金と課金に関する質問をご覧ください。
解像度などのデバイスの詳細はどこで確認できますか？
詳細なデバイス情報は API を介して確認できます。これは、device-run devices describe <device-id> コマンドを使用して Developer Device Platform CLI からアクセスできます。
gcloud beta device-run devices describe DEVICE_ID
バックエンドに到達したトラフィックが Developer Device Platform から来たものであるかを判断するにはどうすればよいですか？
バックエンドで、IP 範囲と送信元 IP アドレスを照合することで、トラフィックの発信元が Developer Device Platform にホストされているテストデバイスかどうかを判断できます。
Developer Device Platform は VPC-SC と連携しますか？
Developer Device Platform は VPC-SC では機能しません。そのため、Developer Device Platform の内部ストレージとユーザーの結果バケット間でのアプリとその他のテスト アーティファクトのコピーがブロックされます。
Developer Device Platform で不安定なテストを減らすにはどうすればよいですか？
テストにおける不安定な動作を検出するには、--flaky-test-attempts オプションの使用をおすすめします。デフレークの再実行は、通常のテスト実行と同様に、1 日の割り当てに対して課金またはカウントされます。
次の点にご注意ください。
- DDP はデフォルトで再試行を順番に実行して、費用を節約します。ユーザーは
--flaky-test-parallel-retryを並列実行するように設定する必要があります。 --flaky-test-retry-levelフラグは、shardレベルまたは個々のtestレベルで再試行するかどうかを定義します。デフォルトはshardです。再試行テストのサイズと期間を短縮するには、testに設定します。
iOS 固有のよくある質問
Developer Device Platform は、Appium、Flutter/FlutterDriver、ReactNative/Jest、Cucumber に対応していますか？
これらのアイテムの一部は Google のロードマップに含まれていますが、現在のところ、これらのテスト プラットフォームやアプリ開発プラットフォームのサポートを明言することはできません。
iOS テストの動画が結果に表示されないのはなぜですか？
iOS 18 以降では、結果に動画を表示する予定です。
Android 固有のよくある質問
デベロッパー デバイス プラットフォームはウェアラブル デバイスに対応していますか？
はい。Developer Device Platform は Google Pixel Watch をサポートしています。そのため、Google Pixel Watch のスタンドアロン Wear OS アプリでテストを実行できます。Developer Device Platform デバイスについて詳しくは、デバイスカタログをご覧ください。
デベロッパー デバイス プラットフォームは最新の Google デバイスに対応していますか？
はい。Developer Device Platform は Google Pixel Tablet と Google Pixel Fold に対応しています。スタンドアロンの実機でテストを実行できます。Developer Device Platform で利用可能なデバイスの詳細については、デバイス カタログをご覧ください。
デベロッパー デバイス プラットフォームは、Appium、Flutter/FlutterDriver、ReactNative/Jest、Cucumber に対応していますか？
これらのアイテムの一部は Google のロードマップに含まれていますが、現在のところ、これらのテスト プラットフォームやアプリ開発プラットフォームのサポートを明言することはできません。ただし、Espresso をサポートするフレームワーク（Flutter など）を使用してアプリを作成した場合は、Espresso を使用してインストルメンテーション テストを作成し、デベロッパー デバイス プラットフォームでテストを実施できます。
Developer Device Platform は、ProGuard や R8 などで難読化されたアプリのテストに対応していますか？
Developer Device Platform では、難読化や難読化解除を明示的にサポートしていません。アプリは実行できるかもしれませんが、スタック トレースなどの難読化されたアプリデータは、難読化されたものとしてログに表示されます。
Developer Device Platform でテストを行う際、折りたたみ式デバイスをさまざまな折りたたみ式の状態と形状で使用できますか？
はい。折りたたみ式デバイスは、複数の折りたたみ式の状態と形状でテストできます。
折りたたみ式デバイスには、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},
]
アプリがない場合でもデベロッパー デバイス プラットフォームを試すことはできますか？
他の Developer Device Platform プロダクトとは異なり、Developer Device Platform を使用するために Developer Device Platform SDK を追加する必要はありません。まだアプリがない場合は、APK をオンラインでダウンロードするか、AndroidX GitHub リポジトリ内のいずれかのサンプルからアプリとテスト APK を構築できます。インストルメンテーション テストでは、ソースコードから構築したアプリとテスト APK の両方が必要です。詳細については、インストルメンテーション テストをご覧ください。
デベロッパー デバイス プラットフォームの機能の詳細については、DDP プロダクトの概要をご覧ください。
どのデバイスがスクリーンショット差分テストに適していますか？
スクリーンショット差分テストでは、テストの実行中に取得した画面イメージと、想定される動作を表すゴールデン イメージとの比較に基づいてテスト アサーションを行います。このようなテストにおいては、デバイスの種類によって結果が安定しないことがあります。この種のテストでは Arm（*.arm）エミュレータ デバイスを対象にすることをおすすめします。Arm エミュレータ デバイスは、Android Studio の汎用エミュレータとよく似た、または同一のイメージを使用します。
また、変更の可能性がある状況でスクリーンショット テストの安定性を高めるのに役立つテスト ライブラリを調査することもおすすめします。
デベロッパー デバイス プラットフォームは仮想デバイスを更新しますか？
はい。仮想デバイスは、次の変更が行われると更新されます。
- 既存の画像への更新
- 以前の API レベルのサポート終了
- 新しい Android API レベルの追加
カバレッジ レポートを有効にするにはどうすればよいですか？
カバレッジ レポートを有効にするには、additional-test-options フィールドに coverage=true を追加します。Android Test Orchestrator を使用している場合は、カバレッジの結果を保存するディレクトリ パスを指定する必要があります。
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
Orchestrator を使用していない場合は、ファイルパスを指定できます。
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
スマートフォンを使わずに Wear アプリにログインするにはどうすればよいですか？
通常、アプリでログインに電話が必要な場合は、ログインをスキップしてテストビルドに埋め込まれたトークンを使用するビルド バリアントを作成するか、通常は --other-files-to-push フラグを使用してプッシュされるディスク上のファイルから読み取ることができます。