このコンテンツは、Android プラットフォームのデベロッパーを対象としています。Android プラットフォームでテストを実施する方法を学ぶ前に、Android プラットフォームのアーキテクチャで概要をご覧ください。
その後、ベンダー テストスイート（VTS）のセクションや、その多数の動画と Codelab のチュートリアルなどを通じて、利用できるテクノロジーについて理解を深めてください。
デバイスの脆弱性の検出とデバイスの強化に使用できるセキュリティ固有のテスト メカニズムにも注意してください。
アプリのテストを行うには、まずテストの基礎に目を通し、提供されたサンプルを使用して Android テスト Codelab を実行します。
最後に、Repo フックで基本的な presubmit テストを使用できます。ここでは、commit のアップロードなどに進む前に、linter の実行、フォーマットの確認、単体テストのトリガーを行うことができます。このフックはデフォルトで無効になっています。 詳細については、Repo フックの概要をご覧ください。
テストの内容と方法
プラットフォーム テストは通常、1 つ以上の Android システム サービス、または Hardware Abstraction Layer（HAL）の各レイヤと連携し、テスト対象の機能を実行して、テスト結果の正当性についてアサーションを行います。
そのため、プラットフォーム テストでは次のことが可能です。
- アプリケーション フレームワークによりフレームワーク API を実行する。実行される特定の API には以下が含まれます。
- サードパーティ アプリケーション向けの公開 API
- 特権アプリケーション向けの非公開 API（システム API）
- 非公開 API（@hide、protected、package private）
- バインド元や IPC プロキシを直接介して Android システム サービスを呼び出す
- 低レベルの API または IPC インターフェースを介して HAL と直接通信する
タイプ 1 と 2 は通常、インストルメンテーション テストとして記述されますが、タイプ 3 は通常 GTests として記述されます。
詳細については、以下のエンドツーエンドの例をご覧ください。
上記ツールは Android でのテストに固有のものであるため、よく理解してください。
互換性テストスイート（CTS）
Android 互換性テストスイートは、さまざまなテストのスイートです。OEM パートナー間、プラットフォーム リリース間での Android フレームワーク実装の互換性を確認するために使用されます。また、インストルメンテーション テストや GTest フレームワークも含まれています。
CTS とプラットフォーム テストは相互に排他的ではありません。一般的なガイドラインは次のとおりです。
- テストがフレームワーク API の機能や動作の正当性についてアサーションを行い、OEM パートナー間で実施される場合は、CTS で行う必要があります
- テストがプラットフォーム開発サイクル中に回帰をキャッチすることを目的としており、実行に特権的な許可が必要で、実装の詳細（AOSP でリリースされたとおり）に依存する場合、プラットフォーム テストのみ行う必要があります
ベンダー テストスイート（VTS）
ベンダー テストスイート（VTS）は、HAL と OS カーネルのテストを自動化します。VTS を使用して、組み込みの Android システムの実装をテストするには、テスト環境をセットアップした後、VTS プランを使用してパッチをテストします。
Trade Federation テスト インフラストラクチャ
Trade Federation（tradefed あるいは単に TF）は、Android デバイスでテストを実行するために設計された継続的なテスト フレームワークです。TF は機能テストをローカルに実行できます。自分のデスクにおいてプラットフォーム チェックアウト内で行うことができます。TF でテストを実行するには、Java テストソースと XML 設定の 2 つのファイルが必要です。例については、RebootTest.java と reboot.xml をご覧ください。
デバッグ
デバッグ セクションでは、プラットフォーム レベルの機能を開発する際に組み込みの Android プラットフォーム コードをデバッグ、トレース、プロファイリングするための便利なツールと関連コマンドをまとめています。