2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
TF テストのライフサイクル
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Trade Federation を使用して実行されるテストのライフサイクルは、正式に定義されたインターフェースを中心に設計された 4 つの個別のステージで構成されます。
定義済みインターフェース
- ビルド プロバイダ: テスト対象のビルドを提供し、必要に応じて適切なファイルをダウンロードします。
- ターゲット作成ツール: テスト環境を準備します。ソフトウェアのインストールとデバイスの設定を行う場合もあります。
- テスト: テストを実行し、テスト結果を収集します。これはなんらかの JUnit テストですが、IRemoteTest インターフェースは、特に Trade Federation 環境で適切に機能するように設計されています。
- テスト呼び出しリスナー(結果レポート): テスト結果をリッスンします。通常は、テスト結果をリポジトリに転送するかテストランナーに表示する目的で使用します。
TF の基本的なテスト エンティティは、構成(config)です。config は、テストのライフサイクル コンポーネントを宣言する XML ファイルです。
このようなテストのライフサイクルの分離は、再利用を目的としています。この設計により、開発者がテストを 1 つ作成すると、インテグレータはさまざまな構成を作成してさまざまな環境でそのテストを実行できます。たとえば、ローカルマシンでテストを実行して結果を stdout にダンプする構成を作成できます。次に、同じテストを実行する 2 つ目の構成を作成し、今度は別のテスト呼び出しリスナーを使用してテスト結果をデータベースに格納できます。3 つ目の構成は、テストラボのいずれかの場所から継続的にテストを実行するように設計できます。
ここで、構成とそのコマンドライン引数(テストランナーによって指定されます)を合わせてコマンドと呼ぶことに注意してください。さらに、TF がコマンドと ITestDevice
を組み合わせて実行する場合、後続のオブジェクトを呼び出しと呼びます。つまり、呼び出しは、ライフサイクル全体にわたる完全な TF テスト実行を包含する概念です。
その他の構成コンポーネント
- デバイス リカバリ: デバイスの通信が失われた場合に復元するメカニズム。
- ロガー: tradefed ロギングデータを収集します。
ステージの出力とエラー
呼び出しの各ステージは順番に実行され、それぞれに特定の目標があります。このセクションでは、各ステージの一般的な出力とエラーについて説明します。
ビルド プロバイダ
このステージでは、テストの設定と実行に必要なすべてのファイル参照を含む IBuildInfo
オブジェクトを作成して出力します。
このステージで最もよくあるエラーは、リクエストされたファイルのダウンロードまたは検索の失敗です。
このステージでエラーが発生した場合は、エラーが直接レポートされ、テストは開始されません。
ターゲットの作成
このステージでは、テストするターゲットに必要な状態を設定します。このステージでは、必要に応じて、特定のテスト呼び出しに対してデバイスまたはホストの設定を変更できます。
このステージでよくあるエラーは、デバイスを特定の状態に設定できないエラー(フラッシュの失敗など)や、設定に必要なファイルが見つからないエラーです。
このステージでエラーが発生した場合は、ターゲットでクリーンアップが実行され、エラーがレポートされ、テストは開始されません。
テスト
このステージでは、リクエストされたテストを前のステージで作成したターゲットで実行し、すべてのテスト実行結果をレポートします。
このステージでよくあるエラーは、テストするターゲットを使用できないエラーや、テストの一部のみが実行されるエラーです。こうしたエラーは 1 つのテストケースに限られた問題ではなく、テスト実行そのものに影響するインフラストラクチャの問題です。
このステージでエラーが発生した場合は、テストの実行が中止され、ターゲットのクリーンアップが実行され、エラーがレポートされ、部分的な結果が返されます。
結果レポート
このステージでは、構成済みのサービス(サーバーやローカル ファイルなど)に結果とエラーをレポートします。
個々の結果レポーターがエラーをレポートしますが、エラーは相互に分離されています(あるレポーターは別のレポーターのエラーを表示しません)。これらのエラーは個々のレポーターの結果レポートにのみ影響します。エラーはログで確認できます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# TF test lifecycle\n\nThe lifecycle of a test executed using Trade Federation is composed of four separate stages,\ndesigned around formally defined interfaces.\n\nDefined interfaces\n------------------\n\n- [Build Provider](/reference/tradefed/com/android/tradefed/build/IBuildProvider): Provides a build to test, downloading appropriate files if necessary.\n- [Target Preparer](/reference/tradefed/com/android/tradefed/targetprep/ITargetPreparer): Prepares the test environment, possibly including software installation and device configuration.\n- [Test](/reference/tradefed/com/android/tradefed/testtype/IRemoteTest): Executes test(s) and gathers test results. This may be any JUnit Test, although our [IRemoteTest](/reference/tradefed/com/android/tradefed/testtype/IRemoteTest) interface is specifically designed to work well in the Trade Federation environment.\n- [Test Invocation Listener (results reporting)](/reference/tradefed/com/android/tradefed/result/ITestInvocationListener): Listens for test results, usually for the purpose of forwarding the test results to a repository or displaying them to the Test Runner.\n\nThe fundamental testing entity in TF is a **Configuration** (config). A config is an XML file\nthat declares the lifecycle components of a test.\n\nThis separation of the test's lifecycle is intended to allow for reuse. Using this design, the\nDeveloper can create a Test once, and then the Integrator can create different Configurations to\nrun that Test in different environments. For example,\nthey could create a Configuration that will run a test on a local machine and dump the result to\nstdout. They could then create a second Configuration that would execute that same test, but use a\ndifferent Test Invocation Listener to store the test results in a database. A third Configuration\nmight be designed run that test continuously from a test lab somewhere.\n\nIt's convenient to note here that a Configuration along with its command-line arguments (as\nprovided by the Test Runner) is known as a **Command** . When TF pairs a Command with an\n`ITestDevice` and executes it, the subsequent object is known as an **Invocation**.\nIn short, an Invocation encompasses a complete TF test execution, across its entire lifecycle.\n\nAdditional configuration components\n-----------------------------------\n\n- [Device Recovery](/reference/tradefed/com/android/tradefed/device/IDeviceRecovery): mechanism to recover device communication if lost.\n- [Logger](/reference/tradefed/com/android/tradefed/log/package-summary): collects tradefed logging data.\n\nStage output and errors\n-----------------------\n\nEach stage of an invocation executes sequentially and has a specific goal. This section describes\nthe usual outputs and errors of each stage.\n\n### Build provider\n\nThis stage creates and outputs an\n[`IBuildInfo`](/reference/tradefed/com/android/tradefed/build/IBuildInfo) object that contains all the required files references to set up and run the tests.\n\nThe most common error at this stage is a failure to download or find the requested files.\n\nAn error at this stage results in directly reporting the error, and no tests being run.\n\n### Target preparation\n\nThis stage sets up the necessary states for the target under tests. This stage can alter the\ndevice or the host setup as needed for the given test invocation.\n\nCommon errors at this stage usually involve failure to setup the device into a given state\n(for example, failed flashing) and failure to find the required files for the setup.\n\nAn error at this stage results in target clean up running, reporting of the error, and no tests\nbeing run.\n\n### Tests\n\nThis stage runs the requested tests on the previously prepared target, and reports all the\ntest execution results.\n\nCommon errors at this stage usually involve the target under test being unavailable or some\nerror causing partial execution of the tests. These errors are infrastructure issues that affect\nthe test execution itself as opposed to a failure of a single test case.\n\nAn error at this stage results in the test execution stopping, the target clean up running,\nreporting the error, and getting partial results.\n\n### Results reporting\n\nThis stage reports the results and errors to the configured services (for example, servers and\nlocal files).\n\nAlthough individual results reporters can have errors, they're isolated from each other\n(one reporter doesn't see errors from another one). These errors affect only an individual\nreporter's own results reporting and the errors can be viewed in the logs."]]