Google は、黒人コミュニティのための人種的公平の促進に取り組んでいます。詳細をご覧ください。

インストルメンテーション テストを使ってみる

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

後で、アプリの APK とテストの APK を Firebase にアップロードします。テスト APK の作成方法については、アプリのテストをご覧ください。オプションとして、NotePad サンプルアプリをダウンロードすることもできます。

ステップ 1.(省略可)アプリにスクリーンショット ライブラリを追加する

Test Lab には、アプリでインストルメンテーション テストを実行する際にスクリーンショットを撮れるスクリーンショット ライブラリが用意されています。テストが完了すると、Android Studio または Firebase コンソールでスクリーンショットを表示できます。

テスト用 APK app-debug-test-unaligned.apk と NotePad サンプルアプリには、スクリーンショットの撮影機能があらかじめ組み込まれています。Robo テストの実行時にもスクリーンショットが自動的にキャプチャされます。

  1. Android Studio で [Project] ビューを開き、プロジェクト名を右クリックします。[New]、[Directory] の順にクリックします。

  2. [New Directory] ダイアログで「aars」と入力します。これで、テスト プロジェクトのルートに(app フォルダのピア ディレクトリとして)aars ディレクトリが作成されます。

  3. cloudtestingscreenshotter_lib.aar をコピーして、aars フォルダに貼り付けます。

  4. アプリのルートレベル(プロジェクト レベル)の build.gradle ファイルで、すべての repositories ブロックに aars フォルダへの参照を追加します。

    repositories {
        jcenter()
        flatDir {
            dirs '../aars'
        }
    }
    ...
  5. モジュールの最上位ディレクトリ(NotePad サンプルアプリの場合は app ディレクトリ)で、build.gradle ファイルを開き、最上位の dependencies ブロックに cloudtestingscreenshotter_lib.aar への依存関係を追加します。

    dependencies {
        // Cloud testing
        androidTestCompile (name:'cloudtestingscreenshotter_lib', ext:'aar')
        // Other dependencies go here
        }
    
  6. 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>
    

テスト中にスクリーンショットを作成するタイミングで、cloudtestingscreenshotter_lib ライブラリから ScreenShotter.takeScreenshot メソッドを呼び出します。ここで最初の引数は、スクリーンショットを識別するラベルです(以下の例では main_screen_2 が使用されます)。

Java

ScreenShotter.takeScreenshot("main_screen_2", this /* activity */);

Kotlin+KTX

ScreenShotter.takeScreenshot("main_screen_2", this /* activity */)

スクリーンショットを表示する

テストの実行に Android Studio を使用している場合は、テストが完了したら、テスト結果ツリーで要素を選択し、[View Screenshots] スクリーンショットを表示する オプションをクリックすることによって、テスト中に撮ったスクリーンショットを比較できます。

スクリーンショット比較画面

次のように、さまざまな構成からスクリーンショットを選択して比較できます。

タスク アクション
テスト実行の切り替え 左上のプルダウン メニューを使用します。

テストケース メニュー
テスト実行内のスクリーンショットの切り替え 右上の矢印を使用します。

スクリーンショットの切り替えツール
現在のビューに別のスクリーンショット比較パネルを追加 [Compare] をクリックします。

比較
別のテスト ディメンション(デバイスタイプ、画面の向き、言語 / 地域など)を選択 スクリーンショット下部のリストから新しいディメンション メンバーを選択

ステップ 2.オプションのテスト機能を有効にする

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

Orchestrator を有効にする

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

Test Lab で Orchestrator を有効にするには、インストルメンテーション テストの設定の [詳細オプション] > [Orchestrator を使用して実行] をクリックします。

メリットとデメリット

  • メリット: 共有データがない。各テストは独自のインストルメンテーション インスタンスで実行されるため、テストをまたいで共有データが蓄積されることはありません。
  • メリット: クラッシュが隔離される。 テストがクラッシュしても、終了するのはそのインストルメンテーションのみであるため、テストスイートに含まれる他のテストは続行されます。
  • デメリット: 実行時間が長い。各テストは独自のインストルメンテーション インスタンスを実行するため、テストプロセス全体の時間は多少長くなります。チェックしないと、実行時間が増加したときに割り当て使用量や課金される時間に影響を与える可能性があります。また、デバイスのタイムアウト上限に達する場合もあります。

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

テストのシャーディングによって、一連のテストをサブグループ(シャード)に分割し、それぞれ分離して実行できるようにします。Test Lab は自動的に各シャードを複数のデバイスで並行して実行するため、テスト全体を完了するまでの時間が短縮されます。

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

N 個のシャードを作成するとします。選択したデバイスごとに、Test Lab は N 個の同一デバイスを起動し、各デバイスでテストのサブセットを実行します。シャーディングされていないテストケースでは常にデバイスごとに 1 つのテストが実行されますが、それとは異なり、テストケースをシャーディングすると、デバイスごとに複数のテストを実行できるということです(Test Lab での重要なコンセプトについては、主なコンセプトをご覧ください)。

テストのシャーディングを有効にするには、Firebase コンソールを使用します。

  1. インストルメンテーション テストの設定で、[詳細オプション] をクリックします。

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

テストシャードに対する課金

Test Lab は、AndroidJUnitRunner の組み込みシャーディング メカニズムを利用してシャードを実装します。空のシャード(テストケースが割り当てられていないシャード)を起動して課金が発生することのないように、作成するシャードの数はテストの合計数より少なくしてください。一般に、各テストケースの実行にかかる時間に応じて、シャードごとに 2~10 個のテストケースを割り当てることをおすすめします。

課金の詳細については、使用量、割り当て、課金をご覧ください。