Trade Federation（Tradefed あるいは単に TF）は、Android デバイスでテストを実行するために設計された継続的なテスト フレームワークです。たとえば、Tradefed は互換性テストスイート（CTS）とベンダー テストスイート（VTS）を実行するために使用されます。
Trade Federation はホスト コンピュータ上で稼働する Java アプリケーションであり、adb を介して ddmlib（DDMS の背後にあるライブラリ）を使用して 1 つ以上の Android デバイスと通信します。
以下に、TF の主要な機能の一部といくつかのユースケースを示します。ただし、今すぐ開始する場合は、こちらから直接開始できます。
機能
- モジュール式、柔軟、スケーラブル デザイン
- instrumentation、uiautomator、native/gtest、ホストベースの JUnit など、さまざまな種類の Android テストを実行するためのサポートが組み込まれています。
- adb に信頼性と復元メカニズムを提供する
- 複数のデバイスに対するテストのスケジューリングと実行を並行して行う
Instrumentation などの既存のテストの実行方法については、TFC によるテストをご覧ください。
使用場面
Trade Federation のモジュール性により、既存のビルド、テスト、報告用のインフラストラクチャを備えた環境に簡単に対応できます。以下に、tradefed が効率的でスケーラブルなテスト慣行を実現できるデモ的なユースケースをいくつか紹介します。
まず、「変更可能な部分と静的部分」の観点で考えられるユースケースについて検討することが重要です。たとえば、デバイスの OEM はフレームワーク、システム、ハードウェアを変更できるものの、既存のアプリへの影響はほとんどまたはまったくありません。 一方、アプリ デベロッパーはアプリを変更できますが、システムやフレームワークの大部分については、ほとんど制御できません。
そのため、各ユースケースの当事者によってテスト目標が異なりますし、テストが失敗した場合の対応も異なります。このような違いにもかかわらず、Trade Federation は、各テストプロセスの効率性、柔軟性、スケーラビリティを高めるのに役立ちます。
デバイスの OEM
デバイス OEM はハードウェアを作成します。多くの場合、そのハードウェアで適切に動作するように Android システムとフレームワークを調整します。OEM は、ハードウェアやシステムレベルで安定性とパフォーマンスを維持しながら、フレームワークの目標を達成しようと努めており、フレームワークの変更が既存のアプリケーションとの互換性を損なわないようにする必要がある場合があります。
OEM は、ライフサイクルのターゲット セットアップ ステージで実行されるデバイスのフラッシュ モジュールを実装できます。そのモジュールでは、実行中にデバイスを完全に制御できます。そのため、デバイスをブートローダーに強制的にフラッシュしてフラッシュし、強制的にユーザー空間モードで再起動させることができます。これにより、モジュールを組み合わせて、システムレベルのファームウェアや Java レベルのフレームワークを変更しながら、OEM がデバイス上でテストを実行できます。
デバイスが完全に起動されると、OEM は既存の JUnit ベースのテストを活用したり、新しいテストを記述して目的の機能を検証したりすることができます。最後に、1 つ以上の結果レポート モジュールを作成して、既存のテスト結果リポジトリに関連付けるか、結果（メールなど）を直接報告します。
アプリのデベロッパー
アプリ デベロッパーは、さまざまなプラットフォーム バージョンとさまざまなデバイスで適切に動作する必要があるアプリをビルドします。特定のプラットフォーム バージョンやデバイスで問題が発生した場合は、回避策を追加して続行することが唯一の解決策となります。大規模なデベロッパーの場合は、継続的なビルドシーケンスにテストプロセスを組み込むことができます。小規模なデベロッパーの場合は、定期的にまたは手動で行われることもあります。
ほとんどのアプリ デベロッパーは、TF にすでに存在する APK テスト インストール モジュールを使用します。ローカル ファイル システムからインストールするバージョンと、ビルドサービスからダウンロードした apk をインストールできるバージョンがあります。古いバージョンは、同じホストマシン上で実行されている多数の TF インスタンスで引き続き正常に動作することに注意してください。
TF は複数のデバイスを扱うための高度なスキルを備えているため、各テスト結果をそのテストに使用されたデバイスタイプで簡単に分類できます。そのため、TF は、アプリケーションのビルドごとに 2 次元（または多次元）互換性マトリックスを生成する可能性があります。
検査サービス
たとえば、テストサービスの場合、アプリ デベロッパーは、電力測定ツールを操作したデバイスでアプリを送信して、アプリの電力消費を確認することで、テストを行うことができます。上述の 2 つのユースケースは、サービス ビルダーが実行中のデバイスまたはアプリケーションを制御しないという点で異なります。
Trade Federation はシンプルな IRemoteTest インターフェースを実装するすべての Java クラスを実行できるため、デバイスで実行されるテストケースを使用して、外部のハードウェアの一部を調整できるドライバを作成するのは簡単です。ドライバ自体は、スレッドを生成したり、他のサーバーにリクエストを送信したり、その他に必要な処理を実行したりできます。さらに、結果レポート インターフェース ITestInvocationListener の単純性と汎用性により、任意のテスト結果（たとえば、数値による電力指標など）を標準的な結果レポート パイプラインに取り込むのが容易になります。