Firebase Summit で発表されたすべての情報をご覧ください。Firebase を使用してアプリ開発を加速し、自信を持ってアプリを実行する方法を紹介しています。詳細

計装テストを開始する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このガイドでは、Firebase Test Lab を使用してインストルメンテーション テストを準備および実行する方法について説明します。このガイドを使用するには、 EspressoまたはUI Automator Android テスト フレームワークを使用するインストルメンテーション テスト(あなたまたはあなたのチームが作成したもの) が必要です。インストルメンテーション テストは、物理デバイスで最大 45 分間、仮想デバイスで最大 60 分間実行できます。

後の手順で、アプリの APK とテストの APK を Firebase にアップロードします。

(オプション) アプリにスクリーンショット ライブラリを追加する

Firebase Test Lab にはライブラリ (testlab-instr-lib) が含まれており、これを使用して、 Espresso テスト フレームワークを使用して記述されたテストなどのインストルメンテーション テストを実行するときに、AndroidX のScreenCaptureで取得したスクリーンショットを処理できます。このセクションでは、AndroidX ライブラリを使用してScreenCaptureオブジェクトを作成する方法と、testlab-instr-lib を使用してそれらを処理する方法について説明します。

インストルメンテーション テストの実行後、キャプチャしたスクリーンショットを Firebase コンソールで表示できます。

サンプルアプリを試す

NotePad サンプル アプリをダウンロードして、この機能を試してください。スクリーンショットを撮る機能は、すでに NotePad プロジェクトに組み込まれています。

ステップ 1. スクリーンショット ライブラリをプロジェクトに追加する

  1. テスト プロジェクトのルート レベル (プロジェクト レベル) の Gradle ファイル ( build.gradle ) で、Google の Maven リポジトリをすべてのリポジトリ セクションに追加します。

    buildscript {
    
      repositories {
        // Add the following line:
        google()  // Google's Maven repository
      }
    
      dependencies {
        // ...
    
        // Check that you have the following line (if not, add it):
        classpath 'com.google.gms:google-services:4.3.8'  // Google Services plugin
      }
    }
    
    allprojects {
      // ...
    
      repositories {
        // Add the following line:
        google()  // Google's Maven repository
        // ...
      }
    }
  2. モジュール (アプリ レベル) の Gradle ファイル (通常はapp/build.gradle ) で、Test Lab スクリーンショット ライブラリの依存関係を追加します。

    dependencies {
      // ...
      // Add Test Lab's instrumentation test screenshot library:
      androidTestImplementation 'com.google.firebase:testlab-instr-lib:0.2'
      // ...
    }
  3. テストのAndroidManifest.xmlファイルで、 FirebaseScreenCaptureProcessor<instrumentation>要素内のメタデータ タグに登録します。代わりに、プロセッサを AndroidJUnitRunner の引数として指定することもできます (方法については、 AndroidJUnitRunner リファレンス ドキュメントを参照してください)。

    <instrumentation
      // Check that you have the following line (if not, add it):
      android:name="androidx.test.runner.AndroidJUnitRunner" // Specifies AndroidJUnitRunner as the test runner
      android:targetPackage="com.your.package.name">
    
    // Add the following:
    <meta-data
      android:name="screenCaptureProcessors"
      android:value="com.google.firebase.testlab.screenshot.FirebaseScreenCaptureProcessor" />
    </instrumentation>
    ...
    
  4. アプリのAndroidManifest.xmlファイルで、 <manifest>要素内に次の行を追加します。

     <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    
  5. AndroidManifest.xmlファイルで、 <manifest>タグ内に次の行を追加して、アプリのシステム権限を指定します。 Android 10 (API レベル 29) 以降でテストしている場合は、 WRITE_EXTERNAL_STORAGEパーミッションを省略します (スクリーンショットを読み込んでデバイスに書き込むために、アプリにこのパーミッションは必要ありません)。

    <manifest ... >
        <!-- WRITE_EXTERNAL_STORAGE is not needed on Android 10 (API level 29) or higher. -->
        <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
        <uses-permission android:name="android.permission.INTERNET"/>
        ...
    </manifest>

ステップ 2. テスト中にスクリーンショットを撮る

スクリーンショットを撮りたいテストの任意の時点で、AndroidX ライブラリからScreenshot.capture()メソッドを呼び出します。これにより、 ScreenCaptureオブジェクトが生成されます。 ScreenCaptureオブジェクトでprocess()を呼び出すと、 AndroidManifest.xmlに登録されているScreenCaptureProcessorを使用して処理されます。プロセッサが登録されていない場合は、 BasicScreenCaptureProcessorが使用されることに注意してください。 FirebaseScreenCaptureProcessorを登録したので、スクリーンショットはFirebaseScreenCaptureProcessorを介して処理され、Firebase Test Lab でテストを実行するときに結果とともに利用できるようになります。

ScreenCaptureを作成する使用例:

  • API Build.VERSION_CODES.JELLY_BEAN_MR2 以降で完全な ScreenCapture を取得します。

    Screenshot.capture()
    
  • 任意の API レベルでアクティビティのScreenCaptureを取得します。これは、Build.VERSION_CODES.JELLY_BEAN_MR2 より前のデバイスの唯一のオプションであることに注意してください。

    @Rule
      public ActivityTestRule<MainActivity> activityRule = new ActivityTestRule<>(MainActivity.class);
    ...
    Screenshot.capture(activityRule.getActivity());
    ...
    

ScreenCapture を処理するユースケースの例

  • FirebaseScreenCaptureProcessorを介してScreenCaptureを処理します。

    Screenshot.capture().process();
    
  • 指定したScreenCaptureProcessorを介してScreenCaptureを処理します (これにより、プロセッサの登録をスキップできます)。

    Set<ScreenCaptureProcessor> processors = new HashSet<>();
    processors.add(new FirebaseScreenCaptureProcessor());
    Screenshot.capture().process(processors);
    
  • ScreenCaptureの名前と形式を設定し、登録されたプロセッサを使用して処理します。

    Screenshot.capture().setName("myscreenshot").setFormat(CompressFormat.JPEG).process();
    

ステップ 3. テストをビルドして実行する

  1. アプリをビルドして APK をテストします (手順については、「アプリをテストする」を参照してください)。

  2. APK ファイルを Firebase コンソールのTest Lab ダッシュボードにアップロードします。

  3. 最後に、テストを実行します。

ステップ 4. テストのスクリーンショットを表示する

テストが完了したら、Firebase コンソールで撮影したスクリーンショットを表示できます。

  1. [テスト] タブで、完了したテストを選択し、[結果] タブをクリックします。

  2. テストをもう一度選択し、表示される [スクリーンショット] タブをクリックします。

(オプション) 追加のテスト機能を有効にする

Test Lab でテストを実行する前に、テストで次の機能を有効にすることができます。

オーケストレーターを有効にする

Android Test Orchestratorは、アプリの各インストルメンテーション テストを個別に実行するツールです。 Test Lab は常に最新バージョンの Orchestrator を使用します。

テスト ラボで Orchestrator を有効にするには、インストルメンテーション テストのセットアップで、 [追加オプション] > [ Orchestrator で実行] をクリックします。

利点と欠点

  • 利点: 状態を共有しない。各テストは独自のインストルメンテーション インスタンスで実行されるため、共有状態がテスト間で蓄積されることはありません。
  • 利点: 分離されたクラッシュ。テストがクラッシュした場合、そのインストルメンテーションのみが終了し、スイート内の他のテストは引き続き実行できます。
  • 欠点: ランタイムが長くなります。各テストでは、独自のインストルメンテーション インスタンスが実行されます。つまり、テスト プロセス全体の所要時間はわずかに長くなります。オンにしないと、実行時間の増加が割り当て使用量や請求時間に影響を与える可能性があり、デバイスのタイムアウト制限に達する可能性があります。

シャーディングを有効にする

テスト シャーディングは、一連のテストを個別に分離して実行するサブグループ (シャード) に分割します。 Test Lab は、複数のデバイスを使用して各シャードを自動的に並行して実行し、一連のテスト全体を短時間で完了します。

テスト シャーディングの仕組み

N 個のシャードを作成するとします。選択したデバイスごとに、Test Lab は N 個の同一のデバイスをスピンアップし、各デバイスでテストのサブセットを実行します。これは、デバイスごとに常に 1 つのテストが実行されるシャードされていないテスト ケースとは異なり、シャードされたテスト ケースでは、デバイスごとに複数のテストが実行される可能性があることを意味します (テスト ラボの主要な概念の概要については、主要な概念を参照してください)。

Firebase コンソールでテスト シャーディングを有効にできます。

  1. インストルメンテーション テストのセットアップで、 [追加オプション] をクリックします。

  2. [シャーディング]セクションで、実行するシャードの数を入力します。

テスト シャードの課金

Test Lab は、 AndroidJUnitRunner の組み込みシャーディング メカニズムを利用してシャードを実装します。空のシャード (テスト ケースが割り当てられていないシャード) のスピンアップに対して課金されないようにするには、作成するシャードの数をテスト ケースの合計数より少なくする必要があります。各テスト ケースの実行にかかる時間にもよりますが、通常はシャードごとに 2 ~ 10 個のテスト ケースを割り当てることをお勧めします。

請求の詳細については、使用量、クォータ、および請求をお読みください。