自動テスト インフラストラクチャ

Android 9 には、AOSP Generic System Image(GSI)を搭載しているパートナー デバイスで VTS、CTS、またはその他のテストに対する自動テストを行うベンダー テストスイート(VTS)インフラストラクチャがあります。以前は、これらのテストをほとんど手動で実行していましたが、新しい VTS テスト インフラストラクチャは、複数のデバイスで 1 日に何回も自動テストできるように設計されています。

アーキテクチャ

VTS 自動テスト インフラストラクチャでは、次のアーキテクチャが使用されています。

自動テストのアーキテクチャ

図 1. VTS 自動テスト インフラストラクチャのアーキテクチャ

テストが起動されると、VTS 自動テスト インフラストラクチャは次のタスクを実行します。

  1. 次の場所からビルド アーティファクトとテストリソースを取得する。
    • パートナー Android ビルド(PAB): GSI、VTS フレームワーク、その他のビルド用。
    • ローカル ファイルシステム、Google Cloud Storage、またはベンダー固有のビルドシステム: Google のクラウドにビルドを保存していないパートナー向け。
  2. ビルド アーティファクト(デバイスから)と GSI(AOSP から)を接続したデバイスに書き込む。
  3. ローカルの TradeFed またはクラウドの TradeFed を使用して VTS テストを実行する。
  4. テスト結果を VTS ダッシュボードに報告する。

このプロセスは VTS ホスト コントローラ(HC)によって調整されます。HC は、すべての接続されたテスト対象デバイスの動作を指揮するラボ内のマシンです。HC は、最新のビルドの取得、デバイスへの書き込み、ローカルまたはコマンダーによるテストを行います。また、クラウド スケジューラと通信し、スケジューラと HC で実行されている TradeFed インスタンス(または他のハーネス)との間のトラフィックを管理します。ホスト コントローラの詳細については、ホスト コントローラのアーキテクチャをご覧ください。

リソース プロバイダ

自動テストには、システムビルド、テストファイル、VTS アーティファクトなどのリソースが必要です。ソースからビルドすることは可能ですが、定期的に最新版からビルドし、ダウンロードするアーティファクトを投稿する方が簡単です。

パートナーは、次の場所を使用して自動化リソースにアクセスできます。

  • パートナー Android ビルド: アカウント単位で付与されるプログラムによるアクセスの権限。
  • ローカル ファイルシステムなど: パートナー Android ビルドを使用していないパートナーの場合。

後でデバイスに書き込む際に使用するために、リソースには両方のオプション用のビルド プロバイダが含まれます。ビルドをローカルの一時ディレクトリに格納する 1 つの build_provider.py から拡張したものです。

パートナー Android ビルド

Android 8.1 以前のリリースでは、Android パートナーは、パートナー Android ビルド ウェブサイト(https://partner.android.com/build)にアクセスし、自身のアカウントに移動して、ユーザー インターフェースで最新のシステム イメージを取得する必要がありました。このような面倒で時間のかかる作業を避けるために、Android 9 では、適切な認証情報が提供されたときに、これらのリソースが PAB から自動的にダウンロードされるようになりました。

アクセスを確立する

プログラムによるアクセスでは、Google API で OAuth2 を使用して必要な RPC にアクセスします。OAuth2 認証情報の生成に標準的な方法を使用する場合、パートナーは Google でクライアント ID とシークレットのペアをセットアップする必要があります。PartnerAndroidBuildClient で初めてそのシークレットが指定されたとき、Google アカウントにログインするためのブラウザ ウィンドウが開き、次へ進むのに必要な OAuth2 認証情報が生成されます。認証情報(アクセス トークンと更新トークン)はローカルに保存されます。つまり、パートナーがログインする必要があるのは一度だけです。

URL に対する POST リクエスト

PAB のリソースリンクをクリックすると、リソースに必要な次のデータを含んだ POST リクエストが送信されます。

  • ビルド ID、ビルド ターゲット
  • リソース名
  • ブランチ
  • リリース候補版名と、それが内部ビルドかどうか

POST リクエストは、buildsvc RPC の downloadBuildArtifact メソッドによって受信され、リソースにアクセスに使用できる URL が返されます。

  • Clockwork Companion APK リソースの場合、URL は PAB でホストされる、わかりやすい URL です。認証で保護され、適切な OAuth2 認証情報でアクセスできます。
  • 他のリソースの場合、URL は内部の Android Build API からの保護されていない長い URL です(有効期間は 5 分です)。

URL を取得する

クロスサイト リクエスト フォージェリを回避するために、buildsvc RPC では、他のパラメータとともに XSRF トークンを POST する必要があります。このトークンにより処理の安全性が高まりますが、アクセスには PAB ページの JavaScript からのみ入手できるトークンも必要となっているため、プログラムからのアクセスがさらに難しくなっています。

この問題を回避するために、Android 9 では、APK だけでなく、すべてのファイルに対して URL の命名規則を再設計し、予測可能な URL 名を使用してアーティファクト リストやアーティファクト URL にアクセスするようにしました。PAB は簡単な URL 形式を使用するようになり、パートナーがリソースをダウンロードできるようになりました。HC スクリプトは URL 形式がわかっているため APK を簡単にダウンロードできますが、HC は buildsvc RPC を必要としないため XSRF や Cookie の問題を回避できます。

ローカル ファイルシステム

ディレクトリにアーティファクトのリストまたは zip ファイルがある場合、ビルド プロバイダは、ディレクトリの内容に基づいて適切なイメージを設定します。Google Cloud Storage からローカル ディレクトリにファイルをコピーするには、gsutil ツールを使用します。

ビルドを書き込む

最新のデバイス イメージがホストにダウンロードされると、そのイメージがデバイスに書き込まれます。これは、ビルド プロバイダによって保存された一時ファイルパスに基づいて、標準の adb コマンドと fastboot コマンド、Python サブプロセスを使用して行います。

以下の操作がサポートされています。

  • GSI のみを書き込む
  • メインシステムから個別のイメージを書き込む(例: fastboot flash boot boot.img
  • メインシステムからすべてのイメージを書き込む。例:
    • fastboot flashall(組み込みの flashall ユーティリティを使用)
    • fastboot flash(1 つずつ)

テストを実行する

Android 9 では、VTS 自動テスト インフラストラクチャは TradeFed テストハーネスのみをサポートしますが、将来的に他のハーネスをサポートするように拡張できます。

デバイスを準備したら、次のいずれかの方法でテストを実行できます。

  • ローカルで TradeFed を使用する場合は、test コマンドをホスト コントローラで使用します。コマンドは、VTS テストプランの名前(vts-selftest など)を受け取り、テストを実行します。
  • TradeFed クラスタ(任意で MTT に接続)を使用している場合は、ホスト コントローラのコンソールで lease コマンドを使用します。これにより、完了していないテスト実行が見つかります。

TradeFed クラスタを使用している場合、TradeFed はリモート マネージャーとしてローカルで動作します。それ以外の場合、テストは Python サブプロセスを使用して呼び出されます。

結果を報告する

テスト結果は VtsMultiDeviceTest によって自動的に VTS ダッシュボード プロジェクトに報告されます。