Infrastruktur pengujian otomatis

Android 9 menyertakan infrastruktur Vendor Test Suite (VTS) untuk pengujian otomatis VTS, CTS, atau pengujian lainnya di perangkat partner yang menjalankan generic system image (GSI) AOSP. Sebelumnya, menjalankan pengujian ini adalah operasi yang sangat manual; infrastruktur pengujian VTS baru dirancang untuk mendukung pengujian otomatis beberapa kali sehari di beberapa perangkat.

Arsitektur

Infrastruktur pengujian otomatis VTS menggunakan arsitektur berikut:

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

1. Mengambil artefak build dan resource pengujian dari berbagai lokasi:
   • Partner Android Build (PAB). Untuk GSI, framework VTS, 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. Mem-flash artefak build (dari perangkat) dan GSI (dari AOSP) ke perangkat yang terhubung.
3. Menjalankan pengujian VTS menggunakan TradeFed lokal atau TradeFed di cloud.
4. Melaporkan hasil pengujian ke dasbor VTS

Proses ini dikoordinasikan oleh pengontrol host VTS (HC), 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 memanggil pengujian (secara lokal atau melalui commander). Alat ini juga berkomunikasi dengan penjadwal cloud dan mengarahkan traffic antara penjadwal dan instance TradeFed (atau beberapa harness lainnya) yang berjalan di HC. Untuk mengetahui detail tentang pengontrol host, lihat Arsitektur Pengontrol Host.

Penyedia resource

Pengujian otomatis memerlukan resource seperti build sistem, file pengujian, dan artefak VTS. Meskipun dapat di-build dari sumber, akan lebih mudah untuk mem-buildnya dari tip-of-tree secara rutin, lalu memposting artefak untuk didownload.

Partner dapat mengakses resource otomatisasi menggunakan lokasi berikut:

• Build Android Partner. Akses terprogram diberikan per akun.
• Sistem file lokal (atau yang serupa). Untuk partner yang tidak menggunakan Build Android Partner.

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

Build Android Partner

Dalam rilis Android 8.1 dan yang lebih lama, partner Android diwajibkan untuk mengunjungi situs 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 melelahkan ini, Android 9 menyertakan dukungan untuk otomatis mendownload resource ini dari PAB saat kredensial yang sesuai diberikan.

Menetapkan akses

Akses terprogram menggunakan OAuth2 di Google API untuk mengakses RPC yang diperlukan. Dengan menggunakan pendekatan standar untuk membuat kredensial OAuth2, partner harus menyiapkan pasangan client ID/rahasia dengan Google. Saat PartnerAndroidBuildClient diarahkan ke secret tersebut untuk pertama kalinya, secret akan membuka jendela browser bagi pengguna untuk login ke akun Google mereka, yang menghasilkan kredensial OAuth2 yang diperlukan untuk melanjutkan. Kredensial (token akses dan token refresh) disimpan secara lokal, yang berarti partner hanya perlu login satu kali.

Permintaan POST untuk URL

Mengklik link referensi di PAB akan mengirim permintaan POST yang menyertakan data yang diperlukan untuk referensi tersebut, termasuk:

• ID build, target build
• nama resource
• cabang
• nama kandidat rilis dan apakah kandidat tersebut merupakan build internal atau tidak

Permintaan POST diterima oleh metode downloadBuildArtifact RPC buildsvc, yang menampilkan URL yang dapat digunakan untuk mengakses resource.

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

Mendapatkan URL

Untuk menghindari pemalsuan permintaan lintas situs, RPC buildsvc memerlukan token XSRF yang dikirimkan dengan parameter lainnya. Meskipun token ini membuat prosesnya lebih aman, token ini juga mempersulit akses terprogram karena token (yang hanya tersedia di JavaScript halaman PAB) kini juga diperlukan untuk akses.

Untuk menghindari masalah ini, Android 9 mendesain ulang skema penamaan URL untuk semua file (bukan hanya APK) agar menggunakan nama URL yang dapat diprediksi untuk mengakses daftar artefak dan URL artefak. PAB kini menggunakan format URL yang praktis yang memungkinkan partner mendownload resource; skrip HC dapat mendownload APK tersebut dengan mudah, karena format URL diketahui, dan HC dapat mengabaikan masalah XSRF/cookie karena tidak memerlukan RPC buildsvc.

Sistem file lokal

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

Build Flash

Setelah image perangkat terbaru didownload ke host, image tersebut harus di-flash ke perangkat. Hal ini dilakukan 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 setiap image dari sistem utama (misalnya, fastboot flash boot boot.img)
• Mem-flash semua image dari sistem utama. Contoh:
  • fastboot flashall (menggunakan utilitas flashall bawaan)
  • fastboot flash (satu per satu)

Menjalankan pengujian

Di Android 9, infrastruktur pengujian otomatis VTS hanya mendukung harness pengujian TradeFed, tetapi dapat diperluas untuk mendukung harness lainnya pada masa mendatang.

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

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

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

Hasil laporan

Hasil pengujian otomatis dilaporkan ke beberapa project dasbor VTS oleh VtsMultiDeviceTest.