Infrastruktur pengujian otomatis

Android 9 menyertakan infrastruktur Vendor Test Suite (VTS) untuk pengujian otomatis VTS, CTS, atau pengujian lainnya pada perangkat mitra yang menjalankan image sistem generik (GSI) AOSP. Sebelumnya, menjalankan pengujian ini merupakan 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:

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

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

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

Penyedia sumber daya

Pengujian otomatis memerlukan sumber daya seperti build sistem, file pengujian, dan artefak VTS. Meskipun dimungkinkan untuk membuatnya dari sumber, lebih mudah untuk membuatnya dari ujung pohon secara teratur kemudian memposting artefaknya 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 partner yang tidak menggunakan Partner Android Build.

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

Mitra Android Build

Pada Android 8.1 dan rilis yang lebih rendah, partner Android diharuskan mengunjungi situs web Partner Android Build ( https://partner.android.com/build ), membuka akun mereka, dan mengambil image sistem terbaru melalui antarmuka pengguna. Untuk membantu partner menghindari proses yang lambat dan memakan banyak tenaga ini, Android 9 menyertakan dukungan untuk mendownload resource ini secara otomatis dari PAB ketika kredensial yang sesuai diberikan.

Membangun akses

Akses terprogram menggunakan OAuth2 di Google API untuk mengakses RPC yang diperlukan. Dengan menggunakan pendekatan standar untuk menghasilkan kredensial OAuth2, mitra harus menyiapkan pasangan id klien/rahasia dengan Google. Saat PartnerAndroidBuildClient diarahkan ke rahasia tersebut untuk pertama kalinya, jendela browser akan terbuka 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 login satu kali.

Permintaan POST untuk URL

Mengklik tautan sumber daya di PAB akan mengirimkan permintaan POST yang mencakup data yang diperlukan untuk sumber daya tersebut, termasuk:

• membangun id, membangun target
• nama Sumberdaya
• cabang
• merilis nama kandidat dan apakah kandidat tersebut merupakan build internal atau tidak

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

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

Dapatkan URL-nya

Untuk menghindari pemalsuan permintaan lintas situs, RPC buildsvc memerlukan token XSRF untuk di-POST dengan parameter lainnya. Meskipun token ini membuat prosesnya lebih aman, token ini juga mempersulit akses terprogram karena token (yang hanya tersedia dalam JavaScript pada halaman PAB) kini 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 mudah digunakan yang memungkinkan mitra mengunduh sumber daya; Skrip HC dapat mengunduh APK tersebut dengan mudah, karena format URL diketahui, dan HC dapat melewati masalah XSRF/cookie karena tidak memerlukan RPC buildsvc .

Sistem file lokal

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

Flash dibangun

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

Tindakan yang didukung:

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

Jalankan tes

Di Android 9, infrastruktur pengujian otomatis VTS hanya mendukung test harness TradeFed namun dapat diperluas untuk mendukung harness 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 (misalnya vts-selftest ) dan menjalankan pengujian.
• Saat menggunakan Cluster TradeFed (opsional terhubung ke MTT), gunakan perintah lease di konsol pengontrol host, yang mencari uji coba yang belum terpenuhi.

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

Laporkan hasil

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