Otomatik test altyapısı

Android 9, AOSP genel sistem görüntüsünü (GSI) çalıştıran ortak cihazlarda VTS, CTS veya diğer testlerin otomatik olarak test edilmesi için bir Satıcı Test Paketi (VTS) altyapısı içerir. Önceden bu testleri yürütmek oldukça manuel bir işlemdi; Yeni VTS test altyapısı, birden fazla cihazda günde birden çok kez otomatik testi destekleyecek şekilde tasarlanmıştır.

Mimari

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

Automated test architecture

Ş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. Farklı konumlardan yapı yapılarını ve test kaynaklarını getirir:
    • İş Ortağı Android Derlemesi (PAB) . GSI, VTS çerçevesi ve diğer bazı yapılar için.
    • Yerel dosya sistemi, Google Cloud Storage veya satıcıya özel başka bir derleme sistemi . Yapıları Google'ın bulutunda depolamayan iş ortakları için.
  2. Flaşlar, bağlı cihazlara yapay yapılar (cihazdan) ve GSI (AOSP'den) oluşturur.
  3. Yerel TradeFed'i veya buluttaki TradeFed'i kullanarak VTS testlerini çalıştırır.
  4. Test sonuçlarını VTS kontrol paneline raporlar

Süreç, laboratuvarda test edilen tüm bağlı cihazların davranışını yönlendiren bir makine olan VTS ana bilgisayar denetleyicisi (HC) tarafından koordine edilmektedir. HC, en yeni yapıları almaktan, bunları cihazlara yüklemekten ve testleri (yerel olarak veya komutan aracılığıyla) başlatmaktan sorumludur. Ayrıca bir bulut zamanlayıcıyla iletişim kurar ve zamanlayıcı ile HC üzerinde çalışan TradeFed örneği (veya başka bir donanım) arasındaki trafiği yönlendirir. Ana bilgisayar denetleyicisine ilişkin ayrıntılar için bkz. Ana Bilgisayar Denetleyici Mimarisi .

Kaynak sağlayıcılar

Otomatik test, sistem yapıları, test dosyaları ve VTS yapıları gibi kaynakları gerektirir. Bunları kaynaktan oluşturmak mümkün olsa da, bunları düzenli olarak ağacın ucundan oluşturmak ve ardından eserleri indirmek için yayınlamak daha kolaydır.

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

  • İş Ortağı Android Derlemesi . Programatik erişim, hesap başına esasına göre verilir.
  • Yerel dosya sistemi (veya benzeri). Partner Android Derlemesini kullanmayan iş ortakları için.

Cihazların daha sonra güncellenmesinde kullanılmak üzere kaynaklar, her iki seçenek için de derleme sağlayıcılarını içerir; bunlar, yapıları yerel geçici dizinlerde saklayan tek bir build_provider.py dosyasından uzanır.

İş 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 etmeleri, hesaplarına gitmeleri ve kullanıcı arayüzü aracılığıyla en son sistem görüntülerini almaları gerekiyordu. İş ortaklarının bu yavaş ve emek yoğun 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 indirilmesine yönelik destek içerir.

Erişimi kurun

Programatik erişim, gerekli RPC'lere erişmek için Google API'lerinde OAuth2'yi kullanır. OAuth2 kimlik bilgileri oluşturmaya yönelik standart yaklaşımı kullanan iş ortağının, Google ile bir istemci kimliği/gizli çifti ayarlaması gerekir. PartnerAndroidBuildClient bu sırra ilk kez işaret edildiğinde, kullanıcının Google hesabında oturum açması için bir tarayıcı penceresi açılır ve bu pencere, ilerlemek için gereken OAuth2 kimlik bilgilerini oluşturur. Kimlik bilgileri (erişim belirteci ve yenileme belirteci) yerel olarak depolanır; bu, iş ortaklarının yalnızca bir kez oturum açması gerektiği anlamına gelir.

URL için POST isteği

PAB'da bir kaynak bağlantısına tıklamak, söz konusu kaynak için aşağıdakiler de dahil olmak üzere gerekli verileri içeren bir POST isteği gönderir:

  • kimlik oluştur, hedef oluştur
  • kaynak adı
  • dal
  • adayın adını ve adayın dahili bir yapı olup olmadığını yayınlayın

POST isteği, buildsvc RPC'nin downloadBuildArtifact yöntemi tarafından alınır ve 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 (kimlik doğrulama korumalıdır ve uygun OAuth2 kimlik bilgileriyle erişilebilir).
  • Diğer kaynaklar için URL, dahili Android Build API'sinden gelen uzun ve korumasız bir URL'dir (bu URL'nin süresi beş dakika sonra dolar).

URL'yi alın

Siteler arası istek sahteciliğini önlemek için buildsvc RPC, diğer parametrelerle birlikte bir XSRF belirtecinin POST'lanmasını gerektirir. Bu belirteç süreci daha güvenli hale getirirken, aynı zamanda (yalnızca PAB sayfasının JavaScript'inde bulunan) belirtecin artık erişim için de gerekli olması nedeniyle programatik erişimi çok daha zorlaştırır.

Bu sorunu önlemek amacıyla Android 9, yapay listelere ve yapay URL'lere erişim için öngörülebilir URL adlarını kullanmak amacıyla tüm dosyalar (yalnızca APK'lar için değil) için URL adlandırma şemasını yeniden tasarlar. PAB artık iş ortaklarının kaynakları indirmesine olanak tanıyan kullanışlı bir URL biçimi kullanıyor; URL formatı 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ıtların bir listesini (veya zip dosyasını) içeren bir dizin verildiğinde, derleme sağlayıcısı, ilgili görüntüleri dizinde bulunanlara göre ayarlar. Dosyaları Google Cloud Storage'dan yerel bir dizine kopyalamak için gsutil aracını kullanabilirsiniz.

Flash derlemeleri

En yeni cihaz görüntüleri ana bilgisayara indirildikten sonra, bu resimlerin cihazlara flaşlanması gerekir. Bu, derleme sağlayıcıları tarafından depolanan geçici dosya yollarına dayalı olarak standart adb ve fastboot komutları ve Python alt işlemleri kullanılarak yapılır.

Desteklenen eylemler:

  • Yalnızca GSI yanıp sönüyor
  • Ana sistemden tek tek görüntülerin yanıp sönmesi (örneğin, 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 (birer birer)

Testleri çalıştır

Android 9'da VTS otomatik test altyapısı yalnızca TradeFed test donanımını destekler ancak gelecekte diğer donanımları 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 bilgisayar denetleyicisindeki test komutunu kullanın; bu, bir VTS test planının adını alır (örn. vts-selftest ) ve testi çalıştırır.
  • TradeFed Kümesini (isteğe bağlı olarak MTT'ye bağlı) kullanırken, ana bilgisayar denetleyici konsolunda, yerine getirilmemiş test çalıştırmalarını arayan lease komutunu kullanın.

TradeFedCluster kullanıyorsanız, TradeFed yerel olarak uzaktan yönetici olarak çalışır. Değilse testler Python alt süreçleri kullanılarak çağrılır.

Sonuçları raporla

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