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

Halaman ini diterjemahkan oleh Cloud Translation API.

Templat uji

AOSP menyertakan templat pengujian untuk modul pengujian yang bukan merupakan subkelas Python sisi host dari BaseTest pelari VTS.

Gambar 1. Uji arsitektur template.

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 dan binary-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.

Gambar 2. Mode non-batch.

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):

Gambar 3. Mode batch, output.xml.

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:

Gambar 4. Mode batch, 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:

Gambar 5. Memperluas template yang ada di repo VTS.

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.