CTS の結果を解釈する

CTS テストの結果は、次のファイルに保存されます。

CTS_ROOT/android-cts/results/start_time.zip

CTS を自分でビルドした場合、CTS_ROOT は out/host/linux-x86/cts のようになります。ただし、プラットフォームによって異なります。その違いは、事前にビルドされた公式の CTS をこのサイトからダウンロードしたときに、CTS を圧縮解除したパスを反映しています。

zip 内の test_result.xml ファイルに実際の結果が含まれています。

Android 10 以降の結果を表示する

test_result.html ファイルは zip アーカイブ内にあり、任意の HTML5 対応ウェブブラウザで直接開くことができます。

Android 10 より前の結果を表示する

テスト結果を表示するには、任意の HTML5 対応ウェブブラウザで test_result.xml ファイルを開きます。

Chrome ブラウザで開いたときに空白のページが表示される場合は、ブラウザの設定を変更して --allow-file-access-from-files コマンドライン フラグを有効にします。

テスト結果を確認する

テスト結果の詳細は、次のうちどちらのバージョンの CTS を使用しているかによって異なります。

  • Android 6.0 以前用の CTS v1
  • Android 7.0 以降用の CTS v2

デバイス情報

CTS v1 以前では、[Device Information]（[Test Summary] の上のリンク）を選択して、デバイス、ファームウェア（型、モデル、ファームウェア ビルド、プラットフォーム）、デバイスのハードウェア（画面の解像度、キーパッド、画面の種類）の詳細を確認できます。CTS v2 では、デバイス情報は表示されません。

テストサマリー

[Test Summary] セクションには、CTS プラン名、実行開始時間、実行終了時間など、実行されたテストプランの詳細が表示されます。また、合格したテスト、不合格になったテスト、タイムアウトしたテスト、実行できなかったテストの総数も表示されます。

Android 10 CTS のテストサマリーのサンプル

Android 10 CTS のテストサマリー

図 1: Android 10 CTS のテストサマリーのサンプル

CTS v2 のテストサマリーのサンプル

CTS v2 のテストサマリー

図2: CTS v2 のテストサマリーのサンプル

CTS v1 のテストサマリーのサンプル

CTS v1 テストサマリー

図3: CTS v1 のテストサマリーのサンプル

テストレポート

次のセクションで示す CTS テストレポートでは、合格したテストをパッケージごとに集計したサマリーが表示されます。

それに続いて、実行された実際のテストの詳細が表示されます。レポートには、テスト パッケージ、テストスイート、テストケース、実行されたテストが一覧表示されます。テストの実行結果（合格した、不合格になった、タイムアウトした、実行されなかった）も表示されます。テストが不合格になった場合は、原因を診断するための詳細が表示されます。

さらに、XML ファイルでは、不合格になった箇所のスタック トレースを参照できます。これは、長いのでレポートには含まれていません。XML ファイルをテキスト エディタで表示すると、テスト不合格の詳細を確認できます。不合格になったテストに対応する [Test] タグを検索し、その中の [StackTrace] タグを確認してください。

CTS v2 のテストレポートのサンプルを表示する

CTS v2 のテストレポート

図 4: CTS v2 のテストレポートのサンプル

CTS v1 のテストレポートのサンプルを表示する

CTS v1 のテストレポート

図 5: CTS v1 のテストレポートのサンプル

未完了のテスト モジュールの test_result.xml を確認する

指定のテスト セッションにおける未完了のモジュールの数を調べるには、コマンド「list results」を実行します。[Modules Completed] と [Total Modules] の数が、前のセッションごとに表示されます。どのモジュールが完了済みでどのモジュールが未完了かを確認するには、test_result.xml ファイルを開いて、結果レポートの各モジュールで「done」属性の値を調べます。done の値が「false」のモジュールは、完了していません。

テスト不合格を選別する

テスト不合格を選別するには、次のヒントを参考にしてください。

  • 前提条件の誤りが原因でテストが不合格になった場合は、CTS 環境が正しくセットアップされているかどうかを確認します。CTS 環境には、物理環境、デスクトップ マシンのセットアップ、Android デバイスのセットアップが含まれます。
  • テストが極度に不安定に見える場合は、デバイスの安定性、テストのセットアップ、環境に関する問題を確認します。
  • それでも不合格になる場合は、テストを分離して再試行します。
  • 次のようなテスト不合格を引き起こす外的要因をチェックします。
    • 環境のセットアップ: たとえば、デスクトップ マシンのセットアップの誤りは、参照デバイスを含むすべてのテスト対象デバイス（DUT）でテスト不合格を引き起こす可能性があります。
    • 外部依存関係: たとえば、特定の時点で開始される複数のサイトのすべてのデバイスでテストが不合格になる場合、不正な URL が原因である可能性があります。
    • DUT にセキュリティ パッチが含まれていない場合は、セキュリティ テストの不合格が予想されます。
  • 合格するデバイスと不合格になるデバイスの違いを検証し、分析します。
  • アサーション、ログ、バグレポート、CTS ソースを分析します。HostTest では、アサーションとログの汎用性がきわめて高いため、デバイスの logcat をチェックしてアタッチすることも有用です。
  • テスト改善パッチを送信すると、テスト不合格の削減に役立ちます。

部分的な結果を保存する

テストの呼び出しが失敗した場合、Tradefed は部分的なテスト結果を保存しません。

Tradefed がテスト結果を生成しない場合は、テスト実行中に重大な問題が発生したため、テスト結果が信頼できないことが示唆されます。部分的な結果は、デバイスの問題を調査する際に価値を提供しないので、有用でないと見なされます。