Template pengujian

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

Gambar 1. Menguji arsitektur template.

Developer dapat menggunakan template ini untuk meminimalkan upaya yang diperlukan dalam mengintegrasikan pengujian tersebut. Bagian ini membahas cara mengonfigurasi dan menggunakan template pengujian (terletak di direktori testcases/template VTS) dan memberikan contoh untuk template yang umum digunakan.

Template BinaryTest

Gunakan template BinaryTest untuk mengintegrasikan pengujian yang dijalankan di perangkat target di VTS. Pengujian sisi target mencakup:

  • Pengujian berbasis C++ yang dikompilasi dan di-push ke perangkat
  • Pengujian Python sisi target yang dikompilasi sebagai biner
  • Skrip shell yang dapat dieksekusi di perangkat

Pengujian ini dapat diintegrasikan ke dalam VTS dengan atau tanpa template BinaryTest.

Mengintegrasikan pengujian sisi target dengan template BinaryTest

Template BinaryTest dirancang untuk membantu developer mengintegrasikan pengujian sisi target dengan mudah. Dalam sebagian besar 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 template.
  • Menentukan jalur host relatif sumber biner pengujian memungkinkan template menangani persiapan, pengiriman file, eksekusi pengujian, penguraian hasil, dan pembersihan.
  • Template ini berisi metode terkait pembuatan kasus pengujian untuk subclass yang akan diganti.
  • Template mengasumsikan satu kasus pengujian per modul biner pengujian, dan nama file sumber biner digunakan sebagai nama kasus pengujian secara default.

Opsi konfigurasi

Template BinaryTest mendukung opsi konfigurasi berikut:

Nama opsi Jenis nilai Deskripsi
binary-test-source string Jalur sumber pengujian biner yang relatif terhadap direktori kasus pengujian vts di host.
Contoh: DATA/nativetest/test
binary-test-working-directory string Direktori kerja (jalur sisi perangkat).
Contoh: /data/local/tmp/testing/
binary-test-envp string Variabel lingkungan untuk biner.
Contoh: PATH=/new:$PATH
binary-test-args string Menguji argumen atau tanda.
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 menonaktifkan Framework Android sebelum pengujian. Contoh: true
binary-test-stop-native-servers boolean Hentikan semua server native yang dikonfigurasi dengan benar selama pengujian. Contoh: true
binary-test-type string Jenis template. Jenis template lainnya diperluas dari template ini, tetapi Anda tidak perlu menentukan opsi ini untuk template ini karena Anda sudah menentukan binary-test-source.

Untuk opsi dengan jenis nilai strings, Anda dapat menambahkan beberapa nilai dengan mengulangi opsi dalam konfigurasi. Misalnya, tetapkan binary-test-source dua kali (seperti yang ditunjukkan dalam contoh VtsDeviceTreeEarlyMountTest).

Menguji tag

Anda dapat menambahkan tag pengujian dengan menambahkan awalan ke opsi dengan nilai strings dan menggunakan :: sebagai pemisah. Tag pengujian sangat berguna saat menyertakan sumber biner dengan nama yang sama, tetapi dengan bitness atau direktori induk yang berbeda. Misalnya, untuk menghindari konflik nama hasil atau push file 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 awalan _32bit:: dan _64bit:: di binary-test-source. Tag yang diakhiri dengan 32bit atau 64bit akan otomatis menandai pengujian sebagai tersedia untuk satu bit ABI; yaitu pengujian dengan tag _32bit tidak dijalankan di ABI 64-bit. Tidak menentukan tag sama dengan menggunakan tag dengan string kosong.

Opsi dengan tag yang sama dikelompokkan dan diisolasi dari tag lainnya. Misalnya, binary-test-args dengan tag _32bit hanya diterapkan ke binary-test-source dengan tag yang sama dan dijalankan di binary-test-working-directory dengan tag yang sama. Opsi binary-test-working-directory bersifat opsional untuk pengujian biner, sehingga Anda dapat menentukan satu direktori kerja untuk tag. Jika opsi binary-test-working-directory tidak ditentukan, direktori default akan digunakan untuk setiap tag.

Nama tag langsung ditambahkan ke nama kasus pengujian dalam laporan hasil. Misalnya, kasus pengujian testcase1 dengan tag _32bit akan 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 hasil menggunakan skrip Python sisi host.

Mengirim biner pengujian

Sebaiknya kirim file menggunakan penyiapan 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 pengujian selesai.

Atau, Anda dapat mendorong file secara manual menggunakan skrip pengujian Python sisi host yang mengikuti prosedur serupa.

Menjalankan pengujian

Setelah mengirim 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 biner pengujian GTest, yang masing-masing biasanya berisi beberapa kasus pengujian. Template ini memperluas template BinaryTest dengan mengganti metode penyiapan, pembuatan kasus pengujian, dan penguraian hasil, sehingga semua konfigurasi BinaryTest diwarisi.

GtestBinaryTest menambahkan opsi gtest-batch-mode:

Nama opsi Jenis nilai Deskripsi
binary-test-type string Jenis template. Menggunakan nilai gtest.
gtest-batch-mode boolean Menjalankan biner Gtest dalam mode batch. Contoh: true

Secara umum, menetapkan gtest-batch-mode ke true akan meningkatkan performa sekaligus sedikit mengurangi keandalan. Dalam pengujian kepatuhan VTS, banyak modul menggunakan mode batch untuk meningkatkan performa. Namun, untuk keandalan, jika mode tidak ditentukan, mode akan ditetapkan secara default ke non-batch.

Mode non-batch

Mode non-batch membuat panggilan terpisah ke biner GTest untuk setiap kasus pengujian. Misalnya, jika biner GTest berisi 10 kasus pengujian (setelah pemfilteran menurut konfigurasi sisi host), biner akan dipanggil 10 kali di shell perangkat setiap kali dengan filter pengujian yang berbeda. Untuk setiap kasus pengujian, XML output hasil GTest yang unik dibuat dan diuraikan oleh template.

Gambar 2. Mode non-batch.

Keuntungan menggunakan mode non-batch meliputi:

  • Isolasi kasus pengujian. Error atau hang dalam satu kasus pengujian tidak memengaruhi kasus pengujian lainnya.
  • Perincian. Lebih mudah mendapatkan pengukuran cakupan/profiling per kasus pengujian, systrace, bugreport, logcat, dll. Hasil dan log pengujian diambil segera setelah setiap kasus pengujian selesai.

Kekurangan menggunakan mode non-batch meliputi:

  • Pemuatan redundan. Setiap kali biner GTest dipanggil, biner tersebut akan memuat library terkait dan melakukan penyiapan class awal.
  • Overhead komunikasi. Setelah pengujian selesai, host dan perangkat target berkomunikasi untuk penguraian hasil dan perintah berikutnya (pengoptimalan mendatang mungkin).

Mode batch

Dalam mode batch GTest, biner pengujian hanya dipanggil sekali dengan nilai filter pengujian yang panjang yang berisi semua kasus pengujian yang difilter oleh konfigurasi sisi host (hal ini menghindari masalah pemuatan yang berlebihan dalam mode non-batch). Anda dapat mengurai hasil pengujian 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 diuraikan melalui file xml output GTest. Namun, karena XML output dihasilkan setelah semua pengujian selesai, jika kasus pengujian membuat biner atau perangkat error, tidak ada file XML hasil yang dihasilkan.

Saat menggunakan output terminal:

Gambar 4. Mode batch, output terminal.

Saat berjalan, GTest akan mencetak log pengujian dan progres ke terminal dalam format yang dapat diuraikan oleh framework untuk status, hasil, dan log pengujian.

Keuntungan menggunakan mode batch meliputi:

  • Isolasi kasus pengujian. Memberikan tingkat isolasi kasus pengujian yang sama dengan mode non-batch jika framework memulai ulang biner/perangkat setelah error dengan filter pengujian yang dikurangi (tidak termasuk kasus pengujian yang selesai dan error).
  • Perincian. Memberikan perincian kasus pengujian yang sama dengan mode non-batch.

Kekurangan menggunakan mode batch meliputi:

  • Biaya pemeliharaan. Jika format logging GTest berubah, semua pengujian akan rusak.
  • Kebingungan. Kasus pengujian dapat mencetak sesuatu yang mirip dengan format progres GTest, yang dapat membingungkan format.

Karena kelemahan ini, kami telah menghapus opsi untuk menggunakan output command line untuk sementara. Kami akan meninjau kembali opsi ini di masa mendatang untuk meningkatkan keandalan fungsi ini.

Template HostBinaryTest

Template HostBinaryTest menyertakan file yang dapat dieksekusi sisi host yang tidak ada di direktori lain atau dalam skrip Python. Pengujian ini mencakup:

  • Biner pengujian yang dikompilasi dan dapat dieksekusi di host
  • Skrip yang dapat dieksekusi dalam shell, Python, atau bahasa lain

Salah satu contohnya adalah pengujian 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 yang serupa. Pada contoh di atas, opsi binary-test-source menentukan jalur relatif sisi host ke file yang dapat dieksekusi pengujian, dan binary-test-type adalah host_binary_test. Serupa dengan template BinaryTest, nama file biner digunakan sebagai nama kasus pengujian secara default.

Memperluas template yang ada

Anda dapat menggunakan template langsung di konfigurasi pengujian untuk menyertakan pengujian non-Python atau memperluasnya di subclass untuk menangani persyaratan pengujian tertentu. Template di repo VTS memiliki ekstensi berikut:

Gambar 5. Memperluas template yang ada di repo VTS.

Developer dianjurkan untuk memperluas template yang ada untuk persyaratan pengujian tertentu. Alasan umum untuk memperluas template meliputi:

  • Prosedur penyiapan pengujian khusus, seperti menyiapkan perangkat dengan perintah khusus.
  • Membuat kasus pengujian dan nama pengujian yang berbeda.
  • Mengurai hasil dengan membaca output perintah atau menggunakan kondisi lain.

Untuk memudahkan perluasan template yang ada, template berisi metode yang dikhususkan untuk setiap fungsi. Jika Anda telah meningkatkan desain untuk template yang ada, sebaiknya kontribusikan ke code base VTS.