AWS Device Farm - 開発者ガイドAWS Device Farm 開発者ガイドデバイススロットの購入 (コンソール)..... 15

AWS Device Farm開発者ガイド

API バージョン 2015-06-23

AWS Device Farm 開発者ガイド

AWS Device Farm: 開発者ガイドCopyright © 2020 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's,in any manner that is likely to cause confusion among customers, or in any manner that disparages or discreditsAmazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may notbe affiliated with, connected to, or sponsored by Amazon.


Table of ContentsAWS Device Farm とは ....................................................................................................................... 1

自動アプリテスト ....................................................................................................................... 1リモートアクセスの操作 .............................................................................................................. 1用語 .......................................................................................................................................... 1セットアップ ............................................................................................................................. 2

セットアップ ..................................................................................................................................... 3ステップ 1: AWS にサインアップする ........................................................................................... 3ステップ 2: AWS アカウントで IAM ユーザーを作成または使用する .................................................. 3ステップ 3: IAM ユーザーに Device Farm へのアクセス許可を付与する .............................................. 3次のステップ ............................................................................................................................. 4

はじめに ............................................................................................................................................ 5前提条件 .................................................................................................................................... 5ステップ 1: コンソールへのサインイン .......................................................................................... 5ステップ 2: プロジェクトを作成する ............................................................................................. 6ステップ 3: 実行を作成し開始する ................................................................................................ 6ステップ 4: 実行の結果を表示する ................................................................................................ 7次のステップ ............................................................................................................................. 7

デバイススロットの購入 ...................................................................................................................... 8デバイススロットの購入 (コンソール) ............................................................................................ 8デバイススロットの購入 (AWS CLI) .............................................................................................. 9デバイススロットの購入 (API) .................................................................................................... 11

概念 ................................................................................................................................................ 13デバイス .................................................................................................................................. 13

サポートされるデバイス .................................................................................................... 13デバイスプール ................................................................................................................. 13プライベートデバイス ....................................................................................................... 13デバイスのブランド化 ....................................................................................................... 14デバイススロット .............................................................................................................. 14プリインストールされたデバイスアプリ ............................................................................... 14デバイス機能 .................................................................................................................... 14

テスト環境 ............................................................................................................................... 14標準のテスト環境 .............................................................................................................. 15カスタムのテスト環境 ....................................................................................................... 15

実行 ........................................................................................................................................ 15設定の実行 ....................................................................................................................... 16ファイル保持の実行 .......................................................................................................... 16デバイス状態の実行 .......................................................................................................... 16並列実行 .......................................................................................................................... 16実行タイムアウトの設定 .................................................................................................... 16計測アプリ ....................................................................................................................... 16実行中のアプリの再署名 .................................................................................................... 16実行中の難読化されたアプリケーション ............................................................................... 17実行中の広告 .................................................................................................................... 17実行中のメディア .............................................................................................................. 17実行のための一般的なタスク .............................................................................................. 17

レポート .................................................................................................................................. 17レポート保持期間 .............................................................................................................. 17レポートコンポーネント .................................................................................................... 17レポートのパフォーマンスサンプル ..................................................................................... 17レポートのログ ................................................................................................................. 18レポートの一般的なタスク ................................................................................................. 18

セッション ............................................................................................................................... 18リモートアクセスでサポートされているデバイス ................................................................... 18セッションファイルの保持期間 ........................................................................................... 18

API バージョン 2015-06-23iii


計測アプリ ....................................................................................................................... 18セッション中のアプリケーションの再署名 ............................................................................ 18セッション中の難読化されたアプリケーション ...................................................................... 19

プロジェクトの使用 .......................................................................................................................... 20プロジェクトの作成 .................................................................................................................. 20

前提条件 .......................................................................................................................... 20プロジェクトの作成 (コンソール) ........................................................................................ 20プロジェクトの作成 (AWS CLI) .......................................................................................... 20プロジェクトの作成 (API) .................................................................................................. 21

プロジェクトのリストを表示する ................................................................................................ 21前提条件 .......................................................................................................................... 21プロジェクトのリストを表示する (コンソール) ...................................................................... 21プロジェクトのリストを表示する (AWS CLI) ........................................................................ 21プロジェクトのリストを表示する (API) ................................................................................ 22

テストランの使用 .............................................................................................................................. 23テストランを作成する ............................................................................................................... 23

前提条件 .......................................................................................................................... 23テストランの作成 (コンソール) ........................................................................................... 23テストランの作成 (AWS CLI) ............................................................................................. 25テストランの作成 (API) ..................................................................................................... 33次のステップ .................................................................................................................... 33

実行タイムアウトの設定 ............................................................................................................ 33前提条件 .......................................................................................................................... 34プロジェクトの実行タイムアウトを設定する ......................................................................... 34テストランの実行タイムアウトを設定する ............................................................................ 34

ネットワーク接続と条件のシミュレート ....................................................................................... 34テストランをスケジュールする場合のネットワークシェーピングの設定 .................................... 35ネットワークプロファイルの作成 ........................................................................................ 35テスト中にネットワーク条件を変更する ............................................................................... 36

実行の停止 ............................................................................................................................... 37実行の停止 (コンソール) .................................................................................................... 37実行の停止 (AWS CLI) ....................................................................................................... 38実行の停止 (API) ............................................................................................................... 39

実行のリストを表示する ............................................................................................................ 39実行のリストを表示する (コンソール) .................................................................................. 39実行のリストを表示する (AWS CLI) .................................................................................... 40実行のリストを表示する (API) ............................................................................................ 40

デバイスプールの作成 ............................................................................................................... 40前提条件 .......................................................................................................................... 40デバイスプールの作成 (コンソール) ..................................................................................... 40デバイスプールの作成 (AWS CLI) ....................................................................................... 41デバイスプールの作成 (API) ............................................................................................... 41

結果を分析する ......................................................................................................................... 41テストレポートの実行 ....................................................................................................... 42アーティファクトを使用する .............................................................................................. 48

Device Farm のタグ付け .................................................................................................................... 52リソースのタグ付け .................................................................................................................. 52タグに基づくリソースの検索 ...................................................................................................... 53リソースのタグの削除 ............................................................................................................... 53

テストタイプを使用する .................................................................................................................... 54テストフレームワーク ............................................................................................................... 54

Android アプリケーションテストフレームワーク ................................................................... 54iOS アプリケーションのテストフレームワーク ...................................................................... 54ウェブアプリケーションのテストフレームワーク ................................................................... 54

組み込みのテストタイプ ............................................................................................................ 55Android テスト ......................................................................................................................... 55

Android アプリケーションテストフレームワーク ................................................................... 55

API バージョン 2015-06-23iv


Android 用の組み込みのテストタイプ ................................................................................... 55Appium Java TestNG ........................................................................................................ 56Appium Java JUnit ............................................................................................................ 61Appium Node.js ................................................................................................................ 66Appium Python ................................................................................................................. 69Appium Ruby ................................................................................................................... 73Calabash ......................................................................................................................... 77インストルメンテーション ................................................................................................. 79UI Automator .................................................................................................................... 80

iOS テスト ............................................................................................................................... 82iOS アプリケーションのテストフレームワーク ...................................................................... 82組み込みの iOS 用テストタイプ .......................................................................................... 82Appium Java TestNG ........................................................................................................ 82Appium Java JUnit ............................................................................................................ 88Appium Node.js ................................................................................................................ 93Appium Python ................................................................................................................. 96Appium Ruby .................................................................................................................. 100Calabash ....................................................................................................................... 104UI Automation ................................................................................................................. 106XCTest .......................................................................................................................... 107XCTest UI ...................................................................................................................... 109

ウェブアプリテスト ................................................................................................................. 110計測および計測対象外デバイスのルール ............................................................................. 110Appium Java TestNG ....................................................................................................... 111Appium Java JUnit .......................................................................................................... 116Appium Node.js .............................................................................................................. 121Appium Python ............................................................................................................... 124Appium Ruby .................................................................................................................. 129

組み込みテスト ....................................................................................................................... 132組み込みのテストタイプ ................................................................................................... 132組み込み: エクスプローラ (Android) ................................................................................... 132組み込み: ファズ (Android および iOS) ............................................................................... 133

カスタムテスト環境での作業 ............................................................................................................. 135テストスペック構文 ................................................................................................................. 135テストスペックの例 ................................................................................................................. 136Environment Variables ............................................................................................................. 138

一般的な環境変数 ............................................................................................................ 138Appium Java JUnit 環境変数 ............................................................................................. 140Appium Java TestNG 環境変数 ......................................................................................... 140XCUITest 環境変数 .......................................................................................................... 140

テストの移行 .......................................................................................................................... 140Appium フレームワーク ................................................................................................... 140Android 実装 .................................................................................................................. 140既存の iOS XCUITest テストの移行 ................................................................................... 141

リモートアクセスの使用 ................................................................................................................... 142セッションの作成 .................................................................................................................... 142

前提条件 ........................................................................................................................ 142Device Farm コンソールを使用してセッションを作成する .................................................... 143次のステップ .................................................................................................................. 143

セッションの使用 .................................................................................................................... 143前提条件 ........................................................................................................................ 143Device Farm コンソールでのセッションの使用 .................................................................... 144次のステップ .................................................................................................................. 144ヒントとコツ .................................................................................................................. 144

セッションの結果の取得 ........................................................................................................... 144前提条件 ........................................................................................................................ 145セッションの詳細の表示 ................................................................................................... 145

API バージョン 2015-06-23v


セッションビデオまたはログのダウンロード ....................................................................... 145プライベートデバイスの使用 ............................................................................................................. 146

プライベートデバイスの管理 ..................................................................................................... 146インスタンスプロファイルを作成する ................................................................................ 147プライベートデバイスインスタンスの管理 .......................................................................... 148テストランまたはリモートアクセスセッションの作成 ........................................................... 149プライベートデバイスプールの作成 ................................................................................... 149次のステップ .................................................................................................................. 151

アプリ再署名のスキップ ........................................................................................................... 152Android デバイスでのアプリ再署名のスキップ ..................................................................... 154iOS デバイスでのアプリ再署名のスキップ .......................................................................... 154リモートアクセスセッションを作成してアプリを信頼する ..................................................... 154

VPC エンドポイントサービスを使用する .................................................................................... 155開始する前に .................................................................................................................. 156ステップ 3: VPC エンドポイントの作成 ............................................................................. 156ステップ 2: VPC エンドポイント設定を作成する ................................................................. 157ステップ 3: テストランを作成する ..................................................................................... 158

リージョン間における操作 ........................................................................................................ 158前提条件 ........................................................................................................................ 159ステップ 1: Device Farm を同じリージョンの VPC に接続する .............................................. 159ステップ 2: VPC-1 をセットアップする .............................................................................. 159ステップ 3: VPC-2 をセットアップする .............................................................................. 161ステップ 4: VPC-1 を設定する .......................................................................................... 161ステップ 5: VPC-2 を設定する .......................................................................................... 162ステップ 6: テストランを作成する ..................................................................................... 163

AWS CloudTrail を使用した API コールのログ作成 .............................................................................. 164CloudTrail 内の AWS Device Farm 情報 ..................................................................................... 164AWS Device Farm ログファイルエントリの概要 .......................................................................... 165

CodePipeline 統合 ........................................................................................................................... 167Device Farm テストを使用するように CodePipeline を設定する ..................................................... 167

AWS CLIリファレンス ..................................................................................................................... 172Windows PowerShell リファレンス .................................................................................................... 173Device Farm の自動化 ..................................................................................................................... 174

例: AWS SDK を使用した Device Farm 実行の開始とアーティファクトの収集 .................................. 174トラブルシューティング ................................................................................................................... 177

Android アプリケーション ........................................................................................................ 177ANDROID_APP_UNZIP_FAILED ........................................................................................ 177ANDROID_APP_AAPT_DEBUG_BADGING_FAILED ............................................................. 178ANDROID_APP_PACKAGE_NAME_VALUE_MISSING .......................................................... 179ANDROID_APP_SDK_VERSION_VALUE_MISSING ............................................................. 179ANDROID_APP_AAPT_DUMP_XMLTREE_FAILED .............................................................. 180ANDROID_APP_DEVICE_ADMIN_PERMISSIONS ............................................................... 180

Appium Java JUnit .................................................................................................................. 181APPIUM_JAVA_JUNIT_TEST_PACKAGE_PACKAGE_UNZIP_FAILED .................................... 181APPIUM_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING ............................... 182APPIUM_JAVA_JUNIT_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR .................... 183APPIUM_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING .................................. 184APPIUM_JAVA_JUNIT_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR .................. 184APPIUM_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN ..................... 185APPIUM_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION ..................................... 186

Appium Java JUnit Web ........................................................................................................... 187APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_UNZIP_FAILED ............................................ 187APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING ....................... 188APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR ........... 188APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING .......................... 189APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR .......... 190APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN ............ 191

API バージョン 2015-06-23vi


APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION ............................ 192Appium Java TestNG ............................................................................................................... 193

APPIUM_JAVA_TESTNG_TEST_PACKAGE_UNZIP_FAILED ................................................. 193APPIUM_JAVA_TESTNG_TEST_PACKAGE_DEPENDENCY_DIR_MISSING ............................ 193APPIUM_JAVA_TESTNG_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR ................ 194APPIUM_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING ............................... 195APPIUM_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR .............. 196

Appium Java TestNG Web ....................................................................................................... 197APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_UNZIP_FAILED ........................................ 197APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_DEPENDENCY_DIR_MISSING ................... 198APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR ....... 198APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING ...................... 199APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR ...... 200

Appium Python ....................................................................................................................... 201APPIUM_PYTHON_TEST_PACKAGE_UNZIP_FAILED .......................................................... 201APPIUM_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING ............................... 202APPIUM_PYTHON_TEST_PACKAGE_INVALID_PLATFORM ................................................. 202APPIUM_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING .................................................. 203APPIUM_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME ....................................... 204APPIUM_PYTHON_TEST_PACKAGE_REQUIREMENTS_TXT_FILE_MISSING ......................... 204APPIUM_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION ...................................... 205APPIUM_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED ................. 206APPIUM_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED ....................................... 207

Appium Python Web ................................................................................................................ 208APPIUM_WEB_PYTHON_TEST_PACKAGE_UNZIP_FAILED ................................................. 208APPIUM_WEB_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING ...................... 209APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_PLATFORM ........................................ 209APPIUM_WEB_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING ......................................... 210APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME ............................... 211APPIUM_WEB_PYTHON_TEST_PACKAGE_REQUIREMENTS_TXT_FILE_MISSING ................ 211APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION .............................. 212APPIUM_WEB_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED ......... 213APPIUM_WEB_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED ............................... 214

Calabash ............................................................................................................................... 215CALABASH_TEST_PACKAGE_UNZIP_FAILED_UNZIP_FAILED ............................................ 215CALABASH_TEST_PACKAGE_FEATURES_DIR_MISSING_FEATURES_DIR_MISSING ............ 216CALABASH_TEST_PACKAGE_FEATURE_FILE_MISSING .................................................... 216CALABASH_TEST_PACKAGE_STEP_DEFINITIONS_DIR_MISSING ....................................... 217CALABASH_TEST_PACKAGE_SUPPORT_DIR_MISSING ..................................................... 218CALABASH_TEST_PACKAGE_RUBY_FILE_MISSING_IN_STEP_DEFINITIONS_DIR ................ 218CALABASH_TEST_PACKAGE_RUBY_FILE_MISSING_IN_SUPPORT_DIR .............................. 219CALABASH_TEST_PACKAGE_EMBEDDED_SERVER_MISSING ........................................... 220CALABASH_TEST_PACKAGE_DRY_RUN_FAILED .............................................................. 220

インストルメンテーション ........................................................................................................ 221INSTRUMENTATION_TEST_PACKAGE_UNZIP_FAILED ...................................................... 221INSTRUMENTATION_TEST_PACKAGE_AAPT_DEBUG_BADGING_FAILED ........................... 222INSTRUMENTATION_TEST_PACKAGE_INSTRUMENTATION_RUNNER_VALUE_MISSING ...... 223INSTRUMENTATION_TEST_PACKAGE_AAPT_DUMP_XMLTREE_FAILED ............................. 223INSTRUMENTATION_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING ............... 224

iOS アプリケーション .............................................................................................................. 225IOS_APP_UNZIP_FAILED ................................................................................................ 225IOS_APP_PAYLOAD_DIR_MISSING .................................................................................. 225IOS_APP_APP_DIR_MISSING ........................................................................................... 226IOS_APP_PLIST_FILE_MISSING ....................................................................................... 227IOS_APP_CPU_ARCHITECTURE_VALUE_MISSING ............................................................ 227IOS_APP_PLATFORM_VALUE_MISSING ........................................................................... 228IOS_APP_WRONG_PLATFORM_DEVICE_VALUE ............................................................... 229

API バージョン 2015-06-23vii


IOS_APP_FORM_FACTOR_VALUE_MISSING ..................................................................... 230IOS_APP_PACKAGE_NAME_VALUE_MISSING ................................................................... 231IOS_APP_EXECUTABLE_VALUE_MISSING ........................................................................ 232

UI Automator .......................................................................................................................... 233UIAUTOMATOR_TEST_PACKAGE_UNZIP_FAILED ............................................................. 233

XCTest .................................................................................................................................. 233XCTEST_TEST_PACKAGE_UNZIP_FAILED ........................................................................ 234XCTEST_TEST_PACKAGE_XCTEST_DIR_MISSING ............................................................ 234XCTEST_TEST_PACKAGE_PLIST_FILE_MISSING .............................................................. 235XCTEST_TEST_PACKAGE_PACKAGE_NAME_VALUE_MISSING .......................................... 235XCTEST_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING ............................................... 236

XCTest UI .............................................................................................................................. 237XCTEST_UI_TEST_PACKAGE_UNZIP_FAILED ................................................................... 237XCTEST_UI_TEST_PACKAGE_PAYLOAD_DIR_MISSING ..................................................... 238XCTEST_UI_TEST_PACKAGE_APP_DIR_MISSING ............................................................. 238XCTEST_UI_TEST_PACKAGE_PLUGINS_DIR_MISSING ...................................................... 239XCTEST_UI_TEST_PACKAGE_XCTEST_DIR_MISSING_IN_PLUGINS_DIR ............................. 240XCTEST_UI_TEST_PACKAGE_PLIST_FILE_MISSING ......................................................... 240XCTEST_UI_TEST_PACKAGE_PLIST_FILE_MISSING_IN_XCTEST_DIR ................................ 241XCTEST_UI_TEST_PACKAGE_CPU_ARCHITECTURE_VALUE_MISSING .............................. 242XCTEST_UI_TEST_PACKAGE_PLATFORM_VALUE_MISSING .............................................. 243XCTEST_UI_TEST_PACKAGE_WRONG_PLATFORM_DEVICE_VALUE .................................. 243XCTEST_UI_TEST_PACKAGE_FORM_FACTOR_VALUE_MISSING ....................................... 244XCTEST_UI_TEST_PACKAGE_PACKAGE_NAME_VALUE_MISSING ..................................... 245XCTEST_UI_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING .......................................... 246XCTEST_UI_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING ............................ 247XCTEST_UI_TEST_PACKAGE_TEST_EXECUTABLE_VALUE_MISSING ................................. 248

セキュリティ .................................................................................................................................. 250Identity and Access Management .............................................................................................. 250

対象者 ........................................................................................................................... 250アイデンティティを使用した認証 ...................................................................................... 251AWS Device Farm と IAM の連携 ...................................................................................... 253ポリシーを使用したアクセスの管理 ................................................................................... 256アイデンティティベースのポリシーの例 ............................................................................. 257トラブルシューティング ................................................................................................... 260

コンプライアンス検証 .............................................................................................................. 262データ保護 ............................................................................................................................. 262

転送中の暗号化 ............................................................................................................... 263保管時の暗号化 ............................................................................................................... 263データの保持 .................................................................................................................. 263データ管理 ..................................................................................................................... 264キーの管理 ..................................................................................................................... 264インターネットトラフィックのプライバシー ....................................................................... 264

弾力 ...................................................................................................................................... 265インフラストラクチャセキュリティ ........................................................................................... 265

物理デバイステストのインフラストラクチャセキュリティ ..................................................... 265デスクトップブラウザのテストのインフラストラクチャセキュリティ ..................................... 266

設定と脆弱性の分析 ................................................................................................................. 266インシデントへの対応 .............................................................................................................. 267ログ記録とモニタリング ........................................................................................................... 267セキュリティベストプラクティス .............................................................................................. 267

制限 .............................................................................................................................................. 268ツールとプラグイン ......................................................................................................................... 269

Jenkins CI プラグイン ............................................................................................................. 269ステップ 1: プラグインをインストールする ........................................................................ 272ステップ 2: IAM ユーザーを作成する ................................................................................. 273ステップ 3: 初回の設定手順 .............................................................................................. 274

API バージョン 2015-06-23viii


ステップ 4: プラグインを使用する ..................................................................................... 274依存関係 ........................................................................................................................ 274

Device Farm Gradle プラグイン ................................................................................................ 274Device Farm Gradle プラグインの構築 ............................................................................... 275Device Farm Gradle プラグインをセットアップする ............................................................. 275IAM ユーザーを作成する .................................................................................................. 277テストタイプの設定 ......................................................................................................... 278依存関係 ........................................................................................................................ 280

ドキュメント履歴 ............................................................................................................................ 281AWS の用語集 ................................................................................................................................ 284

API バージョン 2015-06-23ix

AWS Device Farm 開発者ガイド自動アプリテスト

AWS Device Farm とはDevice Farm は、実際に Amazon Web Services (AWS) によりホストされている電話やタブレットで、Android や iOS、およびウェブアプリを物理的にテストしてやり取りできるアプリテストサービスです。

Device Farm を使用する方法は 2 つあります。

• さまざまなテストフレームワークを使用したアプリの自動テスト• 読み込み、実行、リアルタイムでアプリとやり取り可能なデバイスへのリモートアクセス。

自動アプリテストDevice Farm により、独自のテストをアップロードしたり、組み込まれているスクリプトフリーの互換性テストを使用できます。テストは並列実行されるため、テストは複数のデバイスで数分のうちに開始されます。

テストが完了すると、ハイレベルの結果、低レベルのログ、ピクセルからピクセルへのスクリーンショット、パフォーマンスデータを含むテストレポートが更新されます。

Device Farm は、ネイティブかつハイブリッドな Android、iOS、および Fire OS アプリ、PhoneGap、Titanium、Xamarin、Unity、およびその他のフレームワークで作成されたもののテストをサポートしています。インタラクティブなテスト用に Android アプリおよび iOS アプリのリモートアクセスをサポートしています。サポートされているテストタイプの詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

リモートアクセスの操作リモートアクセスを使用すると、ウェブブラウザを介してリアルタイムでデバイスのスワイプ、ジェスチャ、および操作を行うことができます。デバイスのリアルタイムでの操作が役立つ状況は数多くあります。たとえば、カスタマーサービス担当者は、デバイスの使用やセットアップを通してお客様に案内することができます。また、特定のデバイスで実行されているアプリケーションの使用を通して、お客様に説明することもできます。リモートアクセスセッションで実行されているデバイスにアプリケーションをインストールでき、お客様の問題や報告されたバグを再現できます。

リモートアクセスセッション中、Device Farm は、デバイスとのやり取りで実行されたアクションの詳細を収集します。セッションの終了時に、これらの詳細を含むログとセッションの動画キャプチャが生成されます。

用語Device Farm では、情報を整理する方法を定義する、次の用語が導入されます。

デバイスプール

プラットフォーム、製造元、モデルなど、一般的に類似した特性を共有するデバイスのコレクション。

API バージョン 2015-06-231

AWS Device Farm 開発者ガイドセットアップ

ジョブ

1 つのデバイスに対して単一アプリをテストするための Device Farm へのリクエスト。ジョブは、1つ以上のスイートで構成されます。

計測

デバイスの請求を指します。ドキュメントおよび API リファレンスの「測定デバイス」または「測定対象外デバイス」へのリファレンスが表示されます。料金の詳細については、「AWS Device Farm 料金表」を参照してください。

プロジェクト

実行を含む論理ワークスペース、1 つ以上のデバイスに対する単一のアプリケーションのテストごとに 1 つずつ実行。プロジェクトを使用すると、選択した任意の方法でワークスペースを整理できます。たとえば、アプリのタイトルごとに 1 つのプロジェクトがある場合もあれば、プラットフォームごとに 1 つのプロジェクトがある場合もあります。プロジェクトは必要な数だけ作成できます。

report

これには、実行に関する情報、1 つ以上のデバイスに対して単一アプリをテストするための、DeviceFarm に対するリクエストが含まれます。詳細については、「レポート (p. 17)」を参照してください。

run

特定の一連のデバイスで実行される、アプリの特定のビルド、特定の一連のテスト。実行によって、結果のレポートが生成されます。実行は、1 つ以上のジョブで構成されます。詳細については、「実行 (p. 15)」を参照してください。

session

ウェブブラウザを通した実際の物理デバイスとのリアルタイムのやり取りです。詳細については、「セッション (p. 18)」を参照してください。

スイート

テストパッケージ内の階層構造のテストです。スイートは、1 つ以上のテストで構成されます。テスト

テストパッケージ内の個別のテストケース。

Device Farm の詳細については、「概念 (p. 13)」を参照してください。

セットアップDevice Farm を使用するには、「セットアップ (p. 3)」を参照してください。

API バージョン 2015-06-232

https://aws.amazon.com/device-farm/pricing/


AWS Device Farm 開発者ガイドステップ 1: AWS にサインアップする

AWS Device Farm のセットアップDevice Farm を初めて使用する場合は、事前に以下のタスクをすべて実行する必要があります。

トピック• ステップ 1: AWS にサインアップする (p. 3)• ステップ 2: AWS アカウントで IAM ユーザーを作成または使用する (p. 3)• ステップ 3: IAM ユーザーに Device Farm へのアクセス許可を付与する (p. 3)• 次のステップ (p. 4)

ステップ 1: AWS にサインアップするAmazon Web Services (AWS) にサインアップする

AWS アカウントをお持ちでない場合は、次に説明する手順に従ってアカウントを作成してください。

AWS にサインアップするには

1. https://aws.amazon.com/ を開き、[AWS アカウントの作成] を選択します。2. オンラインの手順に従います。

ステップ 2: AWS アカウントで IAM ユーザーを作成または使用する

Device Farm へのアクセスには、AWS ルートアカウントは使用しないことをお勧めします。代わりに、新しい AWS Identity and Access Management (IAM) ユーザーを作成 (または AWS アカウントの既存のユーザーを使用) し、その IAM ユーザーで Device Farm にアクセスします。

詳細については、「IAM ユーザーの作成 (AWS マネジメントコンソール)」を参照してください。

ステップ 3: IAM ユーザーに Device Farm へのアクセス許可を付与する

IAM ユーザーに Device Farm へのアクセス許可を付与します。そのためには、IAM で新しいアクセスポリシーを作成後、そのアクセスポリシーを以下のように IAM ユーザーに割り当てます。

Note

次のステップを完了するために使用する AWS ルートアカウントまたは IAM ユーザーには、次のIAM ポリシーを作成し、その IAM ユーザーにアタッチするアクセス許可が付与されている必要があります。詳細については、「ポリシーの使用」を参照してください。

IAM でアクセスポリシーを作成する

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

API バージョン 2015-06-233

https://aws.amazon.com/

https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SettingUpUser.html#Using_CreateUser_console

https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_manage.html

https://console.aws.amazon.com/iam/

AWS Device Farm 開発者ガイド次のステップ

2. [Policies (ポリシー)] を選択します。3. [Create Policy] を選択します。([Get Started] ボタンが表示された場合は、そのボタンを選択してか

ら、[Create Policy] を選択します)。4. [独自のポリシーを作成] の横の [選択] を選択します。5. [ポリシー名] に、ポリシーの名前 (例: AWSDeviceFarmAccessPolicy) を入力します。6. [説明] に、「Provides access to all Device Farm actions associated with the IAM

user.」と入力します。7. [Policy Document (ポリシードキュメント)] に、次のステートメントを入力します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "devicefarm:*" ], "Resource": [ "*" ] } ]}

8. [Create Policy] を選択します。

アクセスポリシーを IAM ユーザーに割り当てる

1. IAM コンソール（https://console.aws.amazon.com/iam/）を開きます。2. [Users] を選択します。3. IAM ユーザーを選択します。4. [Permissions (アクセス許可)] エリアで、[Add permissions (アクセス許可の追加)] を選択します。5. [Grant permissions (アクセス許可の付与)] エリアで、[Attach existing policies directly (既存のポリシー

を直接アタッチする)] を選択します。6. 先ほど作成したポリシー (例: AWSDeviceFarmAccessPolicy) を選択します。7. [Next: Review] を選択します。8. [Permissions summary (アクセス権限の概要)] エリアで、[Add permissions (アクセス許可の追加)] を

選択します。

Note

前述のポリシーをアタッチすることで、IAM ユーザーには、IAM ユーザーに関連付けられたすべての Device Farm アクションへのアクセス権が付与されます。IAM ユーザーがアクセス可能な Device Farm アクションを制限する方法の詳細については、「AWS Device Farm での Identityand Access Management (p. 250)」を参照してください。

次のステップこれで Device Farm の使用を開始する準備ができました。「はじめに (p. 5)」を参照してください。

API バージョン 2015-06-234


AWS Device Farm 開発者ガイド前提条件

AWS Device Farm の使用開始このチュートリアルでは、Device Farm を使用してネイティブ Android または iOS アプリケーションをテストする方法を示します。Device Farm コンソールを使用して、プロジェクトを作成後 .apk または .ipaファイルをアップロードし、一連のスタンダードテストを実行してその結果を表示します。

トピック• 前提条件 (p. 5)• ステップ 1: コンソールへのサインイン (p. 5)• ステップ 2: プロジェクトを作成する (p. 6)• ステップ 3: 実行を作成し開始する (p. 6)• ステップ 4: 実行の結果を表示する (p. 7)• 次のステップ (p. 7)

前提条件作業を開始する前に、次の要件を満たしていることを確認してください。

• 「セットアップ (p. 3)」の各ステップを実行します。AWS アカウントと、Device Farm にアクセスするアクセス許可を持つ IAM ユーザーが必要です。

• Android の場合は、.apk (Android アプリパッケージ) ファイルが必要です。iOS の場合は、.ipa (iOS アプリアーカイブ) ファイルが必要です。このチュートリアルでは、後ほどこのファイルを Device Farmにアップロードします。

Note

.ipa ファイルがシミュレーター用ではなく iOS デバイス用に作成されていることを確認します。

• (オプション) Device Farm でサポートされているいずれかのテストタイプのテストが必要です。このチュートリアルの後半で、このテストパッケージを Device Farm にアップロードし、テストを実行します。(使用可能なテストパッケージがない場合、スタンダード組み込みテストスイートを指定し、実行できます。) 詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

Note

AWS Device Farm は、us-west-2 (オレゴン) リージョンでのみご利用いただけます。

ステップ 1: コンソールへのサインインDevice Farm コンソールを使用して、テストのためにプロジェクトや実行を作成および管理できます。プロジェクトや実行については、このチュートリアルの後半で説明します。

• https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。

API バージョン 2015-06-235

https://console.aws.amazon.com/devicefarm

AWS Device Farm 開発者ガイドステップ 2: プロジェクトを作成する

ステップ 2: プロジェクトを作成するDevice Farm でアプリケーションをテストするには、まずプロジェクトを作成する必要があります。

1. Device Farm コンソールページで、プロジェクトの名前 (例: MyDemoProject) を入力します。

2. [Create project (プロジェクトの作成)] を選択します。ページを更新して新しいプロジェクトを確認してください。

ステップ 3: 実行を作成し開始するプロジェクトがあるため、実行を作成して開始することができます。詳細については、「実行 (p. 15)」を参照してください。

1. [MyDemoProject] を選択します。2. [Automated tests (自動テスト)] ページで、[Create a new run (新しいランの作成)] を選択します。3. [Choose your application (アプリケーションの選択)] ページで、[Upload (アップロード)] を選択しま

す。4. Android または iOS アプリファイルを参照して選択します。Android の場合、このファイルは .apk

ファイルである必要があります。iOS の場合、このファイルは .ipa ファイルで、シミュレーター用ではなくデバイス用に構築されている必要があります。

5. [Next step] を選択します。6. [Configure a test (テストの設定)] ページで、テストスイートのいずれかを選択します。

Note

利用可能なテストがない場合は、[Built-in: Fuzz] を選択して、スタンダード組み込みテストスイートを実行します。このチュートリアルでは、[Built-in: Fuzz] を選択した場合、[Eventcount]、[Event throttle]、および [Randomizer seed] はデフォルト値のままにしておきます。

7. [Built-in: Fuzz] を選択しなかった場合は [Upload (アップロード)] を選択し、テストが含まれるファイルを参照して選択します。

8. [Next step] を選択します。9. [Select devices (デバイスの選択)] ページの [Device pool (デバイスプール)] で、デバイスプールとして

[Top Devices] を選択し、次に [Next step (次のステップ)] を選択します。10. [Specify device state] ページで、次のいずれかを実行します。

• 実行中に Device Farm で使用する追加のデータを入力するには、[Add extra data] の横で [Upload]を選択後、.zip ファイルを参照して選択します。

• 実行中に Device Farm が使用する追加のアプリをインストールするには、[Install other apps] の横の [Upload] を選択し、追加のアプリが含まれる .apk または .ipa ファイルを参照して選択します。インストールする他のアプリケーションにこの手順を繰り返します。アプリをドラッグアンドドロップして、アプリのインストール順序を変更できます。

API バージョン 2015-06-236

AWS Device Farm 開発者ガイドステップ 4: 実行の結果を表示する

• 実行中に Wi-Fi、Bluetooth、GPS、または NFC を有効にするかどうか指定するには、[Set radiostates (無線状態の設定)] の横にある適切なボックスを選択します。

Note

デバイスのラジオ状態の設定は、現時点では Android ネイティブテストでのみ使用できます。

• 実行用のデバイスの緯度と経度をプリセットするには、[Device location (デバイスの場所)] の横に座標を入力します。

• 実行用のデバイスロケールをプリセットするには、[Device Locale] でロケールを選択します。• 実行用のネットワークプロファイルをプリセットするには、[Network profileCreate] でプロファイル

を選択するか、[Create a new profile] を選択して独自に作成します。11. [Next step] を選択します。12. [Review and start run] ページで、[Confirm and start] を選択します。

デバイスが利用可能になるとすぐに、通常数分以内に、Device Farm は実行を開始します。実行が開始さ

れるまで、Device Farm にはカレンダーアイコン ( ) が表示されます。実行が開始され、テストが完了

すると結果が表示されます。この期間中、Device Farm には進行状況アイコン ( ) が表示されます。

ステップ 4: 実行の結果を表示する進行状況アイコンが結果アイコンに変わると、実行は完了です。詳細については、「テスト結果を理解する (p. 42)」を参照してください。

結果を表示するには、Device Farm コンソールで完了した実行を選択します。概要のページが表示されます。

• 結果ごとのテストの合計数。• 固有の警告または障害があるテストの一覧。• デバイスの一覧と、それぞれのテスト結果。• 実行時にキャプチャされたスクリーンショット、デバイス別にグループ化。

詳細については、「テストレポートの実行 (p. 42)」を参照してください。

これで、このウォークスルーが完了しました。

次のステップDevice Farm の詳細については、「概念 (p. 13)」を参照してください。

API バージョン 2015-06-237

AWS Device Farm 開発者ガイドデバイススロットの購入 (コンソール)

AWS Device Farm でデバイススロットを購入する

デバイススロットを購入するには、AWS Device Farm コンソール、AWS Command Line Interface (AWSCLI)、または AWS Device Farm API を使用できます。

トピック• デバイススロットの購入 (コンソール) (p. 8)• デバイススロットの購入 (AWS CLI) (p. 9)• デバイススロットの購入 (API) (p. 11)

デバイススロットの購入 (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. [UNLIMITED ACCESS (無制限アクセス)] セクションまでスクロールし、[Learn more about unlimited

testing (無制限テストの詳細)] リンクを選択します。3. [Packages (パッケージ)] ページでは、事前に設定されたパッケージ (SINGLE PLATFORM、CROSS

PLATFORM、CONTINUOUS INTEGRATION) のいずれかを選択するか、購入するタイプのスロットの数をそれぞれ選択して独自のカスタムパッケージを作成できます。

Note

事前に設定されたパッケージのいずれかを選択した場合は、自動化テスト、リモートアクセス、またはその両方を選択する必要があります。

テキストは、請求書に追加される量で動的に更新されます。詳細については、「Device Farm 料金表」を参照してください。

4. [Buy now (今すぐ購入)]、[Complete purchase (購入の完了)] の順に選択します。

[お問い合わせ] または [Contact us to purchase (購入のお問い合わせ)] が表示された場合は、リクエストしたデバイス数を購入する承認がアカウントで得られていないことを意味します。[Send usfeedback for the Device Farm Console (デバイスファームコンソールのフィードバックの送信)] ダイアログボックスに、購入するタイプのスロット数をそれぞれ入力し、[Contact Support (サポートへのお問い合わせ)] を選択します。

API バージョン 2015-06-238




AWS Device Farm 開発者ガイドデバイススロットの購入 (AWS CLI)

無料試用期間が残っている場合のみ、[アカウント設定] ページに [You have xxx FREE TRIAL MINUTESremaining (残り xxx 分の無料試用期間があります)] が表示されます。残り時間は目安です。現在実行されているテストの使用状況は反映されていません。

また、現在持っているデバイススロットの数も表示されます。スロット数に増減がある場合は、変更を行った日付から 1 か月後に持つことになるスロットの数が表示されます。

デバイススロットの購入 (AWS CLI)サービスを購入するには、purchase-offering コマンドを実行することができます。

購入できるデバイススロットの最大数や、無料試用期間の残存数を含む Device Farm のアカウント設定を一覧表示するには、get-account-settings コマンドを実行します。以下のような出力結果が表示されるはずです。

{ "accountSettings": { "maxSlots": { "GUID": 1, "GUID": 1, "GUID": 1, "GUID": 1 }, "unmeteredRemoteAccessDevices": { "ANDROID": 0, "IOS": 0 }, "maxJobTimeoutMinutes": 150, "trialMinutes": { "total": 1000.0, "remaining": 954.1 }, "defaultJobTimeoutMinutes": 150, "awsAccountNumber": "AWS-ACCOUNT-NUMBER", "unmeteredDevices": { "ANDROID": 0, "IOS": 0 } }}

利用可能なデバイススロットのサービスを一覧表示するには、list-offerings コマンドを実行します。次のような出力が表示されます。

{ "offerings": [ { "recurringCharges": [ { "cost": { "amount": 250.0, "currencyCode": "USD" }, "frequency": "MONTHLY" } ], "platform": "IOS", "type": "RECURRING", "id": "GUID", "description": "iOS Unmetered Device Slot"

API バージョン 2015-06-239

AWS Device Farm 開発者ガイドデバイススロットの購入 (AWS CLI)

}, { "recurringCharges": [ { "cost": { "amount": 250.0, "currencyCode": "USD" }, "frequency": "MONTHLY" } ], "platform": "ANDROID", "type": "RECURRING", "id": "GUID", "description": "Android Unmetered Device Slot" }, { "recurringCharges": [ { "cost": { "amount": 250.0, "currencyCode": "USD" }, "frequency": "MONTHLY" } ], "platform": "ANDROID", "type": "RECURRING", "id": "GUID", "description": "Android Remote Access Unmetered Device Slot" }, { "recurringCharges": [ { "cost": { "amount": 250.0, "currencyCode": "USD" }, "frequency": "MONTHLY" } ], "platform": "IOS", "type": "RECURRING", "id": "GUID", "description": "iOS Remote Access Unmetered Device Slot" } ]}

利用可能なサービスプロモーションを一覧表示するには、list-offering-promotions コマンドを実行します。

Note

このコマンドは、まだ購入されていないプロモーションのみ返ります。任意のプロモーションを使用して 1 つまたは複数のスロットをサービスから購入すると、そのプロモーションは結果に表示されなくなります。

次のような出力が表示されます。

{ "offeringPromotions": [ { "id": "2FREEMONTHS", "description": "New device slot customers get 3 months for the price of 1."

API バージョン 2015-06-2310

AWS Device Farm 開発者ガイドデバイススロットの購入 (API)

} ]}

サービスのステータスを取得するには、get-offering-status コマンドを実行します。次のような出力が表示されます。

{ "current": { "GUID": { "offering": { "platform": "IOS", "type": "RECURRING", "id": "GUID", "description": "iOS Unmetered Device Slot" }, "quantity": 1 }, "GUID": { "offering": { "platform": "ANDROID", "type": "RECURRING", "id": "GUID", "description": "Android Unmetered Device Slot" }, "quantity": 1 } }, "nextPeriod": { "GUID": { "effectiveOn": 1459468800.0, "offering": { "platform": "IOS", "type": "RECURRING", "id": "GUID", "description": "iOS Unmetered Device Slot" }, "quantity": 1 }, "GUID": { "effectiveOn": 1459468800.0, "offering": { "platform": "ANDROID", "type": "RECURRING", "id": "GUID", "description": "Android Unmetered Device Slot" }, "quantity": 1 } }}

renew-offering および list-offering-transactions はこの機能にも使用できます。詳細については、「AWSCLI リファレンス (Device Farm)」および「AWS CLIリファレンス (p. 172)」を参照してください。

デバイススロットの購入 (API)1. アカウント設定を一覧表示するには、GetAccountSettings オペレーションを呼び出します。2. 利用可能なデバイススロットのサービスを一覧表示するには、ListOfferings オペレーションを呼び出

します。

API バージョン 2015-06-2311

http://docs.aws.amazon.com/cli/latest/reference/devicefarm/index.html

http://docs.aws.amazon.com/cli/latest/reference/devicefarm/index.html

../../latest/APIReference/API_GetAccountSettings.html

../../latest/APIReference/API_ListOfferings.html

AWS Device Farm 開発者ガイドデバイススロットの購入 (API)

3. 利用可能なサービスのプロモーションを一覧表示するには、ListOfferingPromotions オペレーションを呼び出します。

Note

このコマンドは、まだ購入されていないプロモーションのみ返ります。任意のサービスプロモーションを使用して 1 つまたは複数のスロットを購入すると、そのプロモーションは結果に表示されなくなります。

4. サービスを購入するには、PurchaseOffering オペレーションを呼び出します。5. サービスのステータスを取得するには、GetOfferingStatus オペレーションを呼び出します。

RenewOffering および ListOfferingTransactions はこのコマンドにも使用できます。

Device Farm API の使用については、「Device Farm の自動化 (p. 174)」を参照してください。

API バージョン 2015-06-2312

../../latest/APIReference/API_ListOfferingPromotions.html

../../latest/APIReference/API_PurchaseOffering.html

../../latest/APIReference/API_GetOfferingStatus.html

../../latest/APIReference/API_RenewOffering.html

../../latest/APIReference/API_ListOfferingTransactions.html

AWS Device Farm 開発者ガイドデバイス

AWS Device Farm の概念このセクションでは、Device Farm の重要な概念について説明します。

• デバイス (p. 13)• テスト環境 (p. 14)• 実行 (p. 15)• レポート (p. 17)• セッション (p. 18)

Device Farm でサポートされている設定の詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

AWS Device Farm でのデバイスサポート以下のセクションには、Device Farm の上記のデバイスサポート情報が含まれます。

トピック• サポートされるデバイス (p. 13)• デバイスプール (p. 13)• プライベートデバイス (p. 13)• デバイスのブランド化 (p. 14)• デバイススロット (p. 14)• プリインストールされたデバイスアプリ (p. 14)• デバイス機能 (p. 14)

サポートされるデバイスDevice Farm は、よく使用される一意の何百もの Android、iOS、Fire OS デバイスとオペレーティングシステムの組み合わせをサポートします。利用可能なデバイスのリストは、新しいデバイスが市場に参入するにつれて増加します。デバイスの完全なリストは、「デバイスリスト」を参照してください。

デバイスプールDevice Farm は、デバイスをテスト用に使用できるデバイスプールに整理します。これらのデバイスプールには、Android または iOS でのみ実行されるデバイスなど、関連するデバイスが含まれます。DeviceFarm は、最上位のデバイス用など、精選されたデバイスプールを提供します。パブリックデバイスとプライベートデバイスを混合したデバイスプールを作成することもできます。

プライベートデバイスプライベートデバイスでは、テストのニーズに応じた厳密なハードウェアとソフトウェアの構成を指定できます。各プライベートデバイスは、Amazon データセンターで Device Farm がユーザーに代わってデプロイする物理デバイスです。プライベートデバイスは自分専用で、自動化されたテストと手動テストの両

API バージョン 2015-06-2313

https://aws.amazon.com/device-farm/device-list/

AWS Device Farm 開発者ガイドデバイスのブランド化

方に使用できます。サブスクリプションを終了することを選択したら、ご使用の環境からハードウェアが削除されます。詳細については、「プライベートデバイス」および「AWS Device Farm でのプライベートデバイスの使用 (p. 146)」を参照してください。

デバイスのブランド化Device Farm は、OEM ブランドおよびキャリアブランドの両方である物理的、非ルートデバイスでテストを実行します。

デバイススロットデバイススロットは、購入したデバイススロットの数によってテストまたはリモートアクセスセッションで実行できるデバイスの数を決定する同時実行に対応しています。

デバイススロットには、次の 2 種類あります。

• リモートアクセスデバイススロットはリモートアクセスセッションで同時に実行できるスロットです。

1 つのリモートアクセスデバイススロットがある場合は、一度に 1 つのリモートアクセスセッションしか実行できません。追加のリモートテストデバイススロットを購入すると、複数のセッションを同時に実行することができます。

• 自動テストデバイススロットは、テストを同時に実行できるスロットです。

1 つの自動テストデバイススロットがある場合、テストは、一度に 1 つのデバイスでのみ実行することができます。追加の自動テストデバイススロットを購入すると、複数のデバイスで複数のテストを同時に実行し、テスト結果を迅速に取得できます。

デバイスファミリー (自動テスト用の Android または iOS デバイス、および、リモートアクセス用のAndroid または iOS デバイス) に基づいてデバイススロットを購入できます。詳細については、「DeviceFarm 料金表」を参照してください。

プリインストールされたデバイスアプリDevice Farm のデバイスには、メーカーやキャリアによって既にインストールされているアプリがいくつか含まれています。

デバイス機能デバイスはいずれも、インターネットに Wi-Fi 接続することができます。それらにはキャリア接続がなく、電話をかけたり SMS メッセージを送信することはできません。

前面または背面のカメラをサポートする任意のデバイスで写真を撮ることができます。デバイスのマウント方法により、写真が暗く、ぼやける場合があります。

Google Play サービスはサポートされているデバイスにはインストールされていますが、これらのデバイスには有効な Google アカウントはありません。

AWS Device Farm のテスト環境AWS Device Farm では、自動化テスト用にカスタムテスト環境とテスト環境のいずれも用意されています。自動化テストを完全にコントロールするには、カスタムのテスト環境を選択します。または、DeviceFarm のデフォルトテスト環境を選択します。このテスト環境では、自動化テストスイートの各テストを細かくレポートすることができます。

API バージョン 2015-06-2314

https://aws.amazon.com/device-farm/pricing/#privateDevices



AWS Device Farm 開発者ガイド標準のテスト環境

トピック• 標準のテスト環境 (p. 15)• カスタムのテスト環境 (p. 15)

標準のテスト環境標準環境でテストを実行する場合、Device Farm では、テストスイートのすべてのケースで詳細なログとレポートが用意されています。アプリの問題を特定し、修正するには、各テストのパフォーマンスデータ、動画、スクリーンショット、ログを表示します。

Note

Device Farm の標準環境では、細かいレポートを表示できるため、テスト実行時間は、ローカルにテストを実行する場合よりも長くなる場合があります。実行時間を早めるには、カスタムのテスト環境でテストを実行します。

カスタムのテスト環境テスト環境をカスタマイズする場合は、テストを実行するために Device Farm で実行するコマンドを指定します。これにより、ローカルマシン上でテストを実行した場合と同様に、Device Farm のテストを実行することができます。このモードでテストを実行して、テストのライブログおよびビデオストリーミングを有効にすることもできます。カスタマイズされたテスト環境でテストを実行する場合、各テストケースの細かいレポートは取得できません。詳細については、「カスタムテスト環境での作業 (p. 135)」を参照してください。

テストランを作成するには、Device Farm コンソール、AWS CLI、Device Farm API を使用してカスタムのテスト環境を使用することができます。

詳細については、AWS CLI を使用したカスタムテスト仕様のアップロードに関するページと「AWSDevice Farm でテストランを作成する (p. 23)」を参照してください。

AWS Device Farm での実行次のセクションには、Device Farm での実行に関する情報が含まれています。

Device Farm の実行は、特定の一連のデバイスで実行される、アプリの特定のビルドと、特定の一連のテストを表します。実行により、実行の結果に関する情報を含むレポートが作成されます。実行は、1 つ以上のジョブで構成されます。

トピック• 設定の実行 (p. 16)• ファイル保持の実行 (p. 16)• デバイス状態の実行 (p. 16)• 並列実行 (p. 16)• 実行タイムアウトの設定 (p. 16)• 計測アプリ (p. 16)• 実行中のアプリの再署名 (p. 16)• 実行中の難読化されたアプリケーション (p. 17)• 実行中の広告 (p. 17)• 実行中のメディア (p. 17)

API バージョン 2015-06-2315

https://docs.aws.amazon.com/devicefarm/latest/developerguide/how-to-create-test-run.html#how-to-create-test-run-cli-step5

AWS Device Farm 開発者ガイド設定の実行

• 実行のための一般的なタスク (p. 17)

設定の実行実行の一部として、Device Farm が現在のデバイス設定を上書きするために使用できる設定を指定できます。これには、緯度と経度の座標、ロケール、ラジオの状態 (Bluetooth、GPS、NFC、Wi-Fi など)、追加データ (.zip ファイルに含まれる)、補助アプリケーション (アプリケーションをテストする前にインストールする必要のあるアプリ) が含まれます。

ファイル保持の実行Device Farm は、アプリケーションやファイルを 30 日間保存し、その後システムから削除します。ただし、いつでもファイルを削除することができます。

Device Farm は、実行結果、ログ、およびスクリーンショットを 400 日間保存し、その後システムから削除します。

デバイス状態の実行Device Farm は、次のジョブに使用可能にする前に、常にデバイスを再起動します。

並列実行Device Farm は、デバイスが使用可能になると、並行してテストを実行します。

実行タイムアウトの設定各デバイスのテストの実行を停止するまでのテストランの実行時間の値を設定することができます。たとえば、テストが完了するまでにデバイスあたり 20 分かかる場合、デバイスあたり 30 分のタイムアウトを選択する必要があります。

詳細については、「AWS Device Farm でのテストランの実行タイムアウトの設定 (p. 33)」を参照してください。

計測アプリアプリを計測したり、アプリのソースコードを Device Farm に提供する必要はありません。Android アプリケーションは変更なしで送信できます。iOS アプリは、シミュレータではなく、iOS デバイスターゲットで作成する必要があります。

実行中のアプリの再署名iOS アプリの場合は、Device Farm UUID をプロビジョニングプロファイルに追加する必要はありません。Device Farm では、組み込みプロビジョニングプロファイルをワイルドカードプロファイルに置き換え、アプリに再署名します。補助データを提供する場合、Device Farm は、Device Farm がインストールする前にそれをアプリのパッケージに追加し、その補助データがアプリのサンドボックスに存在するようにします。アプリの再署名は、App Group、Associated Domains、Game Center、HealthKit、HomeKit、ワイヤレスアクセサリー設定、アプリ内購入、アプリ内オーディオ、Apple Pay、プッシュ通知、VPN 設定と制御などの使用権限管理を削除します。

Android アプリの場合、Device Farm がアプリケーションに再署名します。これにより、Google MapsAndroid API などのアプリの署名に依存する機能が破損するか、DexGuard などの製品から著作権侵害や不正使用を検出する可能性があります。

API バージョン 2015-06-2316

AWS Device Farm 開発者ガイド実行中の難読化されたアプリケーション

実行中の難読化されたアプリケーションAndroid アプリでは、アプリが難読化された場合、ProGuard を使用すれば、Device Farm でテストできます。ただし、DexGuard と著作権侵害対策を併用すると、Device Farm は再署名してアプリに対してテストを実行できなくなります。

実行中の広告Device Farm にアップロードする前に、アプリから広告を削除することをおすすめします。実行中に広告が表示されることは保証できません。

実行中のメディアアプリに付随するメディアやその他のデータを提供することができます。追加データは、4 GB 以下のサイズの .zip ファイルで提供する必要があります。

実行のための一般的なタスク詳細については、「AWS Device Farm でテストランを作成する (p. 23)」および「テストランの使用 (p. 23)」を参照してください。

AWS Device Farm のレポート以下のセクションでは、Device Farm のテストレポートについて説明します。

トピック• レポート保持期間 (p. 17)• レポートコンポーネント (p. 17)• レポートのパフォーマンスサンプル (p. 17)• レポートのログ (p. 18)• レポートの一般的なタスク (p. 18)

レポート保持期間Device Farm は 400 日間レポートを保存します。これらのレポートには、メタデータ、ログ、スクリーンショット、パフォーマンスデータが含まれます。

レポートコンポーネントDevice Farm のレポートには、成功および失敗情報、クラッシュレポート、テストとデバイスのログ、スクリーンショット、およびパフォーマンスデータが含まれています。

レポートには、デバイス別の詳細データとハイレベルの結果の両方が含まれます (例: 特定の問題の出現回数)。

レポートのパフォーマンスサンプルテストランの実行中、Device Farm はパフォーマンスサンプルを毎秒キャプチャします。

API バージョン 2015-06-2317

AWS Device Farm 開発者ガイドレポートのログ

レポートのログレポートには、Android テストの完全な logcat キャプチャ、および iOS テストの完全なデバイスコンソールログが含まれます。

レポートの一般的なタスク詳細については、「テストレポートの実行 (p. 42)」を参照してください。

AWS Device Farm のセッションウェブブラウザのリモートアクセスセッションを使用して、Android および iOS のアプリのインタラクティブなテストを実行するには、Device Farm を使用します。このようなインタラクティブなテストは、エンジニアが電話でお客様の問題に対応するのに役立ちます。開発者は問題の原因を分離するために、特定のデバイスで問題を再現できます。リモートセッションを使用して、ターゲットとするお客様と共にユーザビリティテストを実施できます。

トピック• リモートアクセスでサポートされているデバイス (p. 18)• セッションファイルの保持期間 (p. 18)• 計測アプリ (p. 18)• セッション中のアプリケーションの再署名 (p. 18)• セッション中の難読化されたアプリケーション (p. 19)

リモートアクセスでサポートされているデバイスDevice Farm では、よく使用される一意な多数の Android および iOS デバイスがサポートされています。利用可能なデバイスのリストは、新しいデバイスが市場に参入するにつれて増加します。Device Farm コンソールには、リモートアクセスで利用可能な Android および iOS デバイスの最新のリストが表示されます。詳細については、「デバイス (p. 13)」を参照してください。

セッションファイルの保持期間Device Farm は、アプリケーションやファイルを 30 日間保存し、その後システムから削除します。ただし、いつでもファイルを削除することができます。

Device Farm は、セッションログおよびキャプチャしたビデオを 400 日間保存し、その後システムから削除します。

計測アプリアプリを計測したり、アプリのソースコードを Device Farm に提供する必要はありません。Android および iOS のアプリは変更せずに送信できます。

セッション中のアプリケーションの再署名Device Farm によって、Android と iOS のアプリの両方に再署名されます。これにより、アプリケーションの署名に依存する機能が無効になる可能性があります。たとえば、Android の Google マップの APIは、アプリの署名に依存しています。アプリの再署名を行うことで、Android デバイス用の DexGuard などの製品からの著作権侵害や不正使用を検出することもできます。

API バージョン 2015-06-2318

AWS Device Farm 開発者ガイドセッション中の難読化されたアプリケーション

セッション中の難読化されたアプリケーションAndroid アプリでは、アプリが難読化された場合、ProGuard を使用すれば、Device Farm でテストできます。ただし、DexGuard と著作権侵害対策を併用した場合、Device Farm では、アプリの再署名を行うことはできません。

API バージョン 2015-06-2319

AWS Device Farm 開発者ガイドプロジェクトの作成

AWS Device Farm でのプロジェクトの使用

Device Farm のプロジェクトは、実行を含む Device Farm の論理ワークスペースを表し、1 つ以上のデバイスに対する単一のアプリケーションのテストごとに 1 つずつ実行されます。プロジェクトにより、選択した任意の方法でワークスペースを整理できるようになります。たとえば、アプリのタイトルごとに 1 つのプロジェクトがある場合もあれば、プラットフォームごとに 1 つのプロジェクトがある場合もあります。プロジェクトは必要な数だけ作成できます。

プロジェクトを使用するには、AWS Device Farm コンソール、AWS Command Line Interface (AWSCLI)、または AWS Device Farm API を使用します。

トピック• AWS Device Farm でプロジェクトを作成する (p. 20)• AWS Device Farm でプロジェクトのリストを表示する (p. 21)

AWS Device Farm でプロジェクトを作成するAWS Device Farm コンソール、AWS CLI、または AWS Device Farm API を使用してプロジェクトを作成できます。

前提条件• 「セットアップ (p. 3)」の各ステップを実行します。

プロジェクトの作成 (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. Device Farm コンソールで、[新しいプロジェクトを作成する] を選択します。3. プロジェクトの名前を入力し、[Create project (プロジェクトの作成)] を選択します。4. プロジェクトの設定を指定するには、[プロジェクト設定] を選択します。これらの設定には、テスト

ランのデフォルトのタイムアウトが含まれます。適用された設定は、プロジェクトのすべてのテストランで使用されます。詳細については、「AWS Device Farm でのテストランの実行タイムアウトの設定 (p. 33)」を参照してください。

プロジェクトの作成 (AWS CLI)• プロジェクト名を指定して create-project を実行します。

例:

aws devicefarm create-project --name MyProjectName

AWS CLI のレスポンスには、プロジェクトの Amazon リソースネーム (ARN) が含まれます。

{

API バージョン 2015-06-2320


AWS Device Farm 開発者ガイドプロジェクトの作成 (API)

"project": { "name": "MyProjectName", "arn": "arn:aws:devicefarm:us-west-2:123456789101:project:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "created": 1535675814.414 }}

詳細については、「create-project」および「AWS CLIリファレンス (p. 172)」を参照してください。

プロジェクトの作成 (API)• CreateProject API を呼び出します。


AWS Device Farm でプロジェクトのリストを表示する

プロジェクトのリストを表示するには、AWS Device Farm コンソール、AWS CLI、または AWS DeviceFarm API を使用します。

トピック• 前提条件 (p. 21)• プロジェクトのリストを表示する (コンソール) (p. 21)• プロジェクトのリストを表示する (AWS CLI) (p. 21)• プロジェクトのリストを表示する (API) (p. 22)

前提条件• Device Farm で少なくとも 1 つのプロジェクトを作成します。「AWS Device Farm でプロジェクトを

作成する (p. 20)」の指示に従って、このページに戻ります。

プロジェクトのリストを表示する (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. 使用可能なプロジェクトのリストが表示されていない場合は、セカンダリナビゲーションバーで、次

のいずれかを実行します。

• Device Farm コンソールのホームボタンを選択します。• [プロジェクト] で [すべてのプロジェクトを表示] を選択します。

プロジェクトのリストを表示する (AWS CLI)• プロジェクトリストを表示するには、list-projects コマンドを実行します。

API バージョン 2015-06-2321

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/create-project.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateProject.html


https://docs.aws.amazon.com/cli/latest/reference/devicefarm/list-projects.html

AWS Device Farm 開発者ガイドプロジェクトのリストを表示する (API)

1 つのプロジェクトについての情報を表示するには、get-project コマンドを実行します。

AWS CLI での Device Farm の詳細な使用方法については、「AWS CLIリファレンス (p. 172)」を参照してください。

プロジェクトのリストを表示する (API)• プロジェクトリストを表示するには、ListProjects API を呼び出します。

1 つのプロジェクトについての情報を表示するには、GetProject API を呼び出します。

AWS Device Farm API の詳細については、「Device Farm の自動化 (p. 174)」を参照してください。

API バージョン 2015-06-2322

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/get-project.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ListProjects.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_GetProject.html

AWS Device Farm 開発者ガイドテストランを作成する

AWS Device Farm でのテストランの使用

Device Farm の実行は、特定の一連のデバイスで実行される、アプリの特定のビルドと、特定の一連のテストを表します。実行により、実行の結果に関する情報を含むレポートが作成されます。実行は、1 つ以上のジョブで構成されます。詳細については、「実行 (p. 15)」を参照してください。

テストランを使用するには、AWS Device Farm コンソール、AWS Command Line Interface (AWS CLI)、または AWS Device Farm API を使用します。

トピック• AWS Device Farm でテストランを作成する (p. 23)• AWS Device Farm でのテストランの実行タイムアウトの設定 (p. 33)• AWS Device Farm 実行用のネットワーク接続と条件をシミュレートする (p. 34)• AWS Device Farm の実行の停止 (p. 37)• AWS Device Farm で実行のリストを表示する (p. 39)• AWS Device Farm でデバイスプールを作成する (p. 40)• AWS Device Farm での結果の分析 (p. 41)

AWS Device Farm でテストランを作成するテストランを作成するには、AWS Device Farm コンソール、AWS CLI、または AWS Device Farm API を使用します。また、サポートされているプラグイン (例: Device Farm 用 Jenkins または Gradle プラグイン) を使用することもできます。プラグインの詳細については、「ツールとプラグイン (p. 269)」を参照してください。ランに関しては、「実行 (p. 15)」を参照してください。

トピック• 前提条件 (p. 23)• テストランの作成 (コンソール) (p. 23)• テストランの作成 (AWS CLI) (p. 25)• テストランの作成 (API) (p. 33)• 次のステップ (p. 33)

前提条件Device Farm にプロジェクトが作成されている必要があります。「AWS Device Farm でプロジェクトを作成する (p. 20)」の指示に従って、このページに戻ります。

テストランの作成 (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. AWS Device Farm コンソールホームページが表示されたら、プロジェクトの名前を入力し、[Create

project (プロジェクトの作成)] を選択します。ページを更新して新しいプロジェクトを確認してください。

API バージョン 2015-06-2323


AWS Device Farm 開発者ガイドテストランの作成 (コンソール)

3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。それ以外の場合は、[Create a new project (新規プロジェクトの作成)] を選択し、プロジェクトの名前を入力します。

4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションを選択)] ページで、ネイティブアプリケーション ( )

またはウェブアプリケーション ( ) を選択します。

6. アプリケーションファイルをアップロードします。ファイルをドラッグアンドドロップするか、最近のアップロードを選択することもできます。iOS アプリをアップロードする場合は、シミュレータではなく、必ず [iOS デバイス] を選択してください。

7. (オプション) [Run name (実行名)] に名前を入力します。実行名を指定しない場合、Device Farm はアプリのファイル名を使用します。

8. [次のステップ] を選択します。9. [Configure (設定)] ページで、利用可能なテストスイートのいずれかを選択します。

Note

利用可能なテストがない場合は、[Built-in: ファズ] を選択して、標準の組み込みテストスイートを実行します。[Built-in: ファズ] を選択して、[Event count (イベント数)]、[イベント調整]、および [ランダマイザーシード] ボックスが表示されたら、必要に応じて値を変更するか、そのままにすることができます。

使用できるテストスイートの詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

10. [Built-in: ファズ] を選択しなかった場合は、[アップロード] を選択し、テストが含まれるファイルを参照して選択します。

11. 実行環境で、[Run test in our standard environment (標準環境でテストを実行)] または [Customizeyour test environment (テスト環境をカスタマイズ)] を選択します。詳細については、「テスト環境 (p. 14)」を参照してください。

12. 標準のテスト環境を使用している場合は、ステップ 13 に進みます。デフォルトのテストスペックYAML ファイルでカスタムのテスト環境を使用している場合は、ステップ 13 に進みます。

a. カスタムのテスト環境でデフォルトのテストスペックを編集する場合は、[編集] を選択して、デフォルトの YAML 使用をアップデートします。

b. テストスペックを変更する場合は、[Save as New] を選択してテストスペックをアップデートします。

13. 録画またはパフォーマンスデータキャプチャオプションを設定する場合は、[Advanced Configuration]を選択します。

a. テスト実行中の録画を有効にするには、[Enable Video Recording (録画の有効化)] を選択します。b. デバイスのパフォーマンスデータのキャプチャを有効にするには、[Enable App Performance

Data Capture (アプリのパフォーマンスデータキャプチャの有効化)] を選択します。

API バージョン 2015-06-2324

AWS Device Farm 開発者ガイドテストランの作成 (AWS CLI)

Note

プライベートデバイスがある場合は、[Configuration for Private Devices] も表示されます。14. [次のステップ] を選択します。15. [Select devices (デバイスの選択)] ページで、次のいずれかを実行します。

• 組み込みのデバイスプールを選択して [Device pool] に対してテストを実行するには、[Top Devices]を選択します。

• 独自のデバイスプールを作成してテストを実行するには、「デバイスプールの作成 (p. 40)」の手順に従って操作を行った後、このページに戻ります。

• [Device pool] ですでに独自のデバイスプールを作成している場合は、自分のデバイスプールを選択します。

詳細については、「デバイス (p. 13)」を参照してください。16. [次のステップ] を選択します。17. [Specify device state] ページで、以下の操作を実行します。

• 実行中に Device Farm で使用するデータを他にも入力するには、[Add extra data] の横で [Upload]を選択後、データを含む .zip ファイルを参照して選択します。

• 実行中に Device Farm が使用する追加のアプリをインストールするには、[Install other apps] の横の [Upload] を選択し、追加のアプリが含まれる .apk または .ipa ファイルを参照して選択します。インストールする他のアプリケーションにもこの手順を繰り返します。インストール順序を変更するには、アップロードした後にアプリをドラッグアンドドロップします。

• 実行中に Wi-Fi、Bluetooth、GPS、または NFC を有効にするかどうか指定するには、[Set radiostates (無線状態の設定)] の横にある適切なボックスを選択します。

• 実行用のデバイスの緯度と経度をプリセットするには、[Device location (デバイスの場所)] の横に座標を入力します。

• 実行用のデバイスロケールをプリセットするには、[Device Locale (デバイスロケール)] でロケールを選択します。

18. [Review and start run] を選択します。19. このページでは、テストランの実行タイムアウトを指定することができます。無制限のテストスロッ

トを使用している場合は、[Run on unmetered slots (計測されていないスロットで実行)] が選択されていることを確認します。

20. 実行タイムアウトを変更するには、値を入力するか、スライダーを使用します。詳細については、「AWS Device Farm でのテストランの実行タイムアウトの設定 (p. 33)」を参照してください。

21. [Confirm and start run] を選択します。

Device Farm は、デバイスが利用可能になると、通常数分以内に実行を開始します。実行が開始されるま

で、Device Farm にはカレンダーアイコン ( ) が表示されます。実行が開始され、テストが完了すると

結果が表示されます。この期間中、Device Farm には進行状況アイコン ( ) が表示されます。

テストランを停止する必要がある場合は、「AWS Device Farm の実行の停止 (p. 37)」を参照してください。

テストランの作成 (AWS CLI)テストランを作成するには、AWS CLI を使用します。

トピック

API バージョン 2015-06-2325


• ステップ 1: プロジェクトを選択する (p. 26)• ステップ 2: デバイスプールを選択する (p. 26)• ステップ 3: アプリケーションファイルをアップロードする (p. 27)• ステップ 4: テストスクリプトパッケージをアップロードする (p. 28)• ステップ 5: カスタムテストスペックをアップロードする (オプション) (p. 29)• ステップ 6: テストランをスケジュール設定する (p. 31)

ステップ 1: プロジェクトを選択するテストランは Device Farm に関連付ける必要があります。

1. Device Farm プロジェクトを一覧表示するには、list-projects を実行します。プロジェクトがない場合は、「AWS Device Farm でプロジェクトを作成する (p. 20)」を参照してください。

例:

aws devicefarm list-projects

このレスポンスには、Device Farm プロジェクトのリストが含まれています。

{ "projects": [ { "name": "MyProject", "arn": "arn:aws:devicefarm:us-west-2:123456789101:project:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "created": 1503612890.057 } ]}

2. プロジェクトを選択してテストランを関連付け、その Amazon リソースネーム (ARN) を書き留めます。

ステップ 2: デバイスプールを選択するデバイスプールを選択して、テストランを関連付ける必要があります。

1. デバイスプールを表示するには、プロジェクト ARN を指定して list-device-pools を実行します。

例:

aws devicefarm list-device-pools --arn arn:MyProjectARN

このレスポンスには、Device Farm の組み込みデバイスプール (例: Top Devices や、このプロジェクト用に以前作成したデバイスプール) が含まれます。

{ "devicePools": [ { "rules": [ { "attribute": "ARN", "operator": "IN",

API バージョン 2015-06-2326


"value": "[\"arn:aws:devicefarm:us-west-2::device:example1\",\"arn:aws:devicefarm:us-west-2::device:example2\",\"arn:aws:devicefarm:us-west-2::device:example3\"]" } ], "type": "CURATED", "name": "Top Devices", "arn": "arn:aws:devicefarm:us-west-2::devicepool:example", "description": "Top devices" }, { "rules": [ { "attribute": "PLATFORM", "operator": "EQUALS", "value": "\"ANDROID\"" } ], "type": "PRIVATE", "name": "MyAndroidDevices", "arn": "arn:aws:devicefarm:us-west-2:605403973111:devicepool:example2" } ]}

2. デバイスプールを選択し、その ARN を書き留めておきます。

また、デバイスプールは作成することもできます。作成後、このステップに戻ります。詳細については、「デバイスプールの作成 (AWS CLI) (p. 41)」を参照してください。

ステップ 3: アプリケーションファイルをアップロードするアップロードリクエストを作成し、Amazon S3 の署名付き URL を取得するには、以下が必要です。

• プロジェクト ARN。• アプリファイルの名前。• アップロードのタイプ。

詳細については、「create-upload」を参照してください。

1. ファイルをアップロードするには、–-project-arn、--name、および --type パラメータを指定して、create-upload を実行します。

この例では、Android アプリ用のアップロードファイルを作成します。

aws devicefarm create-upload -–project-arn arn:MyProjectArn -–name MyAndroid.apk -–type ANDROID_APP

このレスポンスには、アプリのアップロード ARN および署名付き URL が含まれます。

{ "upload": { "status": "INITIALIZED", "name": "MyAndroid.apk", "created": 1535732625.964, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "ANDROID_APP", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE"

API バージョン 2015-06-2327

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/create-upload.html


}}

2. アプリのアップロード ARN と署名付き URL を書き留めます。3. Amazon S3 の署名付き URL を使用してアプリファイルをアップロードします。この例では、curl を

使用して、Android .apk ファイルをアップロードします。

curl -T MyAndroid.apk "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL"

詳細については、Amazon Simple Storage Service 開発者ガイドの「署名付き URL を使用したオブジェクトのアップロード」を参照してください。

4. アプリアップロードのステータスを確認するには、get-upload を実行し、アプリアップロードの ARNを指定します。

aws devicefarm get-upload –-arn arn:MyAppUploadARN

レスポンスのステータスが SUCCEEDED になるまで待ってから、テストスクリプトパッケージをアップロードします。

{ "upload": { "status": "SUCCEEDED", "name": "MyAndroid.apk", "created": 1535732625.964, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "ANDROID_APP", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "metadata": "{"valid": true}" }}

ステップ 4: テストスクリプトパッケージをアップロードする次に、テストスクリプトパッケージをアップロードします。

1. アップロードリクエストを作成し、Amazon S3 署名付きアップロード URL を取得するには、–-project-arn、--name、--type パラメータを指定して create-upload を実行します。

この例では、Appium Java TestNG テストパッケージアップロードを作成します。

aws devicefarm create-upload –-project-arn arn:MyProjectARN -–name MyTests.zip –-type APPIUM_JAVA_TESTNG_TEST_PACKAGE

このレスポンスには、テストパッケージのアップロード ARN および署名付き URL が含まれます。

{ "upload": { "status": "INITIALIZED", "name": "MyTests.zip", "created": 1535738627.195, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "APPIUM_JAVA_TESTNG_TEST_PACKAGE", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE"

API バージョン 2015-06-2328

https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html


} }

2. テストパッケージのアップロード ARN と署名付き URL を書き留めます。3. Amazon S3 の署名付き URL を使用して、スクリプトパッケージファイルをアップロードします。こ

の例では、curl を使用して、解凍した TestNG スクリプトファイルをアップロードします。

curl -T MyTests.zip "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL"

4. テストスクリプトパッケージアップロードのステータスを確認するには、get-upload を実行し、ステップ 1 で書き留めたテストパッケージのアップロード ARN を指定します。

aws devicefarm get-upload –-arn arn:MyTestsUploadARN

レスポンスのステータスが SUCCEEDED まで待ってから、次のオプションのステップに進みます。

{ "upload": { "status": "SUCCEEDED", "name": "MyTests.zip", "created": 1535738627.195, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "APPIUM_JAVA_TESTNG_TEST_PACKAGE", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "metadata": "{"valid": true}" }}

ステップ 5: カスタムテストスペックをアップロードする (オプション)標準のテスト環境でテストを実行している場合、このステップはスキップします。

Device Farm では、サポートされているテストタイプごとに、デフォルトのテストスペックファイルを保持しています。次に、デフォルトのテストスペックをダウンロードし、カスタムのテスト環境でテストを実行するために必要なカスタムのテストスペックアップロードを作成します。詳細については、「テスト環境 (p. 14)」を参照してください。

1. デフォルトのテストスペックのアップロード ARN を検索するには、プロジェクト ARN を指定してlist-uploads を実行します。

aws devicefarm list-uploads --arn arn:MyProjectARN

このレスポンスには、デフォルトのテストスペックごとのエントリが含まれます。

{ "uploads": [ {

{ "status": "SUCCEEDED", "name": "Default TestSpec for Android Appium Java TestNG", "created": 1529498177.474, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL",

API バージョン 2015-06-2329


"type": "APPIUM_JAVA_TESTNG_TEST_SPEC", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE" } } ]}

2. リストからデフォルトのテストスペックを選択します。アップロード ARN を書き留めます。3. デフォルトのテストスペックをダウンロードするには、アップロード ARN を指定して get-upload を

実行します。

例:

aws devicefarm get-upload –-arn arn:MyDefaultTestSpecARN

このレスポンスには、デフォルトのテストスペックをダウンロードできる署名付き URL が含まれます。

4. この例では、curl を使用してデフォルトのテストスペックをダウンロードし、MyTestSpec.yml という名前で保存します。

curl "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL" > MyTestSpec.yml

5. デフォルトのテストスペックを編集して、テスト要件を満たします。以降のテストランでは変更後のテストスペックを使用します。このステップをスキップして、デフォルトのテストスペックをカスタムのテスト環境でそのまま使用します。

6. カスタムのテストスペックのアップロードを作成するには、テストスペック名、テストスペックタイプ、およびプロジェクト ARN を指定して、create-upload を実行します。

この例では、Appium Java TestNG のカスタムテストスペックのアップロードを作成します。

aws devicefarm create-upload --name MyTestSpec.yml --type APPIUM_JAVA_TESTNG_TEST_SPEC --project-arn arn:MyProjectARN

このレスポンスには、テストスペックのアップロード ARN および署名付き URL が含まれます。

{ "upload": { "status": "INITIALIZED", "category": "PRIVATE", "name": "MyTestSpec.yml", "created": 1535751101.221, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "APPIUM_JAVA_TESTNG_TEST_SPEC", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE" }}

7. テストスペックのアップロード ARN と署名付き URL を書き留めます。8. Amazon S3 の署名付き URL を使用してテストスペックをアップロードします。この例では、curl を

使用して、Appium JavaTestNG テストスペックをアップロードします。

curl -T MyTestSpec.yml "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL"

API バージョン 2015-06-2330


9. テストスペックアップロードのステータスを確認するには、get-upload を実行し、アップロードのARN を指定します。

aws devicefarm get-upload –-arn arn:MyTestSpecUploadARN

レスポンスのステータスが SUCCEEDED になるまで待ってから、テストランのスケジュール設定を行います。

{ "upload": { "status": "SUCCEEDED", "name": "MyTestSpec.yml", "created": 1535732625.964, "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "type": "APPIUM_JAVA_TESTNG_TEST_SPEC", "arn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "metadata": "{"valid": true}" }}

カスタムのテストスペックをアップデートするには、このテストスペックのアップロード ARN を指定して、update-upload を実行します。詳細については、「update-upload」を参照してください。

ステップ 6: テストランをスケジュール設定するAWS CLI を使用してテストランをスケジュール設定するには、schedule-run を実行します。その際、以下を指定します。

• ステップ 1 (p. 26) で書き留めたプロジェクト ARN。• ステップ 2 (p. 26) で書き留めたデバイスプールの ARN。• ステップ 3 (p. 27) で書き留めたアプリのアップロード ARN。• ステップ 4 (p. 28) で書き留めたテストパッケージのアップロード ARN。

カスタムのテスト環境でテストを実行している場合は、ステップ 5 (p. 29) で書き留めたテストスペックの ARN も必要です。

標準のテスト環境の実行をスケジュール設定するには

• プロジェクト ARN、デバイスプール ARN、アプリケーションアップロード ARN、テストパッケージ情報を指定して、schedule-run を実行します。

例:

aws devicefarm schedule-run --project-arn arn:MyProjectARN --app-arn arn:MyAppUploadARN --device-pool-arn arn:MyDevicePoolARN --name MyTestRun --test type=APPIUM_JAVA_TESTNG,testPackageArn=arn:MyTestPackageARN

このレスポンスには、テストランのステータスの確認に使用する実行の ARN が含まれます。

{ "run": { "status": "SCHEDULING", "appUpload": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345appEXAMPLE", "name": "MyTestRun",

API バージョン 2015-06-2331

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/update-upload.html


"radios": { "gps": true, "wifi": true, "nfc": true, "bluetooth": true }, "created": 1535756712.946, "totalJobs": 179, "completedJobs": 0, "platform": "ANDROID_APP", "result": "PENDING", "devicePoolArn": "arn:aws:devicefarm:us-west-2:123456789101:devicepool:5e01a8c7-c861-4c0a-b1d5-12345devicepoolEXAMPLE", "jobTimeoutMinutes": 150, "billingMethod": "METERED", "type": "APPIUM_JAVA_TESTNG", "testSpecArn": "arn:aws:devicefarm:us-west-2:123456789101:upload:5e01a8c7-c861-4c0a-b1d5-12345specEXAMPLE", "arn": "arn:aws:devicefarm:us-west-2:123456789101:run:5e01a8c7-c861-4c0a-b1d5-12345runEXAMPLE", "counters": { "skipped": 0, "warned": 0, "failed": 0, "stopped": 0, "passed": 0, "errored": 0, "total": 0 } }}

詳細については、「schedule-run」を参照してください。

カスタムのテスト環境の実行をスケジュール設定するには

• ステップは、標準テスト環境のステップとほとんど同じですが、--test パラメータのtestSpecArn 属性を追加で指定します。

例:

aws devicefarm schedule-run --project-arn arn:MyProjectARN --app-arn arn:MyAppUploadARN --device-pool-arn arn:MyDevicePoolARN --name MyTestRun --test testSpecArn=arn:MyTestSpecUploadARN,type=APPIUM_JAVA_TESTNG,testPackageArn=arn:MyTestPackageARN

テストランのステータスを確認するには

• 実行の ARN を指定して、get-run コマンドを実行します。

aws devicefarm get-run --arn arn:aws:devicefarm:us-west-2:111122223333:run:5e01a8c7-c861-4c0a-b1d5-12345runEXAMPLE

詳細については、「get-run」を参照してください。AWS CLI での Device Farm の詳細な使用方法については、「AWS CLIリファレンス (p. 172)」を参照してください。

API バージョン 2015-06-2332

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/schedule-run.html

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/get-run.html

AWS Device Farm 開発者ガイドテストランの作成 (API)

テストランの作成 (API)ステップは、AWS CLI セクションに記載されているステップと同じです。「テストランの作成 (AWSCLI) (p. 25)」を参照してください。

この情報は、ScheduleRun API を呼び出すために必要です。

• プロジェクト ARN。「プロジェクトの作成 (API) (p. 21)」および「CreateProject」を参照してください。

• アプリケーションのアップロード ARN。「CreateUpload」を参照してください。• テストパッケージのアップロードの ARN。「CreateUpload」を参照してください。• デバイスプールの ARN。「デバイスプールの作成 (p. 40)」および「CreateDevicePool」を参照し

てください。

Note

カスタムのテスト環境でテストを実行している場合は、テストスペックの ARN も必要です。詳細については、「ステップ 5: カスタムテストスペックをアップロードする (オプション) (p. 29)」および「CreateUpload」を参照してください。


次のステップ

Device Farm コンソールで、テストランが完了すると、進行状況アイコンが結果アイコン ( など) に変わります。テストが完了した時点で実行のレポートが表示されます。詳細については、「レポート (p. 17)」を参照してください。

レポートを使用するには、「テストレポートの実行 (p. 42)」の手順に従います。

AWS Device Farm でのテストランの実行タイムアウトの設定

各デバイスのテストの実行を停止するまでのテストランの実行時間の値を設定することができます。デフォルトの実行タイムアウトはデバイスあたり 150 分ですが、5 分などの低い値にも設定できます。実行アウトを設定するには、AWS Device Farm コンソール、AWS CLI、または AWS Device Farm API を使用できます。

Important

実行タイムアウトオプションは、一部のバッファと共に、テストランの最大所要時間に設定する必要があります。たとえば、テストにデバイスあたり 20 分かかる場合、デバイスあたり 30 分のタイムアウトを選択する必要があります。

実行がタイムアウトを超えた場合、そのデバイスでの実行は強制的に停止されます。可能であれば、部分的な結果を使用することができます。従量制課金オプションを使用している場合は、その時点までの実行に対して請求されます。料金の詳細については、「Device Farm 料金表」を参照してください。

各デバイスでテストランを実行するのにかかる時間を知っている場合は、この機能を使用できます。テストランの実行タイムアウトを指定すると、何らかの理由でテストランが滞り、実行されているテストがないデバイス分に対して課金されるという状況を回避できます。つまり、実行タイムアウト機能を使用すると、テストランに予想以上の時間がかかっている場合にそのランを停止できます。

実行タイムアウトは、プロジェクトレベルおよびテストランレベルの 2 つの場所で設定できます。

API バージョン 2015-06-2333

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRun.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateProject.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateUpload.html


https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateDevicePool.html




前提条件1. 「セットアップ (p. 3)」の各ステップを実行します。2. Device Farm でプロジェクトを作成します。「AWS Device Farm でプロジェクトを作成する (p. 20)」

の指示に従って、このページに戻ります。

プロジェクトの実行タイムアウトを設定する1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. 既にプロジェクトがある場合は、[Your projects (プロジェクト)] ページからそのプロジェクトを選択

します。それ以外の場合は、[Create a new project (新規プロジェクトの作成)] を選択し、プロジェクトの名前を入力します。

3. [Project settings (プロジェクト設定)] を選択します。4. [General] タブの [実行タイムアウト] に値を入力するか、スライダーバーを使用します。5. [Save changes (変更の保存)] を選択します。

プロジェクト内のテストランで、先ほど指定した実行タイムアウト値が使用されるようになりました。ただし、実行をスケジュール設定する際にタイムアウト値を上書きした場合は除きます。

テストランの実行タイムアウトを設定する1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. 既にプロジェクトがある場合は、[Your projects (プロジェクト)] ページからそのプロジェクトを選択

します。それ以外の場合は、[Create a new project (新規プロジェクトの作成)] を選択し、プロジェクトの名前を入力します。

3. [Create a new run (新しい実行の作成)] を選択します。4. ステップに従って、アプリケーションを選択し、テストを設定し、デバイスを選択し、デバイスの状

態を指定します。5. [Review and start run] タブの [実行タイムアウト] に値を入力するか、スライダーバーを使用します。6. [Confirm and start run] を選択します。

AWS Device Farm 実行用のネットワーク接続と条件をシミュレートする

Device Farm で Android、iOS、FireOS、およびウェブアプリのテストをしながら、ネットワークシェーピングを使用して、ネットワーク接続と条件をシミュレートできます。たとえば、ネットワーク条件が完全でなくてもアプリをテストすることができます。

デフォルトのネットワーク設定を使用して実行を作成した場合は、各デバイスを使用して、完全で制限のない WiFi 接続でインターネット接続できます。ネットワークシェーピングを使用すると、Wi-Fi 接続を変更して、インバウンドトラフィックとアウトバウンドトラフィックの両方のスループット、遅延、ジッター、損失を制御する 3G または Lossy WiFi などのネットワークプロファイルを指定できます。

トピック• テストランをスケジュールする場合のネットワークシェーピングの設定 (p. 35)• ネットワークプロファイルの作成 (p. 35)• テスト中にネットワーク条件を変更する (p. 36)

API バージョン 2015-06-2334



AWS Device Farm 開発者ガイドテストランをスケジュールする場合のネットワークシェーピングの設定

テストランをスケジュールする場合のネットワークシェーピングの設定実行をスケジュールする場合、任意の Device Farm-curated プロファイルから選択するか、独自のプロファイルを作成および管理できます。

1. 任意の Device Farm プロジェクトから、[Create a new run (新しいランの作成)] を選択します。

まだプロジェクトがない場合は、「AWS Device Farm でプロジェクトを作成する (p. 20)」を参照してください。

2. アプリケーションを選択後、[Next step (次のステップ)] を選択します。3. テストを設定し、[Next step (次のステップ)] を選択します。4. デバイスを選択し、[Next step (次のステップ)] を選択します。5. ネットワークプロファイルを選択するか、[Create a new network profile (新しいネットワークプロファ

イル)] を選択して独自に作成します。

6. [Next step] を選択します。7. テストランを確認して開始します。

ネットワークプロファイルの作成テストランの作成時に、ネットワークプロファイルを作成できます。

1. [Create a new network profile (新しいネットワークプロファイルの作成)] を選択します。

API バージョン 2015-06-2335

AWS Device Farm 開発者ガイドテスト中にネットワーク条件を変更する

2. ネットワークプロファイルの名前と設定を入力します。3. [Save network profile (ネットワークプロファイルの保存)] を選択します。4. テストランの作成を完了し、実行を開始します。

ネットワークプロファイルを作成したら、[Project settings (プロジェクト設定)] ページで確認および管理できるようになります。

テスト中にネットワーク条件を変更するテスト実行中の帯域幅の減少などの動的ネットワーク条件をシミュレートするには、Appium やCalabash などのフレームワークを使用してデバイスホストから API を呼び出します。詳細については、「CreateNetworkProfile」を参照してください。

API バージョン 2015-06-2336

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateNetworkProfile.html

AWS Device Farm 開発者ガイド実行の停止

AWS Device Farm の実行の停止実行の開始後に、停止することがあります。たとえば、テストの実行中に問題が発生し、更新されたテストスクリプトを使用して再起動する場合です。

実行を停止するには、Device Farm コンソール、AWS CLI、または API を使用します。

トピック• 実行の停止 (コンソール) (p. 37)• 実行の停止 (AWS CLI) (p. 38)• 実行の停止 (API) (p. 39)

実行の停止 (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. Device Farm コンソールのホームページから、アクティブなテストランを持つプロジェクトを選択し

ます。3. [Run results (実行の結果)] ページで、テストランを選択します。

デバイス名の左に、保留中または進行中のアイコンが表示されます。

4. [Stop run (実行の停止)] を選択します。

しばらくすると、振動するオレンジの円が四角を囲んでいるアイコンがデバイス名の横に表示されます。実行が停止している場合、アイコンはオレンジ色の四角に変わります。

Important

既に実行されている場合、Device Farm はテストを停止できません。進行中の場合、DeviceFarm はテストを停止します。請求対象の合計時間が [デバイス] セクションに表示されます。さらに、Device Farm が setup suite および teardown suite の実行にかかる合計時間に対しても請求されます。詳細については、「Device Farm 料金表」を参照してください。

次の図は、テストが正常に停止した後に表示される [Devices (デバイス)] セクションの例です。

API バージョン 2015-06-2337


http://aws.amazon.com/device-farm/faq/#pricing

AWS Device Farm 開発者ガイド実行の停止 (AWS CLI)

実行の停止 (AWS CLI)指定されたテストランを停止するには、次のコマンドを実行することもできます。myARN はテストランのAmazon リソースネーム (ARN) です。

$ aws devicefarm stop-run --arn myARN


{ "run": { "status": "STOPPING", "name": "Name of your run", "created": 1458329687.951, "totalJobs": 7, "completedJobs": 5, "deviceMinutes": { "unmetered": 0.0, "total": 0.0, "metered": 0.0 }, "platform": "ANDROID_APP", "result": "PENDING", "billingMethod": "METERED", "type": "BUILTIN_EXPLORER", "arn": "myARN", "counters": { "skipped": 0, "warned": 0, "failed": 0, "stopped": 0, "passed": 0, "errored": 0, "total": 0 } }}

実行の ARN を取得するには、list-runs コマンドを使用します。出力は次の例のようになります:

{ "runs": [ { "status": "RUNNING", "name": "Name of your run", "created": 1458329687.951,

API バージョン 2015-06-2338

AWS Device Farm 開発者ガイド実行の停止 (API)

"totalJobs": 7, "completedJobs": 5, "deviceMinutes": { "unmetered": 0.0, "total": 0.0, "metered": 0.0 }, "platform": "ANDROID_APP", "result": "PENDING", "billingMethod": "METERED", "type": "BUILTIN_EXPLORER", "arn": "Your ARN will be here", "counters": { "skipped": 0, "warned": 0, "failed": 0, "stopped": 0, "passed": 0, "errored": 0, "total": 0 } } ]}


実行の停止 (API)• テストランに対して、StopRun オペレーションを呼び出します。


AWS Device Farm で実行のリストを表示するプロジェクトの実行のリストを表示するには、Device Farm コンソール、AWS CLI、または API を使用します。

トピック• 実行のリストを表示する (コンソール) (p. 39)• 実行のリストを表示する (AWS CLI) (p. 40)• 実行のリストを表示する (API) (p. 40)

実行のリストを表示する (コンソール)1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトのリストで、表示するリストに対応するプロジェクトを選択します。

使用可能なプロジェクトのリストが表示されていない場合は、セカンダリナビゲーションバーで、次のいずれかを実行します。

• Device Farm コンソールのホームボタンを選択してから、プロジェクトを選択します。• [Projects (プロジェクト)] で [View all projects (すべてのプロジェクトを表示)] を選択してから、プ

ロジェクトを選択します。

API バージョン 2015-06-2339

../../latest/APIReference/API_StopRun.html


AWS Device Farm 開発者ガイド実行のリストを表示する (AWS CLI)

実行のリストを表示する (AWS CLI)• list-runs コマンドを実行します。

1 つの実行についての情報を表示するには、get-run コマンドを実行します。


実行のリストを表示する (API)• ListRuns API を呼び出します。

1 つの実行についての情報を表示するには、GetRun API を呼び出します。

Device Farm API の詳細については、「Device Farm の自動化 (p. 174)」を参照してください。

AWS Device Farm でデバイスプールを作成するデバイスプールを作成するには、Device Farm コンソール、AWS CLI、または API を使用します。

トピック• 前提条件 (p. 40)• デバイスプールの作成 (コンソール) (p. 40)• デバイスプールの作成 (AWS CLI) (p. 41)• デバイスプールの作成 (API) (p. 41)

前提条件• Device Farm コンソールで、ランを作成します。「AWS Device Farm でテストランを作成す

る (p. 23)」の手順に従います。[Select devices (デバイスの選択)] ページが表示されたら、このセクションの手順に進みます。

デバイスプールの作成 (コンソール)1. [Select devices (デバイスの選択)] ページで、[Create new device pool (新しいデバイスプールの作成)]

を選択します。2. [名前] に、このデバイスプールの分かりやすい名前を入力します。3. [説明] に、このデバイスプールの分かりやすい説明を入力します。4. このデバイスプール内のデバイスに対して 1 つ以上の選択条件を使用する場合は、次の手順を実行し

ます。

a. [Add rule] を選択します。b. [Field (フィールド)] で、次のいずれかを選択します。

• デバイスをメーカーごとに含めるには、[Manufacturer] を選択します。• デバイスをタイプの値ごとに含めるには、[Type] を選択します。

API バージョン 2015-06-2340

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/list-runs.html

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/get-run.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ListRuns.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_GetRun.html

AWS Device Farm 開発者ガイドデバイスプールの作成 (AWS CLI)

c. [Operator] で [EQUALS] を選択して、[フィールド] 値と [オペランド] 値が等しいデバイスを含めます。

d. [Operand] の場合、[Field] 値および [Operator] 値を指定する値を入力または選択します。[Field]に [Platform] を選択した場合は、[ANDROID] セクションと [IOS] セクションのみ選択できます。同様に、[Field] に [Type] を選択した場合は、[PHONE] と [TABLET] のみ選択できます。

e. 別のルールを追加するには、[Add rule (ルールの追加)] を選択します。f. ルールを削除するには、削除するルールの横にある [X] アイコンを選択します。

最初のルールを作成すると、デバイスのリストで、ルールに一致する各デバイスの横にあるボックスが選択されます。ルールを作成または変更すると、デバイスのリストで、それらの結合されたルールに一致する各デバイスの横にあるボックスが選択されます。ボックスが選択されているデバイスはデバイスプールに含まれます。ボックスが選択解除されたデバイスは除外されます。

5. 個々のデバイスを手動で追加または除外する場合は、各デバイスの横にあるボックスをオンまたはオフにします。ルールを指定していない場合にのみ、ボックスをオンまたはオフにできます。

6. 表示されているすべてのデバイスを含めたり除外したりする場合は、リストの列ヘッダー行のボックスをオンまたはオフにします。

Important

列ヘッダー行のボックスを使用して表示されたデバイスのリストを変更することはできますが、残りの表示されたデバイスのみが含まれるか除外されるわけではありません。含まれる、または除外されるデバイスを確認するには、列ヘッダー行のすべてのボックスのコンテンツの選択を解除してから、ボックスを参照します。

7. [Save device pool (デバイスプールの保存)] を選択します。

デバイスプールの作成 (AWS CLI)• create-device-pool コマンドを実行します。

Note

Appium のテストでは、APPIUM_VERSION を rules フィールドで使用できます。


デバイスプールの作成 (API)• CreateDevicePool API を呼び出します。

Note

Appium のテストでは、APPIUM_VERSION を rules フィールドで使用できます。


AWS Device Farm での結果の分析標準テスト環境では、Device Farm コンソールを使用して、テストランの各テストのレポートを表示することができます。 API バージョン 2015-06-23

41

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/create-device-pool.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateDevicePool.html

AWS Device Farm 開発者ガイドテストレポートの実行

また、Device Farm では、テストラン完了時にダウンロードできるファイルやログ、イメージなどの他のアーティファクトを収集します。

トピック• AWS Device Farm でのテストレポートの実行 (p. 42)• Device Farm でアーティファクトを使用する (p. 48)

AWS Device Farm でのテストレポートの実行テストレポートを表示するには、Device Farm コンソールを使用します。詳細については、「レポート (p. 17)」を参照してください。

トピック• 前提条件 (p. 42)• テスト結果を理解する (p. 42)• レポートの表示 (p. 43)

前提条件テストランを設定し、完了したことを確認します。

1. 実行を作成するには「AWS Device Farm でテストランを作成する (p. 23)」の手順に従い、その後、このページに戻ります。

2.テストランが完了したことを確認します。テストラン中、Device Farm には進行状況アイコン ( )がコンソールに表示されます。テストランが完了すると、進行状況アイコンはテスト結果アイコンに変わります。詳細については、「テスト結果を理解する (p. 42)」を参照してください。

テスト結果を理解するDevice Farm コンソールに、アイコンとグラフィックスが表示されます。これらを使用して、完了したテストランのステータスをすばやく評価することができます。

トピック• 個別のテストの結果をレポートする (p. 42)• 複数のテストの結果をレポートする (p. 43)

個別のテストの結果をレポートする

個々のテストを示すレポートの場合は、Device Farm にアイコンとテスト結果バーが表示されます。

説明アイコン

テスト結果

テストは成功しました。

テストは失敗しました。

API バージョン 2015-06-2342


説明アイコン

テスト結果

テストをスキップしました。

テストは停止しました。

Device Farm によって警告が返されました。

Device Farm によってエラーが返されました。

複数のテストの結果をレポートする

複数のテストをまとめたレポートの場合は、Device Farm によってテスト結果の概要バーが表示されます。

たとえば、このテストランの結果バーは、停止したテストが 1、失敗したテストが 12、スキップされたテストが 4、成功したテストが 93 あることを表します。

複数のテストの結果に表示されるアイコン (例: テストスイートによるレポート) は、この順序で表示されます。

アイコン説明

停止したテストが 1 つ以上あります。

エラーになったテストが 1 つ以上あります。

失敗したテストが 1 つ以上あります。

警告が表示されたテストが 1 つ以上あります。

すべてのテストは成功しました。

レポートの表示テストの結果は、Device Farm コンソールで表示できます。

トピック• テストランの概要ページの表示 (p. 44)• 一意の問題のレポートを表示する (p. 44)• デバイスのレポートを表示する (p. 45)• テストスイートレポートを表示する (p. 45)• テストレポートを表示する (p. 46)

API バージョン 2015-06-2343


• レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する (p. 46)• レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する (p. 47)

テストランの概要ページの表示

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトのリストで、テストランのプロジェクトを選択します。

Tip

プロジェクトのリストが表示されていない場合は、セカンダリナビゲーションバーの DeviceFarm コンソールホームボタンを選択し、プロジェクトを選択します。

3. 概要レポートページを表示するには、完了したテストランを選択します。4. テストランの概要ページに、テスト結果の概要が表示されます。

• [固有の問題] セクションには、固有の警告と障害がリストされています。固有の問題を表示するには、「一意の問題のレポートを表示する (p. 44)」の手順に従います。

• [デバイス] セクションには、各デバイスの結果の合計テスト数が表示されます。

この例では、Android バージョン 7.1.2 を実行中の Google Pixel デバイスで、実行に 15 分 25 秒かかり、成功したテストが 11 あることがレポートされています。

デバイスごとに結果を表示するには、「デバイスのレポートを表示する (p. 45)」の手順に従います。

• [スクリーンショット] セクションには、実行中に Device Farm がキャプチャしたデバイスごとにグループ化したスクリーンショットのリストが表示されます。

一意の問題のレポートを表示する

1. [固有の問題] で、表示する問題を選択します。2. デバイスを選択します。レポートには、問題に関する情報が表示されます。

[動画] セクションには、ダウンロード可能な動画が表示されます。

[ログ] セクションには、テスト中に Device Farm が記録した情報が表示されます。この情報を表示するには、「レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する (p. 47)」の手順に従います。

[パフォーマンス] セクションには、テスト中に Device Farm が生成したパフォーマンスデータに関する情報が表示されます。このパフォーマンスデータを表示するには、「レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する (p. 46)」の手順に従います。

[ファイル] セクションには、スイートのテストのリストとダウンロード可能な関連ファイル (ログファイルなど) が表示されます。ファイルをダウンロードするには、リスト内のファイルのリンクを選択します。

[スクリーンショット] セクションには、Device Farm がキャプチャしたテスト中のスクリーンショットのリストが表示されます。

API バージョン 2015-06-2344



デバイスのレポートを表示する

• [Devices] セクションで、デバイスを選択します。

[動画] セクションには、ダウンロード可能なテストの動画が表示されます。

[スイート] には、デバイスのスイートに関する情報が表示されます。

[テスト結果] には、テスト数が、デバイス上で実行される各テストスイートの結果ごとにまとめられています。詳細については、「複数のテストの結果をレポートする (p. 43)」を参照してください。

スイートごとに結果を表示するには、「テストスイートレポートを表示する (p. 45)」の手順に従います。

[ログ] セクションには、実行中に Device Farm がデバイス用に記録した情報が表示されます。この情報を表示するには、「レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する (p. 47)」の手順に従います。

[パフォーマンス] セクションには、実行中に Device Farm がデバイス用に生成したパフォーマンスデータに関する情報が表示されます。このパフォーマンスデータを表示するには、「レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する (p. 46)」の手順に従います。

[ファイル] デバイスのスイートのリストと、ダウンロード可能な関連ファイル (ログファイルなど) が表示されます。ファイルをダウンロードするには、リスト内のファイルのリンクを選択します。

[スクリーンショット] セクションには、実行中に Device Farm がデバイス用にキャプチャしたスイートごとにグループ化したスクリーンショットのリストが表示されます。

テストスイートレポートを表示する

1. [Devices] セクションで、デバイスを選択します。2. [スイート] セクションで、スイートを選択します。

スイートの結果ページには、スイートのテストに関する情報が表示されます。詳細については、「複数のテストの結果をレポートする (p. 43)」を参照してください。

テストごとに結果を表示するには、「テストレポートを表示する (p. 46)」の手順に従います。

[ログ] セクションには、スイートの実行中に Device Farm によって記録された情報がすべて表示されます。この情報を表示するには、「レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する (p. 47)」の手順に従います。

[パフォーマンス] セクションには、スイートの実行中に Device Farm が生成したパフォーマンスデータに関する情報が表示されます。このパフォーマンスデータを表示するには、「レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する (p. 46)」の手順に従います。

[ファイル] セクションには、スイートのテストのリストとダウンロード可能な関連ファイル (ログファイルなど) が表示されます。ファイルをダウンロードするには、リスト内のファイルのリンクを選択します。

[スクリーンショット] セクションには、実行中に Device Farm がスイート用にキャプチャしたテストごとにグループ化したスクリーンショットのリストが表示されます。

API バージョン 2015-06-2345


テストレポートを表示する

1. [Devices] セクションで、デバイスを選択します。2. [スイート] セクションで、スイートを選択します。

[テスト] タブには、テストに関する情報 (例: 結果アイコン) が表示されます。詳細については、「個別のテストの結果をレポートする (p. 42)」を参照してください。

[ログ] セクションには、テスト中に Device Farm が記録した情報が表示されます。この情報を表示するには、「レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する (p. 47)」の手順に従います。

[パフォーマンス] タブには、テスト中に Device Farm が生成したパフォーマンスデータに関する情報が表示されます。このパフォーマンスデータを表示するには、「レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する (p. 46)」の手順に従います。

[ファイル] タブには、ダウンロード可能なテスト関連ファイル (ログファイルなど) の一覧が表示されます。ファイルをダウンロードするには、リスト内のファイルのリンクを選択します。

[スクリーンショット] タブには、Device Farm がキャプチャしたテスト中のスクリーンショットのリストが表示されます。

レポート内の問題、デバイス、スイート、またはテストのパフォーマンスデータを表示する

• 以下の情報が [パフォーマンス] タブに表示されます。

• [CPU] グラフは、(縦軸に沿って) 選択した問題、デバイス、スイート、またはテスト、(横軸に沿って) 時間軸上にアプリの 1 つのコアで使用された CPU の割合を表示します。

縦軸は、0% から最大値までを割合 (%) で表します。

アプリが複数のコアを使用している場合、この割合は 100% を超えることがあります。たとえば、3 つのコアが 60% 使用されている場合、この割合 (%) は 180% として表示されます。

• [FPS] グラフは、(縦軸に沿って) 選択した問題、デバイス、スイート、またはテスト、(横軸に沿って) 時間軸上に 1 秒あたりのフレームレート (FPS) を表示します。

縦軸は、0 FPS から記録された FPS の最大数までの FPS で表されます。• [メモリ] グラフは、(縦軸に沿って) 選択した問題、デバイス、スイート、またはテスト、(横軸に

沿って) 時間軸上にアプリで使用された MB 数を表示します。

縦軸は、0 MB から記録された MB の最大値までを MB で表します。• [スレッド] グラフは、(縦軸に沿って) 選択した問題、デバイス、スイート、またはテスト、(横軸に

沿って) 時間軸上に使用されたスレッド数を表示します。

縦軸は、0 スレッドから記録されたスレッドの最大値までをスレッド数で表します。

いずれの場合も横軸には、選択した問題、デバイス、スイート、またはテストの実行の開始から終了までが秒単位で表されます。

特定のデータポイントの情報を表示するには、目的のグラフを横軸に沿って希望の秒で一時停止します。

API バージョン 2015-06-2346


レポート内の問題、デバイス、スイート、またはテストのログ情報を表示する

以下の情報は、[ログ] セクションに表示されます。

• [ソース] はログエントリのソースを表します。以下に示しているのは、可能な値です。• [ハーネス] は Device Farm が作成したログエントリを表します。これらのログエントリは、通常、イ

ベントの開始および停止中に作成されます。• [デバイス] は、デバイスが作成したログエントリを表します。Android の場合、これらのログエントリ

は logcat と互換性があります。iOS の場合、これらのログエントリは syslog と互換性があります。• [Test] は、テストまたはテストフレームワークのいずれかが作成したログエントリを表します。

• [時間] は、最初のログエントリと、このログエントリの間の経過時間を表します。時間は MM:SS.SSS形式で表されます。M は分を表し、S は秒を表します。

• [PID] は、ログエントリを作成したプロセス識別子 (PID) を表します。デバイス上のアプリによって作成されるログエントリの PID はすべて同一になります。

• [レベル] はログエントリのログレベルを表します。たとえば、Logger.debug("This is amessage!") ログは Debug [レベル] を記録します。使用できる値は次のとおりです。• アラート• 非常事態• デバッグ• 緊急• エラー• エラー• 失敗• 情報• 社内• Notice• [成功]• Skipped• 停止• 詳細• 警告• 警告

• [タグ] は、ログエントリの任意のメタデータを表します。たとえば、Android logcat は、システムのどの部分がログエントリを作成したかを記述するためにこれを使用できます (例: ActivityManager)。

• [メッセージ] は、ログエントリのメッセージまたはデータを表します。たとえば、Logger.debug("Hello, World!") ログは "Hello, World!" [メッセージ] を記録します。

情報の一部のみを表示するには:

• 特定の列の値と一致するすべてのログエントリを表示するには、対応する列のヘッダーボックスに値を入力します。たとえば、[ソース] 値が「Harness」であるすべてのログエントリを表示するには、[ソース] 列のヘッダーボックスに「Harness」と入力します。

• 特定の列に対してゼロまたはそれ以上の未知の文字を含むすべてのログエントリを表示するには、ワイルドカード文字 (*) を使用して未知の文字を表します。たとえば、「es」 (Harness および Test など)を含む [ソース] 値を持つすべてのログエントリを表示するには、[ソース] カラムのヘッダーボックスに「*es*」と入力します。

• 特定の列の 1 つ以上の既知の文字の間の選択肢を含むログ項目を表示するには、選択肢のセットを括弧 (( )) で囲み、パイプ文字 (|) を使用して各選択肢を区切ります。たとえば、started 値またはstarting 値のいずれかを含む [メッセージ] 値を持つログエントリを表示するには [メッセージ] 列のヘッダーボックスに「*start(ed|ing)*」と入力します。

API バージョン 2015-06-2347

AWS Device Farm 開発者ガイドアーティファクトを使用する

• 列ヘッダーボックスからすべての文字を削除するには、その列ヘッダーボックスの [X] を選択します。列ヘッダーボックスからすべての文字を削除することは、その列のヘッダーボックスに「*」を入力するのと同じです。

実行されたすべてのスイートとテストを含む、デバイスのすべてのログ情報をダウンロードするには、[ログのダウンロード] を選択します。

Device Farm でアーティファクトを使用する

Device Farm では、レポートやログファイル、イメージなどのアーティファクトをテストランのテストごとに収集します。

テストラン中に作成されたアーティファクトはダウンロードすることができます。

ファイル

テストラン中に生成されたファイル (例: Device Farm レポート)。詳細については、「テストレポートの実行 (p. 42)」を参照してください。

ログ

テストランの各テストの出力。スクリーンショット

テストランのテストごとに記録されるスクリーン画像。

アーティファクトを使用する (コンソール)1. テストランのレポートページで、[デバイス] からモバイルデバイスを選択します。2. ファイルをダウンロードするには、[ファイル] からいずれかを選択します。3. テストランからログをダウンロードするには、[ログ] から [ログのダウンロード] を選択します。4. スクリーンショットをダウンロードするには、[スクリーンショット] からスクリーンショットを選択

します。

カスタムのテスト環境におけるアーティファクトのダウンロードの詳細については、「カスタムのテスト環境でアーティファクトを使用する (p. 51)」を参照してください。

アーティファクトを使用する (AWS CLI)テストランを一覧表示するには、AWS CLI を使用します。

API バージョン 2015-06-2348


トピック• ステップ 1: Amazon リソースネーム (ARN) を取得する (p. 49)• ステップ 2: アーティファクトを一覧表示する (p. 50)• ステップ 3: アーティファクトをダウンロードする (p. 50)

ステップ 1: Amazon リソースネーム (ARN) を取得する

アーティファクトは、ラン、ジョブ、テストスイート、またはテストごとに一覧表示することができます。対応する ARN を指定する必要があります。この表は、各 AWS CLI リストコマンドの入力 ARN を示します。

AWS CLI リストコマンド必須 ARN

list-projects このコマンドでは、ARN を必要としないプロジェクトがすべて返ります。

list-runs project

list-jobs run

list-suites job

list-tests suite

たとえば、テスト ARN を見つけるには、テストスイート ARN を入力パラメータとして使用して list-testsを実行します。

例:

aws devicefarm list-tests –-arn arn:MyTestSuiteARN

この応答には、テストスイートのテスト ARN がテストごとに含まれます。

{ "tests": [ { "status": "COMPLETED", "name": "Tests.FixturesTest.testExample", "created": 1537563725.116, "deviceMinutes": { "unmetered": 0.0, "total": 1.89, "metered": 1.89 }, "result": "PASSED", "message": "testExample passed", "arn": "arn:aws:devicefarm:us-west-2:123456789101:test:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", "counters": { "skipped": 0, "warned": 0, "failed": 0, "stopped": 0, "passed": 1, "errored": 0, "total": 1

API バージョン 2015-06-2349


} } ]}

ステップ 2: アーティファクトを一覧表示する

AWS CLI list-artifacts コマンドでは、ファイル、スクリーンショット、ログなどのアーティファクトのリストが返ります。各アーティファクトには URL が含まれているため、ファイルをダウンロードすることができます。

• ラン、ジョブ、テストスイート、またはテスト ARN を指定して、list-artifacts を呼び出します。タイプ (FILE、LOG、または SCREENSHOT) を指定します。

この例では、各テストで使用できるアーティファクトごとのダウンロード用 URL が返ります。

aws devicefarm list-artifacts --arn arn:MyTestARN --type "FILE"

この応答には、各アーティファクトのダウンロード用 URL が含まれます。

{ "artifacts": [ { "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL", "extension": "txt", "type": "APPIUM_JAVA_OUTPUT", "name": "Appium Java Output", "arn": "arn:aws:devicefarm:us-west-2:123456789101:artifact:5e01a8c7-c861-4c0a-b1d5-12345EXAMPLE", } ]}

ステップ 3: アーティファクトをダウンロードする

• 前のステップの URL を使用して、アーティファクトをダウンロードします。この例では、curl を使用して、Android Appium Java 出力ファイルをダウンロードします。

curl "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/ExampleURL" > MyArtifactName.txt

アーティファクトを使用する (API)Device Farm API の ListArtifacts メソッドでは、ファイル、スクリーンショット、ログなどのアーティファクトのリストが返ります。各アーティファクトには URL が含まれているため、ファイルをダウンロードすることができます。

API バージョン 2015-06-2350

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/list-artifacts.html

https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ListArtifacts.html


カスタムのテスト環境でアーティファクトを使用する

カスタムのテスト環境で、Device Farm は、カスタムレポートやログファイル、イメージなどのアーティファクトを収集します。これらのアーティファクトは、テストランでデバイスごとに表示されます。

テストラン中に作成されるこれらのアーティファクトはダウンロードすることができます。

テストスペック出力

テストスペックの YAML ファイル内のコマンドの実行による出力。お客様のアーティファクト

テストランのアーティファクトを含む ZIP ファイル。テスト仕様の YAML ファイルの [artifacts:] セクションで設定されています。

テストスペックのシェルスクリプト

YAML ファイルから作成される中間シェルスクリプト。このシェルスクリプトファイルはテストランで使用されるため、YAML ファイルのデバッグに使用することができます。

テストスペックファイル

テストランで使用される YAML ファイル。

詳細については、「Device Farm でアーティファクトを使用する (p. 48)」を参照してください。

API バージョン 2015-06-2351

AWS Device Farm 開発者ガイドリソースのタグ付け

AWS Device Farm リソースのタグ付け

AWS Device Farm は AWS Resource Group Tagging API と連携します。この API を使用すると、タグにより AWS アカウントのリソースを管理できます。プロジェクトやテスト実行などのリソースにタグを付けることができます。

タグを使用して以下のことができます。

• 独自のコスト構造を反映するように AWS 請求情報を整理します。そのためには、AWS アカウントにサインアップして、タグキー値が含まれた AWS アカウントの請求書を取得する必要があります。次に、結合したリソースのコストを見るには、同じタグキー値のリソースに従って請求書情報を整理します。たとえば、複数のリソースにアプリケーション名のタグを付け、請求情報を整理することで、複数のサービスを利用しているアプリケーションの合計コストを確認できます。詳細については、「AWS 請求情報とコスト管理について」の「コスト配分とタグ付け」を参照してください。

• IAM ポリシーを通じてアクセスをコントロールします。そのためには、タグ値条件を使用してリソースまたはリソースのセットへのアクセスを許可するポリシーを作成します。

• タグとして特定のプロパティ (テストに使用されたブランチなど) が設定された実行を識別および管理します。

リソースのタグ付けの詳細については、「タグ付けのベストプラクティス」ホワイトペーパーを参照してください。

トピック• リソースのタグ付け (p. 52)• タグに基づくリソースの検索 (p. 53)• リソースのタグの削除 (p. 53)

リソースのタグ付けAWS Resource Group Tagging API を使用すると、リソースのタグを追加、削除、または変更できます。詳細については、「AWS Resource Group Tagging API リファレンス」を参照してください。

リソースにタグを付けるには、resourcegroupstaggingapi エンドポイントから TagResources オペレーションを使用します。このオペレーションでは、サポートされているサービスから ARN のリストとキーと値のペアのリストを取得します。値はオプションです。空の文字列は、そのタグに値がないことを示します。たとえば、以下の Python のタグの例では、一連のプロジェクト ARN にタグ build-configを付けて、値 release を指定しています。

import boto3

client = boto3.client('resourcegroupstaggingapi')

client.tag_resources(ResourceARNList=["arn:aws:devicefarm:us-west-2:111122223333:project:123e4567-e89b-12d3-a456-426655440000", "arn:aws:devicefarm:us-west-2:111122223333:project:123e4567-e89b-12d3-a456-426655441111", "arn:aws:devicefarm:us-west-2:111122223333:project:123e4567-e89b-12d3-a456-426655442222"]

API バージョン 2015-06-2352

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html

https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_TagResources.html

AWS Device Farm 開発者ガイドタグに基づくリソースの検索

Tags={"build-config":"release", "git-commit":"8fe28cb"})

タグの値は必須ではありません。値のないタグを設定するには、値を指定するときに空の文字列 ("") を使用します。タグでは 1 つの値のみ指定できます。タグでリソースに対して指定された以前の値は、新しい値で上書きされます。

タグに基づくリソースの検索タグに基づいてリソースを検索するには、resourcegrouptaggingapi エンドポイントからGetResources オペレーションを使用します。このオペレーションは一連のフィルタを受け取りますが、いずれも必須ではなく、指定された条件に一致するリソースを返します。フィルタを使用しない場合、すべてのタグ付きリソースが返されます。GetResources オペレーションでは、以下の条件に基づいてリソースをフィルタ処理できます。

• タグ値• リソースタイプ (devicefarm:run など)

詳細については、「AWS Resource Group Tagging API リファレンス」を参照してください。

以下の例では、タグ stack の値が production である Device Farm desktop browser testing セッション(devicefarm:testgrid-session リソース) を検索します。

import boto3client = boto3.client('resourcegroupstaggingapi')sessions = client.get_resources(ResourceTypeFilters=['devicefarm:testgrid-session'], TagFilters=[ {"Key":"stack","Values":["production"]} ])

リソースのタグの削除タグを削除するには、UntagResources オペレーションを使用して、削除するリソースとタグのリストを指定します。

import boto3client = boto3.client('resourcegroupstaggingapi')client.UntagResources(ResourceARNList=["arn:aws:devicefarm:us-west-2:111122223333:project:123e4567-e89b-12d3-a456-426655440000"], TagKeys=["RunCI"])

API バージョン 2015-06-2353

https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html

AWS Device Farm 開発者ガイドテストフレームワーク

AWS Device Farm でのテストタイプの実行

このセクションでは、2 つの組み込みのテストタイプと、テストフレームワークの Device Farm のサポートについて説明します。

テストフレームワークDevice Farm では、以下の自動化テストフレームワークをサポートしています。

Android アプリケーションテストフレームワーク• Appium Java TestNG (p. 56)• Appium Java JUnit (p. 61)• Appium Node.js (p. 66)• Appium Python (p. 69)• Appium Ruby (p. 73)• Calabash (p. 77)• Android および AWS Device Farm の計器の操作 (p. 79)• UI Automator (p. 80)

iOS アプリケーションのテストフレームワーク• Appium Java TestNG (p. 82)• Appium Java JUnit (p. 88)• Appium Node.js (p. 93)• Appium Python (p. 96)• Appium Ruby (p. 100)• Calabash (p. 104)• UI Automation (p. 106)• XCTest for iOS と AWS Device Farm の使用 (p. 107)• XCTest UI (p. 109)

ウェブアプリケーションのテストフレームワーク• Appium Java TestNG (p. 111)• Appium Java JUnit (p. 116)• Appium Node.js (p. 121)• Appium Python (p. 124)

API バージョン 2015-06-2354

AWS Device Farm 開発者ガイド組み込みのテストタイプ

• Appium Ruby (p. 129)

カスタムテスト環境のフレームワークDevice Farm では、Calabash、XCTests、および UI Automator のテストフレームワークのテスト環境のカスタマイズをサポートしています。詳細については、「カスタムテスト環境での作業 (p. 135)」を参照してください。

Appium バージョンのサポートDevice Farm では、カスタム環境で実行されているテスト向けに Appium v1.8.1 をサポートしています。Device Farm は標準環境で実行されているテスト向けに v1.7.2 をサポートしています。詳細については、「テスト環境 (p. 14)」を参照してください。

組み込みのテストタイプ組み込みテストでは、テスト自動化スクリプトを記述、管理することなく、複数のデバイスでアプリケーションをテストすることができます。Device Farm では 2 種類の組み込みテストを使用できます。

• 組み込み: エクスプローラ (Android) (p. 132)• 組み込み: ファズ (Android および iOS) (p. 133)

AWS Device Farm での Android テストの実行Device Farm では、Android デバイスの複数の自動化テストタイプ、および 2 種類の組み込みテストがサポートされています。

Android アプリケーションテストフレームワークAndroid デバイスでは、次のテストを使用できます。

• Appium Java TestNG (p. 56)• Appium Java JUnit (p. 61)• Appium Node.js (p. 66)• Appium Python (p. 69)• Appium Ruby (p. 73)• Calabash (p. 77)• Android および AWS Device Farm の計器の操作 (p. 79)• UI Automator (p. 80)

Android 用の組み込みのテストタイプ2 つの組み込みのテストタイプが Android デバイスで利用できます。


API バージョン 2015-06-2355

AWS Device Farm 開発者ガイドAppium Java TestNG

Android および AWS Device Farm の Appium JavaTestNG の使用このセクションでは、Android Appium Java TestNG テストを設定して、パッケージ化し、Device Farmにアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction to Appium」を参照してください。

サンプルアプリおよび動作テストへのリンクについては、GitHub の「Android の Device Farm サンプルアプリ」を参照してください。

Appium Java テストで、Cucumber などのビヘイビア駆動型の開発ツールを使用することもできます。サンプルテストについては、GitHub の「Device Farm Android サンプルアプリの Appium Java TestNG および Cucumber テスト」を参照してください。

バージョン情報

• 現在、Device Farm は Appium Java テストを実行するための Java 8 をサポートしています。• Device Farm は、Appium サーバーバージョン 1.6.5 以上をすべてサポートしています。avm コマンドを

使用して、任意の Appium バージョンを選択できます。たとえば、Appium サーバーバージョン 1.9.1 を使用するには、テストスペックの YAML ファイルに以下のコマンドを追加します。

phases: install: commands: # To install a newer version of Appium such as version 1.9.1: - export APPIUM_VERSION=1.9.1 - avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js

フレームワークのすべての機能 (注釈など) を使用するには、テスト環境を選択し、AWS CLI またはDevice Farm コンソールを使用してカスタムテスト仕様をアップロードします。


トピック• ステップ 1: Appium テストパッケージを設定する (p. 56)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 57)• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 58)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 59)• ステップ 5: Android Appium Java TestNG テストのスクリーンショットを取得する (オプショ

ン) (p. 60)

ステップ 1: Appium テストパッケージを設定するテストパッケージを設定するには、次の手順を実行します。Android アプリケーションの Appium JavaTestNG テストは .zip ファイルに含まれている必要があります。

Maven 設定を更新する

1. pom.xml を変更して、パッケージングを JAR ファイルに設定します。

API バージョン 2015-06-2356

http://appium.io/docs/en/about-appium/intro/

https://github.com/aws-samples/aws-device-farm-sample-app-for-android


https://docs.cucumber.io/

https://github.com/aws-samples/aws-device-farm-appium-cucumber-tests-for-sample-app

https://github.com/aws-samples/aws-device-farm-appium-cucumber-tests-for-sample-app



<groupId>com.acme</groupId><artifactId>acme-android-appium</artifactId><version>1.0-SNAPSHOT</version><packaging>jar</packaging>

2. maven-jar-plugin を変更し、pom.xml を使用してテストを JAR ファイルにビルドします。

次のプラグインは、テストソースコード (src/test ディレクトリ内のもの) を JAR ファイルにビルドします。

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.6</version> <executions> <execution> <goals> <goal>test-jar</goal> </goals> </execution> </executions></plugin>

3. pom.xml を変更し、maven-dependency-plugin を使用して依存関係を JAR ファイルとしてビルドします。

次のプラグインは依存関係を dependency-jars ディレクトリにコピーします。

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <version>2.10</version> <executions> <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/dependency-jars/</outputDirectory> </configuration> </execution> </executions></plugin>

ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• Android テストの Appium Java TestNG で Cucumber を使用している場合は、このステップを使用し

て、Cucumber の設定で Maven を設定します。それ以外の場合は、次のステップに進みます。

Note

Appium テストで Cucumber を使用する場合は、テストをカスタムテスト環境で実行する必要があります。

a. pom.xml を変更し、cucumber-java を依存関係として追加します。

API バージョン 2015-06-2357


<dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-java</artifactId> <version>4.0.0</version></dependency>

b. pom.xml を変更し、cucumber-testng を依存関係として追加します。

<dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-testng</artifactId> <version>4.0.0</version></dependency>

ステップ 3: 圧縮テストパッケージファイルの作成1. 次の XML アセンブリを src/main/assembly/zip.xml に保存します。

次の XML はアセンブリ定義です。この定義により、ビルド出力ディレクトリと dependency-jarsディレクトリのルートにあるすべてを .zip ファイルに含めてビルドするよう設定時に Maven に指示します。

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> <id>zip</id> <formats> <format>zip</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>${project.build.directory}</directory> <outputDirectory>./</outputDirectory> <includes> <include>*.jar</include> </includes> </fileSet> <fileSet> <directory>${project.build.directory}</directory> <outputDirectory>./</outputDirectory> <includes> <include>/dependency-jars/</include> </includes> </fileSet> </fileSets></assembly>

2. pom.xml を変更し、maven-assembly-plugin を使用してテストとすべての依存関係を単一の .zipファイルにパッケージ化します。

次のプラグインは、上記のアセンブリを使用して、mvn package が実行されるたびに、ビルド出力ディレクトリに zip-with-dependencies という名前の .zip ファイルを作成します。

<plugin>

API バージョン 2015-06-2358


<artifactId>maven-assembly-plugin</artifactId> <version>2.5.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <finalName>zip-with-dependencies</finalName> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/main/assembly/zip.xml</descriptor> </descriptors> </configuration> </execution> </executions></plugin>

3. ビルド、パッケージ化、および検証。例:

$ mvn clean package -DskipTests=true$ tree target.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar |— log4j-1.2.14.jar |— (and so on...)

4. Device Farm コンソールを使用してテストパッケージをアップロードします。

Note

注釈が 1.3 でサポートされていないというエラーが表示された場合は、以下を pom.xml に追加します。

<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.7</source> <target>1.7</target> </configuration></plugin>

ステップ 4: テストパッケージを Device Farm にアップロードするDevice Farm コンソールを使用して、Android テストの Appium Java TestNG をアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。

API バージョン 2015-06-2359



2. AWS Device Farm コンソールホームページが表示されたら、プロジェクトの名前を入力し、[Createproject (プロジェクトの作成)] を選択します。ページを更新して新しいプロジェクトを確認してください。

3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[Android ネイティブアプリケーション

( )] を選択して、[Upload (アップロード)] を選択します。

6. Android アプリファイルを参照して選択します。このファイルは、.apk ファイルである必要があります。

7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java TestNG] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:

Appium テストパッケージを設定する (p. 56)」で説明されている形式に従う必要があります。10. 使用している Appium のバージョンを選択します。11. [Next step (次のステップ)] を選択し、手順に従ってデバイスを選択して、実行を開始します。詳細に

ついては、「AWS Device Farm でテストランを作成する (p. 23)」を参照してください。

Note

Device Farm は Android Appium Java TestNG を変更しません。

ステップ 5: Android Appium Java TestNG テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。

Device Farm が Appium Java TestNG テストを実行すると、通信している Appium サーバーの構成を示す次のシステムプロパティが設定されます。

• appium.screenshots.dir: スクリーンショットの保存先のパス。• appium.server.address: Appium サーバーのホストアドレス。• appium.server.port: Appium サーバーがリッスンしているポート。

Device Farm は SCREENSHOT_PATH プロパティを、Appium スクリーンショットの保存先と Device Farmが見なすローカルファイルシステム上の完全修飾パスに設定します。スクリーンショットが保存されているテスト固有のディレクトリは、実行時に定義されます。スクリーンショットは Device Farm レポートに自動的に取り込まれます。スクリーンショットを表示するには、Device Farm コンソールで、[Screenshots] セクションを選択します。

API バージョン 2015-06-2360

AWS Device Farm 開発者ガイドAppium Java JUnit

次の例は appium.screenshots.dir プロパティを使用および消費して、Device Farm レポートに取り込まれた Appium スクリーンショットをキャプチャする方法を示しています。

public boolean takeScreenshot(final String name) { String screenshotDirectory = System.getProperty("appium.screenshots.dir", System.getProperty("java.io.tmpdir", "")); File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); return screenshot.renameTo(new File(screenshotDirectory, String.format("%s.png", name)));}

Android および AWS Device Farm の Appium JavaJUnit の使用このセクションでは、Android Appium Java JUnit テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction to Appium」を参照してください。

Appium Java テストで、Cucumber などのビヘイビア駆動型の開発ツールを使用することもできます。







トピック• ステップ 1: Appium テストパッケージを設定する (p. 61)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 62)• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 63)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 65)• ステップ 5: Android Appium Java JUnit テストのスクリーンショットを取得する (オプショ

ン) (p. 65)

ステップ 1: Appium テストパッケージを設定するテストパッケージを設定するには、次の手順を実行します。

API バージョン 2015-06-2361














ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• Android テストの Appium Java JUnit で Cucumber を使用している場合は、このステップを使用し


API バージョン 2015-06-2362


Note




b. pom.xml を変更し、cucumber-junit を依存関係として追加します。

<dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-junit</artifactId> <version>4.0.0</version> <scope>test</scope></dependency>




API バージョン 2015-06-2363




<plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.5.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <finalName>zip-with-dependencies</finalName> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/main/assembly/zip.xml</descriptor> </descriptors> </configuration> </execution> </executions></plugin>




Note



API バージョン 2015-06-2364


ステップ 4: テストパッケージを Device Farm にアップロードするDevice Farm コンソールを使用して、Android テストの Appium Java JUnit をアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. AWS Device Farm コンソールホームページが表示されたら、プロジェクトの名前を入力し、[Create


3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[Android ネイティブアプリケーション



7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java JUnit] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:



Note

Device Farm は Android Appium Java JUnit を変更しません。

ステップ 5: Android Appium Java JUnit テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。

Device Farm が Appium Java JUnit テストを実行すると、通信している Appium サーバーの構成を示す次のシステムプロパティが設定されます。


API バージョン 2015-06-2365


AWS Device Farm 開発者ガイドAppium Node.js




Appium Node.js for Android アプリケーションおよびAWS Device Farm での作業このセクションでは、Appium Node.js テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。


• Device Farm で Appium Node.js テストを実行する場合は、任意の Node.js バージョンを使用できます。テストスペックの YAML ファイルで Node.js バージョンを指定します。

• Device Farm では、Appium サーバーバージョン 1.6.5 以降をサポートしています。avm コマンドを使用して、任意の Appium バージョンを選択できます。たとえば、Appium サーバーバージョン 1.9.1 を使用するには、テストスペックの YAML ファイルにこれらのコマンドを追加します。



トピック• テストをパッケージ化するための前提条件 (p. 66)• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 67)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 68)

テストをパッケージ化するための前提条件Appium Node.js テストをパッケージ化して Device Farm にアップロードするには、ローカルマシンに次のものをインストールする必要があります。

API バージョン 2015-06-2366





• Node Version Manager (nvm)

不要な依存関係がテストパッケージに含まれないように、テストを開発およびパッケージ化するときにこのツールを使用してください。

• Node.js• npm-bundle (グローバルにインストール)

macOS または Linux の前提条件をインストールするには

1. nvm をインストールするには、このコマンドを実行します。

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

インストールが完了したら、サインアウトしてから再度サインインして端末を再リロードします。

Note

nvm は bash シェル専用の関数としてロードされます。2. bash シェルでこのコマンドを実行して、nvm が正しくインストールされていることを確認します。/

bin/bash を使用して、bash シェルに切り替えることができます。

command -v nvm

出力として nvm が表示されるはずです。

詳細については、GitHub の nvm を参照してください。3. Node.js をインストールするには、このコマンドを実行します。

nvm install node

次に示すように、特定のバージョンの Node.js を指定できます。

nvm install 11.4.0

4. 指定したバージョンを使用していることを確認するには、このコマンドを実行します。

node -v

5. このコマンドを実行して npm-bundle をグローバルにインストールします。

npm install -g npm-bundle

ステップ 1: 圧縮テストパッケージファイルの作成Device Farm にアップロードする Appium Node.js テストパッケージは、.zip 形式で、テストのすべての依存関係を含んでいる必要があります。

1. プロジェクトをチェックアウトします。

プロジェクトのルートディレクトリにいることを確認します。ルートディレクトリで package.jsonを確認できます。

2. ローカルの依存関係をインストールするには、このコマンドを実行します。API バージョン 2015-06-2367

https://github.com/creationix/nvm



npm install

このコマンドは、現在のディレクトリ内に node_modules フォルダも作成します。

Note

この時点で、ローカルでテストを実行できるようにする必要があります。3. このコマンドを実行して、現在のフォルダ内のファイルを *.tgz ファイルにパッケージ化します。ファ

イルの名前は、package.json ファイルの name プロパティを使用して付けられます。

npm-bundle

この tarball(.tgz) ファイルには、コードと依存関係がすべて含まれています。4. このコマンドを実行して、前のステップで生成した tarball (*.tgz ファイル) を単一の zip アーカイブに

バンドルします。

zip -r MyTests.zip *.tgz

これは、次の手順で Device Farm にアップロードする MyTests.zip ファイルです。

ステップ 2: テストパッケージを Device Farm にアップロードするDevice Farm コンソールを使用してテストをアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. AWS Device Farm コンソールホームページが表示されたら [Get started (使用開始)] を選択します。3. 既存のプロジェクトにテストをアップロードするか、[新しいプロジェクトの作成] を選択できます。

Tip

プロジェクトのリストが表示されない場合は、セカンダリナビゲーションバーの [Projects]で、テストをアップロードするプロジェクトの名前を選択します。プロジェクトを作成するには、「AWS Device Farm でプロジェクトを作成する (p. 20)」の手順に従ってください。

4. [Create a new run] ボタンが表示されている場合は、選択します。5. [Choose your application (アプリケーションの選択)] ページで、[Android ネイティブアプリケーション

( )] を選択します。

API バージョン 2015-06-2368


AWS Device Farm 開発者ガイドAppium Python

6. [Upload] を選択し、.apk ファイルをアップロードします。

Device Farm は、続行する前に、.apk ファイルを処理します。7. [Run name] に、実行の名前を入力します。

Tip

実行に名前を付けると、アプリケーションの特定のビルドを識別するのに役立ちます (例:Beta-0.1)。詳細については、「テストランの使用 (p. 23)」を参照してください。

8. [Appium Node.js] を選択してテストを設定します。9. Appium テストスクリプトをテストランに追加するには、[Upload] を選択します。10. 前の手順で作成した MyTests.zip ファイルを選択します。11. テスト仕様を選択する手順に従います。

デフォルトのテスト仕様を使用している場合は、テスト仕様の YAML ファイルの test セクションにあるテスト実行コマンドを変更します。

12. デバイスを選択し、実行を開始します。

詳細については、「AWS Device Farm でテストランを作成する (p. 23)」を参照してください。

Note

Device Farm は Android Appium Node.js テストを変更しません。

Appium Python for Android アプリケーションおよびAWS Device Farm での作業このセクションでは、Appium Python テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。

サンプルアプリについては、GitHub の「Android の Device Farm サンプルアプリ」を参照してください。

Device Farm サンプルテストについては、GitHub の「Device Farm サンプル Android アプリの AppiumPython サンプルテスト」を参照してください。


• 標準モードでは、Device Farm は、テストを実行するために Python バージョン 2.7 をサポートしています。カスタムモードでは、Python 2.7 と Python 3 (3.7) の両方が利用可能です。

• Device Farm は、Appium サーバーバージョン 1.6.5 以上をすべてサポートしています。avm コマンドを使用して、任意の Appium バージョンを選択できます。たとえば、Appium サーバーバージョン 1.9.1 を使用するには、テストスペックの YAML ファイルに以下のコマンドを追加します。



API バージョン 2015-06-2369




https://github.com/aws-samples/aws-device-farm-appium-python-tests-for-android-sample-app

https://github.com/aws-samples/aws-device-farm-appium-python-tests-for-android-sample-app



ステップ 1: 圧縮テストパッケージファイルの作成Device Farm にアップロードする Appium Python テストパッケージは、.zip 形式で、テストのすべての依存関係を含んでいる必要があります。

Note

以下の手順は Linux x86_64 および macOS を対象にしています。現在サポートされているスキームでは、Device Farm は、テストに非普遍性の Python wheels 依存関係が含まれている場合、Appium Python テストのパッケージを Linux x86_64 上で実行する必要があります。コマンドを実行するプラットフォームの場合、ホイールツールは wheelhouse/ フォルダの下にある .whl 依存ファイルを収集します。Linux x86_64 以外のプラットフォームで Python wheel コマンドを実行すると、その特定のプラットフォームに対する非ユニバーサルホイール依存関係のフレーバーが集められ、Device Farm でテストを実行するときにエラーが発生する可能性があります。

1. 不要な依存関係がアプリケーションパッケージに含まれないように、テストの開発とパッケージ化のために Python virtualenv を設定することを強くお勧めします。

$ virtualenv workspace$ cd workspace$ source bin/activate

Tip

• グローバルサイトパッケージディレクトリからパッケージを継承するため、--system-site-packages オプションを使用して Python virtualenv を作成しないでください。これにより、テストで不要な依存関係を仮想環境に含めることになる場合があります。

• これらのネイティブライブラリは、これらのテストが実行されるインスタンス上に存在する場合と存在しない場合があるため、ネイティブライブラリに依存する依存関係をテストで使用しないことも確認する必要があります。

2. 仮想環境に py.test をインストールします。

$ pip install pytest

3. Appium Python クライアントを仮想環境にインストールします。

$ pip install Appium-Python-Client

4. カスタムモードで別のパスを指定しない限り、Device Farm はテストが tests/ に格納されることを想定しています。find を使用して、フォルダ内のすべてのファイルを表示できます。

$ find tests/

これらのファイルに、Device Farm で実行するテストスイートが含まれていることを確認します。

tests/tests/my-first-tests.pytests/my-second-tests/py

5. 仮想環境のワークスペースフォルダからこのコマンドを実行して、テストを実行せずにテストのリストを表示します。

API バージョン 2015-06-2370


http://pythonwheels.com/

https://pypi.python.org/pypi/virtualenv


$ py.test --collect-only tests/

Device Farm で実行するテストが出力に表示されていることを確認します。6. テスト/フォルダの下にあるすべてのキャッシュファイルを消去します。

$ find . -name '__pycache__' -type d -exec rm -r {} +$ find . -name '*.pyc' -exec rm -f {} +$ find . -name '*.pyo' -exec rm -f {} +$ find . -name '*~' -exec rm -f {} +

7. WorkSpace で次のコマンドを実行して、requirements.txt ファイルを生成します。

$ pip freeze > requirements.txt

8. 次に、Device Farm 用にテストをバンドルします。

Python 2

1. pip を使用して、必要な Python パッケージ (「ホイールハウス」と呼ばれる) のアーカイブを生成します。

$ pip wheel --wheel-dir wheelhouse -r requirements.txt

2. ホイールハウス、テスト、pip 要件を Device Farm の zip アーカイブにパッケージ化します。

$ zip -r test_bundle.zip tests/ wheelhouse/ requirements.txt

Python 3

テストと pip 要件を zip ファイルにパッケージ化します。

$ zip -r test_bundle.zip tests/ requirements.txt



Tip




API バージョン 2015-06-2371





Tip


8. [Appium Python] を選択してテストを設定します。9. Appium テストスクリプトをテストランに追加するには、[Upload] を選択します。10. 標準モード (詳細なテストとレポート作成を有効にする) またはカスタムモード (より高い柔軟性を有

効にする) のテストを構成します。

Python 2

標準モードを使用している場合

使用している Appium のバージョンを選択します。カスタムモードを使用している場合

テスト仕様の YAML ファイルで、使用している Appium のバージョンをエクスポートして設定してください。

phases: install: commands: # ... - export APPIUM_VERSION=1.14.2 - avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js

Python 3

Python 3 テストでは、カスタムモードを使用する必要があります。Python 3 を Python のバージョンとして選択するには、テスト仕様の YAML を更新します。

phases: install: commands: - export PYTHON_VERSION=3 # ... - export APPIUM_VERSION=1.14.2

API バージョン 2015-06-2372

AWS Device Farm 開発者ガイドAppium Ruby

- avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js

11. [Next step (次のステップ)] を選択し、手順に従ってデバイスを選択して、実行を開始します。詳細については、「AWS Device Farm でテストランを作成する (p. 23)」を参照してください。

Note

Device Farm は Android Appium Python テストを変更しません。

ステップ 3: Android Appium Python テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。

Device Farm は、SCREENSHOT_PATH プロパティをローカルファイルシステム上の完全修飾パスに設定します。Device Farm は、そのパスを Appium スクリーンショットの保存先とみなします。スクリーンショットが保存されているテスト固有のディレクトリは、実行時に定義されます。スクリーンショットはDevice Farm レポートに自動的に取り込まれます。スクリーンショットを表示するには、Device Farm コンソールで、スクリーンショットセクションを選択します。

スクリーンショットを撮るには、get_screenshot_as_file メソッドを使用します。次の例では、テスト中にスクリーンショットを保存します。

import os# with a given Appium WebDriver and filename, save the filedef take_screenshot(driver, name): if not driver.get_screenshot_as_file(os.path.join(os.getenv("SCREENSHOT_PATH", os.getcwd()), name)): assert 0 # Fail the test if a screenshot cannot be saved.

Appium Ruby for Android アプリケーションおよびAWS Device Farm の使用このセクションでは、Appium Ruby テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。


• Device Farm で Appium Ruby テストを実行する場合は、任意の Ruby バージョンを使用できます。テストスペックの YAML ファイルで Ruby バージョン (2.5.1 など) を指定します。



API バージョン 2015-06-2373

https://selenium-python.readthedocs.io/api.html#selenium.webdriver.remote.webdriver.WebDriver.get_screenshot_as_file





トピック• テストをパッケージ化するための前提条件 (p. 74)• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 75)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 75)• Appium テストをスピードアップするためのヒント (p. 76)

テストをパッケージ化するための前提条件Appium Ruby テストをパッケージ化して Device Farm にアップロードするには、ローカルマシンに次のものをインストールする必要があります。

• Ruby Version Manager (RVM)

不要な依存関係がテストパッケージに含まれないように、テストを開発およびパッケージ化するときにこのコマンドラインツールを使用してください。

• Ruby• Bundler (この Gem には通常、Ruby がすでにインストールされています)。

1. 必要なキー、RVM、および Ruby をインストールします。手順については、RVM ウェブサイトの「RVM のインストール」を参照してください。

# The following command is for reference only. Go to rvm website and look for the complete command.gpg --keyserver hkp://keys.gnupg.net --recv-keys $keys

# install rvm along with ruby\curl -sSL https://get.rvm.io | bash -s stable --ruby


Note

RVM は bash シェル専用の関数としてロードされます。2. bash シェルでこのコマンドを実行して、RVM が正しくインストールされていることを確認します。/


command -v rvm

出力として rvm が表示されるはずです。3. 特定のバージョンの Ruby (たとえば 2.5.1) をインストールする場合は、次のコマンドを実行してくだ

さい。

rvm install ruby 2.5.1 --autolibs=0

指定したバージョンを使用していることを確認するには、このコマンドを実行します。

ruby -v

API バージョン 2015-06-2374


https://rvm.io/rvm/install



4. 通常の Ruby インストールに含まれる Bundler をインストールする必要がある場合は、このコマンドを実行します。

gem install bundler

ステップ 1: 圧縮テストパッケージファイルの作成Device Farm にアップロードする Appium Ruby テストパッケージは、.zip 形式で、テストのすべての依存関係を含んでいる必要があります。

1. 仮想 Ruby 環境を作成するには、次のコマンドを実行します。

# myGemset is the name of your virtual Ruby environmentrvm gemset create myGemset

2. 先ほど作成した環境を使用するには、次のコマンドを実行します。

rvm gemset use myGemset

3. ソースコードを確認してください。

プロジェクトのルートディレクトリにいることを確認します。ルートディレクトリで Gemfile を確認できます。

4. ローカルの依存関係と、Gemfile からすべての Gem をインストールするには、このコマンドを実行します。

bundle install

Note

この時点で、ローカルでテストを実行できるようにする必要があります。テストをローカルで実行するには、このコマンドを使用します。

bundle exec $test_command

5. vendor/cache フォルダの Gem をパッケージングします。

# This will copy all the .gem files needed to run your tests into the vendor/cache directorybundle package

6. 次のコマンドを実行して、すべての依存関係とともにソースコードを単一の zip アーカイブにバンドルします。

zip -r MyTests.zip Gemfile vendor/ $(any other source code directory files)



API バージョン 2015-06-2375



Tip






Tip


8. [Appium Ruby] を選択してテストを設定します。9. Appium テストスクリプトをテストランに追加するには、[Upload] を選択します。10. 前の手順で作成した MyTests.zip ファイルを選択します。11. テスト仕様を選択する手順に従います。




Note

Device Farm は Android Appium Ruby テストを変更しません。

Appium テストをスピードアップするためのヒントステップ 1 のパッケージングの説明では、Gem をパッケージ化していますが、ランタイムに Gem はまだDevice Farm ホストにインストールされています。拡張機能付きの Gem (たとえば、Nokogiri) をホストにインストールするにはかなりの時間がかかります。

API バージョン 2015-06-2376


AWS Device Farm 開発者ガイドCalabash

テストをスピードアップするために、Gem 自体をパッケージ化する代わりに Gem インストールディレクトリをパッケージングすることができます。拡張機能付きの Gem はプラットフォーム固有のものなので、Device Farm がテストの実行に使用するのと同じプラットフォーム上に Gem インストールディレクトリを生成する必要があります。

Device Farm は、Ubuntu マシン (Ubuntu 14.04.5 LTS) で Android テストを実行します。Gem はプラットフォーム固有のものなので、テストをパッケージ化するときには同じバージョンの Ubuntu を使用することをお勧めします。このバージョンを実行している Ubuntu マシンがない場合は、Amazon EC2 を使用してそれを実行するインスタンスを作成できます。インスタンスタイプで、Ubuntu Server 14.04 LTS (HVM)を選択します。ボリュームタイプで、SSD を選択します。


# myGemset is the name of your virtual ruby environmentrvm gemset create myGemset






bundle install --path=vendor/bundle

--path スイッチでは、システムの場所ではなく、vendor/bundle ディレクトリに Gem をインストールし、.bundle/config ファイルを作成して、今後インストールで使用されるデフォルトのパスとして使用します。

Note



5. このコマンドを実行して、ソースコード、Gemfile、Gem のインストールディレクトリ、および.bundle ディレクトリを単一の zip アーカイブにバンドルします。

zip -r MyTests.zip Gemfile .bundle/ vendor/ $(any other source code directory files)

Calabash for Android と AWS Device Farm の使用Device Farm では Calabash for Android がサポートされています。

Device Farm には、サンプルの Android アプリケーションと、Calabash を含む 3 つの Android 自動化フレームワークでの動作テストへのリンクも用意されています。Android 用 Device Farm サンプルアプリは、GitHub でダウンロードできます。

API バージョン 2015-06-2377

https://github.com/awslabs/aws-device-farm-sample-app-for-android



Calabash とはCalabash は、Cucumber で書かれた自動化ユーザーインターフェイスの受け入れテストを Android アプリで実行するのに使用できるモバイルテストフレームワークです。詳細については、GitHub の「Welcometo Calabash for Android」リポジトリを参照してください。

バージョン情報現在 Device Farm では Calabash バージョン 0.9.0 をサポートしています。

Android Calabash テストを準備するAndroid Calabash テストは、以下の構造で .zip ファイルに含まれている必要があります。

my-zip-file-name.zip `-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | `-- (.rb files) |-- support (directory) | `-- (.rb files) `-- (any other supporting files)

Android Calabash テストをアップロードするDevice Farm コンソールを使用してテストをアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトのリストで、テストをアップロードするプロジェクトの横にあるオプションを選択しま

す。

Tip


3. [Create a new run] ボタンが表示されている場合は、選択します。4. [Choose your application (アプリケーションの選択)] ページで、[Upload (アップロード)] を選択しま

す。5. Android アプリファイルを参照して選択します。このファイルは、.apk ファイルである必要がありま

す。6. [Next step] を選択します。7. [Configure a test] ページで、[Calabash] を選択し、次に [Upload] を選択します。8. テストが含まれている .zip ファイルを参照して選択します。9. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。

Android Calabash テストのスクリーンショットの取得Android Calabash テストの一部としてスクリーンショットを撮ることができます。

API バージョン 2015-06-2378

https://github.com/calabash/calabash-android

https://github.com/calabash/calabash-android


AWS Device Farm 開発者ガイドインストルメンテーション

Android Calabash では、スクリーンショットを取得するための一連の定義済みの手順を利用できます。詳細については、GitHub の Calabash Android リポジトリにある Canned steps ページの「Screenshots」セクションを参照してください。

また、Ruby (.rb) ファイル内のカスタムステップを定義して screenshot_embed 関数を呼び出すこともできます。この関数では、スクリーンショットを作成して定義したディレクトリに保存します。次のコード例ではスクリーンショットを作成し、/my/custom/path ディレクトリに screenshot_seconds-since-Epoch のファイル名で保存します。

screenshot_embed(:prefix => "/my/custom/path", :name => "screenshot_#{Time.now.to_i}")

Android Calabash テストに関するその他の考慮事項Device Farm は Device Farm のデバイス上で Android Calabash テストを実行できるようにいくつかのCalabash フックを置き換えますが Android Calabash テスト自体は変更されません。

Android および AWS Device Farm の計器の操作Device Farm は、Android 用の計器 (JUnit、Espresso、Robotium、その他の実装ベースのテスト) を提供します。

Device Farm には、サンプルの Android アプリケーションと、計器 (Espresso) を含む 3 つの Android オートメーションフレームワークでの動作テストへのリンクが用意されています。Android 用 Device Farm サンプルアプリは、GitHub でダウンロードできます。

トピック• 計器とは? (p. 79)• Android 計器テストのアップロード (p. 79)• Android 計測テストでスクリーンショットを撮る (p. 80)• Android 計器テストに関するその他の考慮事項 (p. 80)

計器とは?Android の計器はテストコードでコールバックメソッドを呼び出すことができます。これにより、コンポーネントをデバッグしているかのように、コンポーネントのライフサイクルを段階的に実行することができます。詳細については、Android 開発者ツールドキュメントの『Testing Fundamentals セクション』内の「計器」を参照してください。

Android 計器テストのアップロードDevice Farm コンソールを使用してテストをアップロードします。


す。

Tip


3. [Create a new run] ボタンが表示されている場合は、選択します。

API バージョン 2015-06-2379

https://github.com/calabash/calabash-android/blob/master/ruby-gem/lib/calabash-android/canned_steps.md



http://developer.android.com/tools/testing/testing_android.html#Instrumentation


AWS Device Farm 開発者ガイドUI Automator

4. [Choose your application (アプリケーションの選択)] ページで、[Upload (アップロード)] を選択します。


6. [Next step] を選択します。7. [Configure a test] ページで、[Instrumentation] を選択し、次に [Upload] を選択します。8. テストが含まれている .apk ファイルを参照して選択します。9. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。

Android 計測テストでスクリーンショットを撮るAndroid 計器テストの一部としてスクリーンショットを撮ることができます。

スクリーンショットを撮るには、次のいずれかのメソッドを呼び出します。

• Robotium の場合は、takeScreenShot メソッドを呼び出します (例: solo.takeScreenShot();)。• Spoon の場合は、次のような screenshot メソッドを呼び出します。

Spoon.screenshot(activity, "initial_state");/* Normal test code... */Spoon.screenshot(activity, "after_login");

テスト実行中、Device Farm は、デバイス上の次の場所 (存在する場合) から自動的にスクリーンショットを取得し、テストレポートに追加します。

• /sdcard/robotium-screenshots

• /sdcard/test-screenshots

• /sdcard/Download/spoon-screenshots/test-class-name/test-method-name

• /data/data/application-package-name/app_spoon-screenshots/test-class-name/test-method-name

Android 計器テストに関するその他の考慮事項システムアニメーション

エスプレッソテスト用の Android のドキュメントによれば、実際のデバイスでテストするときはシステムアニメーションをオフにすることをお勧めします。android.support.test.runner.AndroidJUnitRunner 計器テストランナーを使用して実行する場合、Device Farm は Window Animation Scale、Transition Animation Scale、Animator Duration Scaleの設定を自動的に無効にします。

テストレコーダー

Device Farm は、Robotium などのレコード再生スクリプトツールを備えたフレームワークをサポートしています。

Android および AWS Device Farm の UI Automator の操作Device Farm では Android 用 UI Automator がサポートされています。

API バージョン 2015-06-2380

http://developer.android.com/training/testing/ui-testing/espresso-testing.html

http://developer.android.com/reference/android/support/test/runner/AndroidJUnitRunner.html


Note

このフレームワークは現在、プレビューバージョンです。すべてのスクリプトやアプリで動作するとは限りません。

トピック• UI Automator とは何ですか (p. 81)• Android UI Automator テストの準備 (p. 81)• Android UI Automator テストのアップロード (p. 81)• Android UI Automator テストでスクリーンショットを撮る (p. 82)• Android UI Automator テストに関するその他の考慮事項 (p. 82)

UI Automator とは何ですかUI Automator テストフレームワークは、ユーザーおよび Android 用システムアプリケーション間のインタラクションを実行する、ユーザーインターフェイステストを構築する一連の API を提供します。UIAutomator API で、[設定] メニューやテストデバイスのアプリランチャーを開く、などの操作を実行できます。詳細については、Android Developer Tools ドキュメントの「Testing Support Library セクション」内の「UI Automator」を参照してください。

Android UI Automator テストの準備Android UI Automator テストは、1 つの JAR ファイルに含める必要があります。このファイルのパッケージ名は、Android アプリケーションで使用されるパッケージ名と一致している必要があります。たとえば、Android アプリケーションのパッケージ名が com.my.android.app.MyMobileApp の場合、Android UI Automator テストは com.my.android.app という名前のパッケージに含まれている必要があります。

Android UI Automator テストのアップロードDevice Farm コンソールを使用してテストをアップロードします。


す。

Tip



す。5. Android アプリファイルを参照して選択します。このファイルは、.apk ファイルである必要がありま

す。6. [Next step] を選択します。7. [Configure a test] ページで、[uiautomator] を選択し、次に [Upload] を選択します。8. テストが含まれている JAR ファイルを参照して選択します。9. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。

API バージョン 2015-06-2381

https://developer.android.com/tools/testing-support-library/index.html#UIAutomator


AWS Device Farm 開発者ガイドiOS テスト

Android UI Automator テストでスクリーンショットを撮るAndroid UI Automator テストの一部としてスクリーンショットを撮ることができます。

スクリーンショットを取得するには、takeScreenshot メソッドを呼び出します(例 :takeScreenshot("/sdcard/uiautomator-screenshots/home-screen-1234.png");)。

Note

すべてのスクリーンショットを /sdcard/uiautomator-screenshots ディレクトリに保存する必要があります。保存するスクリーンショットの (ファイル名を含む) 完全なパスを指定する必要があります。この takeScreenshot メソッドは、API レベル 17 以降で機能します。API レベル 16 では、UIAutomator がサポートされていますが、スクリーンショットはサポートされていません。

Android UI Automator テストに関するその他の考慮事項Device Farm は Android UI Automator テストパッケージに再署名しますが、Android UI Automator テストを変更しません。

AWS Device Farm での iOS テストの実行Device Farm では、iOS デバイスの複数の自動化テストタイプ、および、組み込みテストがサポートされています。

iOS アプリケーションのテストフレームワークiOS デバイスでは、次のテストを使用できます。

• Appium Java TestNG (p. 82)• Appium Java JUnit (p. 88)• Appium Node.js (p. 93)• Appium Python (p. 96)• Appium Ruby (p. 100)• Calabash (p. 104)• UI Automation (p. 106)• XCTest for iOS と AWS Device Farm の使用 (p. 107)• XCTest UI (p. 109)

組み込みの iOS 用テストタイプ現在、iOS デバイスで 1 つの組み込みのテストタイプが利用できます。

• 組み込み: ファズ (Android および iOS) (p. 133)

iOS および AWS Device Farm の Appium JavaTestNG の使用このセクションでは、iOS Appium Java TestNG テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケー

API バージョン 2015-06-2382


ションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction to Appium」を参照してください。

サンプルアプリおよび動作テストへのリンクについては、GitHub の「iOS の Device Farm サンプルアプリ」を参照してください。







トピック• ステップ 1: Appium テストパッケージを設定する (p. 83)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 84)• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 85)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 86)• ステップ 5: iOS Appium Java TestNG テストのスクリーンショットを取得する (オプション) (p. 87)

ステップ 1: Appium テストパッケージを設定するテストパッケージを設定するには、次の手順を実行します。iOS アプリケーションの Appium JavaTestNG テストは .zip ファイルに含まれている必要があります。






<plugin>

API バージョン 2015-06-2383


https://github.com/aws-samples/aws-device-farm-sample-app-for-ios




<groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.6</version> <executions> <execution> <goals> <goal>test-jar</goal> </goals> </execution> </executions></plugin>




ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• iOS テストの Appium Java TestNG で Cucumber を使用している場合は、このステップを使用し


Note





<dependency> <groupId>io.cucumber</groupId>

API バージョン 2015-06-2384


<artifactId>cucumber-testng</artifactId> <version>4.0.0</version></dependency>






<plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.5.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <finalName>zip-with-dependencies</finalName> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/main/assembly/zip.xml</descriptor> </descriptors>

API バージョン 2015-06-2385


</configuration> </execution> </executions></plugin>




Note



ステップ 4: テストパッケージを Device Farm にアップロードするDevice Farm コンソールを使用してテストをアップロードできます。



3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[iOS ネイティブアプリケーション


API バージョン 2015-06-2386



6. iOS アプリファイルを参照して選択します。このファイルは、.ipa ファイルである必要があります。7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java TestNG] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:



Note

Device Farm は iOS Appium Java TestNG を変更しません。

ステップ 5: iOS Appium Java TestNG テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。






API バージョン 2015-06-2387


iOS 向けの Appium Java JUnit と AWS Device Farmの使用このセクションでは、iOS Appium Java JUnit テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introductionto Appium」を参照してください。

Appium Java テストで、Cucumber などのビヘイビア駆動型の開発ツールを使用することもできます。







トピック• ステップ 1: Appium テストパッケージを設定する (p. 88)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 89)• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 90)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 91)• ステップ 5: iOS Appium Java JUnit テストのスクリーンショットを取得する (オプション) (p. 92)






API バージョン 2015-06-2388











ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• iOS テストの Appium Java JUnit で Cucumber を使用している場合は、このステップを使用し


Note




API バージョン 2015-06-2389









<plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.5.4</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal>

API バージョン 2015-06-2390


</goals> <configuration> <finalName>zip-with-dependencies</finalName> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/main/assembly/zip.xml</descriptor> </descriptors> </configuration> </execution> </executions></plugin>




Note






3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[iOS ネイティブアプリケーション


API バージョン 2015-06-2391



6. iOS アプリファイルを参照して選択します。このファイルは、.ipa ファイルである必要があります。7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java JUnit] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:



Note

Device Farm では iOS Appium Java JUnit テストを変更しません。

ステップ 5: iOS Appium Java JUnit テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。





public boolean takeScreenshot(final String name) { String screenshotDirectory = System.getProperty("appium.screenshots.dir", System.getProperty("java.io.tmpdir", "")); File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); return screenshot.renameTo(new File(screenshotDirectory, String.format("%s.png", name)));

API バージョン 2015-06-2392


}

Appium Node.js for iOS アプリケーションおよび AWSDevice Farm を使用するこのセクションでは、Appium Node.js テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。














API バージョン 2015-06-2393






インストールが完了したら、サインアウトしてから再度サインインして端末を再リロードします。Note



command -v nvm



nvm install node


nvm install 11.4.0


node -v






2. ローカルの依存関係をインストールするには、このコマンドを実行します。

npm install

このコマンドは、現在のディレクトリ内に node_modules フォルダも作成します。Note



npm-bundle

この tarball(.tgz) ファイルには、コードと依存関係がすべて含まれています。

API バージョン 2015-06-2394



4. このコマンドを実行して、前のステップで生成した tarball (*.tgz ファイル) を単一の zip アーカイブにバンドルします。





Tip


4. [Create a new run] ボタンが表示されている場合は、選択します。5. [Choose your application (アプリケーションの選択)] ページで、[iOS ネイティブアプリケーション


6. [Upload] を選択し、.ipa ファイルをアップロードします。

Device Farm は、続行する前に、.ipa ファイルを処理します。7. [Run name] に、実行の名前を入力します。

Tip



API バージョン 2015-06-2395






Note

Device Farm は iOS Appium Node.js テストを変更しません。

Appium Python for iOS Application および AWSDevice Farm の使用このセクションでは、Appium Python テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。

サンプルアプリについては、GitHub の「iOS の Device Farm サンプルアプリ」を参照してください。

Device Farm テストサンプルについては、GitHub の「Device Farm サンプル iOS アプリの Appium Pythonサンプルテスト」を参照してください。







トピック• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 97)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 98)• ステップ 3: iOS Appium Python テストのスクリーンショットを取得する (オプション) (p. 100)

API バージョン 2015-06-2396




https://github.com/aws-samples/aws-device-farm-appium-python-tests-for-ios-sample-app

https://github.com/aws-samples/aws-device-farm-appium-python-tests-for-ios-sample-app




Note




Tip

• /usr/lib/pythonx.x/site-packages またはグローバルサイトパッケージディレクトリの場所からパッケージを継承するため、--system-site-packages オプションを使用してPython virtualenv を作成しないでください。これにより、テストで不要な依存関係を仮想環境に含めることになる場合があります。







$ find tests/





Device Farm で実行するテストが出力に表示されていることを確認します。

API バージョン 2015-06-2397




6. 次のコマンドを使用して、tests/ フォルダの下にあるすべてのキャッシュファイルを消去できます。





Python 2





Python 3





Tip




API バージョン 2015-06-2398





Tip




Python 2


使用している Appium のバージョンを選択します。カスタムモードを使用している場合



Python 3


phases: install: commands: - export PYTHON_VERSION=3 # ... - export APPIUM_VERSION=1.14.2

API バージョン 2015-06-2399


- avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js


Note

Device Farm は iOS Appium Python テストを変更しません。

ステップ 3: iOS Appium Python テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。




Appium Ruby for iOS Application および AWS DeviceFarm を使用するこのセクションでは、Appium Ruby テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。





API バージョン 2015-06-23100






トピック• テストをパッケージ化するための前提条件 (p. 101)• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 102)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 102)• Appium テストをスピードアップするためのヒント (p. 103)









Note



command -v rvm


さい。



ruby -v

API バージョン 2015-06-23101






gem install bundler









bundle install

Note









API バージョン 2015-06-23102



Tip






Tip






Note

Device Farm は iOS Appium Ruby テストを変更しません。

Appium テストをスピードアップするためのヒントステップ 1 のパッケージングの説明では、Gem をパッケージ化していますが、ランタイムに Gem はまだDevice Farm ホストにインストールされています。拡張機能付きの Gem (たとえば、Nokogiri) をホストにインストールするにはかなりの時間がかかります。

API バージョン 2015-06-23103



テストをスピードアップするために、Gem 自体をパッケージ化する代わりに Gem インストールディレクトリをパッケージングすることができます。拡張機能付きの Gem はプラットフォーム固有のものなので、Device Farm がテストの実行に使用するのと同じプラットフォーム上に Gem インストールディレクトリを生成する必要があります。

Device Farm は macOS マシンで iOS テストを実行します。iOS デバイスでは、Device Farm インフラストラクチャを使用して Gem インストールディレクトリを作成できます。

Note

Device Farm は、Device Farm ホストで実行されている macOS のバージョンを定期的に更新します。以下のパッケージングステップは、macOS バージョン間の Gem エクステンションに互換性がない場合、macOS バージョンの変更によって中断することがあります。

1. 「ステップ 1: 圧縮テストパッケージファイルの作成」の手順に従ってテストをパッケージ化します。2. Device Farm でテスト実行をスケジュールするときに、テスト仕様の YAML ファイルで次のコマンド

を変更します。

>> bundle install --localbundle install --local --path=$DEVICEFARMLOGDIRECTORY/vendor/bundle

>> bundle install Bundle install --path=$DEVICEFARMLOGDIRECTORY/vendor/bundle

--path は、Gem をシステムの場所ではなく $DEVICEFARMLOGDIRECTORY/vendor/bundle ディレクトリにインストールします。

テストの実行が終了したら、テストのアーティファクトから vendor/bundle ディレクトリをダウンロードできます。

3. プロジェクトのルートディレクトリにある vendor/bundle ディレクトリをコピーします。4. Gem のインストールディレクトリを vendor/bundle に設定するには、次のコマンドを実行しま

す。

bundle config --local path vendor/bundle

上記のコマンドによって、.bundle/config ファイルが作成されます。

Note



5. このコマンドを実行して、ソースコード、Gemfile、Gem のインストールディレクトリ、および.bundle ディレクトリを単一の zip アーカイブにバンドルします。

zip -r MyTests.zip Gemfile .bundle/ vendor/ $(any other source code directory files)

Calabash for iOS と AWS Device Farm の使用Device Farm では Calabash for iOS. がサポートされています。以下の情報は、このテストフレームワークを Device Farm テストタイプとともに使用する方法を説明しています。

トピック

API バージョン 2015-06-23104


• Calabash とは (p. 105)• バージョン情報 (p. 105)• iOS Calabash テストを準備する (p. 105)• iOS Calabash テストをアップロードする (p. 105)• iOS Calabash テストのスクリーンショットの取得 (p. 106)• iOS Calabash テストに関するその他の考慮事項 (p. 106)

Calabash とはCalabash は、Cucumber で書かれた自動化ユーザーインターフェイスの受け入れテストを iOS アプリで実行するのに使用できるモバイルテストフレームワークです。詳細については、GitHub の「Welcome toCalabash iOS」リポジトリを参照してください。

バージョン情報現在 Device Farm では Calabash バージョン 0.20.5 をサポートしています。

iOS Calabash テストを準備するiOS Calabash テストは、以下の構造で .zip ファイルに含まれている必要があります。

my-zip-file-name.zip `-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | `-- (.rb files) |-- support (directory) | `-- (.rb files) `-- (any other supporting files)

iOS Calabash テストをアップロードするDevice Farm コンソールを使用してテストをアップロードします。


す。Tip

プロジェクトのリストが表示されていない場合は、セカンダリナビゲーションバーの[Projects] で、テストをアップロードするプロジェクトの名前を選択します。プロジェクトを作成するには、「AWS Device Farm でプロジェクトを作成する (p. 20)」の手順に従ってください。


す。5. iOS アプリファイルを参照して選択します。このファイルは、.ipa ファイルである必要があります。

Note


API バージョン 2015-06-23105

https://github.com/calabash/calabash-ios

https://github.com/calabash/calabash-ios


AWS Device Farm 開発者ガイドUI Automation

6. [Next step] を選択します。7. [Configure a test] ページで、[Calabash] を選択し、次に [Upload] を選択します。8. テストが含まれている .zip ファイルを参照して選択します。9. [Next step] を選択後、残りの画面上の指示を完了してテストを実行するデバイスを選択し、実行を開

始します。

iOS Calabash テストのスクリーンショットの取得iOS Calabash テストの一部としてスクリーンショットを取得できます。

iOS Calabash では、スクリーンショットを取得するための定義済みの手順を利用できます。詳細については、GitHub の Calabash iOS リポジトリにある Predefined steps ページの「Screenshots」セクションを参照してください。

また、Ruby (.rb) ファイル内のカスタムステップを定義して screenshot_embed 関数を呼び出すこともできます。この関数では、スクリーンショットを作成して定義したディレクトリに保存します。たとえば、次のコード例では、PNG 形式でスクリーンショットを作成し、/my/custom/path ディレクトリにscreenshot_seconds-since-Epoch のファイル名で保存します。

screenshot_embed(:prefix => "/my/custom/path", :name => "screenshot_#{Time.now.to_i}")

iOS Calabash テストに関するその他の考慮事項Device Farm では特定の Calabash フックを置き換えるため、iOS Calabash テストは Device Farm のデバイス上で実行されますが、Device Farm では iOS Calabash テスト自体は変更されません。

UI Automation for iOS を AWS Device Farm と使用するDevice Farm では UI Automation for iOS. がサポートされています。

トピック• UI Automation とは (p. 106)• iOS UI Automation テストのアップロード (p. 106)• iOS UI Automation テストのスクリーンショットの取得 (p. 107)• iOS UI Automation テストに関するその他の考慮事項 (p. 107)

UI Automation とはお客様が書いたテストスクリプトを使用して iOS アプリでユーザーインターフェイスのテストを自動化するために、自動計測を使用できます。これらのスクリプトはアプリの外部で実行され、UI Automation APIを呼び出してユーザーの操作をシミュレートします。API は、シミュレータまたは接続されたデバイスで実行する際にアプリで実行されるアクションを指定する JavaScript プログラミングインターフェイスです。詳細については、iOS 開発者ライブラリの計測ユーザーガイドの「計測について」を参照してください。

iOS UI Automation テストのアップロードDevice Farm コンソールを使用してテストをアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。

API バージョン 2015-06-23106

https://github.com/calabash/calabash-ios/wiki/02-Predefined-steps

https://developer.apple.com/library/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/index.html


AWS Device Farm 開発者ガイドXCTest

2. プロジェクトのリストで、テストをアップロードするプロジェクトの横にあるオプションを選択します。

Tip

プロジェクトのリストが表示されていない場合は、セカンダリナビゲーションバーの[Projects] で、テストをアップロードするプロジェクトの名前を選択します。プロジェクトを作成するには、「AWS Device Farm でプロジェクトを作成する (p. 20)」の手順に従ってください。



Note


6. [Next step] を選択します。7. [Configure a test] ページで、[UI Automation]、[Upload] の順に選択します。8. 単一のテスト用に .js ファイルを参照して選択します。9. [Next step] を選択後、残りの画面上の指示を完了してテストを実行するデバイスを選択し、実行を開

始します。

iOS UI Automation テストのスクリーンショットの取得iOS UI Automation テストの一部としてスクリーンショットを撮ることができます。

スクリーンショットを取得するには、captureScreenWithName 関数 (例:target.captureScreenWithName(lang + "_home");。lang は現在の言語名。) を呼び出します。

iOS UI Automation テストに関するその他の考慮事項Device Farm は、iOS UI Automation テストの実行フローをモニタリングできるようにログ記録のフックを追加しますが、Device Farm は iOS UI Automation テスト自体を変更することはしません。

XCTest for iOS と AWS Device Farm の使用Device Farm を使用すると、XCTest フレームワークを使用してアプリを実際のデバイスでテストできます。XCTest の詳細については、Xcode でテストするの「テストの基本」を参照してください。

テストを実行するには、テストラン用のパッケージを作成し、これらのパッケージを Device Farm にアップロードします。

トピック• XCTest 実行用のパッケージの作成 (p. 107)• XCTest 実行用のパッケージを Device Farm にアップロードする (p. 108)

XCTest 実行用のパッケージの作成XCTest フレームワークを使用してアプリをテストするには、Device Farm に以下が必要です。

• .ipa ファイルのアプリパッケージ。• .zip ファイルの XCTest パッケージ。

API バージョン 2015-06-23107

https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/03-testing_basics.html

AWS Device Farm 開発者ガイドXCTest

Xcode が生成するビルド出力を使用してこれらのパッケージを作成します。次のステップを実行してパッケージを作成し、Device Farm にアップロードできるようにします。

アプリのビルド出力を生成するには

1. Xcode でアプリプロジェクトを開きます。2. Xcode ツールバーのスキームのドロップダウンメニューで、[Generic iOS Device (汎用 iOS デバイス)]

を送信先として選択します。3. [Product (プロジェクト)] メニューで、[Build For (ビルド用途)] を選択した後、[Testing (テスト)] を選

択します。

アプリパッケージを作成するには

1. Xcode のプロジェクトナビゲーターの [Products (製品)] で、app-project-name.app という名前のファイルのコンテキストメニューを開きます。次に、[Show in Finder (Finder で表示)] を選択します。Debug-iphoneos という名前のフォルダが Finder で開きます。ここに、Xcode によってテストビルド用に生成された出力が含まれています。このフォルダには .app ファイルが含まれています。

2. Finder で、新しいフォルダを作成して Payload という名前を付けます。3. app-project-name.app ファイルをコピーして、Payload フォルダに貼り付けます。4. Payload フォルダのコンテキストメニューを開き、[Compress "Payload" (「Payload」を圧縮)] を選

択します。Payload.zip という名前のファイルが作成されます。5. Payload.zip のファイル名と拡張子を app-project-name.ipa に変更します。

後のステップで、このファイルを Device Farm に提供します。ファイルを見つけやすくするために、デスクトップなど別の場所に移動させても構いません。

6. 必要に応じて、Payload フォルダとその中にある .app ファイルを削除できます。

XCTest パッケージを作成するには

1. Finder を使用し、Debug-iphoneos ディレクトリで app-project-name.app ファイルのコンテキストメニューを開きます。次に、[Show Package Contents (パッケージの内容を表示)] を選択します。

2. パッケージの内容の中で、Plugins フォルダを開きます。このフォルダに app-project-name.xctest という名前のファイルが含まれています。

3. このファイルのコンテキストメニューを開き、[Compress "app-project-name.xctest" (「app-project-name.xctest」を圧縮)] を選択します。app-project-name.xctest.zip という名前のファイルが作成されます。

後のステップで、このファイルを Device Farm に提供します。ファイルを見つけやすくするために、デスクトップなど別の場所に移動させても構いません。

XCTest 実行用のパッケージを Device Farm にアップロードするDevice Farm コンソールを使用してテスト用のパッケージをアップロードします。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトがまだなければ作成します。プロジェクトを作成するステップについては、「AWS

Device Farm でプロジェクトを作成する (p. 20)」を参照してください。

それ以外の場合は、テストを実行するために使用するプロジェクトを選択します。3. [Create a new run (新しい実行の作成)] を選択します。

API バージョン 2015-06-23108


AWS Device Farm 開発者ガイドXCTest UI

4. [Choose your application (アプリケーションを選択)] ページで、[Test a native application on Androidor iOS devices (Android または iOS デバイスでネイティブアプリケーションをテスト)] のオプションを選択します。

5. [Upload] を選択します。6. アプリ用の .ipa ファイルを見つけ、アップロードします。

Note

.ipa パッケージはテスト用にビルドされている必要があります。7. アップロードが完了したら、[Next step (次のステップ)] を選択します。8. [Configure your test (テストを設定)] ページの [Test (テスト)] で、[XCTest] を選択します。次に、

[Upload (アップロード)] を選択します。9. アプリ用の XCTest パッケージが含まれている .zip ファイルを見つけてアップロードします。10. アップロードが完了したら、[Next step (次のステップ)] を選択します。11. プロジェクトの作成プロセスの残りのステップを完了します。テストするデバイスを選択し、デバイ

スの状態を指定します。12. 実行を設定したら、[Create a new run (新しい実行を作成)] ページで、[Confirm and start run (確定し

て実行を開始)] を選択します。

Device Farm によってテストが実行され、結果がコンソールに表示されます。

iOS および AWS Device Farm 用の XCTest UI テストフレームワークの使用Device Farm では、iOS の XCTest UI テストフレームワークをサポートしています。中でも、DeviceFarm では、Objective-C と Swift の両方で記述される XCTest UI テストをサポートしています。

トピック• XCTest UI テストフレームワークとは (p. 109)• iOS XCTest UI テストの準備 (p. 109)• iOS XCTest UI テストのアップロード (p. 109)• iOS XCTest UI テストのスクリーンショットの取得 (p. 110)

XCTest UI テストフレームワークとはXCTest UI フレームワークは Xcode 7 で導入された新しいテストフレームワークです。このフレームワークは、UI テスト機能を備えた XCTest を拡張します。詳細については、iOS 開発者ライブラリの『Xcodeでテストする』セクションの、「ユーザーインターフェイスのテスト」を参照してください。

iOS XCTest UI テストの準備iOS XCTest UI テストランナーバンドルは、適切にフォーマットされた .ipa ファイルに含まれている必要があります。

.ipa ファイルを作成するには、my-project-nameUITest-Runner.app バンドルを空の Payload ディレクトリに配置します。次に、Payload ディレクトリを .zip ファイルにアーカイブし、ファイル拡張子を .ipa に変更します。*UITest-Runner.app バンドルは、テストのためにプロジェクトをビルドするときに Xcode によって生成されます。また、プロジェクトの Products ディレクトリにあります。

iOS XCTest UI テストのアップロードDevice Farm コンソールを使用してテストをアップロードします。

API バージョン 2015-06-23109

https://developer.apple.com/swift/

https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/09-ui_testing.html#//apple_ref/doc/uid/TP40014132-CH13-SW1

AWS Device Farm 開発者ガイドウェブアプリテスト


す。

Tip




Note


6. [Next step] を選択します。7. [Configure a test] ページで、[XCTest UI]、[Upload] の順に選択します。8. iOS XCTest UI テストランナーを含む .ipa ファイルを参照して選択します。9. [Next step] を選択後、残りの画面上の指示を完了してテストを実行するデバイスを選択し、実行を開

始します。

iOS XCTest UI テストのスクリーンショットの取得XCTest UI テストでは、テストのステップごとに自動的にスクリーンショットをキャプチャします。これらのスクリーンショットは、Device Farm テストレポートに表示されます。追加のコードは不要です。

AWS Device Farm でウェブアプリテストを使用する

Device Farm では、ウェブアプリケーションを操作するための次のテストタイプをサポートしています。

• Appium Java TestNG (p. 111)• Appium Java JUnit (p. 116)• Appium Node.js (p. 121)• Appium Python (p. 124)• Appium Ruby (p. 129)

計測および計測対象外デバイスのルールメータリングとは、デバイスの請求を指します。デフォルトでは、Device Farm デバイスが計測され、無料試用期間が経過すると 1 分ごとに課金されます。また、計測対象外のデバイスを購入することもできます。これにより、毎月の定額料金で無制限のテストが可能になります。料金の詳細については、「AWSDevice Farm 料金表」を参照してください。

iOS デバイスと Android デバイスの両方を含むデバイスプールで実行を開始する場合は、計測デバイスと計測対象外デバイスのルールがあります。たとえば、計測されていない Android デバイスが 5 個、計測さ

API バージョン 2015-06-23110


https://aws.amazon.com/device-farm/

https://aws.amazon.com/device-farm/


れていない iOS デバイスが 5 個ある場合、ウェブテスト実行では、計測されていないデバイスが使用されます。

別の例として、計測されていない Android デバイスが 5 個あり、計測されていない iOS デバイスはないとします。ウェブ実行のために Android デバイスのみを選択すると、計測されていないデバイスが使用されます。ウェブ実行のために Android デバイスと iOS デバイスの両方を選択すると、課金方法が計測され、計測されていないデバイスは使用されません。

ウェブアプリケーション向け Appium Java TestNG および AWS Device Farm の使用このセクションでは、ウェブアプリケーションの Appium TestNG テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appiumウェブサイトの「Introduction to Appium」を参照してください。

サンプルテストについては、GitHub の「Device Farm および Appium Java TestNG を使用してウェブアプリケーションをテストする方法」を参照してください。







トピック• ステップ 1: Appium テストパッケージを設定する (p. 111)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 112)• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 113)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 115)• ステップ 5: Android Appium Java TestNG テストのスクリーンショットを取得する (オプショ

ン) (p. 115)

ステップ 1: Appium テストパッケージを設定するテストパッケージを設定するには、次の手順を実行します。ウェブアプリケーションの Appium TestNGテストは .zip ファイルに含まれている必要があります。

API バージョン 2015-06-23111


https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium

https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium












ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• ウェブアプリケーションテストの Appium Java TestNG で Cucumber を使用している場合は、このス

テップを使用して、Cucumber の設定で Maven を設定します。それ以外の場合は、次のステップに進みます。

API バージョン 2015-06-23112


Note





<dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-testng</artifactId> <version>4.0.0</version></dependency>




API バージョン 2015-06-23113








Note



API バージョン 2015-06-23114





3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[ウェブアプリケーション ( )] を選択

します。

6. [Run name (実行名)] で、デフォルト名を受け入れるか、テストランの名前を入力します。7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java TestNG] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:

Appium テストパッケージを設定する (p. 111)」で説明されている形式に従う必要があります。10. 使用している Appium のバージョンを選択します。11. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。詳細について

は、「AWS Device Farm でテストランを作成する (p. 23)」を参照してください。

Note

Device Farm は Android Appium Java TestNG を変更しません。

ステップ 5: Android Appium Java TestNG テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。


API バージョン 2015-06-23115







ウェブアプリケーション向け Appium Java JUnit および AWS Device Farm の使用このセクションでは、ウェブアプリケーションの Appium Java JUnit テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appiumウェブサイトの「Introduction to Appium」を参照してください。







トピック• ステップ 1: Appium テストパッケージを設定する (p. 117)• ステップ 2: Cucumber で実行するようにテストを設定する (オプション) (p. 118)

API バージョン 2015-06-23116




• ステップ 3: 圧縮テストパッケージファイルの作成 (p. 118)• ステップ 4: テストパッケージを Device Farm にアップロードする (p. 120)• ステップ 5: ウェブアプリケーションの Appium Java JUnit テストのスクリーンショットを取得する

(オプション) (p. 120)











API バージョン 2015-06-23117


ステップ 2: Cucumber で実行するようにテストを設定する (オプション)• ウェブアプリケーションテストの Appium Java JUnit で Cucumber を使用している場合は、このス

テップを使用して、Cucumber の設定で Maven を設定します。それ以外の場合は、次のステップに進みます。

Note








<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> <id>zip</id> <formats> <format>zip</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>${project.build.directory}</directory> <outputDirectory>./</outputDirectory> <includes> <include>*.jar</include> </includes> </fileSet> <fileSet> <directory>${project.build.directory}</directory>

API バージョン 2015-06-23118


<outputDirectory>./</outputDirectory> <includes> <include>/dependency-jars/</include> </includes> </fileSet> </fileSets></assembly>







Note


<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration>

API バージョン 2015-06-23119


<source>1.7</source> <target>1.7</target> </configuration></plugin>




3. すでにプロジェクトがある場合は、テストをそのプロジェクトにアップロードできます。4. プロジェクトを開き、[Create a new run (新規ランの作成)] を選択します。5. [Choose your application (アプリケーションの選択)] ページで、[ウェブアプリケーション ( )] を選択

します。

6. [Run name (実行名)] で、デフォルト名を受け入れるか、名前を入力します。7. [Next step] を選択します。8. [Configure a test] ページで、[Appium Java JUnit] を選択し、次に [Upload] を選択します。9. テストが含まれている .zip ファイルを参照して選択します。この .zip ファイルは「ステップ 1:



Note

Device Farm は Android Appium Java JUnit を変更しません。

ステップ 5: ウェブアプリケーションの Appium Java JUnit テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。

API バージョン 2015-06-23120








ウェブアプリケーション用 Appium Node.js およびAWS Device Farm を使用するこのセクションでは、Appium Node.js テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。






トピック• テストをパッケージ化するための前提条件 (p. 122)

API バージョン 2015-06-23121





• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 123)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 123)









Note



command -v nvm



nvm install node


nvm install 11.4.0


node -v



API バージョン 2015-06-23122







2. ローカルの依存関係をインストールするには、このコマンドを実行します。

npm install

このコマンドは、現在のディレクトリ内に node_modules フォルダも作成します。

Note



npm-bundle

この tarball(.tgz) ファイルには、コードと依存関係がすべて含まれています。4. このコマンドを実行して、前のステップで生成した tarball (*.tgz ファイル) を単一の zip アーカイブに

バンドルします。





Tip


4. [Create a new run] ボタンが表示されている場合は、選択します。5. [Choose your application (アプリケーションの選択)] ページで、[ウェブアプリケーション ( )] を選択

します。

API バージョン 2015-06-23123



6. [Run name] に、実行の名前を入力します。Tip






Note

Device Farm ではウェブアプリケーション Appium Node.js テストを変更しません。

ウェブアプリケーション向け Appium Python およびAWS Device Farm の使用このセクションでは、Appium Python テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。

Device Farm サンプルテストについては、GitHub の「Device Farm および Appium Python を使用してウェブアプリケーションをテストする方法」を参照してください。




phases: install:

API バージョン 2015-06-23124



https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python

https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python


commands: # To install a newer version of Appium such as version 1.9.1: - export APPIUM_VERSION=1.9.1 - avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js



トピック• ステップ 1: 圧縮テストパッケージファイルの作成 (p. 125)• ステップ 2: テストパッケージを Device Farm にアップロードする (p. 127)• ステップ 3: ウェブアプリケーションの Appium Python テストのスクリーンショットを取得する (オプ

ション) (p. 128)


Note




Tip

• /usr/lib/pythonx.x/site-packages またはグローバルサイトパッケージディレクトリの場所からパッケージを継承するため、--system-site-packages オプションを使用してPython virtualenv を作成しないでください。これにより、テストで不要な依存関係を仮想環境に含めることになる場合があります。





API バージョン 2015-06-23125







$ find tests/





Device Farm で実行するテストが出力に表示されていることを確認します。6. 次のコマンドを使用して、tests/ フォルダの下にあるすべてのキャッシュファイルを消去できます。





Python 2





Python 3



API バージョン 2015-06-23126




Tip



します。



Tip




Python 2


使用している Appium のバージョンを選択します。API バージョン 2015-06-23

127



カスタムモードを使用している場合



Python 3


phases: install: commands: - export PYTHON_VERSION=3 # ... - export APPIUM_VERSION=1.14.2 - avm $APPIUM_VERSION - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js


Note

Device Farm ではウェブアプリケーション Appium Python テストを変更しません。

ステップ 3: ウェブアプリケーションの Appium Python テストのスクリーンショットを取得する (オプション)テストの一部としてスクリーンショットを取得できます。




API バージョン 2015-06-23128



ウェブアプリケーション用 Appium Ruby および AWSDevice Farm の使用このセクションでは、Appium Ruby テストを設定して、パッケージ化し、Device Farm にアップロードする方法について説明します。Appium は、ネイティブおよびモバイルウェブアプリケーションを自動化するためのオープンソースのツールです。詳細については、Appium ウェブサイトの「Introduction toAppium」を参照してください。













API バージョン 2015-06-23129









Note



command -v rvm


さい。



ruby -v


gem install bundler









bundle install

API バージョン 2015-06-23130


Note










Tip



します。

6. [Run name] に、実行の名前を入力します。API バージョン 2015-06-23

131


AWS Device Farm 開発者ガイド組み込みテスト

Tip






Note

Device Farm ではウェブアプリケーション Appium Ruby テストを変更しません。

AWS Device Farm での組み込みテストの操作Device Farm では、Android デバイスおよび iOS デバイス用に組み込みテストタイプがサポートされています。

組み込みのテストタイプ組み込みテストを使用すると、スクリプトを記述することなくアプリケーションをテストできます。


Device Farm の組み込みエクスプローラーテストの使用Device Farm は、組み込みのエクスプローラーテストタイプを提供します。

組み込みのエクスプローラーテストとは?組み込みのエクスプローラーテストでは、各画面を分析してエンドユーザーであるかのように操作してアプリをクロールします。テストがサインインできるように、調べながらスクリーンショットを取得し、Device Farm に認証情報を入力します。

パラメータ

• Username (オプション).エクスプローラがアプリ内でサインイン画面に遭遇した場合に使用するユーザー名を指定します。ユーザー名が指定されていない場合、Device Farm はユーザー名を挿入しません。

• Password (オプション).エクスプローラがアプリ内でサインイン画面に遭遇した場合に使用するパスワードを指定します。パスワードが指定されていない場合、Device Farm は、パスワードを挿入しません。

API バージョン 2015-06-23132

AWS Device Farm 開発者ガイド組み込み: ファズ (Android および iOS)

組み込みのエクスプローラーテストタイプを使用するDevice Farm コンソールを使用して、組み込みのエクスプローラテストを実行します。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトのリストで、組み込みエクスプローラーテストを実行するプロジェクトの横にあるオプ

ションを選択します。Tip

プロジェクトのリストが表示されない場合は、セカンダリナビゲーションバーの [Projects]で、組み込みのエクスプローラテストを実行するプロジェクト名を選択します。プロジェクトを作成するには、「AWS Device Farm でプロジェクトを作成する (p. 20)」の手順に従ってください。


す。5. 組み込みのエクスプローラーテストを実行するアプリケーションファイルを参照して選択します。6. [Next step] を選択します。7. [Configure a test] ページで、[Built-in: Explorer] を選択します。8. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。

Device Farm 向けの組み込みファズテストの使用Device Farm では、組み込みのファズテストタイプを利用できます。

組み込みのファズテストとは組み込みのファズテストでは、ユーザーインターフェイスのイベントをデバイスにランダムに送信して、その結果をレポートします。

組み込みのファズテストタイプを使用するDevice Farm コンソールを使用して、組み込みのファズテストを実行します。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. プロジェクトの一覧で、組み込みのファズテストを実行するプロジェクトの横にあるオプションを選

択します。Tip

プロジェクトの一覧が表示されない場合は、セカンダリナビゲーションバーの [Projects]で、組み込みのファズテストを実行するプロジェクト名を選択します。プロジェクトを作成するには、「AWS Device Farm でプロジェクトを作成する (p. 20)」の手順に従ってください。


す。5. 組み込みのファズテストを実行するアプリケーションファイルを参照して選択します。6. [Next step] を選択します。7. [Configure a test] ページで、[Built-in: Fuzz] を選択します。8. 以下のいずれかの設定が表示された場合は、デフォルト値をそのまま使用するか、独自の値を指定で

きます。

API バージョン 2015-06-23133



AWS Device Farm 開発者ガイド組み込み: ファズ (Android および iOS)

• イベント数: ファズテストを実行するユーザーインターフェイスのイベントの数を表す 1～10,000の範囲内の数を指定します。

• イベント調整: 次のユーザーインターフェイスのイベントを実行する前にファズテストが待機するミリ秒数を表す 1〜1,000 の範囲内の数を指定します。

• ランダマイザーシード: ファズテストによってユーザーインターフェイスのイベントをランダム化するために使用する数を指定します。後続のファズテストに同じ番号を指定すると、同じイベントシーケンスが保証されます。

9. [Next step] を選択し、残りの手順を完了してデバイスを選択し、実行を開始します。

API バージョン 2015-06-23134

AWS Device Farm 開発者ガイドテストスペック構文

AWS Device Farm のカスタムテスト環境での作業

AWS Device Farm では、デフォルトのスタンダードテスト環境だけでなく、自動テストのカスタム環境を設定することもできます。詳細については、「テスト環境 (p. 14)」を参照してください。

カスタムの自動テスト環境は、YAML 形式のテスト仕様 (テストスペック) ファイルを使用して設定することができます。Device Farm には、サポートされているテストタイプごとにデフォルトのテストスペックが用意されています。デフォルトのテストスペックはそのままに使用するか、必要に応じて編集することができます。テストスペックファイルを編集した場合は、後の実行に備えて保存することができます。


トピック• テストスペック構文 (p. 135)• テストスペックの例 (p. 136)• Environment Variables (p. 138)• 標準テスト環境からカスタムテスト環境へのテストの移行 (p. 140)

テストスペック構文YAML テストスペックファイルの構造を表します。

version: 0.1

phases: install: commands: - command - command pre_test: commands: - command - command test: commands: - command - command post_test: commands: - command - command

artifacts: - location - location

テストスペックには次のものが含まれています。

API バージョン 2015-06-23135


AWS Device Farm 開発者ガイドテストスペックの例

version

Device Farm でサポートされているテストスペックバージョンが反映されます。現在のバージョン番号は 0.1 です。

phases

このセクションには、テストラン中に実行されるコマンドのグループを含みます。

許可されるテストフェーズ名は次のとおりです。install

省略可能。

Device Farm によってサポートされるテスト用フレームワークの依存関係はデフォルトでインストールされています。このフェーズには、追加コマンドが含まれます (インストール時に DeviceFarm で実行するコマンドがある場合)。

pre_test

省略可能。

自動テストラン前に実行されたコマンド (ある場合)。test

省略可能。

自動テストラン中に実行されたコマンド。テストフェーズでいずれかのコマンドが失敗した場合、そのテストは失敗としてマークされます。

post_test

省略可能。

自動テストラン後に実行されたコマンド (ある場合)。artifacts

省略可能。

Device Farm は、カスタムレポートやログファイル、イメージなどのアーティファクトをここの指定された場所から収集します。ワイルドカード文字はアーティファクトの場所の一部としてサポートされていないため、ロケーションごとに有効なパスを指定する必要があります。

これらのテストアーティファクトは、テストランでデバイスごとに表示されます。テストアーティファクトの取得方法については、「カスタムのテスト環境でアーティファクトを使用する (p. 51)」を参照してください。

Important

テストスペックは、有効な YAML ファイルとしてフォーマットされる必要があります。テストスペックのインデントまたはスペースが無効の場合は、テストランが失敗する可能性があります。タブは YAML ファイルでは使用できません。テストスペックが有効な YAML かどうかをテストするには、YAML validator を使用します。詳細については、「YAML のウェブサイト」を参照してください。

テストスペックの例Appium Java TestNG テストランを設定する Device Farm YAML テストスペックの例を表します。

version: 0.1

API バージョン 2015-06-23136

http://yaml.org/spec/1.2/spec.html

AWS Device Farm 開発者ガイドテストスペックの例

# Phases are a collection of commands that get executed on Device Farm.phases: # The install phase includes commands that install dependencies that your tests use. # Default dependencies for testing frameworks supported on Device Farm are already installed. install: commands: # By default, Appium server version used is 1.7.2. # You can switch to an alternate supported version from 1.6.5, 1.7.1, 1.7.2, 1.8.0 or 1.8.1 by using a command like "avm 1.7.1" # OR # To install a newer version of Appium use the following commands: # - export APPIUM_VERSION=1.8.1 # - avm $APPIUM_VERSION # - ln -s /usr/local/avm/versions/$APPIUM_VERSION/node_modules/.bin/appium /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/bin/appium.js

# The pre-test phase includes commands that setup your test environment. pre_test: commands: # Setup environment variables for java - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TESTNG_JAR - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/* - export CLASSPATH=$CLASSPATH:$DEVICEFARM_TEST_PACKAGE_PATH/dependency-jars/* # We recommend starting appium server process in the background using the command below. # Appium server log will go to $DEVICEFARM_LOG_DIR directory. # The environment variables below will be auto-populated during run time. - echo "Start appium server" - >- appium --log-timestamp --device-name $DEVICEFARM_DEVICE_NAME --platform-name $DEVICEFARM_DEVICE_PLATFORM_NAME --app $DEVICEFARM_APP_PATH --udid $DEVICEFARM_DEVICE_UDID --chromedriver-executable $DEVICEFARM_CHROMEDRIVER_EXECUTABLE >> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 &

- >- start_appium_timeout=0; while [ true ]; do if [ $start_appium_timeout -gt 30 ]; then echo "appium server never started in 30 seconds. Exiting"; exit 1; fi; grep -i "Appium REST http interface listener started on 0.0.0.0:4723" $DEVICEFARM_LOG_DIR/appiumlog.txt >> /dev/null 2>&1; if [ $? -eq 0 ]; then echo "Appium REST http interface listener started on 0.0.0.0:4723"; break; else echo "Waiting for appium server to start. Sleeping for 1 second"; sleep 1; start_appium_timeout=$((start_appium_timeout+1)); fi; done;

# The test phase includes commands that start your test suite execution. test: commands: # Your test package is downloaded in $DEVICEFARM_TEST_PACKAGE_PATH so we first change directory to that path. - echo "Navigate to test package directory" - cd $DEVICEFARM_TEST_PACKAGE_PATH

API バージョン 2015-06-23137

AWS Device Farm 開発者ガイドEnvironment Variables

# By default, the following command is used by Device Farm to run your Appium TestNG test. # The goal is to run to your tests jar file with all the dependencies jars in the CLASSPATH. # Alternatively, You may specify your customized command. # Note: For most use cases, the default command works fine. # Please refer "http://testng.org/doc/documentation-main.html#running-testng" for more options on running TestNG tests from the command line. - echo "Start Appium TestNG test" - java -Dappium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output -verbose 10

# To run your tests with testng.xml file, use the following sequence: # Note: you don't have to unzip your test jar unless you have xml file with custom name # 1. Your testng.xml is inside the test jar after packaging step. Unzip it using commands: # - echo "Unzipping TestNG tests jar" # - unzip *-tests.jar # 2. Run your TestSuite by specifying the unzipped testng.xml using commands: # - echo "Start Appium TestNG test" # - java org.testng.TestNG -d $DEVICEFARM_LOG_DIR/test-output testng.xml

# The post test phase includes are commands that are run after your tests are executed. post_test: commands:

# The artifacts phase lets you specify the location where your tests logs, device logs will be stored.# And also let you specify the location of your test logs and artifacts which you want to be collected by Device Farm.# These logs and artifacts will be available through ListArtifacts API in Device Farm.artifacts: # By default, Device Farm will collect your artifacts from following directories - $DEVICEFARM_LOG_DIR

Environment Variables環境変数は、自動テストで使用する値を表します。これらの環境変数は、YAML ファイルやテストコードで使用することができます。カスタムテスト環境では、Device Farm は、ランタイムに環境変数を自動的に入力します。

トピック• 一般的な環境変数 (p. 138)• Appium Java JUnit 環境変数 (p. 140)• Appium Java TestNG 環境変数 (p. 140)• XCUITest 環境変数 (p. 140)

一般的な環境変数Android テストこのセクションでは、Device Farm でサポートされている Android プラットフォームで一般的なカスタム環境変数を示します。

API バージョン 2015-06-23138

AWS Device Farm 開発者ガイド一般的な環境変数

$DEVICEFARM_DEVICE_NAME

テストを実行するデバイスの名前。デバイスの一意のデバイス識別子 (UDID) を表します。$DEVICEFARM_DEVICE_PLATFORM_NAME

デバイスのプラットフォーム名。Android または iOS。$DEVICEFARM_APP_PATH

テストが実行されているホストマシン上のモバイルアプリへのパス。このアプリへのパスは、モバイルアプリでのみ使用できます。

$DEVICEFARM_DEVICE_UDID

自動テストを実行中のモバイルデバイスの一意の識別子。$DEVICEFARM_LOG_DIR

テストラン中に生成されるログファイルへのパス。$DEVICEFARM_SCREENSHOT_PATH

テストラン中にキャプチャされるスクリーンショットへのパス (ある場合)。$DEVICEFARM_CHROMEDRIVER_EXECUTABLE

Chrome ブラウザのバージョン。$DEVICEFARM_TEST_PACKAGE_NAME

テスト対象のパッケージの名前 (com.example.myapp など)。

Note

これは、Android ネイティブの計測テストを使用する場合にのみ使用できます。詳細については、「Android および AWS Device Farm の計器の操作 (p. 79)」を参照してください。

iOS テストこのセクションでは、Device Farm でサポートされている iOS プラットフォームで一般的なカスタム環境変数を示します。

$DEVICEFARM_DEVICE_NAME

テストを実行するデバイスの名前。デバイスの一意のデバイス識別子 (UDID) を表します。$DEVICEFARM_DEVICE_PLATFORM_NAME

デバイスのプラットフォーム名。Android または iOS。$DEVICEFARM_APP_PATH

テストが実行されているホストマシン上のモバイルアプリへのパス。このアプリへのパスは、モバイルアプリでのみ使用できます。

$DEVICEFARM_DEVICE_UDID

自動テストを実行中のモバイルデバイスの一意の識別子。$DEVICEFARM_LOG_DIR

テストラン中に生成されるログファイルへのパス。$DEVICEFARM_SCREENSHOT_PATH

テストラン中にキャプチャされるスクリーンショットへのパス (ある場合)。

API バージョン 2015-06-23139

AWS Device Farm 開発者ガイドAppium Java JUnit 環境変数

Appium Java JUnit 環境変数このセクションでは、カスタムテスト環境の Appium Java JUnit テストで使用される環境変数を示します。

$DEVICEFARM_TESTNG_JAR

TestNG .jar ファイルへのパス。$DEVICEFARM_TEST_PACKAGE_PATH

テストパッケージの解凍された内容へのパス。

Appium Java TestNG 環境変数このセクションでは、カスタムテスト環境の Appium Java TestNG テストで使用される環境変数を示します。

$DEVICEFARM_TESTNG_JAR

TestNG .jar ファイルへのパス。$DEVICEFARM_TEST_PACKAGE_PATH

テストパッケージの解凍された内容へのパス。

XCUITest 環境変数$DEVICEFARM_XCUITESTRUN_FILE

Device Farm の .xctestun ファイルへのパス。アプリとテストパッケージから生成されます。

$DEVICEFARM_DERIVED_DATA_PATH

Device Farm の xcodebuild 出力の予定されたパス。

標準テスト環境からカスタムテスト環境へのテストの移行

カスタム環境でテストを実行するには、テストランで使用される情報がすべて、テストスペック YAMLファイルまたはテストコードに含まれている必要があります。カスタム環境にテストを移行する際は、以下の点に注意してください。

Appium フレームワークカスタムテスト環境では、Device Farm は、Appium フレームワークテストで Appium 機能の挿入または上書きを行うことはありません。テストの Appium 機能は、テストスペック YAML ファイルまたはテストコードで指定する必要があります。

Android 実装Android 実装テストをカスタムテスト環境に移行するために変更を行う必要はありません。

API バージョン 2015-06-23140

AWS Device Farm 開発者ガイド既存の iOS XCUITest テストの移行

iOS XCUITestiOS XCUITest テストをカスタムテスト環境に移行するために変更を行う必要はありません。

API バージョン 2015-06-23141

AWS Device Farm 開発者ガイドセッションの作成

AWS Device Farm でのリモートアクセスの使用

リモートアクセスでは、機能をテストして顧客の問題を再現するために、ウェブブラウザを使用してリアルタイムでデバイスのスワイプ、ジェスチャ、および操作を行うことができます。特定のデバイスを操作するには、そのデバイスとのリモートアクセスセッションを作成します。

Device Farm のセッションは、ウェブブラウザでホストされている実際の物理デバイスとのリアルタイムのやり取りです。セッションは、そのセッションを開始するときに選択した単一のデバイスを表示します。ユーザーは一度に複数のセッションを開始することができますが、同時に操作できるデバイスの総数は、お持ちのデバイススロットの数によって制限されます。デバイススロットは、デバイスファミリー(例: Android、iOS デバイス) に基づいて購入することができます。詳細については、「Device Farm 料金表」を参照してください。

Device Farm では現在、リモートアクセステスト用のデバイスのサブセットを提供しています。デバイスプールには随時新しいデバイスが追加されます。

Device Farm は各リモートアクセスセッションのビデオをキャプチャし、セッション中にアクティビティのログを生成します。これらの結果には、セッション中に提供するすべての情報が含まれます。

Note

セキュリティ上の理由から、リモートアクセスセッション中に、アカウント番号、個人用ログイン情報、その他の詳細などの機密情報を提供または入力しないことをお勧めします。

トピック• AWS Device Farm でリモートアクセスセッションを作成する (p. 142)• AWS Device Farm でリモートアクセスセッションを使用する (p. 143)• AWS Device Farm でリモートアクセスセッションの結果を取得する (p. 144)

AWS Device Farm でリモートアクセスセッションを作成する

リモートアクセスセッションの詳細については、「セッション (p. 18)」を参照してください。

• 前提条件 (p. 142)• テストランの作成 (コンソール) (p. 143)• 次のステップ (p. 143)

前提条件• Device Farm でプロジェクトを作成します。「AWS Device Farm でプロジェクトを作成する (p. 20)」の

指示に従って、このページに戻ります。

API バージョン 2015-06-23142



AWS Device Farm 開発者ガイドDevice Farm コンソールを使用してセッションを作成する

Device Farm コンソールを使用してセッションを作成する1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. AWS Device Farm コンソールホームページが表示されたら [Get started (使用開始)] を選択します。3. [Projects] からプロジェクトを選択するか、[Create a new project] を選択します。4. [Remote access (リモートアクセス)] タブで、[Start a new session (新しいセッションの開始)] を選択

します。5. セッションのデバイスを選択します。使用可能なデバイスのリストから選択、またはリストの上部に

あるフィールドを使用してデバイスを検索します。次の方法で検索できます。

• 名前• プラットフォーム• オペレーティングシステム• フォームファクタ

6. [Session name (セッション名)] にセッションの名前を入力します。7. [Confirm and start session] を選択します。

次のステップリクエストされたデバイスが利用可能になった時点 (通常は数分以内) で、Device Farm はセッションを開始します。セッションが開始するまで、[Device requested] ダイアログボックスが表示されます。セッションのリクエストをキャンセルするには、[Cancel request] を選択します。

セッションが開始された後に、セッションを停止せずにブラウザまたはブラウザのタブを閉じる場合、またはブラウザとインターネット間の接続が失われた場合、セッションは 5 分間アクティブな状態が維持されます。その後、Device Farm はセッションを終了します。アカウントにはアイドル時間に対しても課金されます。

セッションが開始したら、ウェブブラウザでデバイスとやり取りすることができます。

AWS Device Farm でリモートアクセスセッションを使用する

リモートアクセスセッションを通じた Android および iOS のアプリのインタラクティブなテストの実行については、「セッション (p. 18)」を参照してください。

• 前提条件 (p. 143)• Device Farm コンソールでのセッションの使用 (p. 144)• 次のステップ (p. 144)• ヒントとコツ (p. 144)

前提条件• セッションを作成します。「セッションの作成 (p. 142)」の指示に従って、このページに戻ります。

API バージョン 2015-06-23143


AWS Device Farm 開発者ガイドDevice Farm コンソールでのセッションの使用

Device Farm コンソールでのセッションの使用リモートアクセスセッションをリクエストしたデバイスが利用可能になるとすぐに、コンソールにデバイスの画面が表示されます。セッションの最大長は 150 分です。セッションの残り時間は、コンソールの右側にあるメニューバーの下に表示されます。

アプリケーションのインストールセッションデバイスにアプリケーションをインストールするには、[Install applications (アプリケーションのインストール)] で [Upload (アップロード)] を選択し、インストールする .apk ファイル (Android) または .ipa ファイル (iOS) を選択します。リモートアクセスセッションで実行するアプリケーションは、テスト計測またはプロビジョニングを必要としません。

Note

アプリのインストールが完了しても、AWS Device Farm に確認は表示されません。アプリの使用準備ができたかどうか確認するために、アプリのアイコンを操作してみてください。アプリをアップロードするときに、アプリが利用可能になるまでに遅延が発生することもあります。システムトレイを確認し、アプリケーションが利用可能かどうか調べます。

デバイスの制御実際の物理デバイスと同じように、コンソールに表示されるデバイスとやり取りするには、マウスまたは同等のデバイスのタッチ、およびデバイスの画面上のキーボードを使用します。Android デバイスの場合は、Android デバイスの [ホーム] または [戻る] ボタンと同じように機能するボタンが [ビューコントロール] にあります。iOS デバイスの場合は、iOS デバイスのホームボタンと同じように機能する [ホーム] ボタンがあります。[Recent apps] を選択して、デバイスで実行されているアプリケーションを切り替えることもできます。

縦向きと横向きモードの切り替え使用しているデバイスの縦向き (垂直) と横向き (水平) モードを切り替えることもできます。

次のステップDevice Farm は、手動で停止するかまたは 150 分間の時間制限に達するまでセッションを続行します。セッションを終了するには、[Stop session (セッションの中止)] ボタンを選択します。セッションが停止すると、キャプチャされたビデオおよび生成されたログにアクセスできます。詳細については、「セッションの結果の取得 (p. 144)」を参照してください。

ヒントとコツ一部の AWS リージョンでは、リモートアクセスセッションでパフォーマンスの問題が発生する場合があります。この原因のひとつは、一部のリージョンにおけるレイテンシーです。パフォーマンスの問題が発生した場合は、リモートアクセスセッションが追いつくようアプリを再度操作する前に機会を与えます。

AWS Device Farm でリモートアクセスセッションの結果を取得する

セッションの詳細に関しては、「セッション (p. 18)」を参照してください。

• 前提条件 (p. 145)

API バージョン 2015-06-23144


• セッションの詳細の表示 (p. 145)• セッションビデオまたはログのダウンロード (p. 145)

前提条件• セッションを完了します。「AWS Device Farm でリモートアクセスセッションを使用する (p. 143)」

の指示に従って、このページに戻ります。

セッションの詳細の表示リモートアクセスセッションが終了すると、Device Farm コンソールには、セッション中に行われたアクティビティの詳細を含むテーブルが表示されます。詳細については、「ログ情報の分析 (p. 47)」を参照してください。

後でセッションの詳細に戻るには:

1. [Project (プロジェクト)] ドロップダウンリストから、確認するプロジェクトを選択します。2. リストから確認するセッションを選択します。または、[Runs & sessions] ドロップダウンリストよ

り、[View all sessions] を選択後、該当するセッションを選択します。

セッションビデオまたはログのダウンロードリモートアクセスセッションが終了すると、Device Farm コンソールを使用して、セッションのビデオキャプチャとアクティビティログにアクセスすることができます。セッション結果で、セッションビデオとログへのリンクのリストを表示するには、[Files (ファイル)] タブを選択します。これらのファイルは、ブラウザで表示したり、ローカルに保存することができます。

API バージョン 2015-06-23145

AWS Device Farm 開発者ガイドプライベートデバイスの管理

AWS Device Farm でのプライベートデバイスの使用

プライベートデバイスとは、Amazon データセンターで AWS Device Farm がユーザーに代わってデプロイする物理モバイルデバイスです。このデバイスは、お使いの AWS アカウント専用です。

Note

現在、プライベートデバイスは AWS 米国西部 (オレゴン) リージョン (us-west-2) リージョンでのみ使用できます。1 つ以上のプライベートデバイスのフリートを使用する予定がある場合は、お問い合わせください。Device Farm チームは、お客様と協力し、AWS アカウントの 1 つ以上のプライベートデバイスのフリートを設定し、デプロイする必要があります。

プライベートデバイスのフリートがある場合は、リモートアクセスセッションを作成し、プライベートデバイスでテストランをスケジュールすることができます。また、インスタンスプロファイルを作成して、リモートアクセスセッションまたはテストランのプライベートデバイスの動作を制御することもできます。詳細については、「AWS Device Farm でのプライベートデバイスの管理 (p. 146)」を参照してください。

また、Amazon Virtual Private Cloud エンドポイントサービスを作成し、会社がアクセスできるプライベートアプリをテストすることもできますが、これらのアプリはインターネット経由で到達することができません。たとえば、モバイルデバイスでテストする、VPC 内で実行中のウェブアプリケーションなどです。詳細については、「AWS Device Farm で Amazon Virtual Private Cloud エンドポイントサービスを使用する (p. 155)」を参照してください。

トピック• AWS Device Farm でのプライベートデバイスの管理 (p. 146)• AWS Device Farm でのプライベートデバイスにおけるアプリ再署名のスキップ (p. 152)• AWS Device Farm で Amazon Virtual Private Cloud エンドポイントサービスを使用する (p. 155)• リージョン間での Amazon Virtual Private Cloud の操作 (p. 158)

AWS Device Farm でのプライベートデバイスの管理

プライベートデバイスとは、Amazon データセンターで AWS Device Farm がユーザーに代わってデプロイする物理モバイルデバイスです。このデバイスは、お使いの AWS アカウント専用です。

Note

現在、プライベートデバイスは AWS 米国西部 (オレゴン) リージョン (us-west-2) リージョンでのみ使用できます。

1 つ以上のプライベートデバイスを含むフリートを設定できます。これらのデバイスは、お客様の AWSアカウント専用です。デバイスを設定したら、それらのデバイスの 1 つ以上のインスタンスプロファイルをオプションで作成できます。インスタンスプロファイルは、テストランを自動化し、同じ設定をデバイスインスタンスに一貫して適用するのに役立ちます。

このトピックでは、インスタンスプロファイルを作成し、その他の一般的なデバイス管理タスクを実行する方法について説明します。

トピック• インスタンスプロファイルを作成する (p. 147)

API バージョン 2015-06-23146

mailto:[email protected]

AWS Device Farm 開発者ガイドインスタンスプロファイルを作成する

• プライベートデバイスインスタンスの管理 (p. 148)• テストランの作成またはリモートアクセスセッションの開始 (p. 149)• プライベートデバイスプールを作成する (p. 149)• 次のステップ (p. 151)

インスタンスプロファイルを作成するテストラン中またはリモートアクセスセッション中にプライベートデバイスの動作を制御するには、Device Farm のインスタンスプロファイルを作成または変更します。プライベートデバイスの使用を開始するために、インスタンスプロファイルは必要ありません。

1. Device Farm コンソール (https://console.aws.amazon.com/devicefarm/) を開きます。2. [Device Farm settings (デバイスファーム設定)] を選択します。3. [インスタンスプロファイル] を選択します。4. [Create a new instance profile (新しいインスタンスプロファイルの作成)] を選択します。5. インスタンスプロファイルの名前を入力します。

6. (オプション) インスタンスプロファイルの説明を入力します。7. (オプション) 各テストランまたはセッションの終了後に Device Farm がデバイスに対して実行するア

クションを指定するには、次の設定を変更します。

• 使用後に再起動 – デバイスを再起動するには、このチェックボックスをオンにします。デフォルトでは、このチェックボックスはオフ (false) になっています。

• パッケージのクリーンアップ – デバイスにインストール済みのアプリパッケージをすべて削除するには、このチェックボックスをオンにします。デフォルトでは、このチェックボックスはオフ(false) になっています。デバイスにインストール済みのアプリパッケージをすべて保持するには、このチェックボックスをオフにします。

• クリーンアップからパッケージを除外 – 選択したアプリパッケージのみをデバイスに保存するには、[パッケージのクリーンアップ] チェックボックスをオンにして、[新規追加] を選択します。パッケージ名に、デバイスで維持するアプリパッケージの完全修飾名 (例: com.test.example)

API バージョン 2015-06-23147

https://console.aws.amazon.com/devicefarm/

AWS Device Farm 開発者ガイドプライベートデバイスインスタンスの管理

を入力します。さらに多くのアプリケージをデバイスに維持するには、[新規追加] を選択して、各パッケージの完全修飾名を入力します。

プライベートデバイスインスタンスの管理フリートにすでに 1 つ以上のプライベートデバイスがある場合は、各デバイスインスタンスに関する情報を表示したり、特定の設定を管理したりできます。追加のプライベートデバイスインスタンスをリクエストすることもできます。

1. Device Farm コンソール (https://console.aws.amazon.com/devicefarm/) を開きます。2. [Device Farm settings (デバイスファーム設定)] を選択します。3. [デバイスインスタンス] を選択します。[デバイスインスタンス] タブには、フリートにあるプライ

ベートデバイスのテーブルが表示されます。テーブルをすばやく検索またはフィルタリングするには、列の上のフィールドに検索語を入力します。

4. (オプション) 新しいプライベートデバイスインスタンスをリクエストするには、[新しいデバイスインスタンスをリクエスト] を選択するか、お問い合わせください。プライベートデバイスでは、DeviceFarm チームのサポートを受けながら、追加セットアップを行う必要があります。

5. デバイスインスタンスのテーブルで、情報を表示または管理するインスタンスを選択します。

API バージョン 2015-06-23148



AWS Device Farm 開発者ガイドテストランまたはリモートアクセスセッションの作成

6. (オプション) [プロファイル] で、デバイスインスタンスにアタッチするインスタンスプロファイルを選択します。たとえば、特定のアプリパッケージを常にクリーンアップタスクから除外する場合に便利です。

7. (オプション) [ラベル] で、[新規追加] を選択して、ラベルをデバイスインスタンスに追加します。ラベルを使用すると、デバイスを分類して、特定のデバイスを簡単に見つけることができます。

8. [Save device instance (デバイスインスタンスの保存)] を選択します。

テストランの作成またはリモートアクセスセッションの開始プライベートデバイスフリートを設定したら、テストランを作成したり、フリート内の 1 つ以上のプライベートデバイスを使用してリモートアクセスセッションを開始したりできます。

1. Device Farm コンソール (https://console.aws.amazon.com/devicefarm/) を開きます。2. [新しいプロジェクトの作成] を選択するか、既存のプロジェクトを開きます。新しいプロジェクトを

作成する場合は、プロジェクトの名前を入力し、[プロジェクトの作成] を選択します。3. 以下のいずれかの操作を行います。

• テストランを作成するには、[自動テスト] を選択後、[Create a new run (新しいランの作成)] を選択します。ウィザードで、ランを作成するステップに移動します。[デバイスの選択] ステップでは、既存のデバイスプールを編集するか、Device Farm チームが設定し、AWS アカウントに関連付けられているプライベートデバイスのみ含まれる新しいデバイスプールを作成します。詳細については、the section called “プライベートデバイスプールの作成” (p. 149) を参照してください。

• リモートアクセスセッションを開始するには、[リモートアクセス] を選択し、[Start a new session(新しいセッションの開始)] を選択します。[デバイスの選択] ページで、[プライベートデバイスインスタンスのみ] を選択して、Device Farm チームが設定し、AWS アカウントに関連付けられているプライベートデバイスのみ含まれるようにリストを制限します。次に、アクセスするデバイスを選択し、リモートアクセスセッションの名前を入力して、[確認してセッションを開始] を選択します。

プライベートデバイスプールを作成するテストランを作成するときに、テストラン用のデバイスプールを作成し、そのプールにプライベートデバイスのみが含まれるようにします。

API バージョン 2015-06-23149


AWS Device Farm 開発者ガイドプライベートデバイスプールの作成

1. Device Farm コンソール (https://console.aws.amazon.com/devicefarm/) を開きます。2. [新しいプロジェクトの作成] を選択するか、既存のプロジェクトを開きます。新しいプロジェクトを

作成する場合は、プロジェクトの名前を入力し、[プロジェクトの作成] を選択します。3. [自動テスト] を選択後、[新しいランの作成] を選択します。ウィザードの指示に従ってアプリケー

ションを選択し、実行するテストを設定します。4. [デバイスの選択] ステップで、[新しいデバイスプールの作成] を選択し、デバイスプールのオプショ

ンの説明を入力します。5. [デバイスの選択] の横にある [プライベートデバイスインスタンスのみ] を選択して、デバイスのリス

トを、Device Farm チームが設定し、お客様の AWS アカウントに関連付けられているそのようなプライベートデバイスのみに制限します。

6. テストランに含む各デバイスを選択します。7. (オプション) 新しいデバイスが使用可能になると動的に変化するデバイスプールを作成するには、

[ルールの追加] を選択してから、要件に応じて [フィールド]、[演算子]、および [オペランド] の値を設定します。

API バージョン 2015-06-23150


AWS Device Farm 開発者ガイド次のステップ

Device Farm により、ルール条件が true であるデバイスインスタンスがすべて選択されます。8. [Save device pool (デバイスプールの保存)] を選択します。

次のステッププライベートデバイスを設定したら、次の方法でプライベートデバイスを管理することもできます。

• プライベートデバイスにおけるアプリ再署名のスキップ (p. 152)• Device Farm で Amazon Virtual Private Cloud エンドポイントサービスを使用する (p. 155)

インスタンスプロファイルを削除するには、Device Farm コンソールで [アカウント設定] または [プロジェクト設定] ページを使用します。

API バージョン 2015-06-23151

AWS Device Farm 開発者ガイドアプリ再署名のスキップ

AWS Device Farm でのプライベートデバイスにおけるアプリ再署名のスキップ

プライベートデバイスを使用する場合は、AWS Device Farm がアプリに再署名するステップをスキップできます。これは、Device Farm で、Android および iOS プラットフォームのアプリに常に再署名するパブリックデバイスとは異なります。

アプリの再署名は、リモートアクセスセッションまたはテストランを作成する際にスキップすることができます。これは、Device Farm によってアプリに再署名されると破壊される機能がアプリにある場合に役立ちます。たとえば、プッシュ通知は再署名後に動作しない場合があります。アプリをテストするときにDevice Farm によって行われる変更の詳細については、「AWS Device Farm のよくある質問」を参照してください。

テストランのアプリの再署名をスキップするには、テストラン作成時に [設定] ページで [アプリ再署名のスキップ] を選択します。

API バージョン 2015-06-23152

https://aws.amazon.com/device-farm/faq/

AWS Device Farm 開発者ガイドアプリ再署名のスキップ

Note

XCTest フレームワークを使用している場合、[Skip app re-signing (アプリ再署名のスキップ)]オプションは選択できません。詳細については、「XCTest for iOS と AWS Device Farm の使用 (p. 107)」を参照してください。

アプリの署名設定を設定するための追加の手順は、プライベートの Android デバイスと iOS デバイスのどちらを使用しているかによって異なります。

API バージョン 2015-06-23153

AWS Device Farm 開発者ガイドAndroid デバイスでのアプリ再署名のスキップ

Android デバイスでのアプリ再署名のスキッププライベート Android デバイスでアプリをテストする場合は、テストランまたはリモートアクセスセッションを作成するときに、[Skip app re-signing (アプリ再署名のスキップ)] を選択します。必要な設定は他にありません。

iOS デバイスでのアプリ再署名のスキップApple では、デバイスにロードする前に、テスト用にアプリに署名する必要があります。iOS デバイスでは、アプリの署名には 2 つのオプションがあります。

• 社内 (エンタープライズ) 開発者プロファイルを使用している場合は、次のセクション (the section called“リモートアクセスセッションを作成してアプリを信頼する” (p. 154)) にお進みください。

• アドホックの iOS アプリ開発プロファイルを使用している場合は、まず Apple 開発者アカウントを使用してデバイスを登録してから、プロビジョニングファイルをアップデートしてプライベートデバイスを含めます。次に、更新したプロビジョニングプロファイルを使用してアプリに再署名する必要があります。その後、Device Farm で再署名したアプリを実行することができます。

アドホック/iOS アプリ開発プロビジョニングプロファイルでデバイスを登録するには

1. Apple 開発者アカウントにサインインします。2. コンソールの [Certificates, IDs, and Profiles] セクションに移動します。3. [Devices] に移動します。4. デバイスを Apple 開発者アカウントで登録します。デバイスの名前と UDID を取得するには、Device

Farm コンソールを開いて [プロジェクト設定] ページの [デバイスインスタンス] タブに移動するか、Device Farm API の ListDeviceInstances オペレーションを使用します。

5. プロビジョニングプロファイルに移動して、[Edit (編集)] を選択します。6. リストからデバイスを選択します。7. Xcode で、更新されたプロビジョニングプロファイルを取得し、アプリに再署名します。

必要な設定は他にありません。これで、リモートアクセスセッションまたはテストランを作成し、[Skipapp re-signing (アプリ再署名のスキップ)] を選択できます。

リモートアクセスセッションを作成して iOS アプリを信頼する社内 (エンタープライズ) 開発者プロビジョニングプロファイルを使用している場合、1 回限りの手順を実行して、各プライベートデバイスで社内アプリ開発者の証明書を信頼する必要があります。

これを行うには、テストするアプリをプライベートデバイスにインストールするか、テストするアプリと同じ証明書で署名された「ダミー」アプリをインストールできます。同じ証明書で署名されたダミーアプリをインストールするには利点があります。設定プロファイルまたはエンタープライズアプリ開発者を信頼後に「ダミー」アプリをインストールする利点は、その開発者のすべてのアプリは、その開発者のすべてのアプリを削除するまで、プライベートデバイス上でそれらが信頼されることです。したがって、テストする新しいバージョンのアプリをアップロードするときに、再びアプリケーション開発者を信頼する必要はありません。これは、テストの自動化を実行し、アプリをテストするたびにリモートアクセスセッションを作成したくない場合に特に便利です。

リモートアクセスセッションを開始する前に、「インスタンスプロファイルを作成する (p. 147)」の手順に従って、Device Farm でインスタンスプロファイルを作成または変更します。インスタンスプロファイルで、テストアプリまたはダミーアプリのバンドル ID を [Exclude Packages from Cleanup (クリーンアップからパッケージを除外)] 設定に追加します。追加したら、このインスタンスプロファイルをプライベー

API バージョン 2015-06-23154

AWS Device Farm 開発者ガイドVPC エンドポイントサービスを使用する

トデバイスインスタンスにアタッチして、新しいテストランを開始する前に、Device Farm によってデバイスからこのアプリが削除されないようにします。これにより、開発者の証明書は信頼されたままとなります。

ダミーアプリはリモートアクセスセッションを使用してデバイスにアップロードできます。その結果、アプリを起動し、開発者を信頼できます。

1. 「セッションの作成 (p. 142)」の手順に従って、作成したプライベートデバイスインスタンスプロファイルを使用するリモートアクセスセッションを作成します。セッションを作成するときは、必ず[Skip app re-signing (アプリ再署名のスキップ)] を選択します。

Important

プライベートデバイスのみを含むようにデバイスのリストをフィルタリングするには、正しいインスタンスプロファイルでプライベートデバイスを使用されるように [プライベートデバイスインスタンスのみ] を選択します。

このインスタンスにアタッチされているインスタンスプロファイルのダミーアプリケーションまたはテスト対象のアプリケーションも、[Exclude Packages from Cleanup (クリーンアップからパッケージを除外)] 設定に追加してください。

2. リモートセッションが開始されたら、[アップロード] を選択し、社内プロビジョニングプロファイルを使用するアプリケーションをインストールします。

3. アップロードしたアプリを起動します。4. 開発者の証明書を信頼する手順に従います。

その開発者のすべてのアプリを削除するまで、この設定プロファイルまたはエンタープライズアプリ開発者のアプリはすべて、このプライベートデバイス上で信頼されるようになりました。

AWS Device Farm で Amazon Virtual Private Cloudエンドポイントサービスを使用する

Amazon Virtual Private Cloud (Amazon VPC) を使用して、AWS 米国西部 (オレゴン) リージョン (us-west-2) でプライベートウェブアプリケーションをホストする場合は、VPC と AWS Device Farm との間にプライベート接続を確立できます。この接続を使用すると、Device Farm を使用して、パブリックインターネットを介して公開することなく、プライベートウェブアプリケーションをテストすることができます。AWS アカウントがプライベートデバイスでこの機能を使用するには、お問い合わせください。

Amazon VPC は、お客様の定義する仮想ネットワークで AWS リソースを起動するために使用できるAWS のサービスです。VPC を使用すると、IP アドレス範囲、サブネット、ルートテーブル、ネットワー

API バージョン 2015-06-23155


AWS Device Farm 開発者ガイド開始する前に

クゲートウェイなどのネットワーク設定を制御できます。VPC のリソースを Device Farm に接続するには、Amazon VPC コンソールを使用して、VPC エンドポイントサービスを作成します。このエンドポイントサービスでは、Device Farm VPC エンドポイント経由で VPC のリソースを Device Farm に作成することができます。このエンドポイントサービスを使用すると、インターネットゲートウェイやネットワークアドレス変換 (NAT) インスタンス、VPN 接続を必要とせずに、信頼性の高いスケーラブルな方法で VPCを Device Farm に接続できるようになります。詳細については、Amazon VPC ユーザーガイドの「VPCエンドポイントサービス」を参照してください。

Important

Device Farm VPC エンドポイント機能を使用すると、AWS PrivateLink 接続を使用して、VPC 内のプライベートの内部サービスを Device Farm パブリック VPC にセキュアに接続できます。接続は安全でプライベートですが、そのセキュリティはお客様の AWS 認証情報の保護によって異なります。AWS 認証情報が侵害された場合、攻撃者によって、お客様のサービスデータにアクセスされたり、それを外部に公開されたりする恐れがあります。

Amazon VPC の VPC エンドポイント (VPCE) を作成したら、Device Farm コンソールを使用して、Device Farm に VPCE 設定を作成することができます。このトピックでは、Amazon VPC 接続を作成し、Device Farm に VPCE 設定を作成する方法について説明します。

開始する前に以下の情報は、次の各アベイラビリティーゾーンにサブネットを持つ、AWS 米国西部 (オレゴン) リージョンの Amazon VPC のユーザーを対象としています: us-west-2 a、us-west-2 b、us-west-2 c

Device Farm には、VPC エンドポイントと一緒に使用できる追加要件があります。Device Farm を使用するために VPC エンドポイントサービスを作成して設定する場合は、必ず次の要件を満たすオプションを選択してください。

• サービスのアベイラビリティーゾーンに、us-west-2a、us-west-2b、および us-west-2c を含める。VPCエンドポイントサービスのアベイラビリティーゾーンは、エンドポイントサービスに関連付けられているネットワークロードバランサーによって決まります。VPC エンドポイントサービスにこれら 3 つのアベイラビリティーゾーンがすべて表示されない場合は、これら 3 つのゾーンを有効にするようにネットワークロードバランサーを再作成してから、ネットワークロードバランサーをエンドポイントサービスに再度関連付ける必要があります。

• エンドポイントサービスのホワイトリストに登録されたプリンシパルには、Device Farm VPC エンドポイントの Amazon リソースネーム (サービス ARN) を含める必要があります。エンドポイントサービスを作成したら、Device Farm VPC エンドポイントのサービス ARN をホワイトリストに追加して、VPCエンドポイントサービスにアクセスするためのアクセス許可を Device Farm に付与します。DeviceFarm VPC エンドポイントサービス ARN を取得するには、お問い合わせください。

また、[エンドポイントの承諾が必要] 設定が有効になっている場合は、Device Farm よりエンドポイントサービスに送信される各接続リクエストを手動で承認する必要があります。この設定は、VPC エンドポイントサービスの作成時に無効にすることができます。また、既存のエンドポイントサービス用にこの設定を変更することもできます。この設定を変更するには、Amazon VPC コンソールでエンドポイントサービスを選択し、[アクション] を選択後、[エンドポイント承諾設定の変更] を選択します。

次のセクションでは、これらの要件を満たす Amazon VPC エンドポイントサービスを作成する方法について説明します。

ステップ 1: Amazon VPC エンドポイントサービスを作成するVPC と Device Farm の間でプライベート接続を確立するには、まず最初のステップとして、Amazon VPCコンソールを使用して、エンドポイントサービスを VPC に作成します。

API バージョン 2015-06-23156

https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html

https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html


AWS Device Farm 開発者ガイドステップ 2: VPC エンドポイント設定を作成する

1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。2. [リージョン別のリソース] で、[エンドポイントのサービス] を選択します。3. [エンドポイントサービスの作成] を選択します。4. エンドポイントサービスで使用する Network Load Balancer がすでにある場合は、リストから選択し

て、ステップ 11 に進みます。5. [Network Load Balancerの関連付け] の横にある [新規Network Load Balancerを作成] を選択します。6. [ロードバランサーの作成]、[Network Load Balancer] の順に選択します。7. Network Load Balancer の名前と設定を入力します。[アベイラビリティーゾーン] で、us-

west-2a、us-west-2b、us-west-2c のアベイラビリティーゾーンを有効にします。8. 次の指示に従って、Network Load Balancer を設定します。9. ステップ 1～3 を繰り返して、新しい Network Load Balancer を使用するエンドポイントサービスを作

成するためのプロセスを再開します。10. エンドポイントサービス用に作成した Network Load Balancer を選択します。11. [含まれるアベイラビリティーゾーン] に、us-west-2a、us-west-2b、および us-west-2c がリス

トに表示されていることを確認します。12. エンドポイントサービスに送信される各接続リクエストを手動で承認または拒否しない場合は、[エン

ドポイントの承諾が必要] のチェックボックスをオフにします。このチェックボックスをオフにすると、送信される各接続リクエストはエンドポイントサービスで自動的に承認されます。

13. [Create service] を選択します。14. [Close] を選択します。15. エンドポイントサービスのリストで、作成したエンドポイントサービスを選択します。16. [ホワイトリストに登録されたプリンシパル] を選択します。17. エンドポイントサービスのホワイトリストに追加する Device Farm VPC エンドポイントの Amazon

リソース名 (サービス ARN) を取得してから、そのサービス ARN をサービスのホワイトリストに追加する場合は、お問い合わせください。

18. エンドポイントサービスの [詳細] で、サービスの名前 (サービス名) を書き留めます。この名前は、次のステップで VPC エンドポイント設定を作成する際に必要になります。

VPC エンドポイントサービスで Device Farm を使用できるようになりました。

ステップ 2: Device Farm で VPC エンドポイント設定を作成するAmazon VPC にエンドポイントサービスを作成したら、Amazon VPC エンドポイント (VPE) 設定をDevice Farm に作成することができます。

1. https://console.aws.amazon.com/devicefarm で Device Farm コンソールにサインインします。2. ホームページで、[Device Farm 設定] を選択します。3. [VPCE 設定] を選択します。4. [VPCE 設定の作成] を選択します。5. VPCE 設定の名前を入力します。6. Amazon VPC コンソールで書き留めた Amazon VPC エンドポイントサービス (サービス名) の名前を

入力します。名前は com.amazonaws.vpce.us-west-2.vpce-svc-id のようになります。7. テストするアプリのサービス DNS 名 (例: devicefarm.com) を入力します。サービス DNS 名の前に

http または https を指定しないでください。

ドメイン名は、パブリックインターネットからはアクセスできません。また、VPC エンドポイントサービスにマッピングされる新しいドメイン名が Amazon Route 53 によって生成され、Device Farmセッションでお客様専用として使用することができます。

API バージョン 2015-06-23157

https://console.aws.amazon.com/vpc/



AWS Device Farm 開発者ガイドステップ 3: テストランを作成する

8. [VPCE 設定の保存] を選択します。

ステップ 3: テストランを作成するVPCE 設定を保存したら、この設定を使用してテストランまたはリモートアクセスセッションを作成できます。詳細については、「テストランの作成 (p. 23)」または「リモートアクセスセッションの作成 (p. 142)」を参照してください。

リージョン間での Amazon Virtual Private Cloud の操作

このトピックでは、他の AWS リージョンの Amazon Virtual Private Cloud (Amazon VPC) エンドポイントにアクセスする方法について説明します。AWS Device Farm と VPC エンドポイントが同じ AWS リージョンに存在する場合は、the section called “VPC エンドポイントサービスを使用する” (p. 155) を参照してください。

2 つの VPC を別の AWS リージョンに接続することはできますが、重複しない個別の CIDR ブロックがある場合に限ります。これにより、プライベート IP アドレスがすべて一意であることが保証され、VPC 内のすべてのリソースが、任意の形式のネットワークアドレス変換を必要とせずに相互に接続できるようになります。CIDR 表記の詳細については、「RFC 4632」を参照してください。

このトピックには、Device Farm が AWS米国西部 (オレゴン) リージョン (us-west-2) に存在し、VPC-1とも呼ばれるリージョン間のシナリオの例を含みます。この例では、2 番目の VPC は別の AWS リージョンに存在しており、VPC-2 とします。

Device Farm VPC のリージョン間の例

VPC コンポーネント VPC-1 VPC-2

CIDR 10.0.0.0/16 172.16.0.0/16

パブリックサブネット 10.0.0.0/24 172.16.0.0/24

プライベートサブネット 10.0.1.0/24 172.16.1.0/24

VPN インスタンスのプライベート IP アドレス

10.0.0.5 172.16.0.5

API バージョン 2015-06-23158

https://tools.ietf.org/html/rfc4632


VPC コンポーネント VPC-1 VPC-2

VPN インスタンスの Elastic IPアドレス

EIP-1 EIP-2

次の図は、この例のコンポーネントと、それらのコンポーネント間の相互作用を示しています。

トピック• 前提条件 (p. 159)• ステップ 1: Device Farm を同じリージョンの VPC に接続する (p. 159)• ステップ 2: Device Farm リージョンに OpenVPN サーバーをセットアップする (VPC-1) (p. 159)• ステップ 3: 2 つ目のリージョンに OpenVPN サーバーをセットアップする (VPC-2) (p. 161)• ステップ 4: VPC-1 を設定する (p. 161)• ステップ 5: VPC-2 を設定する (p. 162)• ステップ 6: テストランを作成する (p. 163)

前提条件この例では、以下が必要です。

• パブリックサブネットとプライベートサブネットに設定されている 2 つの VPC。• VPC-1 と VPC-2 のパブリックサブネットのそれぞれに関連付けられている Elastic IP アドレス。

ステップ 1: Device Farm を同じリージョンの VPC に接続するDevice Farm と VPC のエンドポイント間でプライベート接続 (AWS PrivateLink) を確立します。詳細については、the section called “VPC エンドポイントサービスを使用する” (p. 155) を参照してください。

ステップ 2: Device Farm リージョンに OpenVPNサーバーをセットアップする (VPC-1)1. Amazon VPC コンソールを開きます。AWS 認証情報を求められる場合があります。2. [VPC ダッシュボード] から、[EC2 インスタンスの起動] を選択します。

API バージョン 2015-06-23159

https://console.aws.amazon.com/vpc/home

AWS Device Farm 開発者ガイドステップ 2: VPC-1 をセットアップする

3. 左のナビゲーションペインから、[AWS Marketplace] を選択します。4. [OpenVPN アクセスサーバー] を検索します。

5. [Select (選択)] を選択して OpenVPN 概要ページを表示し、[Continue (続行)] を選択します。6. Amazon EC2 インスタンスタイプを選択します。7. [Next: Configure Instance Details] を選択します。[Subnet (サブネット)] で、パブリックサブネットを

選択します。8. 以下のページでは、何も変更せずに進みます。

a. [次の手順: ストレージの追加] を選択します。b. [Next: Add Tags] を選択します。c. [Next: Configure Security Group] を選択します。

9. 以下の OpenVPN セキュリティグループ設定を確認します。

• SSH – ポート 22• カスタム TCP ルール – ポート 943• HTTPS – ポート 443• カスタム UDP ルール – ポート 1194

10. [確認と作成] を選択します。11. メディアタイプを選択し、[Next (次へ)] を選択します。12. [Launch] を選択します。13. インスタンスを選択または作成後、[インスタンスの起動] を選択します。14. インスタンスの起動に時間がかかることがあります。Amazon EC2 インスタンスのステータスを追跡

するには、[View Instances (インスタンスの表示)] を選択します。15. VPC トラフィックの送信元と送信先の IP アドレスチェックを無効にします。

a. EC2 [インスタンス] ページの [アクション] から、[ネットワーキング]、[Change Source/DestCheck (送信元/送信先の変更)] の順に選択します。

b. [Yes, Disable] を選択します。

API バージョン 2015-06-23160

AWS Device Farm 開発者ガイドステップ 3: VPC-2 をセットアップする

OpenVPN サーバーを設定するには

1. このインスタンス用に設定したユーザー名 openvpnas とキーペアを使用して、SSH 経由で OpenVPNの Amazon EC2 インスタンスにサインインします。詳細については、「SSH を使用した Linux インスタンスへの接続」を参照してください。

2. 初回サインイン時、OpenVPN アクセスサーバーセットアップウィザードが自動的に実行されます。再度実行するにはこのコマンドを使用します。

sudo vpn-init --ec2

ステップ 3: 2 つ目のリージョンに OpenVPN サーバーをセットアップする (VPC-2)ステップ 2 (p. 159) の情報を使用して、2 つ目のリージョンのパブリックサブネットに OpenVPN サーバーをセットアップします (VPC-2)。

ステップ 4: VPC-1 を設定する1. Amazon VPC コンソールを開きます。AWS 認証情報を求められる場合があります。2. [カスタマーゲートウェイ] を選択し、ゲートウェイ設定を入力後、カスタマーゲートウェイを作成し

ます。

a. [カスタマーゲートウェイの作成] を選択します。b. [ルーティング] で [Static (静的)] を選択します。c. [Name (名前)] に、ゲートウェイの名前を入力します。d. [IP アドレス] に、OpenVPN アクセスサーバーインスタンスのパブリック IP アドレスを入力しま

す。

API バージョン 2015-06-23161

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

https://console.aws.amazon.com/vpc/home

AWS Device Farm 開発者ガイドステップ 5: VPC-2 を設定する

e. [カスタマーゲートウェイの作成] を選択します。f. 成功すると、カスタマーゲートウェイ ID が表示されます。[Close] を選択します。

3. [仮想プライベートゲートウェイ] を選択して、仮想プライベートゲートウェイ (VPG) を作成します。

a. [名前] に、VPG の名前を入力します。b. [Create Virtual Private Gateway (仮想プライベートゲートウェイの作成)] を選択します。

4. 先ほど作成した VPG を選択し、VPG にアタッチします。

a. [Actions (アクション)] から [VPC にアタッチ] を選択します。b. [VPC] から VPC を選択します。c. [ルーティングオプション] から [Static (静的)] を選択します。IP アドレスを CIDR 表記で入力しま

す。d. [Yes, Attach] を選択します。

5. [ルートテーブル] を選択し、ルート設定を行います。

a. サブネットに対応するルーティングテーブルを選択します。b. [ルート伝播] タブで、先ほど作成した仮想プライベートゲートウェイの VGW ID を選択し、[追加]

を選択します。6. [VPG 接続] を選択し、VPN 接続を作成します。

a. [Create VPN Connection (VPN 接続の作成)] を選択します。b. [仮想プライベートゲートウェイ] から、仮想プライベートゲートウェイを選択します。c. [カスタマーゲートウェイ ID] から、既存のカスタマーゲートウェイを選択します。d. [ルーティングオプション] から [Static (静的)] を選択します。[静的 IP アドレス] に Elastic IP アド

レスを入力します。たとえば、静的 IP アドレスが 10.12.34.56 の場合、IP プレフィックスのCIDR 表記は 10.12.34.0/24 です。

e. [Create VPN Connection (VPN 接続の作成)] を選択します。f. 成功すると、VPN 接続 ID が表示されます。[Close] を選択します。

7. [Use Static Routing (静的ルーティングを使用)] を選択します。8. OpenVPN アクセス VPN サーバーの Elastic IP アドレスを入力します。VPN 接続を選択し、トンネル

1 およびトンネル 2 の IP アドレスをコンソールに書き留めます。これらは、この手順の後半で必要になります。

9. [Download Configuration (設定のダウンロード)] を選択します。10. SSH を使用して、OpenVPN アクセスサーバーインスタンスに接続し、/etc/ipsec.conf ファイル

を開きます。

sudo /etc/ipsec.conf

11. VPC CIDR マスクをポイントするように rightsubnet= 値を編集します。12. VPC-CUST-GW1 セクションおよび VPC-CUST-GW2 セクションで、トンネル 1 およびトンネル 2 の

IP アドレスを追加してファイルを保存します。13. /etc/ipsec.secrets ファイルを開き、先ほどダウンロードした VPC-1 設定ファイルの事前共有

キーを入力します。14. VPN 接続を開始するには、ipsec start コマンドを使用します。

VPN 接続エントリのステータスが Amazon VPC コンソールに表示されます。

ステップ 5: VPC-2 を設定するVPC-2 を設定するには、ステップ 4 (p. 161) の情報を使用します。VPC EC2 インスタンスから他のVPC にトラフィックを送信するには、両方の VPC のルーティングテーブルを設定します。

API バージョン 2015-06-23162

AWS Device Farm 開発者ガイドステップ 6: テストランを作成する

Note

トラフィックをルーティングするサブネットに応じて、パブリックサブネットおよびプライベートサブネットに複数のテーブルを設定する必要がある場合があります。

このシナリオの例と、その代替の VPN 実装の詳細については、「EC2 インスタンスを使用して複数のVPC に接続する (SSL)」を参照してください。

ステップ 6: テストランを作成するステップ 1 (p. 159) で説明した VPCE 設定を使用するテストランを作成できます。詳細については、「テストランの作成 (p. 23)」または「リモートアクセスセッションの作成 (p. 142)」を参照してください。

API バージョン 2015-06-23163

https://aws.amazon.com/articles/connecting-multiple-vpcs-with-ec2-instances-ssl

https://aws.amazon.com/articles/connecting-multiple-vpcs-with-ec2-instances-ssl

AWS Device Farm 開発者ガイドCloudTrail 内の AWS Device Farm 情報

AWS Device Farm を使用した AWSCloudTrail API 呼び出しのログ記録

AWS Device Farm は、AWS CloudTrail のユーザーやロール、または AWS のサービスによって実行されたアクションを記録するサービスである AWS Device Farm と統合されています。CloudTrail は、AWSDevice Farm のすべての API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、AWS Device Farm コンソールの呼び出しと、AWS Device Farm API オペレーションへのコード呼び出しが含まれます。証跡を作成する場合は、AWS Device Farm のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの [Event history (イベント履歴)] で最新のイベントを表示できます。CloudTrailによって収集された情報を使用して、リクエストの作成元の IP アドレス、リクエストの実行者、リクエストの実行日時などの詳細を調べて、AWS Device Farm に対してどのようなリクエストが行われたかを判断できます。

CloudTrail の詳細については、「AWS CloudTrail User Guide」を参照してください。

CloudTrail 内の AWS Device Farm 情報CloudTrail は、アカウント作成時に AWS アカウントで有効になります。AWS Device Farm でアクティビティが発生すると、そのアクティビティは [Event history (イベント履歴)] の AWS の他のサービスのイベントとともに CloudTrail イベントに記録されます。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、「CloudTrail イベント履歴でのイベントの表示」を参照してください。

AWS Device Farmのイベントなど、AWS アカウントのイベントの継続的な記録については、証跡を作成します。証跡により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで作成した証跡がすべての AWS リージョンに適用されます。証跡では、AWS パーティションのすべてのリージョンからのイベントがログに記録され、指定した Amazon S3 バケットにログファイルが配信されます。さらに、より詳細な分析と AWS ログで収集されたデータに基づいた行動のためにその他の CloudTrail サービスを設定できます。詳細については、以下を参照してください。

• 証跡を作成するための概要• CloudTrail でサポートされるサービスと統合• CloudTrail の Amazon SNS 通知の設定• 「複数のリージョンから CloudTrail ログファイルを受け取る」と「複数のアカウントから CloudTrail ロ

グファイルを受け取る」

AWS アカウントで CloudTrail ログ記録を有効にすると、Device Farm アクションに対する API コールはログファイルに記録されます。Device Farm レコードは、AWS の他のサービスのレコードと一緒にログファイルに書き込まれます。CloudTrail は、期間とファイルサイズに基づいて新規ファイルの作成と書き込みのタイミングを決定します。

Device Farm アクションすべては、「AWS CLIリファレンス (p. 172)」または「Device Farm の自動化 (p. 174)」に記録され、文書化されます。たとえば、Device Farm で新しいプロジェクト、実行を作成する呼び出しは、CloudTrail ログファイルにエントリを生成します。

各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。この ID 情報は以下のことを確認するのに役立ちます。

API バージョン 2015-06-23164

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html

AWS Device Farm 開発者ガイドAWS Device Farm ログファイルエントリの概要

• リクエストが、ルートまたは AWS Identity and Access Management (IAM) ユーザー認証情報のどちらを使用して送信されたかどうか。

• リクエストが、ロールとフェデレーティッドユーザーのどちらの一時的なセキュリティ認証情報を使用して送信されたか.

• リクエストが、別の AWS サービスによって送信されたかどうか。

詳細については、「CloudTrail userIdentity 要素」を参照してください。

AWS Device Farm ログファイルエントリの概要証跡は、指定した Amazon S3 バケットにイベントをログファイルとして配信できる設定です。CloudTrailログファイルには、1 つ以上のログエントリが含まれます。イベントは任意の送信元からの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどに関する情報が含まれます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。

以下の例は、Device Farm ListRuns アクションの CloudTrail ログエントリを示しています。

{ "Records": [ { "eventVersion": "1.03", "userIdentity": { "type": "Root", "principalId": "AKIAI44QH8DHBEXAMPLE", "arn": "arn:aws:iam::123456789012:root", "accountId": "123456789012", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2015-07-08T21:13:35Z" } } }, "eventTime":"2015-07-09T00:51:22Z", "eventSource": "devicefarm.amazonaws.com", "eventName":"ListRuns", "awsRegion":"us-west-2", "sourceIPAddress":"203.0.113.11", "userAgent":"example-user-agent-string", "requestParameters": { "arn":"arn:aws:devicefarm:us-west-2:123456789012:project:a9129b8c-df6b-4cdd-8009-40a25EXAMPLE"}, "responseElements": { "runs": [ { "created": "Jul 8, 2015 11:26:12 PM", "name": "example.apk", "completedJobs": 2, "arn": "arn:aws:devicefarm:us-west-2:123456789012:run:a9129b8c-df6b-4cdd-8009-40a256aEXAMPLE/1452d105-e354-4e53-99d8-6c993EXAMPLE", "counters": { "stopped": 0, "warned": 0, "failed": 0, "passed": 4, "skipped": 0, "total": 4,

API バージョン 2015-06-23165

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html

AWS Device Farm 開発者ガイドAWS Device Farm ログファイルエントリの概要

"errored": 0 }, "type": "BUILTIN_FUZZ", "status": "RUNNING", "totalJobs": 3, "platform": "ANDROID_APP", "result": "PENDING" }, ... additional entries ... ] } } } ]}

API バージョン 2015-06-23166

AWS Device Farm 開発者ガイドDevice Farm テストを使用するように CodePipeline を設定する

CodePipeline テストステージでのAWS Device Farm の使用

AWS CodePipeline を使用すると、Device Farm で設定したモバイルアプリケーションテストを AWS マネージド型の自動リリースパイプラインに組み込むことができます。オンデマンドで、スケジュールに従って、または継続的な統合フローの一部として、テストを実行するようにパイプラインを設定できます。

以下の図に示しているのは、プッシュがリポジトリにコミットされるたびに Android アプリケーションがビルドされてテストされる、継続的な統合フローです。このパイプライン設定を作成するには、「チュートリアル: GitHub にプッシュするときの Android アプリのビルドとテスト」を参照してください。

1.設定 2.定義の追加 3.Push 4.ビルドとテスト 5.レポート

パイプラインリソースを設定する

パッケージにビルドとテストの定義を追加する

リポジトリにパッケージをプッシュする

アプリケーションをビルドし、自動的に開始されるビルド出力アーティファクトをテストする

テスト結果を表示する

コンパイルされたアプリケーション (iOS の .ipa ファイルや Android の .apk ファイルなど) をソースとして継続的にテストするパイプラインを設定する方法については、「チュートリアル: .ipa ファイルをAmazon S3 バケットにアップロードするたびに iOS アプリケーションをテストする」を参照してください。

Device Farm テストを使用するようにCodePipeline を設定する

以下のステップは、Device Farm プロジェクトの設定 (p. 20)とパイプラインの作成を完了していることを前提としています。テストステージで、テスト定義とコンパイルされたアプリケーションパッケージファイルを含む入力アーティファクトを受け取るように、パイプラインを設定する必要があります。テストステージの入力アーティファクトとしては、パイプラインで設定したソースステージまたはビルドステージの出力アーティファクトを使用できます。

API バージョン 2015-06-23167

https://docs.aws.amazon.com/codepipeline/latest/userguide/

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-codebuild-devicefarm.html

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-codebuild-devicefarm.html

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-codebuild-devicefarm-S3.html

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-codebuild-devicefarm-S3.html

https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-codepipeline.html

https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html#welcome-introducing-artifacts


Device Farm テストランを CodePipeline テストアクションとして設定するには

1. AWS マネジメントコンソールにサインインし、CodePipeline コンソール (https://console.aws.amazon.com/codepipeline/) を開きます。

2. アプリケーションリリースのパイプラインを選択します。3. テストステージパネルで、鉛筆アイコンを選択してから、[Action (アクション)] を選択します。4. [Add action (アクションの追加)] パネルの [Action category (アクションカテゴリ)] で、[Test (テスト)]

を選択します。5. [アクション名] に名前を入力します。6. [Test provider (テストプロバイダー)] で、[AWS Device Farm] を選択します。

7. [プロジェクト名] で、既存の Device Farm プロジェクトを選択するか、[新規プロジェクトの作成] を選択します。

8. [Device pool (デバイスプール)] で、既存のデバイスプールを選択するか、[Create a new device pool(新しいデバイスプールの作成)] を選択します。デバイスプールを作成する場合は、一連のテストデバイスを選択する必要があります。

9. [App type (アプリケーションタイプ)] で、アプリケーションのプラットフォームを選択します。

API バージョン 2015-06-23168

https://console.aws.amazon.com/codepipeline/

https://console.aws.amazon.com/codepipeline/


10. [App file path (アプリファイルパス)] にコンパイルされたアプリケーションパッケージのパスを入力します。パスは、テストの入力アーティファクトのルートを基準とする相対パスです。

11. [Test type (テストタイプ)] で以下のいずれかを実行します。

• 組み込み Device Farm テストのいずれかを使用している場合は、Device Farm プロジェクトで設定されているテストのタイプを選択します。

• 組み込みの Device Farm テストのいずれも使用しない場合は、[Test file path (テストファイルパス)]にテスト定義ファイルのパスを入力します。パスは、テストの入力アーティファクトのルートを基準とする相対パスです。

API バージョン 2015-06-23169


12. 残りのフィールドにはテストおよびアプリケーションタイプに適した設定を入力します。13. (オプション) [Advanced (詳細)] で、テストランの詳細設定を行います。

14. [入力アーティファクト] で、パイプラインのテストステージの前にあるステージの出力アーティファクトに一致する入力アーティファクトを選択します。

API バージョン 2015-06-23170


CodePipeline コンソールでは、パイプライン図の情報アイコンの上にカーソルを置くことで、各ステージの出力アーティファクトの名前を見つけることができます。パイプラインでアプリケーションを [Source ] ステージから直接テストする場合は、[MyApp] を選択します。パイプラインに [ビルド] ステージが含まれている場合は、[MyAppBuild] を選択します。

15. パネルの下部で、[アクションの追加] を選択します。16. CodePipeline のペインで、[パイプラインの変更を保存]、[変更の保存] の順に選択します。17. 変更を送信してパイプラインのビルドを開始するには、[変更のリリース]、[リリース] の順に選択しま

す。

API バージョン 2015-06-23171


AWS Device Farm の AWS CLI リファレンス

AWS Command Line Interface (AWS CLI) を使用して Device Farm コマンドを実行するには、「AWSDevice Farm の AWS CLI リファレンス」を参照してください。

AWS CLI に関する一般的な情報については、「AWS Command Line Interface ユーザーガイド」および「AWS CLI Command Reference」を参照してください。

API バージョン 2015-06-23172

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/index.html

https://docs.aws.amazon.com/cli/latest/reference/devicefarm/index.html

https://docs.aws.amazon.com/cli/latest/userguide/

https://docs.aws.amazon.com/cli/latest/reference/


AWS Device Farm 用 WindowsPowerShell リファレンス

Windows PowerShell を使用して Device Farm コマンドを実行するには、『AWS Tools for WindowsPowerShell コマンドレットリファレンス』内の「Device Farm コマンドレットリファレンス」を参照してください。詳細については、『AWS Tools for Windows PowerShell ユーザーガイド』内の「AWS Toolsfor Windows PowerShell のセットアップ」を参照してください。

API バージョン 2015-06-23173

http://docs.aws.amazon.com/powershell/latest/reference/Index.html

http://docs.aws.amazon.com/powershell/latest/reference/Index.html

http://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Device_Farm_cmdlets.html

http://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html

http://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html

AWS Device Farm 開発者ガイド例: AWS SDK を使用した Device Farm実行の開始とアーティファクトの収集

AWS Device Farm の自動化プログラムによる Device Farm へのアクセスは、実行のスケジュールや実行、スイート、またはテスト用のアーティファクトのダウンロードなど、実行する必要がある一般的なタスクを自動化するための強力な方法です。AWS SDK と AWS CLI は、そのための手段を提供します。

AWS SDK は、Device Farm、Amazon S3 などを含むすべての AWS のサービスへのアクセスを提供します。詳細については、次を参照してください。

• AWS ツールと SDK• AWS Device Farm API リファレンス

例: AWS SDK を使用した Device Farm 実行の開始とアーティファクトの収集

次のでは、AWS SDK を使用して Device Farm を操作する方法を最初から最後まで示します。この例では、次のような処理を実行します。

• テストパッケージとアプリケーションパッケージを Device Farm にアップロードする• テスト実行を開始し、その完了 (または失敗) を待つ• テストスイートによって生成されたすべてのアーティファクトをダウンロードする

この例は、HTTP と対話するサードパーティーの requests パッケージに依存しています。

import boto3import osimport requestsimport stringimport randomimport timeimport datetimeimport timeimport json

# The following script runs a test through Device Farm## Things you have to change:config = { # This is our app under test. "appFilePath":"app-debug.apk", "projectArn": "arn:aws:devicefarm:us-west-2:111122223333:project:1b99bcff-1111-2222-ab2f-8c3c733c55ed", # Since we care about the most popular devices, we'll use a curated pool. "testSpecArn":"arn:aws:devicefarm:us-west-2::upload:4f8bd6b2-7be5-11e8-adc0-fa7ae01bbebc", "poolArn":"arn:aws:devicefarm:us-west-2::devicepool:082d10e5-d7d7-48a5-ba5c-b33d66efa1f5", "namePrefix":"MyAppTest", # This is our test package. This tutorial won't go into how to make these. "testPackage":"tests.zip"}

client = boto3.client('devicefarm')

API バージョン 2015-06-23174

http://aws.amazon.com/tools/

https://docs.aws.amazon.com/devicefarm/latest/APIReference/Welcome.html


unique = config['namePrefix']+"-"+(datetime.date.today().isoformat())+(''.join(random.sample(string.ascii_letters,8)))

print(f"The unique identifier for this run is going to be {unique} -- all uploads will be prefixed with this.")

def upload_df_file(filename, type_, mime='application/octet-stream'): response = client.create_upload(projectArn=config['projectArn'], name = (unique)+"_"+os.path.basename(filename), type=type_, contentType=mime ) # Get the upload ARN, which we'll return later. upload_arn = response['upload']['arn'] # We're going to extract the URL of the upload and use Requests to upload it upload_url = response['upload']['url'] with open(filename, 'rb') as file_stream: print(f"Uploading {filename} to Device Farm as {response['upload']['name']}... ",end='') put_req = requests.put(upload_url, data=file_stream, headers={"content-type":mime}) print(' done') if not put_req.ok: raise Exception("Couldn't upload, requests said we're not ok. Requests says: "+put_req.reason) started = datetime.datetime.now() while True: print(f"Upload of {filename} in state {response['upload']['status']} after "+str(datetime.datetime.now() - started)) if response['upload']['status'] == 'FAILED': raise Exception("The upload failed processing. DeviceFarm says reason is: \n"+response['upload']['message']) if response['upload']['status'] == 'SUCCEEDED': break time.sleep(5) response = client.get_upload(arn=upload_arn) print("") return upload_arn

our_upload_arn = upload_df_file(config['appFilePath'], "ANDROID_APP")our_test_package_arn = upload_df_file(config['testPackage'], 'APPIUM_PYTHON_TEST_PACKAGE')print(our_upload_arn, our_test_package_arn)# Now that we have those out of the way, we can start the test run...response = client.schedule_run( projectArn = config["projectArn"], appArn = our_upload_arn, devicePoolArn = config["poolArn"], name=unique, test = { "type":"APPIUM_PYTHON", "testSpecArn": config["testSpecArn"], "testPackageArn": our_test_package_arn } )run_arn = response['run']['arn']start_time = datetime.datetime.now()print(f"Run {unique} is scheduled as arn {run_arn} ")

try:

while True: response = client.get_run(arn=run_arn) state = response['run']['status'] if state == 'COMPLETED' or state == 'ERRORED': break else:

API バージョン 2015-06-23175


print(f" Run {unique} in state {state}, total time "+str(datetime.datetime.now()-start_time)) time.sleep(10)except: # If something goes wrong in this process, we stop the run and exit.

client.stop_run(arn=run_arn) exit(1)print(f"Tests finished in state {state} after "+str(datetime.datetime.now() - start_time))# now, we pull all the logs.jobs_response = client.list_jobs(arn=run_arn)# Save the output somewhere. We're using the unique value, but you could use something elsesave_path = os.path.join(os.getcwd(), unique)os.mkdir(save_path)# Save the last run informationfor job in jobs_response['jobs'] : # Make a directory for our information job_name = job['name'] os.makedirs(os.path.join(save_path, job_name), exist_ok=True) # Get each suite within the job suites = client.list_suites(arn=job['arn'])['suites'] for suite in suites: for test in client.list_tests(arn=suite['arn'])['tests']: # Get the artifacts for artifact_type in ['FILE','SCREENSHOT','LOG']: artifacts = client.list_artifacts( type=artifact_type, arn = test['arn'] )['artifacts'] for artifact in artifacts: # We replace : because it has a special meaning in Windows & macos path_to = os.path.join(save_path, job_name, suite['name'], test['name'].replace(':','_') ) os.makedirs(path_to, exist_ok=True) filename = artifact['type']+"_"+artifact['name']+"."+artifact['extension'] artifact_save_path = os.path.join(path_to, filename) print("Downloading "+artifact_save_path) with open(artifact_save_path, 'wb') as fn, requests.get(artifact['url'],allow_redirects=True) as request: fn.write(request.content) #/for artifact in artifacts #/for artifact type in [] #/ for test in ()[] #/ for suite in suites #/ for job in _[]# doneprint("Finished")

API バージョン 2015-06-23176

AWS Device Farm 開発者ガイドAndroid アプリケーション

Device Farm エラーのトラブルシューティング

このセクションでは、Device Farm に関する一般的な問題を修正するのに役立つエラーメッセージと手順を示します。

トピック• AWS Device Farm の Android アプリケーションテストのトラブルシューティング (p. 177)• AWS Device Farm での Appium Java JUnit のトラブルシューティング (p. 181)• AWS Device Farm での Appium Java JUnit ウェブアプリケーションテストのトラブルシューティン

グ (p. 187)• AWS Device Farm での Appium Java TestNG テストのトラブルシューティング (p. 193)• AWS Device Farm での Appium Java TestNG ウェブアプリケーションのトラブルシューティン

グ (p. 197)• AWS Device Farm での Appium Python テストのトラブルシューティング (p. 201)• AWS Device Farm での Appium Python ウェブアプリケーションテストのトラブルシューティン

グ (p. 208)• AWS Device Farm での Calabash テストのトラブルシューティング (p. 215)• AWS Device Farm でのインストルメンテーションテストのトラブルシューティング (p. 221)• AWS Device Farm の iOS アプリケーションテストのトラブルシューティング (p. 225)• AWS Device Farm での UI Automator テストのトラブルシューティング (p. 233)• AWS Device Farm での XCTest テストのトラブルシューティング (p. 233)• AWS Device Farm での XCTest UI テストのトラブルシューティング (p. 237)

AWS Device Farm の Android アプリケーションテストのトラブルシューティング

次のトピックでは、Android アプリケーションテストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための推奨される回避策を示します。

Note

以下の手順は Linux x86_64 および Mac を対象にしています。

ANDROID_APP_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーションを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでアプリケーションパッケージを解凍できることを確認します。次の例では、パッケージ名はapp-debug.apk です。

1. テストパッケージを作業ディレクトリにコピーし、次のコマンドを実行します。

API バージョン 2015-06-23177

AWS Device Farm 開発者ガイドANDROID_APP_AAPT_DEBUG_BADGING_FAILED

$ unzip app-debug.apk

2. 正常にパッケージを解凍したら、次のコマンドを実行して作業ディレクトリのツリー構造を見つけることができます。

$ tree .

有効な Android アプリケーションパッケージでは、次のような出力が生成されます。

.|-- AndroidManifest.xml|-- classes.dex|-- resources.arsc|-- assets (directory)|-- res (directory)`-- META-INF (directory)

詳細については、「AWS Device Farm での Android テストの実行 (p. 55)」を参照してください。

ANDROID_APP_AAPT_DEBUG_BADGING_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーションに関する情報を抽出できませんでした。aapt debug badging <path toyour test package>コマンドを実行してアプリケーションが有効であることを確認し、コマンドがエラーを出力しなくなってからもう一度試してください。

アップロードの検証プロセス中に、AWS Device Farm は aapt debug badging <path to yourpackage> コマンドの出力から情報を解析します。

Android アプリケーションでこのコマンドを正常に実行できることを確認してください。次の例では、パッケージ名は app-debug.apk です。

• アプリケーションパッケージを作業ディレクトリにコピーし、次にコマンドを実行します。

$ aapt debug badging app-debug.apk


package: name='com.amazon.aws.adf.android.referenceapp' versionCode='1' versionName='1.0' platformBuildVersionName='5.1.1-1819727'sdkVersion:'9'application-label:'ReferenceApp'application: label='ReferenceApp' icon='res/mipmap-mdpi-v4/ic_launcher.png'application-debuggablelaunchable-activity: name='com.amazon.aws.adf.android.referenceapp.Activities.MainActivity' label='ReferenceApp' icon=''uses-feature: name='android.hardware.bluetooth'uses-implied-feature: name='android.hardware.bluetooth' reason='requested android.permission.BLUETOOTH permission, and targetSdkVersion > 4'mainsupports-screens: 'small' 'normal' 'large' 'xlarge'supports-any-density: 'true'locales: '--_--'

API バージョン 2015-06-23178

AWS Device Farm 開発者ガイドANDROID_APP_PACKAGE_NAME_VALUE_MISSING

densities: '160' '213' '240' '320' '480' '640'


ANDROID_APP_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーション内にパッケージ名の値が見つかりませんでした。aapt debug badging<path to your test package>コマンドを実行してアプリケーションが有効であることを確認し、キーワード "package: name" の後ろにパッケージ名の値を見つけた後にもう一度試して下さい。

アップロードの検証プロセス中に、AWS Device Farm は aapt debug badging <path to yourpackage> コマンドの出力からパッケージ名の値を解析します。

Android アプリケーションでこのコマンドを実行でき、パッケージ名の値を正常に見つけられることを確認してください。次の例では、パッケージ名は app-debug.apk です。

• アプリケーションパッケージを作業ディレクトリにコピーし、次に以下のコマンドを実行します。

$ aapt debug badging app-debug.apk | grep "package: name="


package: name='com.amazon.aws.adf.android.referenceapp' versionCode='1' versionName='1.0' platformBuildVersionName='5.1.1-1819727'


ANDROID_APP_SDK_VERSION_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーション内に SDK バージョンの値が見つかりませんでした。aapt debug badging<path to your test package>コマンドを実行してアプリケーションが有効であることを確認し、キーワード sdkVersion の後ろに SDK バージョンの値を見つけた後にもう一度試して下さい。

アップロードの検証プロセス中に、AWS Device Farm は aapt debug badging <path to yourpackage> コマンドの出力から SDK バージョンの値を解析します。

Android アプリケーションでこのコマンドを実行でき、パッケージ名の値を正常に見つけられることを確認してください。次の例では、パッケージ名は app-debug.apk です。


$ aapt debug badging app-debug.apk | grep "sdkVersion"


API バージョン 2015-06-23179

AWS Device Farm 開発者ガイドANDROID_APP_AAPT_DUMP_XMLTREE_FAILED

sdkVersion:'9'


ANDROID_APP_AAPT_DUMP_XMLTREE_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

有効な AndroidManifest.xml がアプリケーション内に見つかりませんでした。コマンド aaptdump xmltree <path to your test package> AndroidManifest.xml を実行してテストパッケージが有効であることを確認し、コマンドがエラーを出力しなくなってからもう一度試してください。

アップロードの検証プロセス中に、AWS Device Farm はコマンド aapt dump xmltree <path toyour package> AndroidManifest.xml を使用してパッケージに含まれる XML ファイルの XML 解析ツリーから情報を解析します。

Android アプリケーションでこのコマンドを正常に実行できることを確認してください。次の例では、パッケージ名は app-debug.apk です。


$ aapt dump xmltree app-debug.apk. AndroidManifest.xml


N: android=http://schemas.android.com/apk/res/android E: manifest (line=2) A: android:versionCode(0x0101021b)=(type 0x10)0x1 A: android:versionName(0x0101021c)="1.0" (Raw: "1.0") A: package="com.amazon.aws.adf.android.referenceapp" (Raw: "com.amazon.aws.adf.android.referenceapp") A: platformBuildVersionCode=(type 0x10)0x16 (Raw: "22") A: platformBuildVersionName="5.1.1-1819727" (Raw: "5.1.1-1819727") E: uses-sdk (line=7) A: android:minSdkVersion(0x0101020c)=(type 0x10)0x9 A: android:targetSdkVersion(0x01010270)=(type 0x10)0x16 E: uses-permission (line=11) A: android:name(0x01010003)="android.permission.INTERNET" (Raw: "android.permission.INTERNET") E: uses-permission (line=12) A: android:name(0x01010003)="android.permission.CAMERA" (Raw: "android.permission.CAMERA")


ANDROID_APP_DEVICE_ADMIN_PERMISSIONS次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーションにデバイスの管理者権限が必要なことが見つかりました。aapt dumpxmltree <path to your test package> AndroidManifest.xml コマンドを実行して権

API バージョン 2015-06-23180


限が必要ないことを確認して、キーワード android.permission.BIND_DEVICE_ADMIN が出力に含まれていないことを確認してからもう一度試してください。

アップロードの検証プロセス中に、AWS Device Farm はコマンド aapt dump xmltree <path toyour package> AndroidManifest.xml を使用してパッケージに含まれる XML ファイルの XML 解析ツリーからアクセス許可を解析します。

アプリケーションにデバイスの管理者権限が必要ないことを確認してください。次の例では、パッケージ名は app-debug.apk です。


$ aapt dump xmltree app-debug.apk AndroidManifest.xml

次のような出力があります。

N: android=http://schemas.android.com/apk/res/android E: manifest (line=2) A: android:versionCode(0x0101021b)=(type 0x10)0x1 A: android:versionName(0x0101021c)="1.0" (Raw: "1.0") A: package="com.amazonaws.devicefarm.android.referenceapp" (Raw: "com.amazonaws.devicefarm.android.referenceapp") A: platformBuildVersionCode=(type 0x10)0x16 (Raw: "22") A: platformBuildVersionName="5.1.1-1819727" (Raw: "5.1.1-1819727") E: uses-sdk (line=7) A: android:minSdkVersion(0x0101020c)=(type 0x10)0xa A: android:targetSdkVersion(0x01010270)=(type 0x10)0x16 E: uses-permission (line=11) A: android:name(0x01010003)="android.permission.INTERNET" (Raw: "android.permission.INTERNET") E: uses-permission (line=12) A: android:name(0x01010003)="android.permission.CAMERA" (Raw: "android.permission.CAMERA") ……

Android アプリケーションが有効な場合、出力に A:android:name(0x01010003)="android.permission.BIND_DEVICE_ADMIN" (Raw:"android.permission.BIND_DEVICE_ADMIN") を含めることはできません。


AWS Device Farm での Appium Java JUnit のトラブルシューティング

以下のトピックでは、Appium Java JUnit テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

Note


APPIUM_JAVA_JUNIT_TEST_PACKAGE_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23181

AWS Device Farm 開発者ガイドAPPIUM_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING

Warning

テスト ZIP ファイルを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでテストパッケージを解凍できることを確認します。次の例では、パッケージ名は zip-with-dependencies.zip です。


$ unzip zip-with-dependencies.zip


$ tree .

有効な Appium Java JUnit パッケージでは、次のような出力が生成されます。

.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar

詳細については、「Appium Java JUnit (p. 61)」または「Appium Java JUnit (p. 88)」を参照してください。

APPIUM_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

dependency-jars のディレクトリがテストパッケージ内に見つかりませんでした。テストパッケージを解凍し、dependency-jars ディレクトリがパッケージ内にあることを確認して、もう一度やり直してください。

次の例では、パッケージ名は zip-with-dependencies.zip です。




$ tree .

API バージョン 2015-06-23182

AWS Device Farm 開発者ガイドAPPIUM_JAVA_JUNIT_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR

Appium Java JUnit パッケージが有効な場合は、作業ディレクトリ内に dependency-jars ディレクトリがあります。



APPIUM_JAVA_JUNIT_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

dependency-jars ディレクトリツリー内に JAR ファイルが見つかりませんでした。テストパッケージを解凍してから dependency-jars ディレクトリを開き、少なくとも 1 つの JAR ファイルがディレクトリにあることを確認して、もう一度やり直してください。





$ tree .

Appium Java JUnit パッケージが有効な場合は、dependency-jars ディレクトリ内に少なくとも 1つの jar ファイルがあります。


API バージョン 2015-06-23183

AWS Device Farm 開発者ガイドAPPIUM_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING


APPIUM_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内に *-tests.jar ファイルが見つかりませんでした。テストパッケージを解凍し、パッケージ内に少なくとも 1 つの *-tests.jar ファイルがあることを確認して、もう一度やり直してください。





$ tree .

Appium Java JUnit パッケージが有効な場合は、この例の acme-android-appium-1.0-SNAPSHOT-tests.jar のような jar ファイルが少なくとも 1 つあります。ファイルの名前は異なる場合がありますが、–tests.jar で終わります。



APPIUM_JAVA_JUNIT_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テスト JAR ファイル内にクラスファイルが見つかりませんでした。テストパッケージを解凍してから、テスト JAR ファイルをアンジャーし、JAR ファイル内に少なくとも 1 つのクラスファイルがあることを確認して、もう一度やり直してください。


API バージョン 2015-06-23184

AWS Device Farm 開発者ガイドAPPIUM_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN




$ tree .

この例の acme-android-appium-1.0-SNAPSHOT-tests.jar のような jar ファイルが少なくとも1 つあります。ファイルの名前は異なる場合がありますが、–tests.jar で終わります。


3. ファイルを正常に抽出したら、次のコマンドを実行して作業ディレクトリツリーに少なくとも 1 つのクラスがあるはずです。

$ tree .


.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|- one-class-file.class|- folder| `-another-class-file.class|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar


APPIUM_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23185

AWS Device Farm 開発者ガイドAPPIUM_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION

Warning

JUnit のバージョン値が見つかりませんでした。テストパッケージを解凍し、dependency-jarsディレクトリを開き、JUnit JAR ファイルがディレクトリ内にあることを確認して、もう一度やり直してください。




2. 正常にパッケージを解凍したら、次のコマンドを実行して、作業ディレクトリのツリー構造を見つけることができます。

tree .

出力は次のようになります。

.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— junit-4.10.jar |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar

Appium Java JUnit パッケージが有効な場合は、この例の jar ファイル junit-4.10.jar のようなJUnit 依存関係ファイルがあります。名前はキーワード junit とバージョン番号で構成する必要があります。この例では 4.10 です。

詳細については、Appium Java JUnit (p. 61)およびAppium Java JUnit (p. 88)を参照してください。

APPIUM_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

JUnit のバージョンが、サポートしている最小バージョン 4.10 よりも低いことがわかりました。JUnit のバージョンを変更して、もう一度試してください。





$ tree .

API バージョン 2015-06-23186

AWS Device Farm 開発者ガイドAppium Java JUnit Web

この例の junit-4.10.jar のような JUnit 依存関係ファイルとそのバージョン番号 (この例では4.10) を見つける必要があります。


Note

テストパッケージで指定された JUnit のバージョンがサポートしている最小バージョン 4.10よりも低い場合、テストが正しく実行されないことがあります。


AWS Device Farm での Appium Java JUnit ウェブアプリケーションテストのトラブルシューティング

次のトピックでは、Appium Java JUnit ウェブアプリケーションテストのアップロード中に発生するエラーメッセージをリストし、各エラーを解決するための回避策を推奨します。

APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .


.

API バージョン 2015-06-23187

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING

|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar

詳細については、「Appium Java JUnit (p. 116)」を参照してください。

APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_DEPENDENCY_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .




APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23188

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING

Warning






$ tree .




APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_TESTS_JAR_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .

API バージョン 2015-06-23189

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR




APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



3. ファイルを正常に抽出したら、次のコマンドを実行して作業ディレクトリツリーに少なくとも 1 つのクラスがあるはずです。

API バージョン 2015-06-23190

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN

$ tree .


.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|- one-class-file.class|- folder| `-another-class-file.class|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar


APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_JUNIT_VERSION_VALUE_UNKNOWN次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

JUnit のバージョン値が見つかりませんでした。テストパッケージを解凍し、dependency-jarsディレクトリを開き、JUnit JAR ファイルがディレクトリ内にあることを確認して、もう一度やり直してください。




2. 正常にパッケージを解凍したら、次のコマンドを実行して、作業ディレクトリのツリー構造を見つけることができます。

tree .

出力は次のようになります。

.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— junit-4.10.jar |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar

API バージョン 2015-06-23191

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION

`— log4j-1.2.14.jar

Appium Java JUnit パッケージが有効な場合は、この例の jar ファイル junit-4.10.jar のようなJUnit 依存関係ファイルがあります。名前はキーワード junit とバージョン番号で構成する必要があります。この例では 4.10 です。


APPIUM_WEB_JAVA_JUNIT_TEST_PACKAGE_INVALID_JUNIT_VERSION次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

JUnit のバージョンが、サポートしている最小バージョン 4.10 よりも低いことがわかりました。JUnit のバージョンを変更して、もう一度試してください。





$ tree .

この例の junit-4.10.jar のような JUnit 依存関係ファイルとそのバージョン番号 (この例では4.10) を見つける必要があります。


Note

テストパッケージで指定された JUnit のバージョンがサポートしている最小バージョン 4.10よりも低い場合、テストが正しく実行されないことがあります。


API バージョン 2015-06-23192


AWS Device Farm での Appium Java TestNG テストのトラブルシューティング

以下のトピックでは、Appium Java TestNG テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

Note


APPIUM_JAVA_TESTNG_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



詳細については、「Appium Java TestNG (p. 56)」または「Appium Java TestNG (p. 82)」を参照してください。

APPIUM_JAVA_TESTNG_TEST_PACKAGE_DEPENDENCY_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23193

AWS Device Farm 開発者ガイドAPPIUM_JAVA_TESTNG_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR

Warning

dependency-jars のディレクトリがテストパッケージ内に見つかりませんでした。テストパッケージを解凍し、dependency-jars ディレクトリがパッケージ内にあることを確認して、もう一度試してください。





$ tree .




APPIUM_JAVA_TESTNG_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .

API バージョン 2015-06-23194

AWS Device Farm 開発者ガイドAPPIUM_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING




APPIUM_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



API バージョン 2015-06-23195

AWS Device Farm 開発者ガイドAPPIUM_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR


APPIUM_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



3. その jar ファイルからファイルを抽出するには、次のコマンドを実行します。

$ jar xf acme-android-appium-1.0-SNAPSHOT-tests.jar

4. ファイルの抽出が正常に完了したら、次のコマンドを実行します。

$ tree .

作業ディレクトリツリーで、少なくとも 1 つのクラスがあるはずです。

.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|- one-class-file.class

API バージョン 2015-06-23196

AWS Device Farm 開発者ガイドAppium Java TestNG Web

|- folder| `— another-class-file.class|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar


AWS Device Farm での Appium Java TestNG ウェブアプリケーションのトラブルシューティング

次のトピックでは、Appium Java TestNG ウェブアプリケーションテストのアップロード中に発生するエラーメッセージをリストし、各エラーを解決するための推奨する回避策を示します。

APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



API バージョン 2015-06-23197

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_DEPENDENCY_DIR_MISSING

詳細については、「Appium Java TestNG (p. 111)」を参照してください。

APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_DEPENDENCY_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .




APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_JAR_MISSING_IN_DEPENDENCY_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning




API バージョン 2015-06-23198

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING



$ tree .




APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_TESTS_JAR_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .


.|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|— zip-with-dependencies.zip (this .zip file contains all of the items)

API バージョン 2015-06-23199

AWS Device Farm 開発者ガイドAPPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR

`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar


APPIUM_WEB_JAVA_TESTNG_TEST_PACKAGE_CLASS_FILE_MISSING_IN_TESTS_JAR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning






$ tree .



3. その jar ファイルからファイルを抽出するには、次のコマンドを実行します。

$ jar xf acme-android-appium-1.0-SNAPSHOT-tests.jar

4. ファイルの抽出が正常に完了したら、次のコマンドを実行します。

$ tree .

作業ディレクトリツリーで、少なくとも 1 つのクラスがあるはずです。

.

API バージョン 2015-06-23200


|— acme-android-appium-1.0-SNAPSHOT.jar (this is the JAR containing everything built from the ./src/main directory)|— acme-android-appium-1.0-SNAPSHOT-tests.jar (this is the JAR containing everything built from the ./src/test directory)|- one-class-file.class|- folder| `— another-class-file.class|— zip-with-dependencies.zip (this .zip file contains all of the items)`— dependency-jars (this is the directory that contains all of your dependencies, built as JAR files) |— com.some-dependency.bar-4.1.jar |— com.another-dependency.thing-1.0.jar |— joda-time-2.7.jar `— log4j-1.2.14.jar


AWS Device Farm での Appium Python テストのトラブルシューティング

次のトピックでは、Appium Python テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

APPIUM_PYTHON_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Appium テスト ZIP ファイルを開くことができませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでテストパッケージを解凍できることを確認します。次の例では、パッケージの名前はtest_bundle.zip です。


$ unzip test_bundle.zip


$ tree .

有効な Appium Python パッケージでは、次のような出力が生成されます。

.|-- requirements.txt|-- test_bundle.zip|-- tests (directory)| `-- test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl

API バージョン 2015-06-23201

AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING

|-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl

詳細については、「Appium Python (p. 69)」または「Appium Python (p. 96)」を参照してください。

APPIUM_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

wheelhouse ディレクトリツリーに依存ホイールファイルが見つかりませんでした。テストパッケージを解凍して wheelhouse ディレクトリを開き、少なくとも 1 つのホイールファイルがディレクトリにあることを確認して、もう一度やり直してください。





$ tree .

Appium Python パッケージが有効な場合、wheelhouse ディレクトリ内の強調表示されたファイルのような、.whl 依存ファイルが少なくとも 1 つ見つかります。

.|-- requirements.txt|-- test_bundle.zip|-- tests (directory)| `-- test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl


APPIUM_PYTHON_TEST_PACKAGE_INVALID_PLATFORM次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

サポートされていないプラットフォームを指定した wheel ファイルが少なくとも 1 つ見つかりました。テストパッケージを解凍して wheelhouse ディレクトリを開き、ホイールファイルの名前が -any.whl または -linux_x86_64.whl で終わっていることを確認して、もう一度やり直してください。

API バージョン 2015-06-23202

AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING





$ tree .

Appium Python パッケージが有効な場合、wheelhouse ディレクトリ内の強調表示されたファイルのような、.whl 依存ファイルが少なくとも 1 つ見つかります。ファイルの名前は異なる場合がありますが、-any.whl または -linux_x86_64.whl で終わる必要があり、これはプラットフォームを指定します。windows のような他のプラットフォームはサポートされていません。



APPIUM_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内にテストディレクトリが見つかりませんでした。テストパッケージを解凍し、tests ディレクトリがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Appium Python パッケージが有効な場合、tests ディレクトリは作業ディレクトリ内にあります。

.|-- requirements.txt

API バージョン 2015-06-23203

AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME

|-- test_bundle.zip|-- tests (directory)| `-- test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl


APPIUM_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

tests ディレクトリツリーに有効なテストファイルが見つかりませんでした。テストパッケージを解凍して tests ディレクトリを開き、少なくとも 1 つのファイルの名前が「test」というキーワードで開始または終了していることを確認して、もう一度やり直してください。





$ tree .

Appium Python パッケージが有効な場合、tests ディレクトリは作業ディレクトリ内にあります。ファイルの名前は異なる場合がありますが、test_ で始まるか、_test.py で終わる必要があります。



APPIUM_PYTHON_TEST_PACKAGE_REQUIREMENTS_TXT_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23204

AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION

Warning

テストパッケージ内に requirements.txt ファイルが見つかりませんでした。テストパッケージを解凍し、requirements.txt ファイルがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Appium Python パッケージが有効な場合、requirements.txt ファイルは作業ディレクトリ内にあります。



APPIUM_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

サポートされる最低バージョン 2.8.0 より低い pytest のバージョンが見つかりました。requirements.txt ファイル内の pytest のバージョンを変更して、もう一度試してください。





$ tree .

作業ディレクトリの中に requirement.txt ファイルがあるはずです。

API バージョン 2015-06-23205

AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED

.|-- requirements.txt|-- test_bundle.zip|-- tests (directory)| `--test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl

3. pytest のバージョンを取得するには、次のコマンドを実行します。

$ grep "pytest" requirements.txt


pytest==2.9.0

pytest バージョンを示しており、この例では 2.9.0 です。Appium Python パッケージが有効な場合、pytest バージョンは 2.8.0 以上である必要があります。


APPIUM_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

依存ホイールのインストールに失敗しました。テストパッケージを解凍し、requirements.txt ファイルと wheelhouse ディレクトリを開き、requirements.txt ファイルで指定された依存ホイールがwheelhouse ディレクトリ内の依存ホイールと正確に一致することを確認して、もう一度やり直してください。

パッケージングテストのために Python virtualenv を設定することを強くお勧めします。次に、Pythonvirtualenv を使って仮想環境を作成し、それを起動する流れの例を示します。

$ virtualenv workspace$ cd workspace $ source bin/activate




2. ホイールファイルのインストールをテストするには、次のコマンドを実行します。

$ pip install --use-wheel --no-index --find-links=./wheelhouse --requirement=./requirements.txt

API バージョン 2015-06-23206


AWS Device Farm 開発者ガイドAPPIUM_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED


Ignoring indexes: https://pypi.python.org/simpleCollecting Appium-Python-Client==0.20 (from -r ./requirements.txt (line 1))Collecting py==1.4.31 (from -r ./requirements.txt (line 2))Collecting pytest==2.9.0 (from -r ./requirements.txt (line 3))Collecting selenium==2.52.0 (from -r ./requirements.txt (line 4))Collecting wheel==0.26.0 (from -r ./requirements.txt (line 5))Installing collected packages: selenium, Appium-Python-Client, py, pytest, wheel Found existing installation: wheel 0.29.0 Uninstalling wheel-0.29.0: Successfully uninstalled wheel-0.29.0Successfully installed Appium-Python-Client-0.20 py-1.4.31 pytest-2.9.0 selenium-2.52.0 wheel-0.26.0

3. 仮想環境を無効にするには、次のコマンドを実行します。

$ deactivate


APPIUM_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストディレクトリでテストを収集できませんでした。テストパッケージを解凍して、py.test--collect-only <path to your tests directory> コマンドの実行が有効であることを確認し、コマンドがエラーを出力しなくなってからもう一度試してください。






2. ホイールファイルをインストールするには、次のコマンドを実行します。


3. テストを収集するには、次のコマンドを実行します。

$ py.test --collect-only tests


API バージョン 2015-06-23207


AWS Device Farm 開発者ガイドAppium Python Web

==================== test session starts ====================platform darwin -- Python 2.7.11, pytest-2.9.0, py-1.4.31, pluggy-0.3.1rootdir: /Users/zhena/Desktop/Ios/tests, inifile:collected 1 items<Module 'test_unittest.py'> <UnitTestCase 'DeviceFarmAppiumWebTests'> <TestCaseFunction 'test_devicefarm'>

==================== no tests ran in 0.11 seconds ====================


$ deactivate


AWS Device Farm での Appium Python ウェブアプリケーションテストのトラブルシューティング

次のトピックでは、Appium Python ウェブアプリケーションテストのアップロード中に発生するエラーメッセージをリストし、各エラーを解決するための推奨される回避策を示します。

APPIUM_WEB_PYTHON_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Appium テスト ZIP ファイルを開くことができませんでした。ファイルが有効であることを確認してから、もう一度お試しください。





$ tree .


.|-- requirements.txt|-- test_bundle.zip|-- tests (directory)| `-- test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl

API バージョン 2015-06-23208

AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING

|-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl

詳細については、「Appium Python (p. 124)」を参照してください。

APPIUM_WEB_PYTHON_TEST_PACKAGE_DEPENDENCY_WHEEL_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

wheelhouse ディレクトリツリーに依存ホイールファイルが見つかりませんでした。テストパッケージを解凍して wheelhouse ディレクトリを開き、少なくとも 1 つのホイールファイルがディレクトリにあることを確認して、もう一度やり直してください。





$ tree .

Appium Python パッケージが有効な場合、wheelhouse ディレクトリ内の強調表示されたファイルのような、.whl 依存ファイルが少なくとも 1 つ見つかります。



APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_PLATFORM次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

サポートされていないプラットフォームを指定した wheel ファイルが少なくとも 1 つ見つかりました。テストパッケージを解凍して wheelhouse ディレクトリを開き、ホイールファイルの名前が -any.whl または -linux_x86_64.whl で終わっていることを確認して、もう一度やり直してください。

API バージョン 2015-06-23209

AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING





$ tree .

Appium Python パッケージが有効な場合、wheelhouse ディレクトリ内の強調表示されたファイルのような、.whl 依存ファイルが少なくとも 1 つ見つかります。ファイルの名前は異なる場合がありますが、-any.whl または -linux_x86_64.whl で終わる必要があり、これはプラットフォームを指定します。windows のような他のプラットフォームはサポートされていません。



APPIUM_WEB_PYTHON_TEST_PACKAGE_TEST_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内にテストディレクトリが見つかりませんでした。テストパッケージを解凍し、tests ディレクトリがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Appium Python パッケージが有効な場合、tests ディレクトリは作業ディレクトリ内にあります。

.|-- requirements.txt

API バージョン 2015-06-23210

AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME

|-- test_bundle.zip|-- tests (directory)| `-- test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl


APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_TEST_FILE_NAME次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

tests ディレクトリツリーに有効なテストファイルが見つかりませんでした。テストパッケージを解凍して tests ディレクトリを開き、少なくとも 1 つのファイルの名前が「test」というキーワードで開始または終了していることを確認して、もう一度やり直してください。





$ tree .

Appium Python パッケージが有効な場合、tests ディレクトリは作業ディレクトリ内にあります。ファイルの名前は異なる場合がありますが、test_ で始まるか、_test.py で終わる必要があります。



APPIUM_WEB_PYTHON_TEST_PACKAGE_REQUIREMENTS_TXT_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23211

AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION

Warning

テストパッケージ内に requirements.txt ファイルが見つかりませんでした。テストパッケージを解凍し、requirements.txt ファイルがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Appium Python パッケージが有効な場合、requirements.txt ファイルは作業ディレクトリ内にあります。



APPIUM_WEB_PYTHON_TEST_PACKAGE_INVALID_PYTEST_VERSION次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

サポートされる最低バージョン 2.8.0 より低い pytest のバージョンが見つかりました。requirements.txt ファイル内の pytest のバージョンを変更して、もう一度試してください。





$ tree .

作業ディレクトリの中に requirement.txt ファイルがあるはずです。

API バージョン 2015-06-23212

AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED

.|-- requirements.txt|-- test_bundle.zip|-- tests (directory)| `--test_unittest.py`-- wheelhouse (directory) |-- Appium_Python_Client-0.20-cp27-none-any.whl |-- py-1.4.31-py2.py3-none-any.whl |-- pytest-2.9.0-py2.py3-none-any.whl |-- selenium-2.52.0-cp27-none-any.whl `-- wheel-0.26.0-py2.py3-none-any.whl

3. pytest のバージョンを取得するには、次のコマンドを実行します。

$ grep "pytest" requirements.txt


pytest==2.9.0

pytest バージョンを示しており、この例では 2.9.0 です。Appium Python パッケージが有効な場合、pytest バージョンは 2.8.0 以上である必要があります。


APPIUM_WEB_PYTHON_TEST_PACKAGE_INSTALL_DEPENDENCY_WHEELS_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

依存ホイールのインストールに失敗しました。テストパッケージを解凍し、requirements.txt ファイルと wheelhouse ディレクトリを開き、requirements.txt ファイルで指定された依存ホイールがwheelhouse ディレクトリ内の依存ホイールと正確に一致することを確認して、もう一度やり直してください。






2. ホイールファイルのインストールをテストするには、次のコマンドを実行します。


API バージョン 2015-06-23213


AWS Device Farm 開発者ガイドAPPIUM_WEB_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED


Ignoring indexes: https://pypi.python.org/simpleCollecting Appium-Python-Client==0.20 (from -r ./requirements.txt (line 1))Collecting py==1.4.31 (from -r ./requirements.txt (line 2))Collecting pytest==2.9.0 (from -r ./requirements.txt (line 3))Collecting selenium==2.52.0 (from -r ./requirements.txt (line 4))Collecting wheel==0.26.0 (from -r ./requirements.txt (line 5))Installing collected packages: selenium, Appium-Python-Client, py, pytest, wheel Found existing installation: wheel 0.29.0 Uninstalling wheel-0.29.0: Successfully uninstalled wheel-0.29.0Successfully installed Appium-Python-Client-0.20 py-1.4.31 pytest-2.9.0 selenium-2.52.0 wheel-0.26.0


$ deactivate


APPIUM_WEB_PYTHON_TEST_PACKAGE_PYTEST_COLLECT_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストディレクトリでテストを収集できませんでした。テストパッケージを解凍し、"py.test --collect-only <path to your tests directory>" コマンドを実行してテストパッケージが有効であることを確認します。コマンドでエラーが出力されなくなったら再度実行してください。






2. ホイールファイルをインストールするには、次のコマンドを実行します。


3. テストを収集するには、次のコマンドを実行します。

$ py.test --collect-only tests


API バージョン 2015-06-23214



==================== test session starts ====================platform darwin -- Python 2.7.11, pytest-2.9.0, py-1.4.31, pluggy-0.3.1rootdir: /Users/zhena/Desktop/Ios/tests, inifile:collected 1 items<Module 'test_unittest.py'> <UnitTestCase 'DeviceFarmAppiumWebTests'> <TestCaseFunction 'test_devicefarm'>

==================== no tests ran in 0.11 seconds ====================


$ deactivate


AWS Device Farm での Calabash テストのトラブルシューティング

次のトピックでは、Calabash テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

CALABASH_TEST_PACKAGE_UNZIP_FAILED_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning


エラーなしでテストパッケージを解凍できることを確認します。次の例では、パッケージの名前はfeatures.zip です。


$ unzip features.zip


$ tree .

有効な Calabash パッケージでは、次のような出力が生成されます。

.`-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | `-- (.rb files) |-- support (directory) | `-- (.rb files)

API バージョン 2015-06-23215

AWS Device Farm 開発者ガイドCALABASH_TEST_PACKAGE_FEATURES_DIR_MISSING_FEATURES_DIR_MISSING

`-- (any other supporting files)

詳細については、「Calabash (p. 77)」または「Calabash (p. 104)」を参照してください。

CALABASH_TEST_PACKAGE_FEATURES_DIR_MISSING_FEATURES_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

features ディレクトリがテストパッケージツリー内に見つかりませんでした。テストパッケージを解凍し、features ディレクトリがパッケージ内にあることを確認して、もう一度試してください。

次の例では、パッケージの名前は features.zip です。




$ tree .

Calabash パッケージが有効な場合、features ディレクトリは作業ディレクトリ内にあります。

.`-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | `-- (.rb files) |-- support (directory) | `-- (.rb files) `-- (any other supporting files)


CALABASH_TEST_PACKAGE_FEATURE_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

features ディレクトリツリーに .feature ファイルが見つかりませんでした。テストパッケージを解凍してから features ディレクトリを開き、少なくとも 1 つの .feature ファイルがディレクトリにあることを確認して、もう一度試してください。




API バージョン 2015-06-23216

AWS Device Farm 開発者ガイドCALABASH_TEST_PACKAGE_STEP_DEFINITIONS_DIR_MISSING


$ tree .

Calabash パッケージが有効な場合は、features ディレクトリ内に少なくとも 1 つの .featureファイルがあります。



CALABASH_TEST_PACKAGE_STEP_DEFINITIONS_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

step_definitions ディレクトリがテストパッケージ内に見つかりませんでした。テストパッケージを解凍してから features ディレクトリを開き、step_definitions ディレクトリがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Calabash パッケージが有効な場合、step_definitions ディレクトリは features ディレクトリ内にあります。



API バージョン 2015-06-23217

AWS Device Farm 開発者ガイドCALABASH_TEST_PACKAGE_SUPPORT_DIR_MISSING

CALABASH_TEST_PACKAGE_SUPPORT_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

support ディレクトリがテストパッケージ内に見つかりませんでした。テストパッケージを解凍してから features ディレクトリを開き、support ディレクトリがパッケージ内にあることを確認して、もう一度試してください。





$ tree .

Calabash パッケージが有効な場合、support ディレクトリは features ディレクトリ内にあります。



CALABASH_TEST_PACKAGE_RUBY_FILE_MISSING_IN_STEP_DEFINITIONS_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

step_definitions ディレクトリツリー内に ruby ファイルが見つかりませんでした。テストパッケージを解凍してから step_definitions ディレクトリを開き、少なくとも 1 つの ruby ファイルがディレクトリにあることを確認して、もう一度試してください。





$ tree .

API バージョン 2015-06-23218

AWS Device Farm 開発者ガイドCALABASH_TEST_PACKAGE_RUBY_FILE_MISSING_IN_SUPPORT_DIR

Calabash パッケージが有効な場合は、step_definitions ディレクトリ内に少なくとも 1 つのruby ファイルがあります。

.`-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | |-- one-ruby.rb | |-- folder | | `-- another-ruby.rb | `-- (any other supporting files) |-- support (directory) | `-- (.rb files) `-- (any other supporting files)


CALABASH_TEST_PACKAGE_RUBY_FILE_MISSING_IN_SUPPORT_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

support ディレクトリツリー内に ruby ファイルが見つかりませんでした。テストパッケージを解凍してから support ディレクトリを開き、少なくとも 1 つの ruby ファイルがディレクトリにあることを確認して、もう一度試してください。





$ tree .

Calabash パッケージが有効な場合は、support ディレクトリ内に少なくとも 1 つの ruby ファイルがあります。

.`-- features (directory) |-- my-feature-1-file-name.feature |-- my-feature-2-file-name.feature |-- my-feature-N-file-name.feature |-- step_definitions (directory) | `-- (.rb files) |-- support (directory) | |-- one-ruby.rb | |-- folder | | `-- another-ruby.rb | `-- (any other supporting files) `-- (any other supporting files)


API バージョン 2015-06-23219

AWS Device Farm 開発者ガイドCALABASH_TEST_PACKAGE_EMBEDDED_SERVER_MISSING

CALABASH_TEST_PACKAGE_EMBEDDED_SERVER_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内に埋め込みサーバーが見つかりませんでした。コマンド "calabash-ios check<path to your test package>" を実行してサーバーがパッケージ内にあることを確認します。その後、calabash フレームワークを見つけてからもう一度試してください。

Calabash テストには、iOS アプリケーション内の埋め込みウェブサーバーが含まれています。

埋め込みウェブサーバーが iOS アプリケーション内にあることを確認してください。次の例では、iOS アプリケーションの名前は AWSDeviceFarmiOSReferenceApp.ipa です。

• iOS アプリケーションを作業ディレクトリにコピーし、次に以下のコマンドを実行します。

$ calabash-ios check AWSDeviceFarmiOSReferenceApp.ipa

有効な iOS アプリケーションでは、次のような出力が生成されます。

Ipa: AWSDeviceFarmiOSReferenceApp.ipa *contains* calabash.framework0.19.0


CALABASH_TEST_PACKAGE_DRY_RUN_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.feature ファイルの迅速なスキャンに失敗しました。テストパッケージを解凍し、コマンド"calabash --dry-run <path to your features directory>" を実行してファイルが有効なことを確認します。コマンドでエラーが出力されなくなったらもう一度試してください。

アップロード検証プロセス中に、Device Farm は機能を実際に実行せずに迅速にスキャンします。

機能が有効であることを確認します。次の例では、パッケージの名前は features.zip です。



正常にパッケージを解凍したら、作業ディレクトリ内に features ディレクトリがあります。2. 機能をスキャンするには、次のコマンドを実行します。

$ cucumber-ios --dry-run --format json features

有効な Calabash パッケージでは、次のような出力が生成されます。

[ { "uri": "features/homepage.feature", "id": "home-page", "keyword": "Feature",

API バージョン 2015-06-23220

AWS Device Farm 開発者ガイドインストルメンテーション

"name": "Home Page", "description": " As a Device Farm user\n I would like to be able to see examples of testing a static homepage\n So I can apply it to my future tests.", "line": 1, "elements": [ { "id": "home-page;a-valid-homepage", "keyword": "Scenario", "name": "A Valid Homepage", "description": "", "line": 6, "type": "scenario", "steps": [ { "keyword": "Given ", "name": "that I navigate to the \"Home\" menu category", "line": 7, "match": { "location": "/Library/Ruby/Gems/2.0.0/gems/cucumber-2.4.0/lib/cucumber/step_match.rb:98" }, "result": { "status": "skipped", "duration": 16000 } } ] } ] }]


AWS Device Farm でのインストルメンテーションテストのトラブルシューティング

次のトピックでは、インストルメンテーションテストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための推奨する回避策を示します。

INSTRUMENTATION_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テスト APK ファイルを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでテストパッケージを解凍できることを確認します。次の例では、パッケージ名は app-debug-androidTest-unaligned.apk です。


$ unzip app-debug-androidTest-unaligned.apk


API バージョン 2015-06-23221

AWS Device Farm 開発者ガイドINSTRUMENTATION_TEST_PACKAGE_AAPT_DEBUG_BADGING_FAILED

$ tree .

有効なインストルメンテーションテストパッケージでは、次のような出力が生成されます。

.|-- AndroidManifest.xml|-- classes.dex|-- resources.arsc|-- LICENSE-junit.txt|-- junit (directory)`-- META-INF (directory)

詳細については、「Android および AWS Device Farm の計器の操作 (p. 79)」を参照してください。

INSTRUMENTATION_TEST_PACKAGE_AAPT_DEBUG_BADGING_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージに関する情報を抽出できませんでした。"aapt debug badging <path to your testpackage>" コマンドを実行してテストパッケージが有効であることを確認します。コマンドでエラーが出力されなくなったら一度試してください。

アップロードの検証プロセス中に、Device Farm は aapt debug badging <path to yourpackage> コマンドの出力からの情報を解析します。

インストルメンテーションテストパッケージでこのコマンドを正常に実行できることを確認してください。

次の例では、パッケージ名は app-debug-androidTest-unaligned.apk です。

• テストパッケージを作業ディレクトリにコピーし、次のコマンドを実行します。

$ aapt debug badging app-debug-androidTest-unaligned.apk


package: name='com.amazon.aws.adf.android.referenceapp.test' versionCode='' versionName='' platformBuildVersionName='5.1.1-1819727'sdkVersion:'9'targetSdkVersion:'22'application-label:'Test-api'application: label='Test-api' icon=''application-debuggableuses-library:'android.test.runner'feature-group: label=''uses-feature: name='android.hardware.touchscreen'uses-implied-feature: name='android.hardware.touchscreen' reason='default feature for all apps'supports-screens: 'small' 'normal' 'large' 'xlarge'supports-any-density: 'true'locales: '--_--'densities: '160'


API バージョン 2015-06-23222

AWS Device Farm 開発者ガイドINSTRUMENTATION_TEST_PACKAGE_INSTRUMENTATION_RUNNER_VALUE_MISSING

INSTRUMENTATION_TEST_PACKAGE_INSTRUMENTATION_RUNNER_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

AndroidManifest.xml に、インストルメンテーションランナーの値が見つかりませんでした。"aaptdump xmltree <path to your test package> AndroidManifest.xml" コマンドを実行してテストパッケージが有効であることを確認し、キーワード "instrumentation" の後ろにインストルメンテーションランナーの値を見つけた後にもう一度試して下さい。

アップロードの検証プロセス中に、Device Farm はパッケージに含まれる XML ファイルの XML 解析ツリーからインストルメンテーションランナーの値を解析します。以下の aapt dump xmltree <pathto your package> AndroidManifest.xml コマンドを使用できます。

インストルメンテーションテストパッケージでこのコマンドを実行でき、インストルメンテーションの値を正常に見つけられることを確認してください。



$ aapt dump xmltree app-debug-androidTest-unaligned.apk AndroidManifest.xml | grep -A5 "instrumentation"


E: instrumentation (line=9) A: android:label(0x01010001)="Tests for com.amazon.aws.adf.android.referenceapp" (Raw: "Tests for com.amazon.aws.adf.android.referenceapp") A: android:name(0x01010003)="android.support.test.runner.AndroidJUnitRunner" (Raw: "android.support.test.runner.AndroidJUnitRunner") A: android:targetPackage(0x01010021)="com.amazon.aws.adf.android.referenceapp" (Raw: "com.amazon.aws.adf.android.referenceapp") A: android:handleProfiling(0x01010022)=(type 0x12)0x0 A: android:functionalTest(0x01010023)=(type 0x12)0x0


INSTRUMENTATION_TEST_PACKAGE_AAPT_DUMP_XMLTREE_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

有効な AndroidManifest.xml がテストパッケージ内に見つかりませんでした。"aapt dump xmltree<path to your test package> AndroidManifest.xml" コマンドを実行してテストパッケージが有効であることを確認します。コマンドでエラーが出力されくなったらもう一度試してください。

アップロードの検証プロセス中に、Device Farm は aapt dump xmltree <path to your package>AndroidManifest.xml コマンドを使用してパッケージに含まれる XML ファイルの XML 解析ツリーから情報を解析します。

インストルメンテーションテストパッケージでこのコマンドを正常に実行できることを確認してください。

API バージョン 2015-06-23223

AWS Device Farm 開発者ガイドINSTRUMENTATION_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING



$ aapt dump xmltree app-debug-androidTest-unaligned.apk AndroidManifest.xml


N: android=http://schemas.android.com/apk/res/android E: manifest (line=2) A: package="com.amazon.aws.adf.android.referenceapp.test" (Raw: "com.amazon.aws.adf.android.referenceapp.test") A: platformBuildVersionCode=(type 0x10)0x16 (Raw: "22") A: platformBuildVersionName="5.1.1-1819727" (Raw: "5.1.1-1819727") E: uses-sdk (line=5) A: android:minSdkVersion(0x0101020c)=(type 0x10)0x9 A: android:targetSdkVersion(0x01010270)=(type 0x10)0x16 E: instrumentation (line=9) A: android:label(0x01010001)="Tests for com.amazon.aws.adf.android.referenceapp" (Raw: "Tests for com.amazon.aws.adf.android.referenceapp") A: android:name(0x01010003)="android.support.test.runner.AndroidJUnitRunner" (Raw: "android.support.test.runner.AndroidJUnitRunner") A: android:targetPackage(0x01010021)="com.amazon.aws.adf.android.referenceapp" (Raw: "com.amazon.aws.adf.android.referenceapp") A: android:handleProfiling(0x01010022)=(type 0x12)0x0 A: android:functionalTest(0x01010023)=(type 0x12)0x0 E: application (line=16) A: android:label(0x01010001)=@0x7f020000 A: android:debuggable(0x0101000f)=(type 0x12)0xffffffff E: uses-library (line=17) A: android:name(0x01010003)="android.test.runner" (Raw: "android.test.runner")


INSTRUMENTATION_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内にパッケージ名が見つかりませんでした。"aapt debug badging <path to yourtest package>" コマンドを実行してテストパッケージが有効であることを確認し、キーワード"package: name" の後ろにパッケージ名の値を見つけた後にもう一度試して下さい。

アップロードの検証プロセス中に、Device Farm は aapt debug badging <path to yourpackage> コマンドの出力からパッケージ名の値を解析します。

インストルメンテーションテストパッケージでこのコマンドを実行でき、パッケージ名の値を正常に見つけられることを確認してください。



$ aapt debug badging app-debug-androidTest-unaligned.apk | grep "package: name="

API バージョン 2015-06-23224

AWS Device Farm 開発者ガイドiOS アプリケーション


package: name='com.amazon.aws.adf.android.referenceapp.test' versionCode='' versionName='' platformBuildVersionName='5.1.1-1819727'


AWS Device Farm の iOS アプリケーションテストのトラブルシューティング

次のトピックでは、iOS アプリケーションテストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

Note


IOS_APP_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

アプリケーションを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでアプリケーションパッケージを解凍できることを確認します。次の例では、パッケージの名前は AWSDeviceFarmiOSReferenceApp.ipa です。

1. アプリケーションパッケージを作業ディレクトリにコピーし、次に以下のコマンドを実行します。

$ unzip AWSDeviceFarmiOSReferenceApp.ipa


$ tree .

有効な iOS アプリケーションパッケージでは、次のような出力が生成されます。

.`-- Payload (directory) `-- AWSDeviceFarmiOSReferenceApp.app (directory) |-- Info.plist `-- (any other files)

詳細については、「AWS Device Farm での iOS テストの実行 (p. 82)」を参照してください。

IOS_APP_PAYLOAD_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23225

AWS Device Farm 開発者ガイドIOS_APP_APP_DIR_MISSING

Warning

アプリケーション内に Payload ディレクトリが見つかりませんでした。アプリケーションを解凍し、Payload ディレクトリがパッケージ内にあることを確認して、もう一度試してください。

次の例では、パッケージの名前は AWSDeviceFarmiOSReferenceApp.ipa です。




$ tree .

iOS アプリケーションパッケージが有効な場合、Payload ディレクトリは作業ディレクトリ内にあります。



IOS_APP_APP_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Payload ディレクトリ内に .app ディレクトリが見つかりませんでした。アプリケーションを解凍し、次に Payload ディレクトリを開き .app ディレクトリがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

iOS アプリケーションパッケージが有効な場合、Payload ディレクトリ内にこの例のAWSDeviceFarmiOSReferenceApp.app のような .app ディレクトリがあります。

.`-- Payload (directory) `-- AWSDeviceFarmiOSReferenceApp.app (directory) |-- Info.plist

API バージョン 2015-06-23226

AWS Device Farm 開発者ガイドIOS_APP_PLIST_FILE_MISSING

`-- (any other files)


IOS_APP_PLIST_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.app ディレクトリ内に Info.plist ファイルが見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリを開き Info.plist ファイルがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

iOS アプリケーションパッケージが有効な場合、この例の AWSDeviceFarmiOSReferenceApp.appのような .app ディレクトリ内に Info.plist ファイルがあります。



IOS_APP_CPU_ARCHITECTURE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルに CPU アーキテクチャの値が見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "UIRequiredDeviceCapabilities"が指定されていることを確認して、もう一度試してください。





API バージョン 2015-06-23227

AWS Device Farm 開発者ガイドIOS_APP_PLATFORM_VALUE_MISSING

$ tree .

この例の AWSDeviceFarmiOSReferenceApp.app のような .app ディレクトリ内に Info.plistファイルがあるはずです。


3. CPU アーキテクチャの値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。

Python の場合、次のコマンドを実行して biplist モジュールをインストールできます。

$ pip install biplist

4. 次に、Python を開き、次のコマンドを入力します。

import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['UIRequiredDeviceCapabilities']


['armv7']


IOS_APP_PLATFORM_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルにプラットフォームの値が見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleSupportedPlatforms"が指定されていることを確認して、もう一度試してください。





$ tree .


API バージョン 2015-06-23228

AWS Device Farm 開発者ガイドIOS_APP_WRONG_PLATFORM_DEVICE_VALUE


3. プラットフォームの値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。




import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['CFBundleSupportedPlatforms']


['iPhoneOS']


IOS_APP_WRONG_PLATFORM_DEVICE_VALUE次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルでプラットフォームデバイスの値が間違っていることが分かりました。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キーの値"CFBundleSupportedPlatforms" にキーワード "simulator" が含まれていないことを確認して、もう一度試してください。





$ tree .


.`-- Payload (directory) `-- AWSDeviceFarmiOSReferenceApp.app (directory) |-- Info.plist

API バージョン 2015-06-23229

AWS Device Farm 開発者ガイドIOS_APP_FORM_FACTOR_VALUE_MISSING






import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['CFBundleSupportedPlatforms']


['iPhoneOS']

iOS アプリケーションが有効な場合、値にキーワード simulator を含めることはできません。


IOS_APP_FORM_FACTOR_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルにフォームファクタの値が見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "UIDeviceFamily" が指定されていることを確認して、もう一度試してください。





$ tree .



3. フォームファクタの値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。

API バージョン 2015-06-23230

AWS Device Farm 開発者ガイドIOS_APP_PACKAGE_NAME_VALUE_MISSING




import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['UIDeviceFamily']


[1, 2]


IOS_APP_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルにパッケージ名の値が見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleIdentifier" が指定されていることを確認して、もう一度試してください。





$ tree .



3. パッケージ名の値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。




API バージョン 2015-06-23231

AWS Device Farm 開発者ガイドIOS_APP_EXECUTABLE_VALUE_MISSING

import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['CFBundleIdentifier']


Amazon.AWSDeviceFarmiOSReferenceApp


IOS_APP_EXECUTABLE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルに実行可能な値が見つかりませんでした。アプリケーションを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleExecutable" が指定されていることを確認して、もう一度試してください。





$ tree .



3. 実行可能な値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。




import biplistinfo_plist = biplist.readPlist('Payload/AWSDeviceFarmiOSReferenceApp-cal.app/Info.plist')print info_plist['CFBundleExecutable']


API バージョン 2015-06-23232


AWSDeviceFarmiOSReferenceApp


AWS Device Farm での UI Automator テストのトラブルシューティング

次のトピックでは、UI Automator テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

UIAUTOMATOR_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テスト JAR ファイルを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。Note


エラーなしでアプリケーションパッケージを解凍できることを確認します。次の例では、パッケージの名前は com.uiautomator.example.jar です。


$ unzip com.uiautomator.example.jar


$ tree .

有効な UI Automator パッケージでは、次のような出力が生成されます。

.|-- classes.dex |-- META-INF (directory)| `-- MANIFEST.MF `-- (any other files)

詳細については、「UI Automator (p. 80)」を参照してください。

AWS Device Farm での XCTest テストのトラブルシューティング

次のトピックでは、XCTest テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するための回避策を推奨します。

API バージョン 2015-06-23233

AWS Device Farm 開発者ガイドXCTEST_TEST_PACKAGE_UNZIP_FAILED

Note

以下の指示は MacOS を使用していることを前提としています。

XCTEST_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning


エラーなしでアプリケーションパッケージを解凍できることを確認します。次の例では、パッケージ名は[swiftExampleTests.xctest-1.zip] です。


$ unzip swiftExampleTests.xctest-1.zip


$ tree .

有効な XCTest パッケージでは、次のような出力が生成されます。

.`-- swiftExampleTests.xctest (directory) |-- Info.plist `-- (any other files)

詳細については、「XCTest for iOS と AWS Device Farm の使用 (p. 107)」を参照してください。

XCTEST_TEST_PACKAGE_XCTEST_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テストパッケージ内に .xctest ディレクトリが見つかりませんでした。テストパッケージを解凍し、.xctest ディレクトリがパッケージ内にあることを確認して、もう一度試してください。

次の例では、パッケージ名は [swiftExampleTests.xctest-1.zip] です。




$ tree .

XCTest パッケージが有効である場合、作業ディレクトリ内に swiftExampleTests.xctest に類似した名前のディレクトリがあります。ディレクトリ名の末尾は .xctest です。

API バージョン 2015-06-23234

AWS Device Farm 開発者ガイドXCTEST_TEST_PACKAGE_PLIST_FILE_MISSING



XCTEST_TEST_PACKAGE_PLIST_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.xctest ディレクトリ内に Info.plist ファイルが見つかりませんでした。テストパッケージを解凍し、次に .xctest ディレクトリを開き Info.plist ファイルがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

XCTest パッケージが有効な場合、Info.plist ファイルは .xctest ディレクトリ内にあります。以下の例では、ディレクトリ名は swiftExampleTests.xctest です。



XCTEST_TEST_PACKAGE_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルにパッケージ名の値が見つかりませんでした。テストパッケージを解凍し、次に Info.plist ファイルを開き、「CFBundleIdentifier」というキーが指定されていることを確認して、もう一度試してください。




API バージョン 2015-06-23235

AWS Device Farm 開発者ガイドXCTEST_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING


$ tree .

この例の swiftExampleTests.xctest のような .xctest ディレクトリ内に Info.plist ファイルがあるはずです。






import biplistinfo_plist = biplist.readPlist('swiftExampleTests.xctest/Info.plist')print info_plist['CFBundleIdentifier']

有効な XCtest アプリケーションパッケージでは、次のような出力が生成されます。

com.amazon.kanapka.swiftExampleTests


XCTEST_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルに実行可能な値が見つかりませんでした。テストパッケージを解凍し、次にInfo.plist ファイルを開き、「CFBundleExecutable」というキーが指定されていることを確認して、もう一度試してください。





$ tree .

この例の swiftExampleTests.xctest のような .xctest ディレクトリ内に Info.plist ファイルがあるはずです。

API バージョン 2015-06-23236

AWS Device Farm 開発者ガイドXCTest UI






import biplistinfo_plist = biplist.readPlist('swiftExampleTests.xctest/Info.plist')print info_plist['CFBundleExecutable']

有効な XCtest アプリケーションパッケージでは、次のような出力が生成されます。

swiftExampleTests


AWS Device Farm での XCTest UI テストのトラブルシューティング

次のトピックでは、XCTest UI テストのアップロード中に発生するエラーメッセージを示し、各エラーを解決するために推奨される回避策を示します。

Note


XCTEST_UI_TEST_PACKAGE_UNZIP_FAILED次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

テスト IPA ファイルを開けませんでした。ファイルが有効であることを確認してから、もう一度お試しください。

エラーなしでアプリケーションパッケージを解凍できることを確認します。次の例では、パッケージ名はswift-sample-UI.ipa です。


$ unzip swift-sample-UI.ipa


API バージョン 2015-06-23237

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_PAYLOAD_DIR_MISSING

$ tree .


.`-- Payload (directory) `-- swift-sampleUITests-Runner.app (directory) |-- Info.plist |-- Plugins (directory) | `swift-sampleUITests.xctest (directory) | |-- Info.plist | `-- (any other files) `-- (any other files)

詳細については、「XCTest UI (p. 109)」を参照してください。

XCTEST_UI_TEST_PACKAGE_PAYLOAD_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Payload のディレクトリがテストパッケージ内に見つかりませんでした。テストパッケージを解凍し、Payload ディレクトリがパッケージ内にあることを確認して、もう一度試してください。

次の例では、パッケージ名は swift-sample-UI.ipa です。




$ tree .

XCTest UI パッケージが有効な場合、Payload ディレクトリは作業ディレクトリ内にあります。



XCTEST_UI_TEST_PACKAGE_APP_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23238

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_PLUGINS_DIR_MISSING

Warning

Payload ディレクトリ内に .app ディレクトリが見つかりませんでした。テストパッケージを解凍し、次に Payload ディレクトリを開き .app ディレクトリがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

XCTest UI パッケージが有効な場合、Payload ディレクトリ内にこの例の swift-sampleUITests-Runner.app のような .app ディレクトリがあります。



XCTEST_UI_TEST_PACKAGE_PLUGINS_DIR_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.app ディレクトリ内に Plugins ディレクトリが見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリを開き Plugins ディレクトリがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

XCTest UI パッケージが有効な場合、Plugins ディレクトリは .app ディレクトリ内にあります。この例では、ディレクトリ名は swift-sampleUITests-Runner.app です。

.

API バージョン 2015-06-23239

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_XCTEST_DIR_MISSING_IN_PLUGINS_DIR

`-- Payload (directory) `-- swift-sampleUITests-Runner.app (directory) |-- Info.plist |-- Plugins (directory) | `swift-sampleUITests.xctest (directory) | |-- Info.plist | `-- (any other files) `-- (any other files)


XCTEST_UI_TEST_PACKAGE_XCTEST_DIR_MISSING_IN_PLUGINS_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Plugins ディレクトリ内に .xctest ディレクトリが見つかりませんでした。テストパッケージを解凍し、次に Plugins ディレクトリを開き .xctest ディレクトリがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

XCTest UI パッケージが有効な場合、.xctest ディレクトリは Plugins ディレクトリ内にあります。この例では、ディレクトリ名は swift-sampleUITests.xctest です。



XCTEST_UI_TEST_PACKAGE_PLIST_FILE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.app ディレクトリ内に Info.plist ファイルが見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリを開き Info.plist ファイルがディレクトリ内にあることを確認して、もう一度試してください。


API バージョン 2015-06-23240

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_PLIST_FILE_MISSING_IN_XCTEST_DIR




$ tree .

XCTest UI パッケージが有効な場合、Info.plist ファイルは .app ディレクトリ内にあります。次の例では、ディレクトリ名は swift-sampleUITests-Runner.app です。



XCTEST_UI_TEST_PACKAGE_PLIST_FILE_MISSING_IN_XCTEST_DIR次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.xctest ディレクトリ内に Info.plist ファイルが見つかりませんでした。テストパッケージを解凍し、次に .xctest ディレクトリを開き Info.plist ファイルがディレクトリ内にあることを確認して、もう一度試してください。





$ tree .

XCTest UI アプリケーションパッケージが有効な場合、Info.plist ファイルは .xctest ディレクトリ内にあります。以下の例では、ディレクトリ名は swift-sampleUITests.xctest です。

.`-- Payload (directory) `-- swift-sampleUITests-Runner.app (directory) |-- Info.plist |-- Plugins (directory) | `swift-sampleUITests.xctest (directory) | |-- Info.plist | `-- (any other files)

API バージョン 2015-06-23241

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_CPU_ARCHITECTURE_VALUE_MISSING



XCTEST_UI_TEST_PACKAGE_CPU_ARCHITECTURE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist ファイルに CPU アーキテクチャの値が見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "UIRequiredDeviceCapabilities"が指定されていることを確認して、もう一度試してください。





$ tree .

この例の swift-sampleUITests-Runner.app のような .app ディレクトリ内に Info.plistファイルがあるはずです。


3. CPU アーキテクチャの値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。




import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist') print info_plist['UIRequiredDeviceCapabilities']

有効な XCtest UI パッケージでは、次のような出力が生成されます。

['armv7']


API バージョン 2015-06-23242

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_PLATFORM_VALUE_MISSING

XCTEST_UI_TEST_PACKAGE_PLATFORM_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

Info.plist にプラットフォームの値が見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleSupportedPlatforms" が指定されていることを確認して、もう一度試してください。





$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist')print info_plist['CFBundleSupportedPlatforms']


['iPhoneOS']


XCTEST_UI_TEST_PACKAGE_WRONG_PLATFORM_DEVICE_VALUE次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23243

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_FORM_FACTOR_VALUE_MISSING

Warning

Info.plist ファイルでプラットフォームデバイスの値が間違っていることが分かりました。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キーの値"CFBundleSupportedPlatforms" にキーワード "simulator" が含まれていないことを確認して、もう一度試してください。





$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist')print info_plist['CFBundleSupportedPlatforms']


['iPhoneOS']

XCTest UI パッケージが有効な場合、値にキーワード simulator を含めることはできません。


XCTEST_UI_TEST_PACKAGE_FORM_FACTOR_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23244

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_PACKAGE_NAME_VALUE_MISSING

Warning

Info.plist にフォームファクタの値が見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "UIDeviceFamily" が指定されていることを確認して、もう一度試してください。





$ tree .



3. フォームファクタの値を見つけるため、Xcode または Python を使用して Info.plist を開くことができます。




import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist')print info_plist['UIDeviceFamily']


[1, 2]


XCTEST_UI_TEST_PACKAGE_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23245

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING

Warning

Info.plist ファイルにパッケージ名の値が見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleIdentifier" が指定されていることを確認して、もう一度試してください。





$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist')print info_plist['CFBundleIdentifier']


com.apple.test.swift-sampleUITests-Runner


XCTEST_UI_TEST_PACKAGE_EXECUTABLE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

API バージョン 2015-06-23246

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING

Warning

Info.plist ファイルに実行可能な値が見つかりませんでした。テストパッケージを解凍し、次に .app ディレクトリ内の Info.plist ファイルを開き、キー "CFBundleExecutable" が指定されていることを確認して、もう一度試してください。





$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Info.plist')print info_plist['CFBundleExecutable']


XCTRunner


XCTEST_UI_TEST_PACKAGE_TEST_PACKAGE_NAME_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.xctest ディレクトリ内の Info.plist ファイルにパッケージ名の値が見つかりませんでした。テストパッケージを解凍し、次に .xctest ディレクトリ内の Info.plist ファイルを開き、キー"CFBundleIdentifier" が指定されていることを確認して、もう一度試してください。

API バージョン 2015-06-23247

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_TEST_EXECUTABLE_VALUE_MISSING





$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Plugins/swift-sampleUITests.xctest/Info.plist')print info_plist['CFBundleIdentifier']


com.amazon.swift-sampleUITests


XCTEST_UI_TEST_PACKAGE_TEST_EXECUTABLE_VALUE_MISSING次のメッセージが表示された場合は、次の手順に従って問題を解決してください。

Warning

.xctest ディレクトリ内の Info.plist ファイルに実行可能な値が見つかりませんでした。テストパッケージを解凍し、次に .xctest ディレクトリ内の Info.plist ファイルを開き、キー"CFBundleExecutable" が指定されていることを確認して、もう一度試してください。



API バージョン 2015-06-23248

AWS Device Farm 開発者ガイドXCTEST_UI_TEST_PACKAGE_TEST_EXECUTABLE_VALUE_MISSING



$ tree .







import biplistinfo_plist = biplist.readPlist('Payload/swift-sampleUITests-Runner.app/Plugins/swift-sampleUITests.xctest/Info.plist')print info_plist['CFBundleExecutable']


swift-sampleUITests


API バージョン 2015-06-23249

AWS Device Farm 開発者ガイドIdentity and Access Management

AWS Device Farm のセキュリティAWS では、クラウドのセキュリティが最優先事項です。AWS のお客様は、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャから利点を得られます。

セキュリティは、AWS とお客様の間の共有責任です。責任共有モデルでは、これをクラウドのセキュリティおよびクラウド内のセキュリティと説明しています。

• クラウドのセキュリティ – AWS は、AWS クラウド内で AWS サービスを実行するインフラストラクチャを保護する責任を担います。また、AWS は、使用するサービスを安全に提供します。AWSコンプライアンスプログラムの一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。AWS Device Farmに適用されるコンプライアンスプログラムの詳細については、「コンプライアンスプログラムの対象範囲に含まれる AWS のサービス」を参照してください。

• クラウド内のセキュリティ – お客様の責任はお客様が使用する AWS のサービスによって決まります。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。

このドキュメントは、Device Farm を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するように Device Farmを設定する方法について説明します。また、Device Farm リソースのモニタリングや保護に役立つ他のAWS のサービスの使用方法についても説明します。

トピック• AWS Device Farm での Identity and Access Management (p. 250)• AWS Device Farm のコンプライアンス検証 (p. 262)• AWS Device Farm でのデータ保護 (p. 262)• AWS Device Farm での耐障害性 (p. 265)• AWS Device Farm でのインフラストラクチャセキュリティ (p. 265)• Device Farm での設定の脆弱性の分析と管理 (p. 266)• Device Farm でのインシデントへの対応 (p. 267)• Device Farm でのログ記録とモニタリング (p. 267)• Device Farm のセキュリティのベストプラクティス (p. 267)

AWS Device Farm での Identity and AccessManagement

対象者AWS Identity and Access Management (IAM) の用途は、Device Farm で行う作業によって異なります。

サービスユーザー – ジョブを実行するために Device Farm サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。作業を実行するためにさらに多くの Device Farm 機能を使用するとき、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Device Farm の機能にアクセスできない場合は、「AWS Device Farm Identity and Access のトラブルシューティング (p. 260)」を参照してください。

API バージョン 2015-06-23250

http://aws.amazon.com/compliance/shared-responsibility-model/

http://aws.amazon.com/compliance/programs/


http://aws.amazon.com/compliance/services-in-scope/

AWS Device Farm 開発者ガイドアイデンティティを使用した認証

サービス管理者 – 社内の Device Farm リソースを担当している場合は、おそらく Device Farm へのフルアクセスがあります。従業員がどの Device Farm 機能とリソースアクセスする必要があるかを決定するのは管理者の仕事です。その後で、サービスユーザーのアクセス許可を変更するために、IAM 管理者にリクエストを送信する必要があります。IAM の基本概念については、このページの情報を確認します。お客様の会社で Device Farm の IAM を利用する方法の詳細については、「AWS Device Farm と IAM の連携 (p. 253)」を参照してください。

IAM 管理者 – IAM 管理者は、Device Farm へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できる Device Farm アイデンティティベースのポリシーの例を表示するには、「AWS Device Farm アイデンティティベースのポリシーの例 (p. 257)」を参照してください。

アイデンティティを使用した認証認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS マネジメントコンソールを使用するサインインの詳細については、IAM ユーザーガイドの「IAM コンソールとサインインページ」を参照してください。

AWS アカウントのルートユーザー、IAM ユーザーとして、または IAM ロールを引き受けて、認証されている (AWS にサインインしている) 必要があります。会社のシングルサインオン認証を使用することも、Google や Facebook を使用してサインインすることもできます。このような場合、管理者は以前にIAM ロールを使用して ID フェデレーションを設定しました。他の会社の認証情報を使用して AWS にアクセスした場合、ロールを間接的に割り当てられています。

AWS マネジメントコンソールへ直接サインインするには、ルートユーザー E メールまたは IAM ユーザー名とパスワードを使用します。ルートユーザーまたは IAM を使用して AWS にプログラム的にアクセスできます。AWS では、SDK とコマンドラインツールを提供して、お客様の認証情報を使用して、リクエストに暗号で署名できます。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。これには、インバウンド API リクエストを認証するためのプロトコル、署名バージョン 4 を使用します。リクエストの認証の詳細については、AWS General Referenceの「署名バージョン 4 の署名プロセス」を参照してください。

使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。たとえば、AWS では多要素認証 (MFA) を使用してアカウントのセキュリティを高めることを推奨しています。詳細については、IAM ユーザーガイドの「AWS のデバイスに多要素認証 (MFA) を使用」を参照してください。

AWS アカウントのルートユーザーAWS アカウントを初めて作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権限を持つシングルサインインアイデンティティで始めます。このアイデンティティはAWS アカウントルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでのサインインによりアクセスします。強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためだけにルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザー認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。

IAM ユーザーとグループIAM ユーザーは、単一のユーザーまたはアプリケーションに特定のアクセス許可がある AWS アカウント内のアイデンティティです。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。アクセスキーを生成する方法の詳細については、IAM ユーザーガイドの「IAM ユーザーのアクセスキーの管理」を参照してください。IAM ユーザーにアクセスキーを生成するとき、必ずキーペアを表示して安全に保存してください。後になって、シークレットアクセスキーを回復することはできません。新しいアクセスキーペアを生成する必要があります。

IAM グループは、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、一度に複数のユーザーに対してアクセス許可を指定で

API バージョン 2015-06-23251

https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html

https://console.aws.amazon.com/

https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html

AWS Device Farm 開発者ガイドアイデンティティを使用した認証

きます。多数の組のユーザーがある場合、グループを使用すると管理が容易になります。たとえば、IAMAdmin という名前のグループを設定して、そのグループに IAM リソースを管理するアクセス許可を与えることができます。

ユーザーは、ロールとは異なります。ユーザーは 1 人の特定の人またはアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が利用できます。詳細については、IAMユーザーガイドの「IAM ユーザーの作成が適している場合 (ロールではなく)」を参照してください。

IAM ロールIAM ロールは、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAMユーザーに似ていますが、特定のユーザーに関連付けられていません。ロールを切り替えて、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWSCLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、IAM ユーザーガイドの「IAM ロールの使用」を参照してください。

IAM ロールと一時的な認証情報は、次の状況で役立ちます。

• 一時的な IAM ユーザーアクセス許可 – IAM ユーザーは、特定のタスクに対して複数の異なるアクセス許可を一時的に IAM ロールで引き受けることができます。

• フェデレーティッドユーザーアクセス – IAM ユーザーを作成する代わりに、AWS Directory Service、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーに既存のアイデンティティを使用できます。このようなユーザーはフェデレーティッドユーザーと呼ばれます。AWS では、ID プロバイダーを通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、IAM ユーザーガイドの「フェデレーティッドユーザーとロール」を参照してください。

• クロスアカウントアクセス – IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを別のアカウントの信頼済みプリンシパルに許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

• AWS サービスアクセス – サービスロールは、サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受ける IAM ロールです。一部の AWS のサービス環境を設定するときに、サービスが引き受けるロールを定義する必要があります。このサービスロールには、サービスが必要とする AWS のリソースにサービスがアクセスするために必要なすべてのアクセス権限を含める必要があります。サービスロールはサービスによって異なりますが、多くのサービスロールでは、そのサービスの文書化された要件を満たしている限り、アクセス権限を選択することができます。サービスロールは、お客様のアカウント内のみでアクセスを提供します。他のアカウントのサービスへのアクセス権を付与するためにサービスロールを使用することはできません。IAM 内部からロールを作成、修正、削除できます。たとえば、Amazon Redshift がお客様に代わって Amazon S3 バケットにアクセスし、バケットからデータを Amazon Redshift クラスターにロードすることを許可するロールを作成できます。詳細については、IAM ユーザーガイドのAWS サービスにアクセス権限を委任するロールの作成を参照してください。

• Amazon EC2で実行されているアプリケーション – IAM ロールを使用して、EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時認証情報を取得することができます。詳細については、IAM ユーザーガイドの「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する」を参照してください。

IAM ロールを使用するべきかどうかについては、IAM ユーザーガイドの「IAM ロール (ユーザーではない)の作成が適している場合」を参照してください。

API バージョン 2015-06-23252

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role

https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role

AWS Device Farm 開発者ガイドAWS Device Farm と IAM の連携

AWS Device Farm と IAM の連携Device Farm へのアクセスを管理するために IAM を使用する前に、Device Farm でどの IAM 機能が使用できるかを理解しておく必要があります。IAM と連携する Device Farm や他の AWS のサービスの動作の概要については、IAM ユーザーガイドの「IAM と連携する AWS のサービス」を参照してください。

トピック• Device Farm のアイデンティティベースのポリシー (p. 253)• Device Farm リソースベースのポリシー (p. 255)• アクセスコントロールリスト (p. 255)• Device Farm タグに基づいた承認 (p. 255)• Device Farm IAM のロール (p. 255)

Device Farm のアイデンティティベースのポリシーIAM アイデンティティベースのポリシーでは、許可または拒否されたアクションとリソースを指定でき、さらにアクションが許可または拒否された条件を指定できます。Device Farm は、特定のアクション、リソース、条件キーをサポートしています。JSON ポリシーで使用するすべての要素については、IAM ユーザーガイドの「IAM JSON ポリシーエレメントのリファレンス」を参照してください。

アクションIAM アイデンティティベースのポリシーの Action エレメントは、そのポリシーにより許可または拒否される特定のアクションについて説明します。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。このアクションは、関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

Device Farm のポリシーアクションでは、アクションの前にプレフィックス devicefarm: を使用します。たとえば、Device Farm desktop browser testing CreateTestGridUrl API オペレーションを使用して Selenium セッションを開始するアクセス許可を付与するには、そのポリシーにdevicefarm:CreateTestGridUrl アクションを含めます。ポリシーステートメントには、Action または NotAction 要素を含める必要があります。Device Farm は、このサービスで実行できるタスクを説明する独自の一連のアクションを定義します。

単一のステートメントに複数のアクションを指定するには、次のようにコンマで区切ります。

"Action": [ "devicefarm:action1", "devicefarm:action2"

ワイルドカード (*) を使用して複数のアクションを指定することができます。たとえば、List という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。

"Action": "devicefarm:List*"

Device Farm のアクションのリストを表示するには、IAM ユーザーガイドの「Actions Defined by AWSDevice Farm」を参照してください。

リソースResource エレメントは、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource または NotResource エレメントを含める必要があります。ARN を使用して、またはステートメントがすべてのリソースに適用されることを示すワイルドカード (*) を使用して、リソースを指定します。

API バージョン 2015-06-23253

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions



Amazon EC2 インスタンスリソースには以下のような ARN があります。

arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}

ARN の形式の詳細については、「Amazon リソースネーム (ARN) と AWS サービスの名前空間」を参照してください。

たとえば、ステートメントで i-1234567890abcdef0 インスタンスを指定するには、次の ARN を使用します。

"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"

アカウントに属するすべてのインスタンスを指定するには、ワイルドカード (*) を使用します。

"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"

リソースの作成など、一部の Device Farm アクションは、リソースで実行できません。このような場合は、ワイルドカード (*) を使用する必要があります。

"Resource": "*"

Amazon EC2 API アクションの多くが複数のリソースと関連します。たとえば、AttachVolume ではEBS ボリュームをインスタンスにアタッチするため、IAM ユーザーはボリュームおよびインスタンスを使用するアクセス許可が必要です。複数のリソースを単一のステートメントで指定するには、ARN をカンマで区切ります。

"Resource": [ "resource1", "resource2"

Device Farm リソースタイプおよびその ARN のリストを表示するには、IAM ユーザーガイドの「Resources Defined by AWS Device Farm」を参照してください。どのアクションで、各リソースのARN を指定することができるかについては、「Actions Defined by AWS Device Farm」を参照してください。

条件キーCondition エレメント (または Condition ブロック) を使用すると、ステートメントが有効な条件を指定できます。Conditionエレメントはオプションです。イコールや以下などの条件演算子を使用する条件式を構築して、リクエスト内に値のあるポリシーの条件に一致させることができます。

1 つのステートメントに複数の Condition エレメントを指定する場合、または 1 つの Condition エレメントに複数のキーを指定する場合、AWS が論理 AND 演算を使用してそれらを評価します。単一の条件キーに複数の値を指定する場合、AWS が論理 OR 演算を使用して条件を評価します。ステートメントのアクセス許可が付与される前にすべての条件が満たされる必要があります。

条件を指定する際にプレースホルダー変数も使用できます。たとえば、IAM ユーザー名でタグ付けされている場合のみ、リソースにアクセスする IAM ユーザーアクセス許可を付与できます。詳細については、IAM ユーザーガイドの「IAM ポリシーエレメント: 変数およびタグ」を参照してください。

Device Farm は独自の一連の条件キーを定義し、一部のグローバル条件キーの使用もサポートしています。すべての AWS グローバル条件キーを確認するには、IAM ユーザーガイドの「AWS グローバル条件コンテキストキー」を参照してください。

Device Farm 条件キーのリストを表示するには、IAM ユーザーガイドの「Condition Keys for AWS DeviceFarm」を参照してください。どのアクションおよびリソースと条件キーを使用できるかについては、「Actions Defined by AWS Device Farm」を参照してください。

API バージョン 2015-06-23254

https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies


https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys



例

Device Farm アイデンティティベースのポリシーの例を表示するには、「AWS Device Farm アイデンティティベースのポリシーの例 (p. 257)」を参照してください。

Device Farm リソースベースのポリシーDevice Farm は、リソースベースのポリシーをサポートしていません。

アクセスコントロールリストDevice Farm は、アクセスコントロールリスト (ACL) をサポートしていません。

Device Farm タグに基づいた承認タグを Device Farm リソースにアタッチするか、Device Farm へのリクエストでタグを渡すことができます。タグに基づいてアクセスを制御するには、aws:ResourceTag/key-name、aws:RequestTag/key-name、または aws:TagKeys の条件キーを使用して、ポリシーの条件要素でタグ情報を提供します。Device Farm リソースのタグ付けの詳細については、「Device Farm のタグ付け (p. 52)」を参照してください。

リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースのポリシーの例については、「タグに基づく Device Farm Desktop Browser Testing プロジェクトの表示 (p. 259)」を参照してください。

Device Farm IAM のロールIAM ロールは、特定のアクセス許可を持つ AWS アカウント内のエンティティです。

Device Farm を使用した一時的な認証情報の使用

Device Farm は、一時的な認証情報の使用をサポートしています。

一時的な認証情報を使用して、フェデレーションでのサインイン、IAM ロールの引き受け、またはクロスアカウントロールの引き受けを行うことができます。一時的なセキュリティ認証情報を取得するには、AssumeRole または GetFederationToken などの AWS STS API オペレーションを呼び出します。

サービスにリンクされたロール

Device Farm は、サービスにリンクされたロールをサポートしていません。

サービスにリンクされたロールによって、AWS サービスが他のサービスのリソースにアクセスして自動的にアクションを完了できます。サービスにリンクされたロールは、IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。

サービスロール

Device Farm は、サービスロールをサポートしていません。

この機能では、サービスのロールをユーザーに代わって引き受けることをサービスに許可します。このロールにより、サービスはユーザーに代わって他のサービスのリソースにアクセスし、アクションを実行できます。サービスロールは、IAM アカウントに表示され、サービスによって所有されます。つまり、IAM 管理者は、このロールのアクセス許可を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。

API バージョン 2015-06-23255

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html


https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role

AWS Device Farm 開発者ガイドポリシーを使用したアクセスの管理

ポリシーを使用したアクセスの管理AWS でアクセスをコントロールするには、ポリシーを作成して IAM アイデンティティや AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、エンティティ (ルートユーザー、IAM ユーザーまたはIAM ロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、IAM ユーザーガイドの「JSON ポリシー概要」を参照してください。

IAM 管理者は、ポリシーを使用して、AWS リソースへのアクセスを許可するユーザーと、これらのリソースで実行できるアクションを指定できます。すべての IAM エンティティ (ユーザーまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行するアクセス許可をユーザーに付与するには、管理者がユーザーにアクセス許可ポリシーをアタッチする必要があります。また、管理者は、必要なアクセス許可があるグループにユーザーを追加できます。管理者がグループにアクセス許可を付与すると、そのグループ内のすべてのユーザーにこれらのアクセス許可が付与されます。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションのアクセス許可を定義します。たとえば、iam:GetRole アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロールの情報を取得できます。

アイデンティティベースのポリシーアイデンティティベースのポリシーは、IAM ユーザー、ロール、グループなどのアイデンティティにJSON ドキュメントとしてアタッチできるアクセス許可ポリシーです。これらのポリシーは、アイデンティティが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドの「IAM ポリシーの作成」を参照してください。

アイデンティティベースのポリシーは、さらにインラインポリシーまたは管理ポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。管理ポリシーまたはインラインポリシーのいずれかを選択する方法については、IAM ユーザーガイドの「管理ポリシーとインラインポリシーの比較」を参照してください。

その他のポリシータイプAWS では、別のあまり一般的ではないポリシータイプもサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大のアクセス許可を設定できます。

• アクセス許可の境界 – アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティ(IAM ユーザーまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティの IDベースのポリシーとそのアクセス許可の境界の共通部分です。Principal フィールドでユーザーまたはロールを指定するリソースベースのポリシーは、アクセス許可の境界では制限されません。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。アクセス許可の境界の詳細については、IAM ユーザーガイドの「IAM エンティティのアクセス許可の境界」を参照してください。

• サービスコントロールポリシー (SCP) – SCP は、AWS Organizations で組織や組織単位 (OU) に最大権限を指定する JSON ポリシーです。AWS Organizations は、お客様のビジネスが所有する複数の AWSアカウントをグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントのルートユーザーなど)。組織および SCP の詳細については、AWS Organizations ユーザーガイドの「SCP の動作」を参照してください。

• セッションポリシー – セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られる

API バージョン 2015-06-23256

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html

AWS Device Farm 開発者ガイドアイデンティティベースのポリシーの例

セッションのアクセス許可は、ユーザーまたはロールの ID ベースのポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーからアクセス許可が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。詳細については、IAM ユーザーガイドの「セッションポリシー」を参照してください。

複数のポリシータイプ1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに複雑になります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、IAM ユーザーガイドの「ポリシーの評価ロジック」を参照してください。

AWS Device Farm アイデンティティベースのポリシーの例デフォルトでは、IAM ユーザーおよびロールには、Device Farm リソースを作成または変更するアクセス許可はありません。また、AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行するアクセス許可をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらのアクセス権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチします。

JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドの「[JSON] タブでのポリシーの作成」を参照してください。

トピック• ポリシーのベストプラクティス (p. 257)• ユーザーに自分のアクセス許可の表示を許可 (p. 258)• 1 つの Device Farm デスクトップブラウザテストプロジェクトへのアクセス (p. 258)• タグに基づく Device Farm Desktop Browser Testing プロジェクトの表示 (p. 259)

ポリシーのベストプラクティスアイデンティティベースのポリシーは非常に強力です。アカウント内で、Device Farm リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションを実行すると、AWS アカウントに追加料金が発生する可能性があります。アイデンティティベースのポリシーを作成または編集するときは、以下のガイドラインと推奨事項に従います。

• AWS 管理ポリシーの使用を開始する – Device Farm の使用をすばやく開始するには、AWS 管理ポリシーを使用して、従業員に必要なアクセス許可を付与します。これらのポリシーはアカウントですでに有効になっており、AWS によって管理および更新されています。詳細については、IAM ユーザーガイドの「AWS 管理ポリシーを使用したアクセス許可の使用開始」を参照してください。

• 最小権限を付与する – カスタムポリシーを作成するときは、タスクを実行するために必要なアクセス許可のみを付与します。最小限のアクセス権限から開始し、必要に応じて追加のアクセス権限を付与します。この方法は、寛容なアクセス権限で始め、後でそれらを強化しようとするよりも安全です。詳細については、IAM ユーザーガイドの「最小権限を付与する」を参照してください。

• 機密性の高いオペレーションに MFA を有効にする – 追加セキュリティとして、機密性の高リソースまたは API オペレーションにアクセスするために IAM ユーザーに対して、多要素認証 (MFA) の使用を要求します。詳細については、IAM ユーザーガイドの「AWS のデバイスに多要素認証 (MFA) を使用」を参照してください。

• 追加セキュリティに対するポリシー条件を使用する – 実行可能な範囲内で、アイデンティティベースのポリシーがリソースにアクセスできる条件を定義します。たとえば、要求が発生しなければならない許

API バージョン 2015-06-23257

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html


容 IP アドレスの範囲を指定するための条件を記述できます。指定された日付または時間範囲内でのみリクエストを許可する条件を書くことも、SSL や MFA の使用を要求することもできます。ポリシー要素の詳細については、IAM ユーザーガイドの「IAM JSON ポリシー要素: 条件」を参照してください。

ユーザーに自分のアクセス許可の表示を許可この例は

この例では、ユーザー ID にアタッチされたインラインおよび管理ポリシーの表示を IAM ユーザーに許可するポリシーを作成する方法を示します。このポリシーには、コンソールで、または AWS CLI か AWSAPI を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ]}

1 つの Device Farm デスクトップブラウザテストプロジェクトへのアクセスこの例では、AWS アカウントの IAM ユーザーに、Device Farm デスクトップブラウザテストプロジェクトの 1 つである arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111 へのアクセスを許可します。そのプロジェクトに関連するアイテムを表示できるようにする必要があります。

devicefarm:GetTestGridProject エンドポイントに加えて、アカウントにはdevicefarm:ListTestGridSessions、devicefarm:GetTestGridSession、devicefarm:ListTestGridSessionActions、および devicefarm:ListTestGridSessionArtifacts エンドポイントが必要です。

{ "Version":"2012-10-17",

API バージョン 2015-06-23258



"Statement":[ { "Sid":"GetTestGridProject", "Effect":"Allow", "Action":[ "devicefarm:GetTestGridProject" ], "Resource":"arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111" }, { "Sid":"ViewProjectInfo", "Effect":"Allow", "Action":[ "devicefarm:ListTestGridSessions", "devicefarm:ListTestGridSessionActions", "devicefarm:ListTestGridSessionArtifacts" ], "Resource":"arn:aws:devicefarm:us-west-2:111122223333:testgrid-*:123e4567-e89b-12d3-a456-426655441111/*" } ]}

CI システムを使用している場合は、各 CI 実行者に一意のアクセス認証情報を付与する必要があります。たとえば、CI システムでは、devicefarm:ScheduleRun または devicefarm:CreateUpload よりも多くのアクセス許可が必要になることはほとんどありません。以下の IAM ポリシーで概説しているのは、アップロードを作成し、そのアップロードを使用してテスト実行をスケジュールすることにより、新しいDevice Farm ネイティブアプリケーションのテストを開始することを、CI 実行者に許可する、最小限のポリシーです。

{ "Version":"2012-10-17", "Statement": [ { "$id":"scheduleTestRuns", "effect":"Allow", "Action": [ "devicefarm:CreateUpload","devicefarm:ScheduleRun" ], "Resource": [ "arn:aws:devicefarm:us-west-2:111122223333:project:123e4567-e89b-12d3-a456-426655440000", "arn:aws:devicefarm:us-west-2:111122223333:*:123e4567-e89b-12d3-a456-426655440000/*", ] } ]}

タグに基づく Device Farm Desktop Browser Testing プロジェクトの表示アイデンティティベースのポリシーの条件を使用して、タグに基づいて Device Farm リソースへのアクセスをコントロールできます。この例では、プロジェクトとセッションの表示を許可するポリシーを作成する方法を示しています。リクエスト先のリソースの Owner タグがリクエスト元のアカウントのユーザー名と一致する場合、アクセス許可が付与されます。

{ "Version": "2012-10-17",

API バージョン 2015-06-23259

AWS Device Farm 開発者ガイドトラブルシューティング

"Statement": [ { "Sid": "ListTestGridProjectSessions", "Effect": "Allow", "Action": [ "devicefarm:ListTestGridSession*", "devicefarm:GetTestGridSession", "devicefarm:ListTestGridProjects" ], "Resource": [ "arn:aws:devicefarm:us-west-2:testgrid-project:*/*" "arn:aws:devicefarm:us-west-2:testgrid-session:*/*" ], "Condition": { "StringEquals": {"aws:TagKey/Owner":"${aws:username}"} } } ]}

このポリシーをアカウントの IAM ユーザーにアタッチできます。richard-roe という名前のユーザーがDevice Farm プロジェクトまたはセッションを表示しようとする場合、プロジェクトに Owner=richard-roe または owner=richard-roe というタグが付いている必要があります。それ以外の場合、ユーザーはアクセスを拒否されます。条件キー名では大文字と小文字は区別されないため、条件タグキー Owner はOwner と owner に一致します。ポリシー要素の詳細については、IAM ユーザーガイドの「IAM JSON ポリシー要素: 条件」を参照してください。

AWS Device Farm Identity and Access のトラブルシューティング以下の情報は、Device Farm と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。

Device Farm でのアクションの実行を承認されていないAWS マネジメントコンソールでアクションの実行を承認されていないというエラーが表示された場合、管理者に問い合わせ、サポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。

以下の例のエラーは、IAM ユーザー mateojackson がコンソールを使用して、実行の詳細を表示しようとしているが、devicefarm:GetRun アクセス許可がない場合に発生します。

User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: devicefarm:GetRun on resource: arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111

この場合、Mateo は管理者に依頼し、devicefarm:GetRun アクションを使用してarn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111 リソースに対するdevicefarm:GetRun にアクセスできるようにポリシーを更新してもらいます。

iam:PassRole を実行する権限がないiam:PassRole アクションを実行する権限がないというエラーが表示された場合、管理者に問い合わせ、サポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。Device Farm にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。

API バージョン 2015-06-23260



AWS Device Farm 開発者ガイドトラブルシューティング

一部の AWS サービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。

以下の例のエラーは、marymajor という IAM ユーザーがコンソールを使用して Device Farm でアクションを実行しようする場合に発生します。ただし、アクションでは、サービスロールによって付与されたアクセス許可がサービスにある必要があります。メアリーには、ロールをサービスに渡すアクセス許可がありません。

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

この場合、メアリーは担当の管理者に iam:PassRole アクションを実行できるようにポリシーの更新を依頼します。

マイアクセスキーを表示したいIAM ユーザーアクセスキーを作成した後は、いつでもアクセスキー ID を表示できます。ただし、シークレットアクセスキーをもう一度表示することはできません。シークレットアクセスキーを紛失した場合は、新しいキーペアを作成する必要があります。

アクセスキーは、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー (例:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) の 2 つの部分から構成されます。ユーザー名とパスワードと同様に、リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユーザー名とパスワードと同様に、アクセスキーをしっかり管理してください。

Important

正規ユーザー ID を確認するためであっても、アクセスキーをサードパーティーに提供しないでください。提供すると、第三者がアカウントへの永続的アクセスを取得する場合があります。

アクセスキーペアを作成する場合、アクセスキー ID とシークレットアクセスキーを安全な場所に保存するように求めるプロンプトが表示されます。このシークレットアクセスキーは、作成時にのみ使用できます。シークレットアクセスキーを紛失した場合、新しいアクセスキーを IAM ユーザーに追加する必要があります。最大 2 つのアクセスキーを持つことができます。すでに 2 つある場合は、新しいキーペアを作成する前に、いずれかを削除する必要があります。手順を表示するには、IAM ユーザーガイドの「アクセスキーの管理」を参照してください。

管理者として Device Farm へのアクセスを他のユーザーに許可したいDevice Farm へのアクセスを他のユーザーに許可するには、アクセスを必要とする人またはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。ユーザーは、このエンティティの認証情報を使用して AWS にアクセスします。次に、Device Farm の適切なアクセス許可を付与するポリシーを、そのエンティティにアタッチする必要があります。

すぐに開始するには、IAM ユーザーガイドの「IAM が委任した最初のユーザーおよびグループの作成」を参照してください。

自分の AWS アカウント以外のユーザーに Device Farm リソースへのアクセスを許可したい他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールを引き受けるように信頼されたユーザーを指定することができます。リソースベースのポリ

API バージョン 2015-06-23261

https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey

https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-delegated-user.html

AWS Device Farm 開発者ガイドコンプライアンス検証

シーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。

詳細については、以下を参照してください。

• Device Farm でこれらの機能がサポートされるかどうかを確認するには、「AWS Device Farm と IAMの連携 (p. 253)」を参照してください。

• 所有している AWS アカウント間でリソースへのアクセスを付与する方法については、IAM ユーザーガイドの「所有している別の AWS アカウントへのアクセスを IAM ユーザーに許可」を参照してください。

• サードパーティーの AWS アカウントにリソースへのアクセスを提供する方法については、IAM ユーザーガイドの「第三者が所有する AWS アカウントへのアクセス権を付与する」を参照してください。

• ID フェデレーションを介してアクセスを提供する方法については、IAM ユーザーガイドの「外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可」を参照してください。

• クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

AWS Device Farm のコンプライアンス検証サードパーティーの監査者は、さまざまな AWS コンプライアンスプログラムの一環として AWSDevice Farm のセキュリティとコンプライアンスを評価します。これらのプログラムとしてはSOC、PCI、FedRAMP、HIPAA などがあります。AWS Device Farm は AWS コンプライアンスプログラムの対象ではありません。

特定のコンプライアンスプログラムの対象となる AWS サービスのリストについては、「コンプライアンスプログラムによる AWS 対象範囲内のサービス」を参照してください。一般的な情報については、「AWS コンプライアンスプログラム」を参照してください。

サードパーティーの監査レポートをダウンロードするには、AWS Artifact を使用します。詳細については、「AWS Artifact でレポートをダウンロードする」を参照してください。

Device Farm を使用する際のお客様のコンプライアンス責任は、データの機密性、企業のコンプライアンス目的、適用法規によって決まります。AWS は、コンプライアンスに役立つ以下のリソースを提供しています。

• セキュリティおよびコンプライアンスのクイックスタートガイド – これらのデプロイガイドでは、アーキテクチャー上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境を AWS でデプロイするための手順を説明します。

• AWS コンプライアンスのリソース – このワークブックおよびガイドのコレクションは、お客様の業界や場所に適用される場合があります。

• AWS Config 開発者ガイドの「ルールでのリソースの評価」– AWS Config は、リソース設定が、社内のプラクティス、業界のガイドラインそして規制にどの程度適合しているのかを評価します。

• AWS Security Hub – この AWS サービスでは、AWS 内のセキュリティ状態を包括的に表示しており、セキュリティ業界の標準およびベストプラクティスへの準拠を確認するのに役立ちます。

AWS Device Farm でのデータ保護AWS Device Farm は、データ保護の規制やガイドラインを含む AWS 責任共有モデルに準拠しています。AWS は、AWS のすべてのサービスを実行するグローバルなインフラストラクチャを保護する責任を負います。また、AWS は、カスタマーコンテンツや個人データを取り扱うためのセキュリティ設定の管理など、このインフラストラクチャ上でホスティングされるデータの管理を担当します。AWS のお客様と

API バージョン 2015-06-23262

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html





https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html

http://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance

http://aws.amazon.com/compliance/resources/

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html

http://aws.amazon.com/compliance/shared-responsibility-model/

AWS Device Farm 開発者ガイド転送中の暗号化

APN パートナーは、データ管理者やデータ処理者として、AWS クラウド内に保存した個人データに対する責任を負います。

データ保護目的の場合、AWS アカウント認証情報を保護して IAM (AWS Identity and AccessManagement) で個々のユーザーアカウントをセットアップし、そのユーザーに各自の職務を果たすために必要なアクセス許可のみが付与されるようにすることをお勧めします。また、以下の方法でデータを保護することをお勧めします。

• 各アカウントで多要素認証 (MFA) を使用します。• SSL/TLS を使用して AWS リソースと通信します。

• AWS CloudTrail で API とユーザーアクティビティログをセットアップします。• AWS 暗号化ソリューションを、AWS サービス内のすべてのデフォルトのセキュリティ管理と一緒に使

用します。• Amazon Macie などの高度なマネージドセキュリティサービスを使用します。これにより、Amazon S3

に保存される個人データの検出と保護が支援されます。

顧客のアカウント番号などの機密の識別情報は、[名前] フィールドなどの自由形式のフィールドに配置しないことを強くお勧めします。これは、コンソール、API、AWS CLI、または AWS SDK によって DeviceFarm や AWS の他のサービスを使用する場合も同様です。Device Farm や他のサービスに入力したすべてのデータは、診断ログに取り込まれる可能性があります。外部サーバーへの URL を指定するときは、そのサーバーへのリクエストを検証するための認証情報を URL に含めないでください。

データ保護の詳細については、AWS セキュリティブログのブログ投稿「AWS の責任共有モデルとGDPR」を参照してください。

転送中の暗号化Device Farm エンドポイントは、特に明記されていない限り、署名された HTTPS (SSL/TLS) リクエストのみをサポートしています。アップロード URL を通じて Amazon S3 から取得または配置されたすべてのコンテンツは、SSL/TLS を使用して暗号化されます。AWS での HTTPS リクエストの署名方法の詳細については、AWS 全般リファレンスの「AWS API リクエストへの署名」を参照してください。

テスト対象のアプリケーションが行う通信と、デバイスでのテストの実行中にインストールされるアプリケーションを暗号化して保護するのは、お客様の責任です。

保管時の暗号化Device Farm データは保管時に暗号化されません。

データの保持Device Farm のデータは一定期間保持されます。保持期間が終了すると、データは Device Farm 補助ストレージから削除されますが、メタデータ (ARN、アップロード日、ファイル名など) は今後の使用のために保持されます。以下の表では、さまざまなコンテンツタイプの保持期間を示しています。

コンテンツタイプ保持期間 (日数)

アップロードされたアプリケーション 30

アップロードされたテストパッケージ 30

カスタムテスト設定 30

API バージョン 2015-06-23263

http://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/

http://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/

https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html

AWS Device Farm 開発者ガイドデータ管理

コンテンツタイプ保持期間 (日数)

ログ 400

ビデオ録画やその他のアーティファクト 400

長期間保持するコンテンツをアーカイブするのは、お客様の責任です。

データ管理Device Farm のデータは、使用する機能に応じて異なる方法で管理します。このセクションでは、DeviceFarm の使用中および使用後のデータの管理方法について説明します。

デスクトップブラウザのテストSelenium セッション中に使用されるインスタンスは保存されません。ブラウザの操作の結果として生成されたすべてのデータは、セッションが終了すると破棄されます。

物理デバイスのテスト次のセクションでは、Device Farm を使用した後にデバイスをクリーンアップまたは破壊するために AWSで行うステップについて説明します。

パブリックデバイスフリート

テスト実行が完了すると、Device Farm は、パブリックデバイスフリートの各デバイスで、一連のクリーンアップタスク (アプリのアンインストールなど) を実行します。アプリのアンインストールまたは他のいずれかのクリーンアップステップを確認できない場合、デバイスが再利用される前にファクトリのリセットが実行されます。

Note

場合によっては (特に、アプリのコンテキスト外でデバイスシステムを使用する場合)、セッション間でデータが保持されることがあります。そのため、さらに Device Farm が各デバイスの使用中にアクティビティのビデオとログをキャプチャするため、自動テストおよびリモートアクセスセッション中に、機密情報 (Google アカウント、Apple ID など)、個人情報、およびその他のセキュリティを必要とする詳細などは入力しないことをお勧めします。

プライベートデバイス

プライベートデバイス契約の終了または解除後、デバイスは使用から除外され、AWS 破壊ポリシーに従って安全に破棄されます。詳細については、「AWS Device Farm でのプライベートデバイスの使用 (p. 146)」を参照してください。

キーの管理現在、Device Farm には、保管中または転送中のデータの暗号化のための外部キー管理は用意されていません。

インターネットトラフィックのプライバシーDevice Farm は、プライベートデバイスに対してのみ、Amazon VPC エンドポイントを使用して AWS のリソースに接続するように設定できます。アカウントに関連付けられた非パブリック AWS インフラストラクチャ (パブリック IP アドレスのない Amazon EC2 インスタンスなど) へのアクセスには、Amazon

API バージョン 2015-06-23264

AWS Device Farm 開発者ガイド弾力

VPC エンドポイントを使用する必要があります。VPC エンドポイントの設定に関係なく、Device Farm はDevice Farm ネットワーク全体でトラフィックを他のユーザーから分離します。

AWS ネットワークの外部での接続が安全であるとは限りません。アプリケーションが行うインターネット接続を保護するのは、お客様の責任です。

AWS Device Farm での耐障害性AWS のグローバルインフラストラクチャは AWS リージョンとアベイラビリティーゾーンを中心として構築されます。AWS リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立・隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。

AWSのリージョンやアベイラビリティーゾーンの詳細については、AWSグローバルインフラストラクチャを参照してください。

Device Farm は us-west-2 リージョンでのみ利用できるため、バックアップおよび復旧プロセスを実装することを強くお勧めします。Device Farm が、アップロードされたコンテンツの唯一のソースにならないようにしてください。

Device Farm では、パブリックデバイスの可用性が保たれるとは限りません。これらのデバイスは、障害発生率や隔離ステータスなどのさまざまな要因に応じて、パブリックデバイスプールに対して追加または削除されます。パブリックデバイスプール内のいずれかのデバイスの可用性に依存することはお勧めしません。

AWS Device Farm でのインフラストラクチャセキュリティ

マネージド型サービスとしての AWS Device Farm は、ホワイトペーパー「Amazon Web Services: セキュリティプロセスの概要」に記載されている AWS グローバルネットワークセキュリティの手順で保護されています。

AWS が公開している API コールを使用して、ネットワーク経由で Device Farm にアクセスします。クライアントで Transport Layer Security (TLS) 1.0 以降がサポートされている必要があります。TLS 1.2 以降が推奨されています。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman(ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。

リクエストは、アクセスキー ID と、IAM プリンシパルに関連付けられているシークレットのアクセスキーを使用して署名する必要があります。または、AWS Security Token Service (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。

物理デバイステストのインフラストラクチャセキュリティ物理デバイスのテスト中、デバイスは物理的に分離されています。ネットワークの分離により、ワイヤレスネットワークを介したデバイス間通信が防止されます。

パブリックデバイスは共有され、Device Farm はベストエフォートベースでデバイスを長期間にわたって安全に保ちます。デバイスに対する完全な管理者権限を取得する試み (ルート化または脱獄と呼ばれる行

API バージョン 2015-06-23265

http://aws.amazon.com/about-aws/global-infrastructure/

http://aws.amazon.com/about-aws/global-infrastructure/

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

AWS Device Farm 開発者ガイドデスクトップブラウザのテストの

インフラストラクチャセキュリティ

為) など特定のアクションが検出されると、パブリックデバイスが隔離されます。それらのデバイスは自動的にパブリックプールから削除され、手動による確認の対象になります。

プライベートデバイスには、明示的に承認された AWS アカウントのみがアクセスできます。Device Farmは、これらのデバイスを他のデバイスから物理的に分離し、別のネットワークに保持します。

プライベートで管理されているデバイスでは、Amazon VPC エンドポイントを使用して AWS アカウントとの接続を保護するようにテストを設定できます。

デスクトップブラウザのテストのインフラストラクチャセキュリティデスクトップブラウザのテスト機能を使用すると、すべてのテストセッションが互いに分離されます。Selenium インスタンスは、AWS の外部にある中間のサードパーティーなしでは相互通信できません。

Selenium WebDriver コントローラーへのすべてのトラフィックは、createTestGridUrl で生成されたHTTPS エンドポイントを通過する必要があります。

現時点では、デスクトップブラウザのテスト機能は Amazon VPC エンドポイント設定をサポートしていません。各 Device Farm テストインスタンスがテスト対象のリソースに安全にアクセスできるようにするのは、お客様の責任です。

Device Farm での設定の脆弱性の分析と管理Device Farm を使用すると、OS ベンダー、ハードウェアベンダー、キャリアなどのベンダーによって積極的に維持またはパッチ提供されていないソフトウェアを実行できます。Device Farm はベストエフォートベースで、最新のソフトウェアを維持しようとしますが、物理デバイス上の特定のソフトウェアのバージョンが最新であることを保証するものではなく、設計上、脆弱であり得るソフトウェアの使用が許可されます。

たとえば、Android 4.4.2 で動作しているデバイスで Device Farm によるテストを実行しても、StageFrightと呼ばれる Android の脆弱性に対するパッチがデバイスに適用されているとは限りません。デバイスにセキュリティ更新を提供するのは、デバイスのベンダー (場合によってはキャリア) の責任です。また、この脆弱性を使用する悪意のあるアプリケーションが自動検疫によって検出されるとは限りません。

プライベートデバイスは AWS との契約に従って維持されます。

Device Farm はベストエフォートベースで、お客様のアプリケーションがルート化や脱獄など特定のアクションを実行しないようにします。また、Device Farm は隔離されたデバイスを、手動で確認されるまでパブリックプールから削除します。

Python ホイールや Ruby Gem など、テストで使用するソフトウェアのライブラリやバージョンを最新に保つのは、お客様の責任です。Device Farm では、テストライブラリを更新することが推奨されます。

これらのリソースは、テストの依存関係を最新に保つのに役立ちます。

• Ruby Gem を保護する方法については、RubyGems ウェブサイトの「Security Practices」を参照してください。

• 既知の脆弱性の依存関係グラフをスキャンするために Pipenv によって使用される、PythonPackaging Authority による承認済みの安全パッケージについては、GitHub の「Detection of SecurityVulnerabilities」を参照してください。

• Open Web Application Security Project (OWASP) Maven 依存関係チェッカーについては、OWASP ウェブサイトの「OWASP DependencyCheck」を参照してください。

API バージョン 2015-06-23266

https://en.wikipedia.org/wiki/Stagefright_(bug)

https://en.wikipedia.org/wiki/Stagefright_(bug)

https://guides.rubygems.org/security/

https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities

https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities

https://owasp.org/www-project-dependency-check/

AWS Device Farm 開発者ガイドインシデントへの対応

自動化システムによって既知のセキュリティ問題が検出されなくても、セキュリティ問題がないことを意味するわけではありません。サードパーティーのライブラリまたはツールを使用するときは、常にデューデリジェンスを使用し、可能または妥当であれば、暗号化署名を確認してください。

Device Farm でのインシデントへの対応Device Farm は、セキュリティの問題の可能性のある動作がないかデバイスを継続的にモニタリングします。顧客データ (テスト結果や、パブリックデバイスに書き込まれたファイルなど) に別の顧客がアクセスできるケースを AWS が認識した場合、AWS のサービス全体で使用される標準のインシデントアラートおよびレポートポリシーに従って、AWS は影響を受ける顧客に連絡します。

Device Farm でのログ記録とモニタリングこのサービスは AWS CloudTrail をサポートします。これは、AWS アカウントの &AWS; 呼び出しを記録し、ログファイルを Amazon S3 バケットに配信するサービスです。CloudTrail が収集した情報を使用して、成功した AWS サービスリクエスト、そのリクエストの送信者、そのリクエストの送信時間などを確認できます。CloudTrail の詳細（有効にする方法、ログファイルを検索する方法を含む）については、AWS CloudTrail User Guide を参照してください。

Device Farm での CloudTrail の使用については、「AWS Device Farm を使用した AWS CloudTrail API 呼び出しのログ記録 (p. 164)」を参照してください。

Device Farm のセキュリティのベストプラクティスDevice Farm には、独自のセキュリティポリシーを開発および実装する際に考慮対象となるいくつかのセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションに相当するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは処方箋ではなく、有用な考慮事項と見なしてください。

• 使用する継続的な統合 (CI) システムに、IAM で可能な最小限の権限を付与します。各 CI システムテストには一時的な認証情報を使用することを検討してください。これにより、CI システムがウィルスに感染しても、偽のリクエストを行うことができなくなります。一時的な認証情報の詳細については、IAMユーザーガイドを参照してください。

• カスタムテスト環境で adb コマンドを使用して、アプリケーションによって作成されたコンテンツをクリーンアップします。カスタムテスト環境の詳細については、「カスタムテスト環境での作業 (p. 135)」を参照してください。

API バージョン 2015-06-23267

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole


AWS Device Farm の制限次のリストに、AWS Device Farm の現在の制限を示します。

• アップロードできるアプリの最大ファイルサイズは 4 GB です。• テストランに含めることができるデバイスの数に制限はありません。ただし、Device Farm がテストラ

ン中に同時にテストするデバイスの最大数は 5 です。(この数値は、リクエストに応じて増やすことができます。)

• スケジュールできる実行の数に制限はありません。• リモートアクセスセッションの期間には、150 分の制限があります。• 自動化されたテスト実行の期間には、150 分の制限があります。

API バージョン 2015-06-23268

AWS Device Farm 開発者ガイドJenkins CI プラグイン

AWS Device Farm のツールとプラグイン

このセクションには、AWS Device Farm ツールとプラグインの操作に関するリンクと情報が含まれています。Device Farm プラグインは GitHub の AWS ラボにあります。

Android 開発者である場合は、GitHub の Android 用 AWS Device Farm サンプルアプリもご利用いただけます。独自の Device Farm テストスクリプトのリファレンスとして、このアプリおよびテスト例を使用できます。

トピック• AWS Device Farm の Jenkins CI プラグインとの統合 (p. 269)• AWS Device Farm Gradle プラグイン (p. 274)

AWS Device Farm の Jenkins CI プラグインとの統合

このプラグインは、独自の Jenkins 継続的インテグレーション (CI) サーバーから AWS Device Farm 機能を提供します。詳細については、「Jenkins (ソフトウェア)」を参照してください。

Note

Jenkins プラグインをダウンロードするには、GitHub にアクセスし、ステップ 1: プラグインをインストールする (p. 272) の手順に従います。

このセクションには、AWS Device Farm で Jenkins CI プラグインをセットアップして使用する一連の手順が含まれます。

トピック• ステップ 1: プラグインのインストール (p. 272)• ステップ 2: Jenkins CI Plugin のための AWS Identity and Access Management ユーザーを作成す

る (p. 273)• ステップ 3: 初回の設定手順 (p. 274)• ステップ 4: Jenkins ジョブでのプラグインの使用 (p. 274)• 依存関係 (p. 274)

以下の画像は、Jenkins CI プラグインの機能を示しています。

API バージョン 2015-06-23269

https://github.com/awslabs/


https://en.wikipedia.org/wiki/Jenkins_%28software%29

https://github.com/awslabs/aws-device-farm-jenkins-plugin


API バージョン 2015-06-23270


また、このプラグインではすべてのテストアーティファクト (ログ、スクリーンショットなど) をローカルにプルダウンすることもできます。

API バージョン 2015-06-23271

AWS Device Farm 開発者ガイドステップ 1: プラグインをインストールする

ステップ 1: プラグインのインストールAWS Device Farm の Jenkins 継続的インテグレーション (CI) プラグインをインストールするには 2 つのオプションがあります。Jenkins ウェブ UI の [Available Plugins] ダイアログ内からプラグインを検索するか、hpi ファイルをダウンロードして Jenkins 内からインストールできます。

Jenkins UI 内からのインストール1. [Manage Jenkins]、[Manage Plugins] を選択し、次に [Available] を選択して Jenkins UI 内でプラグイ

ンを見つけます。2. [aws-device-farm] を検索します。3. AWS Device Farm プラグインをインストールします。4. プラグインが Jenkins ユーザーに所有されていることを確認します。5. Jenkins を再起動します。

プラグインのダウンロード1. hpi ファイルを直接 http://updates.jenkins-ci.org/latest/aws-device-farm.hpi からダウンロードしま

す。2. プラグインが Jenkins ユーザーに所有されていることを確認します。3. 次のいずれかのオプションを使用して、プラグインをインストールします。

• [Manage Jenkins]、[Manage Plugins]、[Advanced]、[Upload plugin] の順に選択してプラグインをアップロードします。

• hpi ファイルを Jenkins プラグインディレクトリ (通常は /var/lib/jenkins/plugins) に配置します。

4. Jenkins を再起動します。

API バージョン 2015-06-23272

http://updates.jenkins-ci.org/latest/aws-device-farm.hpi

AWS Device Farm 開発者ガイドステップ 2: IAM ユーザーを作成する

ステップ 2: Jenkins CI Plugin のための AWS Identityand Access Management ユーザーを作成するDevice Farm へのアクセスには、AWS ルートアカウントは使用しないことをお勧めします。代わりに、AWS アカウントに新しい AWS Identity and Access Management (IAM) ユーザーを作成 (または既存の IAM ユーザーを使用) し、その IAM ユーザーで Device Farm にアクセスします。

新しい IAM ユーザーを作成する方法については、「IAM ユーザーを作成する (AWS マネジメントコンソール)」を参照してください。各ユーザーのアクセスキーを生成していることを確認し、ユーザーのセキュリティ認証情報をダウンロードまたは保存します。認証情報は後で必要になります。

Device Farm にアクセスするためのアクセス許可を IAM ユーザーに付与します。IAM ユーザーに Device Farm へのアクセス許可を付与するには、IAM で新しいアクセスポリシーを作成し、そのアクセスポリシーを次のように IAM ユーザーに割り当てます。

Note


IAM でアクセスポリシーを作成する

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [Policies (ポリシー)] を選択します。3. [Create Policy] を選択します。([Get Started] ボタンが表示された場合は、そのボタンを選択してか

ら、[Create Policy] を選択します)。4. [独自のポリシーを作成] の横の [選択] を選択します。5. [ポリシー名] に、ポリシーの名前 (AWSDeviceFarmAccessPolicy など) を入力します。6. [説明] に、この IAM ユーザーを Jenkins プロジェクトに関連付けるための説明を入力します。7. [Policy Document (ポリシードキュメント)] に、次のステートメントを入力します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DeviceFarmAll", "Effect": "Allow", "Action": [ "devicefarm:*" ], "Resource": [ "*" ] } ]}

8. [Create Policy] を選択します。

アクセスポリシーを IAM ユーザーに割り当てる

1. IAM コンソール（https://console.aws.amazon.com/iam/）を開きます。2. [Users] を選択します。3. アクセスポリシーを割り当てる IAM ユーザーを選択します。4. [Permissions (アクセス許可)] エリアの [Managed Policies (管理ポリシー)] で、[Attach Policy (ポリ

シーのアタッチ)] を選択します。

API バージョン 2015-06-23273






AWS Device Farm 開発者ガイドステップ 3: 初回の設定手順

5. 先ほど作成したポリシー (例: AWSDeviceFarmAccessPolicy) を選択します。6. [Attach Policy] を選択します。

ステップ 3: 初回の設定手順Jenkins サーバーを初めて実行するときは、次のようにシステムを設定する必要があります。

Note

デバイススロット (p. 8)を使用している場合、デバイススロット機能はデフォルトで無効になっています。

1. Jenkins のウェブユーザーインターフェイスにログインします。2. 画面の左側で、[Manage Jenkins] を選択します。3. [Configure System] を選択します。4. [AWS Device Farm] ヘッダーまで下にスクロールします。5. ステップ 2: IAM ユーザーを作成する (p. 273) からセキュリティ認証情報をコピーして、アクセス

キー ID とシークレットアクセスキーをそれぞれのボックスに貼り付けます。6. [Save] を選択します。

ステップ 4: Jenkins ジョブでのプラグインの使用Jenkins プラグインのインストールが完了したら、次の手順に従って、Jenkins ジョブでプラグインを使用します。

1. Jenkins のウェブ UI にログインします。2. 編集するジョブをクリックします。3. 画面の左側にある [Configure (設定)] を選択します。4. [Post-build Actions] ヘッダーまでスクロールダウンします。5. [Add post-build action] をクリックして [Run Tests on AWS Device Farm] を選択します。6. 使用するプロジェクトを選択します。7. 使用するデバイスプールを選択します。8. テストアーティファクト (ログやスクリーンショットなど) をローカルにアーカイブするかどうかを選

択します。9. [Application] で、コンパイルされたアプリケーションへのパスを入力します。10. 実行するテストを選択し、すべての必須フィールドに入力します。11. [Save] を選択します。

依存関係Jenkins CI プラグインには、AWS Mobile SDK 1.10.5 以降が必要です。SDK のインストールおよび詳細については、「AWS Mobile SDK」を参照してください。

AWS Device Farm Gradle プラグインこのプラグインは、Android Studio の Gradle ビルドシステムの AWS Device Farm との統合を提供します。詳細については、「Gradle」を参照してください。

API バージョン 2015-06-23274

https://aws.amazon.com/mobile/sdk/

https://gradle.org

AWS Device Farm 開発者ガイドDevice Farm Gradle プラグインの構築

Note

Gradle プラグインをダウンロードするには、GitHub にアクセスし、Device Farm Gradle プラグインの構築 (p. 275) の手順に従います。

Device Farm Gradle プラグインは、Android Studio 環境からの Device Farm 機能を提供します。実際にDevice Farm によってホストされている Android 電話やタブレットでテストを開始できます。

このセクションには、Device Farm Gradle プラグインをセットアップして使用する一連の手順が含まれます。

トピック• ステップ 1: AWS Device Farm Gradle プラグインを構築する (p. 275)• ステップ 2: AWS Device Farm Gradle プラグインをセットアップする (p. 275)• ステップ 3: IAM ユーザーを作成する (p. 277)• ステップ 4: テストタイプの設定 (p. 278)• 依存関係 (p. 280)

ステップ 1: AWS Device Farm Gradle プラグインを構築するこのプラグインは、Android Studio の Gradle ビルドシステムの AWS Device Farm との統合を提供します。詳細については、「Gradle」を参照してください。

Note

プラグインの構築はオプションです。プラグインは、Maven セントラルを通じて発行されます。Gradle がプラグインを直接ダウンロードするよう許可する場合は、この手順をスキップして、ステップ 2: AWS Device Farm Gradle プラグインをセットアップする (p. 275) に進みます。

プラグインを構築するには

1. GitHub に移動して、リポジトリのクローンを作成します。2. gradle install を使用してプラグインを構築します。

プラグインはローカルの maven リポジトリにインストールされます。

次のステップ: ステップ 2: AWS Device Farm Gradle プラグインをセットアップする (p. 275)

ステップ 2: AWS Device Farm Gradle プラグインをセットアップするリポジトリのクローンとプラグインのインストールをまだ行っていない場合は、以下の手順を参照して実行してください。Device Farm Gradle プラグインの構築 (p. 275)

AWS Device Farm Gradle プラグインを設定するには

1. build.gradle の依存関係リストにプラグインアーティファクトを追加します。

buildscript {

repositories {

API バージョン 2015-06-23275

https://github.com/awslabs/aws-device-farm-gradle-plugin

https://gradle.org

https://github.com/awslabs/aws-device-farm-gradle-plugin

AWS Device Farm 開発者ガイドDevice Farm Gradle プラグインをセットアップする

mavenLocal() mavenCentral() }

dependencies { classpath 'com.android.tools.build:gradle:1.3.0' classpath 'com.amazonaws:aws-devicefarm-gradle-plugin:1.0' } }

2. build.gradle ファイルのプラグインを設定します。以下のテスト固有の設定がガイドとして役立ちます。

apply plugin: 'devicefarm'

devicefarm {

// Required. The project must already exist. You can create a project in the AWS Device Farm console. projectName "My Project" // required: Must already exist.

// Optional. Defaults to "Top Devices" // devicePool "My Device Pool Name" // Optional. Default is 150 minutes // executionTimeoutMinutes 150 // Optional. Set to "off" if you want to disable device video recording during a run. Default is "on" // videoRecording "on" // Optional. Set to "off" if you want to disable device performance monitoring during a run. Default is "on" // performanceMonitoring "on" // Optional. Add this if you have a subscription and want to use your unmetered slots // useUnmeteredDevices() // Required. You must specify either accessKey and secretKey OR roleArn. roleArn takes precedence. authentication { accessKey "AKIAIOSFODNN7EXAMPLE" secretKey "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" // OR roleArn "arn:aws:iam::111122223333:role/DeviceFarmRole" }

// Optionally, you can // - enable or disable Wi-Fi, Bluetooth, GPS, NFC radios // - set the GPS coordinates // - specify files and applications that must be on the device when your test runs devicestate { // Extra files to include on the device. // extraDataZipFile file("path/to/zip") // Other applications that must be installed in addition to yours. // auxiliaryApps files(file("path/to/app"), file("path/to/app2")) // By default, Wi-Fi, Bluetooth, GPS, and NFC are turned on. // wifi "off" // bluetooth "off" // gps "off"

API バージョン 2015-06-23276

AWS Device Farm 開発者ガイドIAM ユーザーを作成する

// nfc "off" // You can specify GPS location. By default, this location is 47.6204, -122.3491 // latitude 44.97005 // longitude -93.28872 } // By default, the Instrumentation test is used. // If you want to use a different test type, configure it here. // You can set only one test type (for example, Calabash, Fuzz, and so on) // Fuzz // fuzz { }

// Calabash // calabash { tests file("path-to-features.zip") } }

3. 次のタスク gradle devicefarmUpload を使用して Device Farm テストを実行します。

ビルド出力で Device Farm コンソールへのリンクが出力され、テストの実行をモニタリングできます。

次のステップ: IAM ユーザーを作成する (p. 277)

ステップ 3: IAM ユーザーを作成するAWS Identity and Access Management (IAM) では、AWS リソースを使用するためのアクセス許可とポリシーを管理できます。このトピックでは AWS Device Farm リソースにアクセスするアクセス許可を持つIAM ユーザーの作成方法について説明します。

手順 1 と 2 を実行していない場合は、IAM user を作成する前に完了してください。

Device Farm へのアクセスには、AWS ルートアカウントは使用しないことをお勧めします。代わりに、AWS アカウントに新しい IAM ユーザーを作成 (または既存の IAM ユーザーを使用) し、その IAMユーザーで Device Farm にアクセスします。

Note


IAM で適切なアクセスポリシーを持つ新しいユーザーを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。2. [Users] を選択します。3. [Create New Users (新規ユーザーの作成)] を選択します。4. 任意のユーザー名を入力します。

たとえば、GradleUser と指定します。5. [Create (作成)] を選択します。6. [Download Credentials (認証情報のダウンロード)] を選択し、後で簡単に取得できる場所に保存しま

す。7. [Close] を選択します。

API バージョン 2015-06-23277



AWS Device Farm 開発者ガイドテストタイプの設定

8. リスト内でユーザー名を選択します。9. [Permissions (アクセス許可)] で、右側にある下矢印をクリックして [Inline Policies (インラインポリ

シー)] ヘッダーを展開します。10. [Click here (ここをクリック)] を選択します。[There are no inline policies to show.To create one, click

here] と表示されている場所です。11. [Set Permissions (アクセス許可の設定)] 画面で [Custom Policy (カスタムポリシー)] を選択します。12. [Select (選択)] を選択します。13. ポリシーに名前を付けます (例: AWSDeviceFarmGradlePolicy)。14. 次のポリシーを [Policy Document (ポリシードキュメント)] に貼り付けます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DeviceFarmAll", "Effect": "Allow", "Action": [ "devicefarm:*" ], "Resource": [ "*" ] } ] }

15. [Apply Policy] を選択します。

次のステップ: テストタイプの設定 (p. 278).

詳細については、「IAM ユーザーの作成 (AWS マネジメントコンソール)」または「セットアップ (p. 3)」を参照してください。

ステップ 4: テストタイプの設定デフォルトでは、AWS Device Farm Gradle プラグインは Android および AWS Device Farm の計器の操作 (p. 79) テストを実行します。独自のテストを実行、または追加のパラメーターを指定する場合は、テストタイプを設定することもできます。このトピックでは、利用可能な各テストタイプに関する情報と、Android Studio で使用するために設定する必要がある内容について説明します。Device Farm で使用できるテストタイプの詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

まだ行っていない場合は、テストタイプを設定する前に手順 1 – 3 を完了します。Note

デバイススロット (p. 8)を使用している場合、デバイススロット機能はデフォルトで無効になっています。

AppiumDevice Farm では、Android の Appium Java JUnit および TestNG をサポートしています。

• Appium Java JUnit (p. 61)• Appium Java TestNG (p. 56)

useTestNG() または useJUnit() を選択します。デフォルトは JUnit ですが、明示的に指定する必要はありません。

appium {

API バージョン 2015-06-23278


AWS Device Farm 開発者ガイドテストタイプの設定

tests file("path to zip file") // required useTestNG() // or useJUnit() }

Built-in: エクスプローラーDevice Farm には、カスタムテストスクリプトを記述せずに、アプリケーションでユーザーフローをテストする組み込みのアプリケーションエクスプローラーが用意されています。ログインを必要とするシナリオをテストするためにユーザー名とパスワードを指定できます。ユーザー名とパスワードを設定する方法を次に示します。

appexplorer { username "my-username" password "my-password" }

詳細については、「組み込み: エクスプローラ (Android) (p. 132)」を参照してください。

Built-in: ファズDevice Farm には、ランダムにユーザーインターフェイスのイベントをデバイスに送信し、その結果をレポートする組み込みのファズテストタイプが用意されています。

fuzz {

eventThrottle 50 // optional default eventCount 6000 // optional default randomizerSeed 1234 // optional default blank

}

詳細については、「組み込み: ファズ (Android および iOS) (p. 133)」を参照してください。

CalabashDevice Farm では Calabash for Android がサポートされています。Android Calabash のテストの準備方法については、「Calabash (p. 77)」を参照してください。

calabash { tests file("path to zip file") // required tags "my tags" // optional calabash tags profile "my profile" // optional calabash profile }

インストルメンテーションDevice Farm では、Android 用の計器 (JUnit、Espresso、Robotium などの実装ベースのテスト) がサポートされています。詳細については、「Android および AWS Device Farm の計器の操作 (p. 79)」を参照してください。

Gradle で実装テストを実行する場合、Device Farm では、androidTest ディレクトリから生成された .apkファイルをテストのソースとして使用します。

instrumentation {

filter "test filter per developer docs" // optional

API バージョン 2015-06-23279

AWS Device Farm 開発者ガイド依存関係

}

UI Automatorアプリと UI Automator ベースのテストを .jar ファイルにアップロードします。

uiautomator { tests file("path to uiautomator jar file") // required filter "test filter per developer docs" // optional

}

詳細については、「UI Automator (p. 80)」を参照してください。

依存関係ランタイム

• Device Farm Gradle プラグインには、AWS Mobile SDK 1.10.15 以降が必要です。SDK のインストールおよび詳細については、「AWS Mobile SDK」を参照してください。

• Android ツールビルダーテスト api 0.5.2• Apache Commons Lang3 3.3.4

ユニットテストの場合

• Testng 6.8.8• Jmockit 1.19• Android gradle ツール 1.3.0

API バージョン 2015-06-23280

https://aws.amazon.com/mobile/sdk/


ドキュメント履歴以下の表に、このガイドの前回のリリース以降に行われた重要な変更を示します。

変更説明変更日

Python 3 のサポート Device Farm は、カスタムモードテストで Python 3 をサポートするようになりました。テストパッケージでの Python 3 の使用方法の詳細については、こちらを参照してください。

• the section called “Appium Python” (p. 96)• the section called “Appium Python” (p. 69)

2020 年 4 月20 日

新しいセキュリティ情報と AWS リソースのタグ付けに関する情報。

AWS のサービスの保護をより容易かつ包括的にするために、セキュリティに関する新しいセクションが作成されました。詳細については、「AWS Device Farm のセキュリティ (p. 250)」を参照してください。

Device Farm でのタグ付けに関する新しいセクションが追加されました。タグ付けの詳細については、「Device Farm のタグ付け (p. 52)」を参照してください。

2020 年 3 月27 日

直接デバイスアクセスの廃止。

直接デバイスアクセス (プライベートデバイスでのリモートデバッグ) は、一般的な使用目的には利用できなくなりました。直接デバイスアクセスの今後の利用可能性については、こちらまでお問い合わせください。

2019 年 9 月9 日

Gradle プラグイン設定の更新

更新された Gradle プラグイン設定には、カスタマイズ可能なバージョンの Gradle 設定が含まれ、オプションのパラメーターはコメントアウトされています。Device Farm Gradle プラグインをセットアップする (p. 275) の詳細情報。

2019 年 8 月16 日

XCTest を使用したテストランの新しい要件

XCTest フレームワークを使用するテストランでは、テスト用に構築されたアプリケーションパッケージが Device Farm で必要になります。詳細情報 the section called “XCTest” (p. 107).

2019 年 2 月4 日

カスタム環境でのAppium Node.js および Appium Ruby テストタイプのサポート

Appium Node.js と Appium Ruby の両方のカスタムテスト環境でテストを実行できます。詳細情報 AWS Device Farm でのテストタイプの実行 (p. 54).

2019 年 1 月10 日

Appium サーバーバージョン 1.7.2 が標準環境とカスタム環境の両方でサポートされるようになりました。カスタムテストスペックのYAML ファイルを使用したバージョン 1.8.1がカスタムテスト環境でサポートされるようになりました。

Appium サーバーバージョン 1.72、1.71、および 1.6.5 を使用して、標準テスト環境とカスタムのテスト環境の両方でテストを実行できるようになりました。また、カスタムのテスト環境で、カスタムのテストスペック YAML ファイルを使用して、バージョン 1.8.1 および 1.8.0 のテストを実行することもできます。詳細情報 AWS Device Farm でのテストタイプの実行 (p. 54).

2018 年 10 月2 日

カスタムのテスト環境カスタムのテスト環境では、ローカル環境と同様のテストランを行うことができます。Device Farm では、ライブログやビデオストリーミングがサポートされるようになったため、カスタ

2018 年 8 月16 日

API バージョン 2015-06-23281




変更説明変更日ムのテスト環境で実行されるテストのフィードバックを素早く取得することができます。詳細情報カスタムテスト環境での作業 (p. 135).

AWS CodePipeline のテストプロバイダとしての Device Farm の使用をサポート

AWS CodePipeline でパイプラインを設定して、リリースプロセスのテストアクションとして、AWS Device Farm のランを使用できるようになりました。CodePipeline では、リポジトリにすばやくリンクして、ステージを構築してテストし、ニーズに応じてカスタマイズされた継続的な統合システムを実現することができます。詳細情報 CodePipeline テストステージでのAWS Device Farm の使用 (p. 167).

2018 年 7 月19 日

プライベートデバイスのサポート

プライベートデバイスを使用してテストランをスケジュールし、リモートアクセスセッションを開始できるようになりました。これらのデバイスのプロファイルと設定の管理、AmazonVPC エンドポイントの作成によるプライベートアプリのテスト、およびリモートデバッグセッションの作成を行うことができます。詳細情報 AWS Device Farm でのプライベートデバイスの使用 (p. 146).

2018 年 5 月2 日

Appium 1.6.3 のサポート

Appium カスタムテストの Appium バージョンを設定できるようになりました。

2017 年 3 月21 日

テストランの実行タイムアウトを設定する

テストランの実行タイムアウトまたはプロジェクトのすべてのテストの実行タイムアウトを設定できます。詳細情報AWS Device Farm でのテストランの実行タイムアウトの設定 (p. 33).

2017 年 2 月9 日

ネットワークシェーピング

テストラン用のネットワーク接続と条件をシミュレートできるようになりました。詳細情報ネットワーク接続と条件のシミュレート (p. 34).

2016 年 12 月8 日

トラブルシューティングセクションの新規追加

Device Farm コンソールで発生する可能性のあるエラーメッセージを解決するための一連の手順を使用して、テストパッケージのアップロードのトラブルシューティングができるようになりました。詳細情報トラブルシューティング (p. 177).

2016 年 8 月10 日

リモートアクセスセッション

コンソールで単一のデバイスにリモートでアクセスして連携できるようになりました。詳細情報リモートアクセスの使用 (p. 142).

2016 年 4 月19 日

デバイススロットセルフサービス

AWS マネジメントコンソール、AWS Command LineInterface、または API を使用して、デバイススロットを購入できるようになりました。デバイススロットの購入 (p. 8) 方法の詳細情報。

2016 年 3 月22 日

テストランの停止方法 AWS マネジメントコンソール、AWS Command LineInterface、または API を使用して、テストランを停止できるようになりました。AWS Device Farm の実行の停止 (p. 37) 方法の詳細情報。

2016 年 3 月22 日

XCTest UI テストタイプの新規追加

iOS アプリケーションで XCTest UI カスタムテストを実行できるようになりました。XCTest UI (p. 109) テストタイプの詳細情報。

2016 年 3 月8 日

API バージョン 2015-06-23282


変更説明変更日

Appium Python テストタイプの新規追加

Android、iOS、およびウェブアプリケーションで AppiumPython カスタムテストを実行できるようになりました。詳細情報 AWS Device Farm でのテストタイプの実行 (p. 54).

2016 年 1 月19 日

ウェブアプリケーションテストタイプ

ウェブアプリケーションで Appium Java JUnit および TestNGカスタムテストを実行できるようになりました。詳細情報AWS Device Farm でウェブアプリテストを使用する (p. 110).

2015 年 11 月19 日

AWS Device FarmGradle プラグイン

Device Farm Gradle プラグイン (p. 274) のインストールおよび使用方法の詳細情報。

2015 年 9 月28 日

Android 組み込みテストの新規追加: エクスプローラー

詳細情報組み込み: エクスプローラ (Android) (p. 132).エクスプローラーテストでは、各画面をエンドユーザーであるかのように分析してアプリをクロールし、調査中のスクリーンショットを取得します。

2015 年 9 月16 日

iOS サポートの追加 iOS デバイスのテストと iOS テスト (XCTest を含む) の実行の詳細については、「AWS Device Farm でのテストタイプの実行 (p. 54)」を参照してください。

2015 年 8 月4 日

初回一般リリースこれは『AWS Device Farm 開発者ガイド』の初回一般リリースです。

2015 年 7 月13 日

API バージョン 2015-06-23283


AWS の用語集最新の AWS の用語については、『AWS General Reference』の「AWS の用語集」を参照してください。

API バージョン 2015-06-23284

https://docs.aws.amazon.com/general/latest/gr/glos-chap.html

Documents

AWS Device Farm - 開発者ガイドAWS Device Farm 開発者ガイド デバイススロットの購入 (コンソール)..... 15

AWS Device Farm - 開発者ガイドAWS Device Farm 開発者ガイドデバイススロットの購入 (コンソール)..... 15