AOSP menyertakan templat pengujian untuk modul pengujian yang bukan merupakan subkelas Python sisi host dari BaseTest pelari VTS.
Pengembang dapat menggunakan templat ini untuk meminimalkan upaya yang diperlukan dalam mengintegrasikan pengujian tersebut. Bagian ini mencakup konfigurasi dan penggunaan template pengujian (terletak di direktori testcases/template VTS) dan memberikan contoh template yang umum digunakan.
Templat Tes Biner
Gunakan templat BinaryTest untuk mengintegrasikan pengujian yang dijalankan pada perangkat target di VTS. Tes sisi target meliputi:
- Tes berbasis C++ dikompilasi dan dikirim ke perangkat
- Tes Python sisi target dikompilasi sebagai biner
- Skrip shell dapat dieksekusi di perangkat
Tes ini dapat diintegrasikan ke dalam VTS dengan atau tanpa template BinaryTest.
Integrasikan pengujian sisi target dengan template BinaryTest
Templat BinaryTest dirancang untuk membantu pengembang dengan mudah mengintegrasikan pengujian sisi target. Dalam kebanyakan kasus, Anda dapat menambahkan beberapa baris konfigurasi sederhana di AndroidTest.xml
. Contoh konfigurasi dari VtsDeviceTreeEarlyMountTest :
<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest."> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/> <option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" /> <option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" /> <option name="test-timeout" value="5m"/> </test> </configuration>
Dalam konfigurasi ini:
-
binary-test-source
danbinary-test-type
bersifat khusus templat. - Menentukan jalur host relatif sumber biner pengujian memungkinkan templat menangani persiapan, pengiriman file, eksekusi pengujian, penguraian hasil, dan pembersihan.
- Templat berisi metode terkait pembuatan kasus uji untuk ditimpa oleh subkelas.
- Templat ini mengasumsikan satu kasus uji per modul biner pengujian, dan nama file sumber biner digunakan sebagai nama kasus uji secara default.
Opsi konfigurasi
Templat BinaryTest mendukung opsi konfigurasi berikut:
Nama opsi | Tipe nilai | Keterangan |
---|---|---|
sumber uji biner | string | Jalur sumber pengujian biner relatif terhadap direktori kasus uji vts di host. Contoh: DATA/nativetest/test |
direktori kerja-uji-biner | string | Direktori kerja (jalur sisi perangkat). Contoh: /data/local/tmp/testing/ |
biner-uji-envp | string | Variabel lingkungan untuk biner. Contoh: PATH=/new:$PATH |
argumen-uji-biner | string | Uji argumen atau tanda. Contoh: --gtest_filter=test1 |
jalur-perpustakaan-uji-biner | string | Variabel lingkungan LD_LIBRARY_PATH .Contoh: /data/local/tmp/lib |
kerangka-uji-disable-biner | boolean | Jalankan adb stop untuk mematikan Kerangka Android sebelum pengujian. Contoh: true |
server asli-uji-berhenti-biner | boolean | Hentikan semua server asli yang dikonfigurasi dengan benar selama pengujian. Contoh: true |
tipe uji biner | rangkaian | Jenis templat. Tipe templat lainnya diperluas dari templat ini, namun Anda tidak perlu menentukan opsi ini untuk templat ini karena Anda sudah menentukan binary-test-source . |
Untuk opsi dengan tipe nilai strings
, Anda dapat menambahkan beberapa nilai dengan mengulangi opsi dalam konfigurasi. Misalnya, atur binary-test-source
dua kali (seperti yang ditunjukkan dalam contoh VtsDeviceTreeEarlyMountTest
).
Tag uji
Anda dapat menambahkan tag pengujian dengan mengawali tag tersebut ke opsi dengan nilai strings
dan menggunakan ::
sebagai pembatas. Tag pengujian sangat berguna ketika menyertakan sumber biner dengan nama yang sama tetapi dengan bitness atau direktori induk berbeda. Misalnya, untuk menghindari tabrakan file atau nama hasil untuk sumber dengan nama yang sama tetapi dari direktori sumber berbeda, Anda dapat menentukan tag berbeda untuk sumber tersebut.
Seperti yang ditunjukkan dalam contoh VtsDeviceTreeEarlyMountTest
dengan dua sumber dt_early_mount_test
, tag pengujiannya adalah awalan _32bit::
dan _64bit::
pada binary-test-source
. Tag yang diakhiri dengan 32bit
atau 64bit
secara otomatis menandai pengujian sebagai tersedia untuk satu bit ABI; yaitu pengujian dengan tag _32bit
tidak dijalankan pada ABI 64-bit. Tidak menentukan tag sama dengan menggunakan tag dengan string kosong.
Opsi dengan tag yang sama dikelompokkan dan diisolasi dari tag lain. Misalnya, binary-test-args
dengan tag _32bit
diterapkan hanya pada binary-test-source
dengan tag yang sama dan dieksekusi di binary-test-working-directory
dengan tag yang sama. Opsi binary-test-working-directory
bersifat opsional untuk pengujian biner, memungkinkan Anda menentukan satu direktori kerja untuk sebuah tag. Ketika opsi binary-test-working-directory
tidak ditentukan, direktori default digunakan untuk setiap tag.
Nama tag langsung ditambahkan ke nama kasus pengujian di laporan hasil. Misalnya, kasus uji testcase1
dengan tag _32bit
muncul sebagai testcase1_32bit
di laporan hasil.
Integrasikan pengujian sisi target tanpa templat BinaryTest
Di VTS, format pengujian default adalah pengujian Python sisi host yang diperluas dari BaseTest di runner VTS. Untuk mengintegrasikan pengujian sisi target, Anda harus memasukkan file pengujian ke perangkat terlebih dahulu, menjalankan pengujian menggunakan perintah shell, lalu mengurai hasilnya menggunakan skrip Python sisi host.
Biner uji dorong
Kami merekomendasikan mendorong file menggunakan pembuat target VtsFilePusher
. Contoh:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push" value="DATA/test->/data/local/tmp/test"/> </target_preparer>
VtsFilePusher
melakukan hal berikut:
- Memeriksa konektivitas perangkat.
- Menentukan jalur file sumber absolut.
- Mendorong file menggunakan perintah
adb push
. - Menghapus file setelah tes selesai.
Alternatifnya, Anda dapat memasukkan file secara manual menggunakan skrip pengujian Python sisi host yang mengikuti prosedur serupa.
Jalankan tes
Setelah memasukkan file ke perangkat, jalankan pengujian menggunakan perintah shell di skrip pengujian Python sisi host. Contoh:
device = self.android_devices[0] res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"]) asserts.AssertFalse(any(res[return_codes]))
Templat GtestBinaryTest
Templat GtestBinaryTest menghosting biner pengujian GTest, yang masing-masing biasanya berisi beberapa kasus pengujian. Templat ini memperluas templat BinaryTest dengan mengesampingkan metode penyiapan, pembuatan kasus pengujian, dan penguraian hasil, sehingga semua konfigurasi BinaryTest diwariskan.
GtestBinaryTest menambahkan opsi gtest-batch-mode
:
Nama opsi | Tipe nilai | Keterangan |
---|---|---|
tipe uji biner | rangkaian | Jenis templat. Menggunakan nilai gtest . |
mode batch gtest | boolean | Jalankan biner Gtest dalam mode batch. Contoh: true |
Secara umum, menyetel gtest-batch-mode
ke true
akan meningkatkan performa sekaligus sedikit menurunkan keandalan. Dalam pengujian kepatuhan VTS, banyak modul menggunakan mode batch untuk meningkatkan kinerja. Namun untuk keandalan, jika modenya tidak ditentukan maka defaultnya adalah non-batch.
Mode non-batch
Mode non-batch melakukan panggilan individual ke biner GTest untuk setiap kasus pengujian. Misalnya, jika biner GTest berisi 10 kasus pengujian (setelah difilter berdasarkan konfigurasi sisi host), biner tersebut dipanggil 10 kali pada shell perangkat setiap kali dengan filter pengujian yang berbeda. Untuk setiap kasus pengujian, XML keluaran hasil GTest unik dihasilkan dan diuraikan oleh template.
Keuntungan menggunakan mode non-batch antara lain:
- Isolasi kasus uji . Crash atau hang pada satu test case tidak mempengaruhi test case lainnya.
- granularitas . Lebih mudah untuk mendapatkan pembuatan profil/pengukuran cakupan per kasus pengujian, systrace, laporan bug, logcat, dll. Hasil pengujian dan log diambil segera setelah setiap kasus pengujian selesai.
Kerugian menggunakan mode non-batch meliputi:
- Pemuatan berlebihan . Setiap kali biner GTest dipanggil, ia memuat perpustakaan terkait dan melakukan pengaturan kelas awal.
- Komunikasi di atas kepala . Setelah pengujian selesai, host dan perangkat target berkomunikasi untuk penguraian hasil dan perintah selanjutnya (pengoptimalan di masa mendatang dimungkinkan).
Modus kumpulan
Dalam mode batch GTest, biner pengujian dipanggil hanya sekali dengan nilai filter pengujian panjang yang berisi semua kasus pengujian yang difilter berdasarkan konfigurasi sisi host (ini menghindari masalah pemuatan berlebihan dalam mode non-batch). Anda dapat mengurai hasil tes untuk GTest menggunakan output.xml atau menggunakan output terminal.
Saat menggunakan output.xml (default):
Seperti dalam mode non-batch, hasil pengujian diurai melalui file xml keluaran GTest. Namun, karena keluaran xml dihasilkan setelah semua pengujian selesai, jika kasus pengujian mengalami kerusakan pada biner atau perangkat, tidak ada file xml hasil yang dihasilkan.
Saat menggunakan keluaran terminal:
Saat GTest berjalan, GTest mencetak log pengujian dan kemajuannya ke terminal dalam format yang dapat diurai oleh kerangka kerja untuk status pengujian, hasil, dan log.
Keuntungan menggunakan mode batch meliputi:
- Isolasi kasus uji . Memberikan tingkat isolasi kasus uji yang sama dengan mode non-batch jika kerangka kerja memulai ulang biner/perangkat setelah error dengan filter pengujian yang dikurangi (tidak termasuk kasus uji yang sudah selesai dan error).
- granularitas . Memberikan perincian kasus uji yang sama seperti mode non-batch.
Kerugian menggunakan mode batch meliputi:
- Biaya perawatan . Jika format logging GTest berubah, semua pengujian akan gagal.
- Kebingungan . Kasus uji dapat mencetak sesuatu yang mirip dengan format kemajuan GTest, yang dapat membingungkan formatnya.
Karena kelemahan ini, kami untuk sementara menghapus opsi untuk menggunakan keluaran baris perintah. Kami akan meninjau kembali opsi ini di masa mendatang untuk meningkatkan keandalan fungsi ini.
Templat HostBinaryTest
Templat HostBinaryTest menyertakan executable sisi host yang tidak ada di direktori lain atau dalam skrip Python. Tes-tes ini meliputi:
- Biner pengujian yang dikompilasi dapat dieksekusi di host
- Skrip yang dapat dieksekusi dalam shell, Python, atau bahasa lain
Salah satu contohnya adalah pengujian sisi host kebijakan SELinux Keamanan VTS :
<configuration description="Config for VTS Security SELinux policy host-side test cases"> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/> <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" /> <option name="binary-test-type" value="host_binary_test"/> </test> </configuration>
HostBinaryTest tidak memperluas template BinaryTest tetapi menggunakan konfigurasi pengujian serupa. Dalam contoh di atas, opsi binary-test-source
menentukan jalur relatif sisi host ke pengujian yang dapat dieksekusi, dan binary-test-type
adalah host_binary_test
. Mirip dengan template BinaryTest, nama file biner digunakan sebagai nama kasus pengujian secara default.
Perluas template yang ada
Anda dapat menggunakan templat secara langsung di konfigurasi pengujian untuk menyertakan pengujian non-Python atau memperluasnya dalam subkelas untuk menangani persyaratan pengujian tertentu. Templat di repo VTS memiliki ekstensi berikut:
Pengembang didorong untuk memperluas template yang ada untuk persyaratan pengujian tertentu. Alasan umum untuk memperluas template meliputi:
- Prosedur pengaturan pengujian khusus, seperti menyiapkan perangkat dengan perintah khusus.
- Menghasilkan kasus uji dan nama pengujian yang berbeda.
- Mengurai hasil dengan membaca keluaran perintah atau menggunakan kondisi lain.
Untuk mempermudah perluasan templat yang ada, templat berisi metode khusus untuk setiap fungsi. Jika Anda telah menyempurnakan desain untuk templat yang sudah ada, kami mendorong Anda untuk berkontribusi pada basis kode VTS.