Trade Federation（Tradefedまたは略してTF）は、Androidデバイスでテストを実行するために設計された継続的なテストフレームワークです。たとえば、Tradefedは、互換性テストスイート（CTS）とベンダーテストスイート（VTS）を実行するために使用されます。
Trade Federationは、ホストコンピューター上で実行されるJavaアプリケーションであり、adbを介してddmlib（DDMSの背後にあるライブラリ）を使用して1つ以上のAndroidデバイスと通信します。
TFの主な機能のいくつかを、いくつかのサンプルの使用例とともに以下にリストしました。とは言うものの、すぐに始めて始めたい場合は、 [ここから開始]ページに直接進むことができます。
特徴
- モジュール式、柔軟、スケーラブルなデザイン
- インストルメンテーション、 uiautomator 、native / gtest、ホストベースのJUnitなど、さまざまなタイプのAndroidテストを実行するためのサポートが組み込まれています。
- adbの上に信頼性と回復メカニズムを提供します
- 複数のデバイスでのテストのスケジューリングと実行を並行してサポートします
Instrumentationなどの既存のテストを実行する方法に関する最新情報については、 TFによるテストを参照してください。
ユースケース
Trade Federationのモジュール性により、既存のビルド、テスト、およびレポートインフラストラクチャを備えた環境に簡単に組み込むことができます。 Tradefedが効率的でスケーラブルなテスト手法を可能にする可能性のあるいくつかの実証的なユースケースを以下に示します。
まず、「どの部分が変更可能で、どの部分が静的であるか」という質問の観点から、潜在的なユースケースの状況を検討することは有用です。たとえば、デバイスOEMはフレームワーク、システム、およびハードウェアを変更できますが、既存のアプリケーションにはほとんどまたはまったく影響を与えません。一方、アプリケーション開発者はアプリを変更できますが、システムまたはフレームワークのほとんどの側面をほとんど制御できません。
その結果、各ユースケースのエンティティには異なるテスト目標があり、一連のテストが失敗した場合には異なるオプションがあります。これらの違いにもかかわらず、Trade Federationは、各テストプロセスを効率的、柔軟、かつスケーラブルにするのに役立ちます。
デバイスOEM
デバイスOEMはハードウェアを構築し、Androidシステムとフレームワークをそのハードウェアで適切に実行するように調整することがよくあります。 OEMは、ハードウェアおよびシステムレベルで安定性とパフォーマンスを維持し、フレームワークの変更によって既存のアプリケーションとの互換性が損なわれないようにしながら、これらの目標を達成しようと努める場合があります。
OEMは、ライフサイクルのターゲットセットアップ段階で実行されるデバイスフラッシュモジュールを実装できます。そのモジュールは、実行期間中にデバイスを完全に制御します。これにより、デバイスを強制的にブートローダーに入れてフラッシュし、デバイスを強制的に再起動してユーザースペースモードに戻すことができます。モジュールと組み合わせて継続的ビルドシステムに結び付けることで、OEMは、システムレベルのファームウェアとJavaレベルのフレームワークに変更を加えるときにデバイスでテストを実行できます。
デバイスが完全に起動すると、OEMは既存のJUnitベースのテストを活用したり、新しいテストを作成して、目的の機能を検証したりできるようになります。最後に、1つ以上の結果レポートモジュールを作成して、既存のテスト結果リポジトリに関連付けたり、結果を直接（たとえば、電子メールで）レポートしたりできます。
アプリ開発者
アプリケーション開発者は、さまざまなプラットフォームバージョンとさまざまなデバイスで適切に実行する必要があるアプリを作成します。特定のプラットフォームバージョンやデバイスで問題が発生した場合、唯一の解決策は回避策を追加して先に進むことです。大規模な開発者の場合、テストプロセスは継続的なビルドシーケンスに組み込まれる可能性があります。小規模な開発者の場合、定期的または手動で開始される場合があります。
ほとんどのアプリ開発者は、TFにすでに存在するapkテストインストールモジュールを使用します。ローカルファイルシステムからインストールするバージョンと、ビルドサービスからダウンロードしたapksをインストールできるバージョンがあります。後者のバージョンは、同じホストマシンで実行されている任意の数のTFインスタンスで引き続き適切に機能することに注意することが重要です。
TFは複数のデバイスを扱うことに熟練しているため、各テスト結果を、そのテストに使用されたデバイスのタイプで分類するのは簡単です。したがって、TFは、アプリケーションのビルドごとに2次元（または多次元）の互換性マトリックスを生成する可能性があります。
テストサービス
たとえば、テストサービスを使用すると、アプリ開発者はアプリを送信し、電力測定ツールを備えたデバイスでテストを実行して、アプリの電力使用量を判断できます。これは、サービスビルダーが実行中のデバイスまたはアプリケーションを制御しないという点で、前の2つのユースケースとは異なります。
Trade Federationは、単純なIRemoteTestインターフェイスを実装する任意のJavaクラスを実行できるため、デバイスで実行されているテストケースと外部ハードウェアを調整できるドライバーを作成するのは簡単です。ドライバ自体は、スレッドを生成したり、他のサーバーに要求を送信したり、その他必要なことを実行したりできます。さらに、結果レポートインターフェイスであるITestInvocationListenerのシンプルさと汎用性は、任意のテスト結果（たとえば、数値パワーメトリックを含む）を標準の結果レポートパイプラインに表すことも同様に簡単であることを意味します。