Automatisierte Testinfrastruktur

Android 9 enthält eine Vendor Test Suite (VTS)-Infrastruktur zum automatisierten Testen von VTS, CTS oder anderen Tests auf Partnergeräten, auf denen das generische AOSP-Systemabbild (GSI) ausgeführt wird. Bisher war die Durchführung dieser Tests ein sehr manueller Vorgang; Die neue VTS-Testinfrastruktur wurde entwickelt, um automatisierte Tests mehrmals täglich auf mehreren Geräten zu unterstützen.

Die Architektur

Die automatisierte Testinfrastruktur von VTS verwendet die folgende Architektur:

Automated test architecture

Abbildung 1. VTS automatisierte Prüfinfrastruktur Architektur

Wenn ein Test ausgelöst wird, führt die automatisierte Testinfrastruktur von VTS die folgenden Aufgaben aus:

  1. Ruft Build-Artefakte und Testressourcen von verschiedenen Orten ab:
    • Partner Android Build (PAB). Für GSI, VTS-Framework und einige andere Builds.
    • Lokale Dateisystem, Google Cloud Storage oder anderes herstellerspezifische Build - System. Für Partner, die keine Builds in der Cloud von Google speichern.
  2. Blitze erzeugen Artefakte (vom Gerät) und die GSI (vom AOSP) auf dem/den angeschlossenen Gerät(en).
  3. Führt VTS-Tests mit lokalem TradeFed oder einem TradeFed in der Cloud durch.
  4. Meldet Testergebnisse an das VTS-Dashboard

Der Prozess wird vom VTS Host Controller (HC) koordiniert, einer Maschine im Labor, die das Verhalten aller angeschlossenen Geräte im Test steuert. Der HC ist dafür verantwortlich, die neuesten Builds abzurufen, sie auf Geräte zu flashen und Tests aufzurufen (entweder lokal oder über den Commander). Es kommuniziert auch mit einem Cloud-Scheduler und leitet den Verkehr zwischen dem Scheduler und der TradeFed-Instanz (oder einem anderen Kabelbaum), die auf dem HC ausgeführt wird. Einzelheiten zu den Host - Controller, siehe Host - Controller - Architektur .

Ressourcenanbieter

Automatisierte Tests erfordern Ressourcen wie Systembuilds, Testdateien und VTS-Artefakte. Es ist zwar möglich, diese aus dem Quellcode zu erstellen, es ist jedoch einfacher, sie regelmäßig aus dem Tip-of-Tree zu erstellen und dann die Artefakte zum Download bereitzustellen.

Partner können über die folgenden Speicherorte auf Automatisierungsressourcen zugreifen:

  • Partner Android - Build. Der programmatische Zugriff wird pro Konto gewährt.
  • Lokale Dateisystem (oder ähnliches). Für Partner, die den Partner Android Build nicht verwenden.

Für den Einsatz in später die Geräte zu blinken, sind Ressourcen Build - Provider für beiden Optionen, von einem einzigen erstreckt build_provider.py dass speichert die in lokalen temporären Verzeichnissen erstellt.

Partner-Android-Build

In Android 8.1 und niedrigeren Versionen wurden Android - Partner benötigt , um den Partner Android - Build Webseite (besuchen https://partner.android.com/build ) Navigieren auf ihr Konto, und holen Ihnen den neuesten System - Images über die Benutzeroberfläche. Damit Partner diesen langsamen und arbeitsintensiven Prozess vermeiden können, bietet Android 9 Unterstützung für das automatische Herunterladen dieser Ressourcen von PAB, wenn die entsprechenden Anmeldeinformationen bereitgestellt werden.

Zugang einrichten

Der programmatische Zugriff verwendet OAuth2 auf Google-APIs, um auf die erforderlichen RPCs zuzugreifen. Unter Verwendung der Standard - Ansatz zur Erzeugung von OAuth2 Anmeldeinformationen muss der Partner festgelegt eine Client - ID / secret Paar mit Google auf. Wenn der PartnerAndroidBuildClient zu diesem Geheimnis zum ersten Mal gezeigt wird, öffnet sie ein Browser - Fenster für den Benutzer auf ihr Google - Konto anmelden, das die OAuth2 Anmeldeinformationen erzeugt benötigten vorwärts zu bewegen. Die Anmeldeinformationen (Zugriffstoken und Aktualisierungstoken) werden lokal gespeichert, sodass sich Partner nur einmal anmelden müssen.

POST-Anfrage für URL

Durch Klicken auf einen Ressourcenlink in PAB wird eine POST-Anfrage gesendet, die die erforderlichen Daten für diese Ressource enthält, einschließlich:

  • Build-ID, Build-Ziel
  • Ressourcenname
  • Zweig
  • Name des Release-Kandidaten und ob der Kandidat ein interner Build ist oder nicht

Die POST - Anforderung wird durch die empfangene downloadBuildArtifact Verfahren des buildsvc RPC, das eine URL zurückgibt , die verwendet werden können , auf die Ressource zuzugreifen.

  • Für Clockwork Companion APK-Ressourcen ist die URL eine lesbare URL, die auf PAB gehostet wird (die authentifiziert und mit den entsprechenden OAuth2-Anmeldeinformationen zugänglich ist).
  • Für andere Ressourcen ist die URL eine lange, nicht geschützte URL aus der internen Android Build API (die nach fünf Minuten abläuft).

Abrufen der URL

Um zu vermeiden , Fälschung Cross-Site Request, die buildsvc erfordert RPC eine XSRF Token mit den anderen Parametern gebucht werden. Dieses Token macht zwar den Prozess sicherer, erschwert aber auch den programmatischen Zugriff, da das Token (das nur im JavaScript der PAB-Seite verfügbar ist) nun auch für den Zugriff benötigt wird.

Um dieses Problem zu vermeiden, gestaltet Android 9 das URL-Benennungsschema für alle Dateien (nicht nur APKs) neu, um vorhersagbare URL-Namen für den Zugriff auf Artefaktlisten und Artefakt-URLs zu verwenden. Der PAB verwendet jetzt ein praktisches URL-Format, das es Partnern ermöglicht, Ressourcen herunterzuladen. HC - Skripte können diese APKs einfach herunterladen, da der URL - Format bekannt ist, und HC Bypass den XSRF / Cookie Probleme , weil es muss nicht die buildsvc RPC.

Lokales Dateisystem

Bei einem Verzeichnis mit einer Liste (oder ZIP-Datei) von Artefakten legt der Buildanbieter die relevanten Bilder basierend auf dem Inhalt des Verzeichnisses fest. Sie können die Verwendung gsutil Tool Dateien von Google Cloud Storage in einem lokalen Verzeichnis zu kopieren.

Flash-Builds

Nachdem die neuesten Geräteimages auf den Host heruntergeladen wurden, müssen diese Images auf die Geräte geflasht werden. Dies geschieht mit den Standard - adb und fastboot - Befehlen und Python Teilprozessen, basierend auf den temporären Dateipfaden von dem Build - Anbieter gespeichert.

Unterstützte Aktionen:

  • Blinkt nur die GSI
  • Flashing einzelne Bilder aus dem Hauptsystem (zB fastboot flash boot boot.img - fastboot flash boot boot.img - fastboot flash boot boot.img - fastboot flash boot boot.img )
  • Flashen aller Bilder vom Hauptsystem. Beispiel:
    • fastboot flashall (mit dem eingebauten in flashall Utility)
    • fastboot flash - fastboot flash (einer nach dem anderen)

Laufende Tests

In Android 9 unterstützt die automatisierte Testinfrastruktur von VTS nur das TradeFed-Testkabel, könnte aber in Zukunft auf andere Kabelbäume erweitert werden.

Nachdem die Geräte vorbereitet sind, können Sie Tests mit einer der folgenden Optionen aufrufen:

  • Wenn lokal mit TradeFed, verwendet , um den test - Befehl in dem Host - Controller, der den Namen eines VTS Testplanes erfolgt (zB vts-selftest ) und die Testläufe.
  • Wenn ein Cluster mit TradeFed (optional an MTT verbunden ist ), verwendet , um den lease - Befehl in der Host - Controller - Konsole, die für unerfüllte Testläufe aussieht.

Wenn TradeFedCluster verwendet wird , läuft TradeFed lokal als Remote Manager . Wenn nicht, werden die Tests mit Python-Unterprozessen aufgerufen.

Berichtsergebnisse

Die Testergebnisse werden auf einige VTS Armaturenbrett Projekte automatisch gemeldet VtsMultiDeviceTest .