Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

Atest

Atest はローカルで Android テストを作成、インストール、実行できるコマンドライン ツールで、Trade Federation テストハーネスのコマンドライン オプションを知らなくても、テストの再実行を大幅に高速化します。このページでは、Atest を使用して Android テストを実行する方法について説明します。

Android のテスト作成に関する基本情報については、Android プラットフォームのテストをご覧ください。

Atest の全体的な構造については、Atest デベロッパー ガイドをご覧ください。

Atest に機能を追加するには、Atest Developer Workflow に従います。

環境設定

Atest を実行するには、以下の手順に従って環境を設定します。

環境変数の設定

Soong の場合は test_suite、Make の場合は LOCAL_COMPATIBILITY_SUITE をビルド スクリプト ルールのパッケージに従って設定します。

1. envsetup.sh を実行する

Android ソース チェックアウトのルートで、次のコマンドを実行します。

    source build/envsetup.sh
    

2. lunch を実行する

$ lunch コマンドを実行すると、サポートされているデバイスのメニューが表示されます。デバイスを見つけて、そのコマンドを実行します。

たとえば、ARM デバイスを接続している場合、次のコマンドを実行します。

    lunch aosp_arm64-eng
    

これにより、Atest の実行に必要なさまざまな環境変数が設定され、Atest コマンドが $PATH に追加されます。

基本的な使用法

Atest コマンドの形式は次のとおりです。

    atest [optional-arguments] test-to-run
    

省略可能な引数

Atest コマンドでは、次のオプションの引数を使用できます。

オプション 詳細オプション 説明
-b --build テスト ターゲットをビルドします。
-i --install デバイスにテスト アーティファクト(APK)をインストールします。
-t --test テストを実行します。
-s --serial 指定したデバイスに対してテストを実行します。一度に 1 つのデバイスをテストできます。
-d --disable-teardown テストのティアダウンとクリーンアップを無効にします。
--info 指定したターゲットの関連情報を表示して終了します。
--dry-run --info と同じです。
-m --rebuild-module-info module-info.json ファイルを強制的に再構築します。
-w --wait-for-debugger 実行前にデバッガを待機します(インストゥルメンテーション テストの場合のみ)。
-v --verbose DEBUG レベルのロギングを表示します。
--generate-baseline ベースラインの指標を生成し、デフォルトで 5 回反復実行します。
--generate-new-metrics 新しい指標を生成し、デフォルトで 5 回反復実行します。
--detect-regression 回帰検出アルゴリズムを実行します。
--[CUSTOM_ARGS] テストランナーのカスタム引数を指定します。
-a --all-abi 使用可能なすべてのデバイス アーキテクチャのテストを実行します。
-h --help ヘルプ メッセージを表示して終了します。
--host デバイスを指定せずにホスト上で完全にテストを実行します。
(注: --host を指定してデバイスが必要なホストテストを実行すると失敗します)。

-b-i-t の詳細については、ステップの指定: ビルド、インストール、実行をご覧ください。

実行するテスト

test-to-run を使用して 1 つ以上のテストを実行できます。複数のテストを実行するには、テスト参照をスペースで区切ります。例:

    atest test-to-run-1 test-to-run-2
    

次に例を示します。

    atest FrameworksServicesTests
    atest example/reboot
    atest FrameworksServicesTests CtsJankDeviceTestCases
    atest FrameworksServicesTests:ScreenDecorWindowTests
    

テストの参照方法については、テストの特定をご覧ください。

テストの特定

test-to-run 引数として、テストのモジュール名、Module:Class、クラス名、TF 統合テスト、ファイルパス、パッケージ名を指定できます。

モジュール名

テスト モジュール全体を実行するには、モジュール名を使用します。該当するテストの Android.mk または Android.bp ファイル内の LOCAL_MODULE または LOCAL_PACKAGE_NAME 変数にある名前を指定します。

例:

    atest FrameworksServicesTests
    atest CtsJankDeviceTestCases
    

Module:Class

モジュール内の 1 つのクラスを実行するには、Module:Class を使用します。Moduleモジュール名で説明したものと同じです。Class は、.java ファイル内のテストクラスの名前で、完全修飾クラス名または基本名を指定できます。

例:

    atest FrameworksServicesTests:ScreenDecorWindowTests
    atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
    atest CtsJankDeviceTestCases:CtsDeviceJankUi
    

クラス名

モジュール名を明示せずに単一のクラスを実行するには、クラス名を使用します。

例:

    atest ScreenDecorWindowTests
    atest CtsDeviceJankUi
    

モジュールが指定されていない場合、Atest は一致すると見込まれるモジュールをソースツリー全体で検索するため、時間がかかります。可能な限り Module:Class 参照を使用することをおすすめします。

例(実行が速い順)

    atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
    atest FrameworksServicesTests:ScreenDecorWindowTests
    atest ScreenDecorWindowTests
    

TF 統合テスト

TradeFed に統合されたテスト(非モジュール)を実行するには、tradefed.sh list configs コマンドの出力に表示されている名前を指定します。例:

reboot.xml テストを実行するには:

    atest example/reboot
    

native-benchmark.xml テストを実行するには:

    atest native-benchmark
    

ファイルパス

モジュール ベースのテストと統合ベースのテストの両方を実行するには、テストファイルまたはディレクトリへのパスを適宜指定します。クラスの Java ファイルへのパスを指定して、1 つのクラスを実行することもできます。相対パスと絶対パスの両方がサポートされています。

例: パスにより CtsJankDeviceTestCases モジュールを実行する(2 つの方法)

  1. Android の repo-root からモジュールを実行:

        atest cts/tests/jank
        
  2. Android の repo-root/cts/tests/jank からモジュールを実行:

        atest .
        

例: パスにより CtsJankDeviceTestCases モジュール内の特定のクラスを実行(Android の repo-root から):

    atest cts/tests/jank/src/android/jank/cts/ui/CtsDeviceJankUi.java
    

例: パスにより統合テストを実行(Android の repo-root から):

    atest tools/tradefederation/contrib/res/config/example/reboot.xml
    

パッケージ名

Atest は、パッケージ名によるテスト検索をサポートしています。

例:

    atest com.android.server.wm
    atest android.jank.cts
    

ステップの指定: ビルド、インストール、実行

-b-i-t オプションを使用して、実行するステップを指定できます。オプションを指定しない場合、すべてのステップが実行されます。

  • ビルド ターゲットのみ: atest -b test-to-run
  • テストのみを実行: atest -t test-to-run
  • apk をインストールしてテストを実行: atest -it test-to-run
  • ビルドして実行するが、インストールしない: atest -bt test-to-run

Atest によるテストで、クリーンアップやティアダウンのステップをスキップするよう強制できます。CTS などの多くのテストでは、テストの実行後にデバイスをクリーンアップするため、-t でテストを再実行する場合、--disable-teardown パラメータを指定しないと失敗します。テストのクリーンアップ ステップをスキップしてテストを反復するには、-d を使用してから -t を使用します。

    atest -d test-to-run
    atest -t test-to-run
    

特定のメソッドの実行

テストクラス内で特定のメソッドを実行できます。モジュール全体をビルドする必要がありますが、テストの実行に必要な時間が短縮されます。特定のメソッドを実行するには、サポートされているクラス特定方法(Module:Class、ファイルパスなど)を使用してクラスを特定し、メソッドの名前を追加します。

    atest reference-to-class#method1
    

カンマを使用して複数のメソッドを指定できます。

    atest reference-to-class#method1,method2,method3
    

例:

    atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
    

次の 2 つの例は、testFlagChange という単一のメソッドを実行するためのおすすめの方法を示しています。モジュールや Java ファイルの場所を指定すると、Atest でテストをすばやく見つけることができるため、クラス名のみを使用するよりも、こうした例の方法をおすすめします。

  1. Module:Class の使用

        atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
        
  2. Android の repo-root から

        atest frameworks/base/services/tests/servicestests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
        

さまざまなクラスとモジュールから複数のメソッドを実行できます。

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
    

複数のクラスの実行

複数のクラスを実行するには、複数のテストを実行する場合と同じようにクラスをスペースで区切ります。Atest はクラスを効率的にビルドして実行します。モジュール内のクラスのサブセットを指定すると、モジュール全体を実行するよりもパフォーマンスが向上します。

例:

  • 同じモジュール内の 2 つのクラス:

        atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
        
  • モジュールが異なる 2 つのクラス:

        atest FrameworksServicesTests:ScreenDecorWindowTests CtsJankDeviceTestCases:CtsDeviceJankUi
        

ネイティブ テストの実行

Atest はネイティブ テストを実行できます。

例:

  • 入力テスト:

        atest -a libinput_tests inputflinger_tests
        

-a を使用して、使用可能なすべてのデバイス アーキテクチャのテストを実行します。この例の場合、アーキテクチャは armeabi-v7a(ARM 32 ビット)および arm64-v8a(ARM 64 ビット)です。

指標回帰の検出

回帰検出を実行せずに、パッチ適用前またはパッチ適用後の指標を生成できます。反復回数を指定できますが、デフォルトは 5 回です。

例:

    atest test-to-run --generate-baseline [optional-iteration]
    atest test-to-run --generate-new-metrics [optional-iteration]
    

ローカル回帰の検出は、次の 3 つのオプションで実行できます。

  1. 基準となるパッチ適用前の指標を生成し、フォルダに配置します。Atest は指定した回数分テストを反復実行し、パッチ適用後の指標を生成して、既存の指標と比較します。

    例:

        atest test-to-run --detect-regression /path/to/baseline --generate-new-metrics [optional-iteration]
        
  2. 以前に生成されたパッチ適用後の指標を含むフォルダを使用して、Atest はテストを n 回反復実行し、パッチ適用前の指標の新しいセットを生成して、これらの指標を比較します。

    例:

        atest test-to-run --detect-regression /path/to/new --generate-baseline [optional-iteration]
        
  3. パッチ適用前とパッチ適用後の両方の指標を含む 2 つのフォルダを使用して、Atest はテストせずに回帰検出アルゴリズムを実行します。

    例:

        atest --detect-regression /path/to/baseline /path/to/new