Infrastruktur pengujian otomatis

Android 9 menyertakan infrastruktur Vendor Test Suite (VTS) untuk pengujian otomatis VTS, CTS, atau pengujian lainnya pada perangkat partner yang menjalankan image sistem generik AOSP (GSI). 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 (HC) VTS, sebuah mesin di lab yang mengarahkan perilaku semua perangkat yang terhubung dan sedang diuji. HC bertanggung jawab untuk mengambil build terbaru, mem-flash-nya ke perangkat, dan memanggil pengujian (baik secara lokal maupun melalui pengontrol). HC 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 dibuat dari sumber, akan lebih mudah untuk membuatnya dari tip-of-tree secara rutin, lalu memposting artefak untuk didownload.

Partner dapat mengakses resource otomatisasi menggunakan lokasi berikut:

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

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

Partner Android Build

Di Android 8.1 dan rilis yang lebih rendah, 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 padat karya ini, Android 9 menyertakan dukungan untuk mendownload resource ini secara otomatis dari PAB saat kredensial yang sesuai diberikan.

Menetapkan akses

Akses terprogram menggunakan OAuth2 di Google API untuk mengakses RPC yang diperlukan. Dengan menggunakan pendekatan standaruntuk membuat kredensial OAuth2, partner harus menyiapkan pasangan ID/rahasia klien dengan Google. Saat PartnerAndroidBuildClient diarahkan ke rahasia tersebut untuk pertama kalinya, jendela browser akan terbuka agar pengguna dapat login ke akun Google mereka, yang akan 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 resource di PAB akan mengirim permintaan POST yang menyertakan data yang diperlukan untuk resource tersebut, termasuk:

• ID build, target build
• nama resource
• cabang
• nama kandidat rilis dan apakah kandidat tersebut adalah build internal atau bukan

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

• Untuk resource APK Clockwork Companion, URL-nya 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 akan berakhir setelah lima menit).

Mendapatkan URL

Untuk menghindari pemalsuan permintaan lintas situs, buildsvc RPC memerlukan token XSRF untuk di-POST dengan parameter lainnya. Meskipun token ini membuat proses menjadi lebih aman, token ini juga membuat akses terprogram menjadi jauh lebih sulit 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 mudah digunakan yang memungkinkan partner mendownload resource; skrip HC dapat mendownload APK tersebut dengan mudah, karena format URL-nya diketahui, dan HC dapat melewati masalah XSRF/cookie karena tidak memerlukan buildsvc RPC.

Sistem file lokal

Dengan direktori yang berisi daftar (atau file zip) artefak, penyedia build akan menetapkan image yang relevan berdasarkan konten di direktori. Anda dapat menggunakan alat gsutil untuk menyalin file dari Google Cloud Storage ke direktori lokal.

Mem-flash build

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

Tindakan yang didukung:

• Hanya mem-flash GSI
• Mem-flash image satu per satu 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 di 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 paket pengujian VTS (misalnya, vts-selftest) dan menjalankan pengujian.
• Saat menggunakan TradeFed Cluster (yang secara opsional terhubung ke MTT), gunakan perintah lease di konsol pengontrol host, yang mencari pengujian yang belum terpenuhi.

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

Melaporkan hasil

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