AOSP menyertakan template pengujian untuk modul pengujian yang bukan merupakan subkelas Python sisi host dari BaseTest runner VTS.
Pengembang dapat menggunakan template ini untuk meminimalkan upaya yang terlibat dalam mengintegrasikan pengujian tersebut. Bagian ini mencakup konfigurasi dan penggunaan template pengujian (terletak di direktori testcases/template VTS) dan memberikan contoh untuk template yang umum digunakan.
Template BinaryTest
Gunakan template BinaryTest untuk mengintegrasikan tes yang dijalankan pada perangkat target di VTS. Tes sisi target meliputi:
- Tes berbasis C++ dikompilasi dan didorong ke perangkat
- Tes Python sisi target dikompilasi sebagai binari
- Skrip shell dapat dieksekusi di perangkat
Tes ini dapat diintegrasikan ke dalam VTS dengan atau tanpa template BinaryTest.
Mengintegrasikan pengujian sisi target dengan template BinaryTest
Template BinaryTest dirancang untuk membantu pengembang mengintegrasikan pengujian sisi target dengan mudah. 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
adalah template-spesifik. - Menentukan jalur host relatif sumber biner pengujian memungkinkan template menangani persiapan, mendorong file, eksekusi pengujian, penguraian hasil, dan pembersihan.
- Template berisi metode terkait pembuatan kasus uji untuk ditimpa oleh subkelas.
- Template mengasumsikan satu kasus uji per modul biner pengujian, dan nama file sumber biner digunakan sebagai nama kasus uji secara default.
Opsi konfigurasi
Template BinaryTest mendukung opsi konfigurasi berikut:
Nama opsi | Jenis nilai | Keterangan |
---|---|---|
biner-tes-sumber | string | Jalur sumber pengujian biner relatif terhadap direktori kasus uji vts di host. Contoh: DATA/nativetest/test |
direktori-tes-kerja-biner | string | Direktori kerja (jalur sisi perangkat). Contoh: /data/local/tmp/testing/ |
tes-biner-envp | string | Variabel lingkungan untuk biner. Contoh: PATH=/new:$PATH |
uji-biner-args | string | Uji argumen atau flag. Contoh: --gtest_filter=test1 |
binary-test-ld-library-path | string | Variabel lingkungan LD_LIBRARY_PATH .Contoh: /data/local/tmp/lib |
binary-test-disable-framework | boolean | Jalankan adb stop untuk mematikan Kerangka Android sebelum pengujian. Contoh: true |
binary-test-stop-native-server | boolean | Hentikan semua server asli yang dikonfigurasi dengan benar selama pengujian. Contoh: true |
tipe-tes biner | rangkaian | Jenis templat. Jenis template lain diperluas dari template ini, tetapi Anda tidak perlu menentukan opsi ini untuk template ini karena Anda telah menentukan binary-test-source . |
Untuk opsi dengan tipe nilai strings
, Anda dapat menambahkan beberapa nilai dengan mengulangi opsi dalam konfigurasi. Misalnya, setel binary-test-source
dua kali (seperti yang ditunjukkan pada contoh VtsDeviceTreeEarlyMountTest
).
tag uji
Anda dapat menambahkan tag pengujian dengan mengawalinya ke opsi dengan nilai strings
dan menggunakan ::
sebagai pembatas. Tag uji sangat berguna saat menyertakan sumber biner dengan nama yang sama tetapi dengan bitness atau direktori induk yang berbeda. Misalnya, untuk menghindari tabrakan file push atau nama hasil untuk sumber dengan nama yang sama tetapi dari direktori sumber yang berbeda, Anda dapat menentukan tag yang berbeda untuk sumber ini.
Seperti yang ditunjukkan dalam contoh VtsDeviceTreeEarlyMountTest
dengan dua sumber dt_early_mount_test
, tag pengujian adalah _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
hanya diterapkan ke binary-test-source
dengan tag yang sama dan dieksekusi di binary-test-working-directory
dengan tag yang sama. Opsi binary-test-working-directory
adalah opsional untuk pengujian biner, memungkinkan Anda menentukan satu direktori kerja untuk sebuah tag. Ketika opsi binary-test-working-directory
dibiarkan tidak ditentukan, direktori default digunakan untuk setiap tag.
Nama tag secara langsung ditambahkan ke nama kasus uji dalam laporan hasil. Misalnya, testcase1
dengan tag _32bit
muncul sebagai testcase1_32bit
dalam laporan hasil.
Mengintegrasikan pengujian sisi target tanpa template 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 terlebih dahulu mendorong file pengujian ke perangkat, menjalankan pengujian menggunakan perintah shell, lalu mengurai hasilnya menggunakan skrip Python sisi host.
Mendorong tes binari
Kami merekomendasikan mendorong file menggunakan persiapan 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.
Atau, Anda dapat mendorong file secara manual menggunakan skrip pengujian Python sisi host yang mengikuti prosedur serupa.
Menjalankan tes
Setelah mendorong file ke perangkat, jalankan pengujian menggunakan perintah shell dalam 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]))
Template GtestBinaryTest
Template GtestBinaryTest menghosting binari pengujian GTest, yang masing-masing biasanya berisi beberapa kasus pengujian. Templat ini memperluas templat BinaryTest dengan mengesampingkan penyiapan, pembuatan kasus uji, dan metode penguraian hasil, sehingga semua konfigurasi BinaryTest diwariskan.
GtestBinaryTest menambahkan opsi gtest-batch-mode
:
Nama opsi | Jenis nilai | Keterangan |
---|---|---|
tipe-tes biner | rangkaian | Jenis templat. Menggunakan nilai gtest . |
gtest-batch-mode | boolean | Jalankan binari Gtest dalam mode batch. Contoh: true |
Secara umum, menyetel gtest-batch-mode
ke true
meningkatkan kinerja sekaligus sedikit menurunkan keandalan. Dalam tes kepatuhan VTS, banyak modul menggunakan mode batch untuk meningkatkan kinerja. Namun untuk keandalan, jika mode tidak ditentukan, defaultnya adalah non-batch.
Modus non-batch
Mode non-batch membuat panggilan individual ke biner GTest untuk setiap kasus uji. Misalnya, jika biner GTest berisi 10 kasus uji (setelah memfilter menurut konfigurasi sisi host), biner dipanggil 10 kali pada shell perangkat setiap kali dengan filter uji yang berbeda. Untuk setiap kasus pengujian, XML keluaran hasil GTest unik dihasilkan dan diuraikan oleh template.
Keuntungan menggunakan mode non-batch meliputi:
- Isolasi kasus uji . Sebuah crash atau hang dalam satu test case tidak mempengaruhi test case lainnya.
- Granularitas . Lebih mudah mendapatkan pengukuran profil/cakupan per kasus pengujian, systrace, laporan bug, logcat, dll. Hasil pengujian dan log diambil segera setelah setiap kasus uji selesai.
Kerugian menggunakan mode non-batch meliputi:
- Pemuatan berlebihan . Setiap kali biner GTest dipanggil, ia memuat pustaka terkait dan melakukan pengaturan kelas awal.
- Overhead komunikasi . Setelah pengujian selesai, host dan perangkat target berkomunikasi untuk penguraian hasil dan perintah selanjutnya (pengoptimalan di masa mendatang dimungkinkan).
Modus batch
Dalam mode batch GTest, biner pengujian dipanggil hanya sekali dengan nilai filter pengujian panjang yang berisi semua kasus pengujian yang difilter oleh konfigurasi sisi host (ini menghindari masalah pemuatan yang 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 diuraikan melalui file xml keluaran GTest. Namun, karena xml keluaran dihasilkan setelah semua pengujian selesai, jika kasus uji crash, biner atau perangkat tidak ada file xml hasil yang dihasilkan.
Saat menggunakan keluaran terminal:
Saat GTest berjalan, ia mencetak log pengujian dan melanjutkan ke terminal dalam format yang dapat diuraikan 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 framework memulai ulang biner/perangkat setelah error dengan filter pengujian yang dikurangi (tidak termasuk kasus pengujian yang sudah selesai dan error).
- Granularitas . Memberikan perincian kasus uji yang sama dengan mode non-batch.
Kerugian menggunakan mode batch meliputi:
- Biaya pemeliharaan . Jika format logging GTest berubah, semua pengujian akan rusak.
- Kebingungan . Kasus uji dapat mencetak sesuatu yang mirip dengan format kemajuan GTest, yang dapat membingungkan formatnya.
Karena kelemahan ini, kami telah menghapus sementara opsi untuk menggunakan output baris perintah. Kami akan meninjau kembali opsi ini di masa mendatang untuk meningkatkan keandalan fungsi ini.
Template HostBinaryTest
Template HostBinaryTest menyertakan executable sisi host yang tidak ada di direktori lain atau dalam skrip Python. Tes ini meliputi:
- Biner pengujian yang dikompilasi dapat dieksekusi di host
- Skrip yang dapat dieksekusi di shell, Python, atau bahasa lain
Salah satu contohnya adalah uji sisi host kebijakan VTS Security SELinux :
<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 uji secara default.
Memperluas template yang ada
Anda dapat menggunakan template secara langsung dalam konfigurasi pengujian untuk menyertakan pengujian non-Python atau memperluasnya dalam subkelas untuk menangani persyaratan pengujian tertentu. Template dalam 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 uji yang berbeda.
- Parsing hasil dengan membaca output perintah atau menggunakan kondisi lain.
Untuk mempermudah perluasan template yang ada, template berisi metode khusus untuk setiap fungsi. Jika Anda telah meningkatkan desain untuk template yang ada, kami mendorong Anda untuk berkontribusi pada basis kode VTS.