Android オープンソース プロジェクト(AOSP)には、実装のさまざまな部分をテストするための複数のツールとテストスイートが用意されています。このセクションのページを読む前に、以下の用語について知っておく必要があります。
- Android 互換デバイス
- サードパーティ デベロッパーが Android SDK および NDK を使用して作成したサードパーティ製アプリを実行できるデバイス。Android 互換デバイスは、互換性定義ドキュメント(CDD)の要件に準拠し、互換性テストスイート(CTS)に合格している必要があります。Android 互換デバイスは Android エコシステムに参加でき、Google Play のライセンス、Google モバイル サービス(GMS)アプリスイートおよび API のライセンスを取得できる可能性があるほか、Android 商標の使用が許可されています。Android ソースコードは誰でも使用できますが、Android エコシステムに参加していると見なされるためには、デバイスが Android 互換である必要があります。
- アーティファクト
- ローカルのトラブルシューティングを可能にする、ビルドに関連するログです。
- 互換性定義ドキュメント(CDD)
- Android 互換デバイスに関するソフトウェア要件とハードウェア要件が列挙されたドキュメント。
- 互換性テストスイート(CTS)
無料でありながら商用レベルの品質を持つテストスイート。AOSP のバイナリまたはソースとしてダウンロードできます。CTS は、日々のワークフローに組み込まれるように設計された単体テストの集まりです。非互換性を明らかにし、開発プロセス全体を通じてソフトウェアの互換性を保つことを目的としたツールです。
CTS とプラットフォーム テストは相互に排他的ではありません。一般的なガイドラインは次のとおりです。
- フレームワーク API の機能や動作の正当性をアサーションで検証する目的で、OEM パートナー間でテストを実施する場合は、CTS で行う必要があります。
- プラットフォーム開発中にリグレッションをキャッチするための回帰テストで、実行するために特権的な許可が必要で、実装の詳細(AOSP でリリースされたとおり)に依存する場合、プラットフォーム テストを行う必要があります
- Google モバイル サービス(GMS)
デバイスにプリインストールできる Google アプリおよび API の集合。
- GoogleTest(GTest)
C++ のテストおよびモック フレームワークです。通常、GTest バイナリは、低レベル抽象化レイヤにアクセスするか、さまざまなシステム サービスに対して raw IPC を実行します。GTest のテスト方法は通常、テスト対象のサービスと密接に関連しています。CTS には GTest フレームワークが含まれています。
- インストルメンテーション テスト
am instrument
コマンドによって起動される特別なテスト実行環境です。この環境でターゲット アプリプロセスが再起動され、基本アプリ コンテキストで初期化されて、アプリプロセス仮想マシン内でインストルメンテーション スレッドが起動されます。CTS にはインストルメンテーション テストが含まれています。- Logcat
デバイスがエラーをスローしたときのスタック トレースや、
Log
クラスを使用してアプリから書き込んだメッセージなど、システム メッセージのログを作成するコマンドライン ツールです。- ロギング
ログを使用してコンピュータ システムのイベント(エラーなど)を追跡します。Android におけるロギングは、さまざまな規格が使用されて Logcat ツールに組み込まれているため、複雑になっています。
- postsubmit テスト
共通カーネル ブランチに新しいカーネルが commit されるときに実施される Android テストです。ブランチ名の一部として
aosp_kernel
を入力すると、該当するカーネル ブランチの結果がリスト表示されます。たとえば、android-mainline
の結果は https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid で確認できます。- presubmit テスト
共通カーネルにエラーが入り込むのを防ぐために使用されるテストです。
- Trade Federation
Android デバイスでテストを実行するために設計された継続的なテスト フレームワークです(Tradefed とも呼ばれます)。たとえば、Tradefed は互換性テストスイートとベンダー テストスイートを実行するために使用されます。
- ベンダー テストスイート(VTS)
Android のテスト用に提供される幅広い機能です。テスト駆動開発プロセスを推進して、Hardware Abstraction Layer(HAL)と OS カーネルのテストを自動化します。
プラットフォーム テストのタイプ
プラットフォーム テストは通常、1 つ以上の Android システム サービス、または HAL のレイヤと連携し、テスト対象の機能を実行して、結果の正当性をアサーションで検証します。プラットフォーム テストは次のように動作します。
- (タイプ 1)Android フレームワークを使用してフレームワーク API を実行します。実行される API は具体的には以下のとおりです。
- サードパーティ製アプリを対象とする公開 API
- 特権アプリを対象とする非表示の API。つまり、システム API または非公開 API(
@hide
、protected
、package private
)
- (タイプ 2)バインド元や IPC プロキシを直接使用して Android システム サービスを呼び出します。
- (タイプ 3)低レベルの API または IPC インターフェースを使用して HAL と直接やり取りします。
タイプ 1 と 2 のテストは一般にインストルメンテーション テストですが、タイプ 3 は通常は GTest です。
次のステップ
以下は、詳細情報を確認できるドキュメントの一覧です。
Android アーキテクチャについて学習していない場合は、アーキテクチャの概要をご覧ください。
Android 互換デバイスを作成している場合は、Android 互換性プログラムの概要をご覧ください。
インストルメンテーション テスト、機能テスト、指標テスト、JAR ホストテストをプラットフォームの継続的なテストサービスに統合するには、テスト開発ワークフローをご覧ください。
デバイスの脆弱性を検出してデバイスを強化するには、セキュリティ テストをご覧ください。
HAL 実装とカーネル実装のテストの詳細については、ベンダー テストスイート(VTS)とインフラストラクチャをご覧ください。
アプリテストについては、Android アプリのテストの基礎を読み、用意されたサンプルを使用して Kotlin 05.1 での高度な Android: テストの基礎を実施してください。
Repo フックを通じて使用できる基本の presubmit テストについてご紹介します。これらのフックを使用すると、commit のアップロードなどに進む前に、linter を実行したり、フォーマットを確認したり、単体テストをトリガーしたりできます。これらのフックはデフォルトでは無効になっています。詳細については、AOSP プリアップロード フックをご覧ください。
ロギングの詳細については、ロギングについてをご覧ください。
Android コードのデバッグ方法について理解するには、ネイティブ Android プラットフォーム コードのデバッグをご覧ください。