Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Infrastruktur Pengujian Otomatis

Android 9 menyertakan infrastruktur Vendor Test Suite (VTS) untuk pengujian otomatis VTS, CTS, atau pengujian lain 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:

Automated test architecture

Gambar 1. VTS arsitektur infrastruktur pengujian otomatis

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

  1. Mengambil artefak build dan menguji sumber daya dari lokasi berbeda:
    • Membangun mitra Android (PAB). Untuk GSI, framework VTS, dan beberapa build lainnya.
    • Filesystem 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 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 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 rincian tentang host controller, lihat Host Controller Arsitektur .

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:

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

Untuk penggunaan di flashing perangkat kemudian, sumber termasuk penyedia membangun untuk kedua pilihan, membentang dari satu build_provider.py yang menyimpan membangun di direktori sementara lokal.

Mitra Android Build

Dalam Android 8.1 dan rilis yang lebih rendah, mitra Android diminta untuk mengunjungi situs web Partner Android Build ( https://partner.android.com/build ), navigasi ke rekening 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 klien id / pasangan rahasia dengan Google. Ketika PartnerAndroidBuildClient adalah menunjuk bahwa rahasia untuk pertama kalinya, ini akan membuka jendela browser bagi pengguna untuk masuk ke akun Google mereka, yang menghasilkan kepercayaan OAuth2 yang diperlukan untuk bergerak maju. 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 tidak

Permintaan POST diterima oleh downloadBuildArtifact metode 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 lintas situs pemalsuan permintaan, yang buildsvc RPC membutuhkan XSRF token untuk akan 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; HC script dapat men-download mereka APK mudah, karena format URL diketahui, dan HC dapat bypass masalah XSRF / kue karena tidak perlu buildsvc RPC.

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 gsutil alat untuk menyalin file dari Google Cloud Storage ke direktori lokal.

Membangun berkedip

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

Tindakan yang didukung:

  • Hanya mem-flash GSI
  • Berkedip gambar individu dari sistem utama (misalnya, fastboot flash boot boot.img )
  • Mem-flash semua gambar dari sistem utama. Contoh:
    • fastboot flashall (menggunakan built-in flashall utilitas)
    • 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:

  • Bila menggunakan TradeFed lokal, gunakan test perintah di host controller, yang mengambil nama dari rencana uji VTS (misalnya vts-selftest ) dan berjalan tes.
  • Bila menggunakan TradeFed Cluster (opsional terhubung ke MTT), menggunakan lease perintah di host controller konsol, yang terlihat untuk tes berjalan terpenuhi.

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

Melaporkan hasil

Hasil pengujian secara otomatis dilaporkan beberapa proyek dashboard VTS oleh VtsMultiDeviceTest .