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:

Arsitektur pengujian otomatis

Gambar 1. Arsitektur infrastruktur pengujian otomatis VTS

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

  1. Mengambil artefak build dan resource pengujian dari lokasi yang berbeda:
    • Build Android Partner (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, yaitu mesin di lab yang mengarahkan perilaku semua perangkat yang terhubung dalam pengujian. HC bertanggung jawab untuk mengambil build terbaru, mem-flash-nya ke perangkat, dan memanggil pengujian (baik secara lokal maupun melalui commander). Proses ini juga berkomunikasi dengan penjadwal cloud dan mengarahkan traffic antara penjadwal dan instance TradeFed (atau harness lain) 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:

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

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.

Build Android Partner

Pada rilis Android 8.1 dan yang lebih lama, partner Android diwajibkan untuk membuka 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 membutuhkan banyak tenaga 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 standar untuk membuat kredensial OAuth2, partner harus menyiapkan pasangan ID/rahasia klien dengan Google. Saat PartnerAndroidBuildClient diarahkan ke rahasia tersebut untuk pertama kalinya, PartnerAndroidBuildClient akan membuka jendela browser agar pengguna 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 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 dengan autentikasi dan dapat diakses dengan kredensial OAuth2 yang sesuai).
  • Untuk resource lainnya, URL 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, buildsvcRPC memerlukan token XSRF untuk diposting 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 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 RPC buildsvc.

Sistem file lokal

Mengingat direktori dengan daftar (atau file zip) artefak, penyedia build menetapkan gambar yang relevan berdasarkan isi 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 melakukan flash GSI
  • Mem-flash gambar 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 platform pengujian TradeFed, tetapi dapat diperluas untuk mendukung platform 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 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 proses pengujian yang belum selesai.

Jika menggunakan TradeFedCluster, TradeFed 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.