開発者によるCTS

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

テストカバレッジ

CTS-Dは、CTSおよびCTS Verifierと同様に、次のことのみを強制できます。

  • 特定のAPIレベルの開発者SDK（developer.android.com）で説明されているすべてのパブリックAPI。
  • 特定のAPIレベルのAndroid互換性定義ドキュメント（CDD）に含まれているすべてのMUST要件。

STRONGLY RECOMMENDED、SHOULD、MAYなどのMUST以外の要件はオプションであり、CTSを使用してテストすることはできません。

すべてのAPIおよびCDD要件は特定のAPIレベルに関連付けられているため、すべてのCTSテスト（CTS、CTS-D、およびCTS Verifier）は、関連するAPIまたは要件と同じAPIレベルに関連付けられています。特定のAPIが非推奨または変更された場合、対応するテストを非推奨または更新する必要があります。

CTSテスト作成ルール

  • テストは、一貫して同じ客観的な結果を生成する必要があります。
  • テストでは、デバイスを箱から出して1回テストすることにより、デバイスが合格か不合格かを判断する必要があります。
  • テストの作成者は、テスト結果に影響を与える可能性のあるすべての要因を取り除く必要があります。
  • デバイスに特定のハードウェア条件/環境/セットアップが必要な場合は、そのセットアップをコミットメッセージで明確に定義する必要があります。セットアップ手順の例については、 CTSのセットアップを参照してください。
  • テストは一度に6時間を超えて実行してはなりません。長時間実行する必要がある場合は、レビューできるように、テスト提案に理由を含めてください。

以下は、アプリの制限をテストするための一連のテスト条件の例です。

  • Wifiは安定しています（Wifiに依存するテストの場合）。
  • テスト中、デバイスは静止したままです（テストによっては静止したままになります）。
  • デバイスは、バッテリーレベルのXパーセントの電源からプラグが抜かれています。
  • CTSを除いて、アプリ、フォアグラウンドサービス、またはバックグラウンドサービスは実行されていません。
  • CTSの実行中は画面がオフになります。
  • デバイスはisLowRamDeviceではありません。
  • バッテリーセーバー/アプリの制限は、「すぐに使える」状態から変更されていません。

テストの適格性

既存のCTS、CTS Verifier、またはCTS-Dテストではテストされない動作を強制する新しいテストを受け入れます。テストカバレッジの範囲外の動作をチェックするテストはすべて拒否されます。

CTS提出プロセス

  1. テスト提案を作成する：アプリ開発者は、 Google Issue Trackerを使用してテスト提案を送信し、特定された問題を説明し、それを確認するためのテストを提案します。プロポーザルには、関連するCDD要件IDを含める必要があります。 Androidチームが提案を確認します。
  2. CTSテストの開発：提案が承認された後、その提出者はメイン（AOSP /マスター）ブランチのAOSPでCTSテストを作成します。 Androidチームがコードを確認します。
  3. テストの公開： CLをAOSP/masterに送信してから、最新の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 。
  • errorproneでbuild_error.logが発生しやすいすべての警告と提案を処理します。
  • 変更を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 run cts --plan cts-developerを使用して、コマンドラインからCTS-Dテストプランを実行します。

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

フルCTSの実行については、「 CTSテストの実行」を参照してください。

受け入れと解放

テストリクエストが送信されると、内部チームがそれをレビューして、CDD要件または文書化されたAPIの動作をテストしていることを確認します。テストが有効な要件または動作をチェックしていると判断された場合、チームはこのテストケースをGoogleのエンジニアに転送してさらに確認します。 Googleのエンジニアは、CTSに受け入れられる前に、テストを改善する方法についてフィードバックを提供します。

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