Struktur keseluruhan konfigurasi modul mengikuti pola yang serupa dengan konfigurasi XML Tradefed biasa, tetapi dengan beberapa batasan karena fakta bahwa konfigurasi tersebut berjalan sebagai bagian dari rangkaian pengujian.
Daftar tag yang diizinkan
AndroidTest.xml atau konfigurasi modul secara lebih luas hanya dapat berisi tag XML berikut: target_preparer, multi_target_preparer, test, dan metrics_collector.
Meskipun daftar tersebut terlihat membatasi, Anda dapat menentukan secara tepat kebutuhan penyiapan modul pengujian dan pengujian yang akan dijalankan.
CATATAN: Lihat Konfigurasi XML Tradefed jika Anda perlu mempelajari kembali berbagai tag.
Objek seperti build_provider atau result_reporter akan memunculkan
ConfigurationException jika dicoba dijalankan dari dalam konfigurasi
modul. Hal ini dimaksudkan untuk menghindari ekspektasi bahwa 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 untuk
diinstal dan akan menjalankan instrumentasi terhadap paket android.gesture.cts.
Tag penyertaan <include> dan <template-include>
Penggunaan <include> dan <template-include> dalam konfigurasi modul tidak disarankan. Fitur ini tidak dijamin berfungsi seperti yang diharapkan.
Kasus khusus untuk tag metrics_collector
metrics_collector diizinkan, tetapi terbatas pada
class FilePullerLogCollector
untuk menentukan file atau direktori tertentu yang akan ditarik dan dicatat untuk
modul. Hal 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 atau download build?
Definisi tag yang diizinkan dapat memberikan kesan yang salah bahwa modul tidak akan mendapatkan informasi build apa pun. Ini tidak benar.
Informasi build disediakan dari penyiapan tingkat suite dan akan dibagikan oleh semua modul suite. Hal ini memungkinkan penyiapan tingkat teratas tunggal untuk rangkaian agar dapat menjalankan semua modul yang merupakan bagian dari rangkaian.
Misalnya, alih-alih setiap modul
Compatibility Test Suite (CTS)
mengkueri informasi perangkat, jenis, dll. secara terpisah, penyiapan tingkat rangkaian CTS (cts.xml) melakukannya satu kali dan setiap modul akan menerima informasi tersebut jika memintanya.
Agar objek dalam modul menerima informasi build, objek tersebut harus
melakukan hal yang sama seperti dalam konfigurasi Tradefed biasa: mengimplementasikan
antarmuka IBuildReceiver untuk menerima IBuildInfo. Lihat
pengujian dengan perangkat
untuk mengetahui detail selengkapnya.
Kolom metadata
Sejumlah besar modul pengujian mencakup beberapa spesifikasi metadata, yang masing-masing memiliki sasaran 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. Hal ini tidak berdampak langsung pada eksekusi pengujian; hal ini
terutama digunakan untuk tujuan organisasi.
Daftar komponen yang diizinkan dan terbaru untuk CTS tersedia di CtsConfigLoadingTest. Pengujian ini gagal dalam pra-kirim jika komponen yang tidak ada ditambahkan ke modul CTS.
Anda dapat memfilter eksekusi rangkaian pengujian 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 dianotasi dengan komponen framework.
Parameter
Metadata parameter bersifat informatif dan memengaruhi eksekusi pengujian. Menentukan mode Android yang diterapkan pada modul pengujian.
Dalam hal ini, mode terbatas pada mode Android tingkat tinggi, seperti
instant apps, secondary users, atau different abis.
Selama rangkaian pengujian berjalan, jika mode berlaku untuk pengujian, beberapa variasi modul pengujian dibuat berdasarkan mode. Setiap variasi menjalankan pengujian serupa, tetapi dalam mode yang berbeda.
instant_app: Buat variasi pengujian yang menginstal APK sebagai aplikasi instan.multi_abi: Buat variasi pengujian untuk setiap ABI yang didukung oleh perangkat.secondary_user: Buat variasi pengujian yang menginstal APK dan menjalankan pengujian sebagai pengguna sekunder.
Pengumpulan dan pasca-pemrosesan metrik untuk modul pengujian performa
Untuk modul pengujian performa, metrics_collector dan
metric_post_processor tingkat modul diizinkan karena penting untuk pengujian performa.
Pengumpul metrik dan pasca-pemroses tingkat modul dapat bersifat khusus untuk modul.
Sebaiknya jangan tentukan post-processor di tingkat teratas dan
tingkat modul.
Konfigurasi modul pengujian performa harus menyertakan metadata test-type
dengan nilai performance, seperti:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Tanpa ini, jika konfigurasi pengujian menyertakan metric_collector selain
FilePullerLogCollector atau metric_post_processor, pengujian akan gagal
dalam pra-kirim.
Contoh konfigurasi modul uji performa:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>