Developer-Powered CTS

このページでは、Developer-Powered CTS（CTS-D）の使用ガイドラインについて概説します。

テスト カバレッジ

CTS-D は、CTS や CTS 検証ツールと同様に、以下にのみ適用できます。

  • 特定の API レベル向けのデベロッパー SDK（developer.android.com）に記載されているすべての公開 API。
  • 特定の API レベル向けの Android 互換性定義ドキュメント（CDD）に含まれているすべての「しなければならない」要件。

「強く推奨される」、「するものとする」、「してもよい」といった、「しなければならない」以外の要件は省略可能であるため、CTS を使ってテストすることはできません。

すべての API と CDD の要件は特定の API レベルに関連付けられているため、CTS テスト（CTS、CTS-D、CTS 検証ツール）はすべて、関連付けられている API または要件と同じ API レベルに関連付けられます。特定の API がサポート終了となったり変更されたりした場合は、対応するテストもサポート終了または更新しなければなりません。

CTS テスト作成ルール

  • テストは、目標とする同じ結果が一貫して出るものでなければなりません。
  • テストは、初期状態でデバイスを 1 回テストすることにより、そのデバイスが合格か不合格かを判断するものでなければなりません。
  • テストの作成者は、テスト結果に影響を与える可能性のある要因をすべて取り除かなければなりません。
  • デバイスに特定のハードウェア条件 / 環境 / 設定が必要な場合は、コミット メッセージでその設定を明確に定義しなければなりません。設定手順の例については、CTS のセットアップについての説明をご覧ください。
  • テストは一度に 6 時間を超えて実行してはなりません。実行時間の延長が必要な場合は、Google で審査できるようテストプランにその理由の説明を含めてください。

以下に、アプリの制限をテストするためのテスト条件セットの例を示します。

  • Wi-Fi が安定している（Wi-Fi を使用するテストの場合）。
  • デバイスがテスト中に静止している（または、テストによっては、静止していない）。
  • デバイスはバッテリー残量が X% の状態で電源から外されている。
  • アプリ、フォアグラウンド サービス、バックグラウンド サービスが実行されていない（CTS を除く）。
  • CTS の実行中は画面がオフになる。
  • デバイスが isLowRamDevice ではない。
  • バッテリー セーバー / アプリの制限が「初期状態」から変更されていない。

テストの資格要件

Google は、既存の CTS、CTS 検証ツール、CTS-D のテストではテストされていない動作に適用される新しいテストを承認しています。テスト対象の動作がテスト カバレッジの範囲外であるテストは承認されません。

CTS 提出手続き

  1. テストプランを作成する: アプリ デベロッパーは、Google Issue Tracker を使用してテストプランを提出し、特定された問題を説明して、その問題を調べるためのテストを提案します。関連付けられた CDD の要件 ID を必ずプランに記載してください。Android チームがプランを審査します。
  2. CTS テストを作成する: プランが承認されると、プランの提出者がメイン（AOSP / メイン）ブランチの AOSP で CTS テストを作成します。Android チームがコードを審査します。
  3. テストを公開する: AOSP/main で CL を提出し、最新の androidx-tests-dev ブランチにチェリーピックします。これでテストは一般公開されます。

CTS-D テスト作成のガイドライン

  • Java コード スタイルガイドに沿って作成します。
  • CTS の開発に記載されているすべての手順を行います。
  • 適切なテストプランにテストを追加します。
    • include-filters を使用して新しいテストを CTS-D テストプラン（platform/cts/tools/cts-tradefed/res/config/cts-developer.xml）に追加します。
    • exclude-filters を使用して新しいテストをメインの CTS テストプラン（platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml）から除外します。
  • build_error.log に含まれている errorprone のすべての警告と提案に対処します。
  • head に変更をリベースします。これには、cts-developer.xml と cts-developer-exclude.xml のテストプランが含まれます。
  • Google のエンジニアリング担当者とともに、テストケースを既存の CTS モジュールに追加できるかどうかを判断します。追加できない場合は、エンジニアリング担当者が新しいモジュールの作成をサポートします。
  • 作成した新しいテスト モジュールごとに、新しいテスト モジュール ディレクトリに OWNERS ファイルを作成します。
    • OWNERS ファイルには、担当の Google テストオーナーから取得した次の情報を含めます。
    • # Bug component: xxx
    • Google テストオーナーの LDAP
  • AndroidTest.xml で、次のパラメータを指定します。例については、サンプル ファイル（1、2）をご覧ください。
    • Instant_app または not_instant_app
    • secondary_user または not_secondary_user
    • all_foldable_states または no_foldable_states
  • 正しい minSDK を指定するには、<uses-sdk> のドキュメントをご覧ください。
  • 新しいテストメソッド、クラス、モジュールをチェックインする場合は、新しいテストの場合と同じ方法で、それらを CTS-D テストプランに追加し、メインの CTS テストプランから除外します。

CTS-D テストの実行

run cts --plan cts-developer を使用してコマンドラインから CTS-D テストプランを実行します。

特定のテストケースを実行するには、run cts --include-filter "test_module_name test_name" を使用します。

CTS 全体の実行については、CTS テストの実行をご覧ください。

承認とリリース

テスト リクエストが提出されると、社内のチームが審査し、CDD 要件やドキュメント内の API 動作がテストされることを確認します。テストの対象が有効な要件や動作であると判断すると、チームはこのテストケースを Google エンジニアに転送し、さらに審査します。テストが CTS として承認される前に、Google エンジニアからテストの改善点についてフィードバックがあります。

CTS のリリース スケジュールについて詳しくは、リリース スケジュールとブランチ情報をご覧ください。