Infrastruktur Pengujian Otomatis

Android 9 menyertakan infrastruktur Vendor Test Suite (VTS) untuk pengujian otomatis VTS, CTS, atau pengujian lainnya pada perangkat mitra yang menjalankan citra sistem generik (GSI) AOSP. Sebelumnya, menjalankan tes ini adalah operasi yang sangat manual; infrastruktur pengujian VTS baru dirancang untuk mendukung pengujian otomatis beberapa kali sehari pada beberapa perangkat.

Arsitektur

Infrastruktur pengujian otomatis VTS menggunakan arsitektur berikut:

Saat pengujian dipicu, infrastruktur pengujian otomatis VTS melakukan tugas-tugas berikut:

1. Mengambil artefak build dan menguji sumber daya dari lokasi berbeda:
   • Mitra Android Build (PAB) . Untuk GSI, VTS framework, dan beberapa build lainnya.
   • Sistem file lokal, Google Cloud Storage, atau sistem build khusus vendor lainnya . Untuk partner yang tidak menyimpan build di cloud Google.
2. Flash membuat artefak (dari perangkat) dan GSI (dari AOSP) ke perangkat yang terhubung.
3. Menjalankan tes VTS menggunakan TradeFed lokal atau TradeFed di cloud.
4. Melaporkan hasil tes ke dasbor VTS

Prosesnya dikoordinasikan oleh VTS host controller (HC), sebuah mesin di lab yang mengarahkan perilaku semua perangkat terhubung yang sedang diuji. HC bertanggung jawab untuk mengambil build terbaru, mem-flash-nya ke perangkat, dan menjalankan tes (baik secara lokal atau melalui komandan). Ini juga berkomunikasi dengan penjadwal cloud dan mengarahkan lalu lintas antara penjadwal dan instans TradeFed (atau harness lainnya) yang berjalan di HC. Untuk detail tentang pengontrol host, lihat Arsitektur Pengontrol Host .

Penyedia sumber daya

Pengujian otomatis memerlukan sumber daya seperti pembuatan sistem, file pengujian, dan artefak VTS. Meskipun dimungkinkan untuk membangun ini dari sumber, lebih mudah untuk membangunnya dari tip-of-tree secara teratur kemudian memposting artefak untuk diunduh.

Mitra dapat mengakses sumber daya otomatisasi menggunakan lokasi berikut:

• Mitra Android Build . Akses terprogram diberikan per akun.
• Sistem file lokal (atau serupa). Bagi mitra yang tidak menggunakan Mitra Android Build.

Untuk digunakan dalam mem-flash perangkat nanti, sumber daya menyertakan penyedia build untuk kedua opsi, yang diperluas dari satu build_provider.py yang menyimpan build di direktori sementara lokal.

Mitra Android Build

Di Android 8.1 dan rilis yang lebih rendah, mitra Android diminta untuk mengunjungi situs web Mitra Android Build ( https://partner.android.com/build ), menavigasi ke akun mereka, dan mengambil gambar sistem terbaru melalui antarmuka pengguna. Untuk membantu mitra menghindari proses yang lambat dan padat karya ini, Android 9 menyertakan dukungan untuk mengunduh sumber daya ini secara otomatis dari PAB saat kredensial yang sesuai diberikan.

Membangun akses

Akses terprogram menggunakan OAuth2 di Google API untuk mengakses RPC yang diperlukan. Menggunakan pendekatan standar untuk menghasilkan kredensial OAuth2, mitra harus menyiapkan pasangan id/rahasia klien dengan Google. Saat PartnerAndroidBuildClient diarahkan ke rahasia itu untuk pertama kalinya, ini akan membuka jendela browser bagi pengguna untuk masuk ke akun Google mereka, yang menghasilkan kredensial OAuth2 yang diperlukan untuk melanjutkan. Kredensial (token akses dan token penyegaran) disimpan secara lokal, artinya mitra hanya perlu masuk sekali.

POST permintaan untuk URL

Mengklik tautan sumber daya di PAB mengirimkan permintaan POST yang menyertakan data yang diperlukan untuk sumber daya itu, termasuk:

• membangun id, membangun target
• nama Sumberdaya
• cabang
• rilis nama kandidat dan apakah kandidat tersebut adalah build internal atau bukan

Permintaan POST diterima oleh metode downloadBuildArtifact dari buildsvc RPC, yang mengembalikan URL yang dapat digunakan untuk mengakses sumber daya.

• Untuk sumber daya APK Clockwork Companion, URL adalah URL yang dapat dibaca yang dihosting di PAB (yang dilindungi auth dan dapat diakses dengan kredensial OAuth2 yang sesuai).
• Untuk sumber daya lainnya, URL-nya panjang, URL yang tidak dilindungi dari Android Build API internal (yang kedaluwarsa setelah lima menit).

Mendapatkan URL

Untuk menghindari pemalsuan permintaan lintas situs, RPC buildsvc memerlukan token XSRF untuk diPOSTING dengan parameter lainnya. Sementara token ini membuat proses lebih aman, itu juga membuat akses program menjadi lebih sulit karena token (yang hanya tersedia di JavaScript halaman PAB) sekarang juga diperlukan untuk akses.

Untuk menghindari masalah ini, Android 9 mendesain ulang skema penamaan URL untuk semua file (bukan hanya APK) untuk menggunakan nama URL yang dapat diprediksi untuk mengakses daftar artefak dan URL artefak. PAB sekarang menggunakan format URL yang nyaman yang memungkinkan mitra untuk mengunduh sumber daya; Skrip HC dapat mengunduh APK tersebut dengan mudah, karena format URL diketahui, dan HC dapat mengabaikan masalah XSRF/cookie karena tidak memerlukan RPC buildsvc .

Sistem file lokal

Diberikan direktori dengan daftar (atau file zip) artefak, penyedia build menyetel gambar yang relevan berdasarkan apa yang ada di direktori. Anda dapat menggunakan alat gsutil untuk menyalin file dari Google Cloud Storage ke direktori lokal.

Bangunan berkedip

Setelah gambar perangkat terbaru diunduh ke host, gambar tersebut harus di-flash ke perangkat. Ini dilakukan dengan menggunakan perintah adb dan fastboot standar dan subproses Python, berdasarkan jalur file sementara yang disimpan oleh penyedia build.

Tindakan yang didukung:

• Hanya mem-flash GSI
• Mem-flash masing-masing gambar dari sistem utama (misalnya, fastboot flash boot boot.img )
• Mem-flash semua gambar dari sistem utama. Contoh:
  • fastboot flashall (menggunakan utilitas flashall )
  • fastboot flash (satu per satu)

Menjalankan tes

Di Android 9, infrastruktur pengujian otomatis VTS hanya mendukung rangkaian uji TradeFed tetapi dapat diperluas untuk mendukung rangkaian lainnya di masa mendatang.

Setelah perangkat disiapkan, Anda dapat menjalankan pengujian menggunakan salah satu opsi berikut:

• Saat menggunakan TradeFed secara lokal, gunakan perintah test di pengontrol host, yang mengambil nama rencana pengujian VTS (mis vts-selftest ) dan menjalankan pengujian.
• Saat menggunakan TradeFed Cluster (secara opsional terhubung ke MTT), gunakan perintah lease di konsol pengontrol host, yang mencari uji coba yang tidak terpenuhi.

Jika menggunakan TradeFedCluster, TradeFed berjalan secara lokal sebagai manajer jarak jauh . Jika tidak, tes dipanggil menggunakan subproses Python.

Melaporkan hasil

Hasil pengujian secara otomatis dilaporkan ke beberapa proyek dasbor VTS oleh VtsMultiDeviceTest .