Otomatik test altyapısı

Android 9, AOSP genel sistem imajını (GSI) çalıştıran iş ortağı cihazlarında VTS, CTS veya diğer testlerin otomatik olarak test edilmesi için bir Tedarikçi Test Paketi (VTS) altyapısı içerir. Daha önce bu testleri çalıştırmak oldukça manuel bir işlemdi. Yeni VTS test altyapısı, birden fazla cihazda günde birden çok kez otomatik testi desteklemek için tasarlanmıştır.

Mimari

VTS otomatik test altyapısı aşağıdaki mimariyi kullanır:

Otomatik test mimarisi

Şekil 1. VTS otomatik test altyapısı mimarisi

Bir test tetiklendiğinde VTS otomatik test altyapısı aşağıdaki görevleri gerçekleştirir:

  1. Derleme yapılarını ve test kaynaklarını farklı konumlardan getirir:
    • İş Ortağı Android Derlemesi (PAB). GSI, VTS çerçevesi ve bazı diğer derlemeler için
    • Yerel dosya sistemi, Google Cloud Storage veya tedarikçiye özgü başka bir derleme sistemi. Derlemeleri Google'ın bulutunda depolamayan iş ortakları için.
  2. Derleme yapılarını (cihazdan) ve GSI'yi (AOSP'den) bağlı cihazlara yükler.
  3. Bulutta yerel TradeFed veya bir TradeFed kullanarak VTS testleri çalıştırır.
  4. Test sonuçlarını VTS kontrol paneline raporlar

Bu süreç, laboratuvardaki ve test altındaki tüm bağlı cihazların davranışını yöneten bir makine olan VTS ana makine denetleyicisi (HC) tarafından koordine edilir. HC, en son derlemeleri getirme, cihazlara yükleme ve testleri çağırma (yerel olarak veya komutan aracılığıyla) işlemlerinden sorumludur. Ayrıca bir bulut planlayıcıyla iletişim kurar ve trafiği planlayıcı ile HC'de çalışan TradeFed örneği (veya başka bir koşum takımı) arasında yönlendirir. Düzenleyen denetleyici hakkında ayrıntılı bilgi için Düzenleyen Denetleyici Mimarisi başlıklı makaleyi inceleyin.

Kaynak sağlayıcılar

Otomatik test için sistem derlemeleri, test dosyaları ve VTS yapıları gibi kaynaklar gerekir. Bunları kaynaktan oluşturmak mümkün olsa da bunları düzenli olarak ağaç ucundan oluşturmak ve indirilmek üzere yayınlamak daha kolaydır.

İş ortakları, aşağıdaki konumları kullanarak otomasyon kaynaklarına erişebilir:

  • İş ortağı Android derlemesi. Programatik erişim hesap bazında verilir.
  • Yerel dosya sistemi (veya benzeri). İş ortağı Android derlemesini kullanmayan iş ortakları için.

Cihazları daha sonra flaşlamada kullanmak için kaynaklar, her iki seçenek için de derleme sağlayıcıları içerir. Bu sağlayıcılar, derlemeleri yerel geçici dizinlerde depolayan tek bir build_provider.py'ten genişler.

İş Ortağı Android Derlemesi

Android 8.1 ve önceki sürümlerde Android iş ortaklarının İş Ortağı Android Derlemesi web sitesini (https://partner.android.com/build) ziyaret etmeleri, hesaplarına gitmeleri ve kullanıcı arayüzünden en son sistem görüntülerini getirmeleri gerekiyordu. İş ortaklarının bu yavaş ve zahmetli süreçten kaçınmasına yardımcı olmak için Android 9, uygun kimlik bilgileri sağlandığında bu kaynakları PAB'den otomatik olarak indirme desteği içerir.

Erişim oluşturma

Programatik erişim, gerekli UPÇ'lere erişmek için Google API'lerinde OAuth2'yi kullanır. İş ortağının, OAuth2 kimlik bilgilerini oluşturmak için standart yaklaşımı kullanarak Google ile bir istemci kimliği/gizli anahtar çifti oluşturması gerekir. PartnerAndroidBuildClient, bu gizliye ilk kez yönlendirildiğinde kullanıcının Google Hesabı'na Kimlik bilgileri (erişim jetonu ve yenileme jetonu) yerel olarak depolanır. Bu nedenle, iş ortaklarının yalnızca bir kez giriş yapması gerekir.

URL için POST isteği

PAB'deki bir kaynak bağlantısını tıkladığınızda, söz konusu kaynak için gerekli verileri içeren bir POST isteği gönderilir. Bu veriler şunlardır:

  • derleme kimliği, derleme hedefi
  • kaynak adı
  • dal
  • sürüm adayı adı ve adayın dahili bir derleme olup olmadığı

POST isteği, buildsvc RPC'nin downloadBuildArtifact yöntemi tarafından alınır. Bu yöntem, kaynağa erişmek için kullanılabilecek bir URL döndürür.

  • Clockwork Companion APK kaynakları için URL, PAB'de barındırılan okunabilir bir URL'dir (bu URL, kimlik doğrulama korumalıdır ve uygun OAuth2 kimlik bilgileriyle erişilebilir).
  • Diğer kaynaklar için URL, dahili Android Build API'den gelen uzun, korunmayan URL'dir (süresi beş dakika sonra dolar).

URL'yi alma

Siteler arası istek sahtekarlığını önlemek için buildsvc RPC, diğer parametrelerle birlikte bir XSRF jetonunun POST edilmesini gerektirir. Bu jeton, süreci daha güvenli hale getirirken erişmek için artık jeton (yalnızca PAB sayfasının JavaScript'inde kullanılabilir) gerektiğinden programatik erişimi de çok daha zor hale getirir.

Android 9 bu sorunu önlemek amacıyla tüm dosyalar (yalnızca APK'lar değil) için URL adlandırma şemasını yeniden tasarlar. Böylece, yapı listelerine ve yapı URL'lerine erişmek için tahmin edilebilir URL adları kullanılır. PAB artık iş ortaklarının kaynakları indirmesini sağlayan kullanışlı bir URL biçimi kullanır. URL biçimi bilindiği için HC komut dosyaları, bu APK'ları kolayca indirebilir ve HC, buildsvc SRF/çerez sorunlarını atlayabildiği için bu biçimi atlayabilir.

Yerel dosya sistemi

Derleme sağlayıcı, yapıların listesini (veya zip dosyasını) içeren bir dizin verildiğinde, alakalı resimleri dizindeki öğelere göre ayarlar. Google Cloud Storage'daki dosyaları yerel bir dizine kopyalamak için gsutil aracını kullanabilirsiniz.

Flash derlemeleri

En son cihaz resimleri ana makineye indirildikten sonra bu resimler cihazlara yüklenmelidir. Bu işlem, derleme sağlayıcıları tarafından saklanan geçici dosya yollarına göre standart adb ve fastboot komutları ile Python alt süreçleri kullanılarak yapılır.

Desteklenen işlemler:

  • Yalnızca GSI'yi flaşlama
  • Ana sistemden tek tek resimleri yanıp sönen görüntüler (ör. fastboot flash boot boot.img)
  • Ana sistemdeki tüm görüntülerin yanıp sönmesi. Örnek:
    • fastboot flashall (yerleşik flashall yardımcı programını kullanarak)
    • fastboot flash (tek tek)

Test çalıştırma

Android 9'da VTS otomatik test altyapısı yalnızca TradeFed test donanımını destekler ancak gelecekte diğer donanımları da desteklemek için genişletilebilir.

Cihazlar hazırlandıktan sonra aşağıdaki seçeneklerden birini kullanarak testleri çağırabilirsiniz:

  • TradeFed'i yerel olarak kullanırken ana makine denetleyicisinde test komutunu kullanın.Bu komut, VTS test planının adını alır (ör. vts-selftest) ve testi çalıştırır.
  • TradeFed kümesi (isteğe bağlı olarak MTT'ye bağlı) kullanırken, ana makine denetleyicisi konsolunda lease komutunu kullanarak tamamlanmamış test çalıştırmalarını arayın.

TradeFedCluster kullanılıyorsa TradeFed yerel olarak uzaktan yönetici olarak çalışır. Aksi takdirde testler, Python alt işlemleri kullanılarak çağrılır.

Sonuçları raporlama

Test sonuçları, VtsMultiDeviceTest tarafından bazı VTS kontrol paneli projelerine otomatik olarak bildirilir.