Template Tes

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

Gambar 1. Uji arsitektur template.

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

  1. Memeriksa konektivitas perangkat.
  2. Menentukan jalur file sumber absolut.
  3. Mendorong file menggunakan perintah adb push .
  4. 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.

Gambar 2. Modus non-batch.

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

Gambar 3. Modus batch, output.xml.

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:

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

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