Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Struktur AndroidTest.xml

Struktur keseluruhan dari konfigurasi modul mengikuti pola yang mirip dengan konfigurasi XML Tradefed biasa tetapi dengan beberapa batasan karena fakta bahwa mereka berjalan sebagai bagian dari suite.

Daftar tag yang diizinkan

AndroidTest.xml atau konfigurasi modul yang lebih luas hanya dapat berisi tag XML berikut: target_preparer , multi_target_preparer , test dan metrics_collector .

Meskipun daftar itu terlihat terbatas, ini memungkinkan Anda untuk secara tepat menentukan kebutuhan pengaturan modul pengujian dan pengujian untuk dijalankan.

CATATAN: Lihat konfigurasi Tradefed XML jika Anda memerlukan penyegaran pada tag yang berbeda.

Objek seperti build_provider atau result_reporter akan memunculkan ConfigurationException jika dicoba dijalankan dari dalam konfigurasi modul. Ini dimaksudkan untuk menghindari harapan objek-objek ini benar-benar melakukan beberapa tugas dari dalam modul.

Contoh konfigurasi modul

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

Konfigurasi ini menjelaskan pengujian yang memerlukan CtsGestureTestCases.apk dan akan menjalankan instrumentasi terhadap paket android.gesture.cts .

Kasus khusus untuk tag "metrics_collector"

metrics_collector diperbolehkan tetapi terbatas pada kelas FilePullerLogCollector untuk menentukan file atau direktori tertentu yang akan ditarik dan dicatat untuk modul. Ini berguna jika Anda meninggalkan log di lokasi tertentu dan ingin memulihkannya secara otomatis.

Contoh konfigurasi:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

Bagaimana dengan info build atau unduhan?

Definisi tag yang diizinkan mungkin memberikan kesan yang salah bahwa modul tidak akan mendapatkan informasi build apa pun. Ini tidak benar .

Informasi build disediakan dari pengaturan tingkat suite dan akan dibagikan oleh semua modul suite. Ini memungkinkan satu pengaturan tingkat atas untuk suite untuk menjalankan semua modul bagian dari suite.

Misalnya, alih-alih setiap modul Compatibility Test Suite (CTS) secara individual menanyakan informasi perangkat, jenis, dll., penyiapan tingkat suite CTS ( cts.xml ) melakukannya sekali dan setiap modul akan menerima informasi itu jika mereka memintanya.

Agar objek dalam modul menerima informasi build, objek tersebut perlu melakukan hal yang sama seperti pada konfigurasi Tradefed biasa: mengimplementasikan antarmuka IBuildReceiver untuk menerima IBuildInfo . Lihat pengujian dengan perangkat untuk detail selengkapnya.

Bidang metadata

Sejumlah besar modul pengujian menyertakan beberapa spesifikasi metadata , yang masing-masing memiliki tujuan unik.

Contoh:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

Komponen

Metadata component menjelaskan komponen Android umum yang ingin diuji oleh modul. Itu tidak memiliki dampak langsung pada eksekusi tes; itu terutama digunakan untuk tujuan organisasi.

Daftar komponen terbaru yang diizinkan untuk CTS tersedia di CtsConfigLoadingTest . Tes ini gagal dalam pra-pengiriman jika komponen yang tidak ada ditambahkan ke modul CTS.

Anda dapat memfilter rangkaian yang dijalankan berdasarkan komponen menggunakan module-metadata-include-filter dan module-metadata-exclude-filter .

Contoh:

  --module-metadata-include-filter component framework

Contoh ini hanya menjalankan modul pengujian yang dijelaskan dengan komponen framework .

Parameter

Metadata parameter bersifat informasional dan berdampak pada eksekusi pengujian. Ini menentukan mode Android mana yang diterapkan modul pengujian. Dalam hal ini, mode terbatas pada mode Android level tinggi, seperti instant apps , secondary users , atau different abis .

Selama rangkaian berjalan, jika mode berlaku untuk pengujian, beberapa variasi modul pengujian dibuat berdasarkan mode. Setiap variasi menjalankan tes serupa tetapi dalam mode yang berbeda.

  • instant_app : Buat variasi pengujian yang menginstal APK sebagai aplikasi instan.
  • multi_abi : Buat variasi tes untuk setiap ABI yang didukung oleh perangkat.
  • secondary_user : Buat variasi pengujian yang menginstal APK dan menjalankan pengujian sebagai pengguna sekunder.