Struktur keseluruhan konfigurasi modul mengikuti pola yang mirip dengan konfigurasi XML Tradefed biasa tetapi dengan beberapa batasan karena faktanya modul tersebut dijalankan sebagai bagian dari suite.
Daftar tag yang diizinkan
Konfigurasi modul AndroidTest.xml atau lebih luas hanya dapat berisi tag XML berikut: target_preparer , multi_target_preparer , test dan metrics_collector .
Meskipun daftar tersebut tampak terbatas, daftar tersebut memungkinkan Anda menentukan secara tepat kebutuhan pengaturan modul pengujian dan pengujian yang akan dijalankan.
CATATAN: Lihat Konfigurasi XML Tradefed 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. Hal ini dimaksudkan untuk menghindari ekspektasi 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 instalasi CtsGestureTestCases.apk 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. Mereka tidak dijamin akan bekerja sesuai harapan.
Kasus khusus untuk tag metrics_collector
metrics_collector diperbolehkan namun 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 pembangunan apa pun. Ini tidak benar .
Informasi pembangunan disediakan dari pengaturan tingkat suite dan akan dibagikan oleh semua modul suite. Hal ini memungkinkan satu pengaturan tingkat atas untuk suite tersebut untuk menjalankan semua modul bagian dari suite tersebut.
Misalnya, alih-alih setiap modul Compatibility Test Suite (CTS) menanyakan informasi perangkat, jenis, dll. secara individual, penyiapan tingkat suite CTS ( cts.xml ) melakukannya satu kali dan setiap modul akan menerima informasi tersebut jika mereka memintanya.
Agar objek dalam modul dapat 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. Ini tidak berdampak langsung pada pelaksanaan pengujian; ini terutama digunakan untuk tujuan organisasi.
Daftar terkini komponen yang diizinkan untuk CTS tersedia di CtsConfigLoadingTest . Pengujian ini gagal dalam pengiriman awal 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 dianotasi dengan komponen framework .
Parameter
Metadata parameter bersifat informatif dan memengaruhi pelaksanaan pengujian. Ini menentukan mode Android mana yang digunakan modul pengujian. Dalam hal ini, mode dibatasi pada mode Android tingkat tinggi, seperti instant apps , secondary users , atau different abis .
Selama rangkaian dijalankan, jika mode diterapkan pada pengujian, beberapa variasi modul pengujian dibuat berdasarkan mode tersebut. Setiap variasi menjalankan pengujian serupa tetapi dalam mode berbeda.
-
instant_app: Membuat variasi pengujian yang menginstal APK sebagai aplikasi instan. -
multi_abi: Membuat variasi pengujian untuk setiap ABI yang didukung oleh perangkat. -
secondary_user: Membuat variasi pengujian yang menginstal APK dan menjalankan pengujian sebagai pengguna sekunder.
Pengumpulan metrik dan pasca-pemrosesan untuk modul uji kinerja
Untuk modul pengujian kinerja, metrics_collector dan metric_post_processor tingkat modul diperbolehkan karena keduanya penting untuk pengujian kinerja. Pengumpul metrik tingkat modul dan pasca-pemroses dapat spesifik untuk modul. Tidak disarankan untuk menentukan pasca-prosesor di tingkat atas dan tingkat modul.
Konfigurasi modul pengujian kinerja harus menyertakan metadata test-type dengan nilai performance , seperti: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Tanpa ini, jika pengujian config mencakup metric_collector selain FilePullerLogCollector atau metric_post_processor apa pun, pengujian gagal dalam pengiriman awal.
Contoh konfigurasi modul uji kinerja:
<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>