Otomatik test altyapısı

Android 9, AOSP genel sistem görüntüsü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 testlerin çalıştırılması büyük ölçüde manuel bir işlemdi. Yeni VTS test altyapısı ise birden fazla cihazda günde birden çok kez otomatik test yapılmasını destekleyecek şekilde tasarlanmıştır.

Mimari

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

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:
   • Partner Android Build (PAB). GSI, VTS çerçevesi ve diğer bazı derlemeler için.
   • Yerel dosya sistemi, Google Cloud Storage veya diğer tedarikçiye özel derleme sistemi. Derlemeleri Google'ın bulutunda depolamayan iş ortakları için.
2. Bağlı cihazlara, cihazdan derleme yapılarını ve AOSP'den GSI'yı yükler.
3. Yerel TradeFed veya buluttaki bir TradeFed kullanarak VTS testlerini çalıştırır.
4. Test sonuçlarını VTS kontrol paneline bildirir.

Süreç, laboratuvardaki ve test edilen tüm bağlı cihazların davranışını yönlendiren bir makine olan VTS ana denetleyicisi (HC) tarafından koordine edilir. HC, en yeni derlemeleri getirmek, bunları cihazlara yüklemek ve testleri (yerel olarak veya komutan aracılığıyla) çağırmaktan sorumludur. Ayrıca bir bulut planlayıcıyla iletişim kurar ve planlayıcı ile HC'de çalışan TradeFed örneği (veya başka bir koşum) arasındaki trafiği yönlendirir. Ana makine denetleyicisiyle ilgili ayrıntılar için Ana Makine Denetleyicisi 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 tip-of-tree'den oluşturup yapıtları indirilmek üzere yayınlamak daha kolaydır.

İş ortakları, aşağıdaki yerleri 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.

Kaynaklar, cihazları daha sonra yanıp söndürmek için kullanılacak her iki seçeneğe yönelik derleme sağlayıcıları içerir. Bu sağlayıcılar, derlemeleri yerel geçici dizinlerde depolayan tek bir build_provider.py ile başlar.

İş Ortağı Android Derlemesi

Android 8.1 ve önceki sürümlerde Android iş ortaklarının Partner Android Build web sitesini (https://partner.android.com/build) ziyaret etmesi, hesaplarına gitmesi ve kullanıcı arayüzü üzerinden en son sistem görüntülerini getirmesi 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ın PAB'den otomatik olarak indirilmesi için destek içerir.

Erişim oluşturma

Programatik erişim, gerekli UPÇ'lere erişmek için Google API'lerinde OAuth2'yi kullanır. OAuth2 kimlik bilgilerini oluşturmak için standart yaklaşımı kullanan iş ortağı, Google ile bir istemci kimliği/gizli anahtar çifti oluşturmalıdır. PartnerAndroidBuildClient ilk kez bu gizli anahtara yönlendirildiğinde kullanıcının Google Hesabı'na giriş yapması için bir tarayıcı penceresi açılır. Bu işlem, devam etmek için gereken OAuth2 kimlik bilgilerini oluşturur. 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'de 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 arasında şunlar yer alı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 (yetkilendirme korumalı ve uygun OAuth2 kimlik bilgileriyle erişilebilir) barındırılan okunabilir bir URL'dir.
• Diğer kaynaklar için URL, dahili Android Build API'den alınan uzun ve korunmayan bir URL'dir (beş dakika sonra sona erer).

URL'yi alma

Siteler arası istek sahteciliğini önlemek için buildsvc RPC'nin diğer parametrelerle birlikte bir XSRF jetonunun POST edilmesi gerekir. Bu jeton, süreci daha güvenli hale getirirken erişim için 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 için tüm dosyaların (yalnızca APK'lar değil) URL adlandırma şemasını yeniden tasarlayarak yapıt listelerine ve yapıt URL'lerine erişmek için tahmin edilebilir URL adları kullanır. PAB artık iş ortaklarının kaynakları indirmesine olanak tanıyan uygun bir URL biçimi kullanır. URL biçimi bilindiğinden HC komut dosyaları bu APK'ları kolayca indirebilir ve HC, buildsvc RPC'ye ihtiyaç duymadığından XSRF/çerez sorunlarını atlayabilir.

Yerel dosya sistemi

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

Flash derlemeleri

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

Desteklenen işlemler:

• Yalnızca GSI'yi flaşlama
• Ana sistemden tek tek görüntülerin yanıp sönmesi (ör. fastboot flash boot boot.img)
• Ana sistemdeki tüm görüntüleri yanıp söndürme. Örnek:
  • fastboot flashall (yerleşik flashall aracını kullanarak)
  • fastboot flash (birer birer)

Testler yapın

Android 9'da VTS otomatik test altyapısı yalnızca TradeFed test düzeneğini destekler ancak gelecekte diğer düzeneği destekleyecek şekilde genişletilebilir.

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

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

TradeFedCluster kullanılıyorsa TradeFed, uzak yönetici olarak yerel çalışır. Aksi takdirde testler, Python alt süreçleri kullanılarak çağrılır.

Sonuçları raporlama

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