Infrastruktur für automatisierte Tests

Android 9 enthält eine VTS-Infrastruktur (Vendor Test Suite) für automatisierte VTS-, CTS- oder andere Tests auf Partnergeräten mit dem generischen AOSP-System-Image (GSI). Bisher war die Durchführung dieser Tests sehr manuell. Die neue VTS-Testinfrastruktur wurde entwickelt, um automatisierte Tests mehrmals täglich auf mehreren Geräten zu unterstützen.

Architektur

Die automatisierte Testinfrastruktur von VTS verwendet die folgende Architektur:

Automatisierte Testarchitektur

Abbildung 1. VTS-Infrastruktur für automatisierte Tests

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

  1. Er ruft Build-Artefakte und Testressourcen von verschiedenen Orten ab:
    • Partner Android Build (PAB) Für das GSI, das VTS-Framework und einige andere Builds.
    • Lokales Dateisystem, Google Cloud Storage oder anderes anbieterspezifisches Build-System Für Partner, die Builds nicht in der Google-Cloud speichern
  2. Flash-Build-Artefakte (vom Gerät) und die GSI (von AOSP) werden auf die verbundenen Geräte übertragen.
  3. Führt VTS-Tests mit lokalem TradeFed oder TradeFed in der Cloud aus.
  4. Testergebnisse an das VTS-Dashboard melden

Der Prozess wird vom VTS-Host-Controller (HC) koordiniert, einer Maschine im Labor, die das Verhalten aller zu testenden verbundenen Geräte steuert. Die Hilfe ist für das Abrufen der neuesten Builds, das Flashen auf Geräten und das Aufrufen von Tests (entweder lokal oder über den Commander) zuständig. Er kommuniziert außerdem mit einem Cloud-Planer und leitet den Traffic zwischen dem Planer und der TradeFed-Instanz (oder einem anderen Dienst) weiter, die in der Hilfe ausgeführt wird. Weitere Informationen zum Hostcontroller finden Sie unter Architektur des Hostcontrollers.

Ressourcenanbieter

Automatisierte Tests erfordern Ressourcen wie System-Builds, Testdateien und VTS-Artefakte. Es ist zwar möglich, diese aus der Quelle zu erstellen, aber es ist einfacher, sie regelmäßig vom Stamm des Verzeichnisbaums aus zu erstellen und die Artefakte zum Download anzubieten.

Partner können an den folgenden Stellen auf Automatisierungsressourcen zugreifen:

  • Android-Build des Partners Programmatischer Zugriff pro Konto.
  • Local filesystem (oder ähnlich). Für Partner, die nicht den Partner Android Build verwenden.

Für das spätere Flashen der Geräte enthalten die Ressourcen Buildanbieter für beide Optionen, die von einem einzelnen build_provider.py ausgehen, in dem die Builds in lokalen temporären Verzeichnissen gespeichert werden.

Partner Android-Build

In Android 8.1 und früheren Versionen mussten Android-Partner die Android Build-Website des Partners (https://partner.android.com/build) besuchen, ihr Konto aufrufen und über die Benutzeroberfläche die neuesten System-Images abrufen. Damit Partner diesen langsamen und arbeitsintensiven Prozess vermeiden können, unterstützt Android 9 das automatische Herunterladen dieser Ressourcen von PAB, wenn die entsprechenden Anmeldedaten angegeben werden.

Zugriff einrichten

Beim programmatischen Zugriff werden OAuth2 in Google APIs für den Zugriff auf die erforderlichen RPCs verwendet. Der Partner muss mit dem Standardansatz zum Generieren von OAuth2-Anmeldedaten ein Client-ID/Secret-Paar bei Google einrichten. Wenn die PartnerAndroidBuildClient zum ersten Mal auf dieses Geheimnis verweist, wird ein Browserfenster geöffnet, in dem sich der Nutzer in seinem Google-Konto anmelden kann. Dadurch werden die für die weitere Ausführung erforderlichen OAuth2-Anmeldedaten generiert. Die Anmeldedaten (Zugriffstoken und Aktualisierungstoken) werden lokal gespeichert. Das bedeutet, dass 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, darunter:

  • build id, build target
  • Ressourcenname
  • Zweig
  • Name des Release-Kandidaten und ob es sich um einen internen Build handelt

Die POST-Anfrage wird von der Methode downloadBuildArtifact des RPCs buildsvc empfangen, der eine URL zurückgibt, mit der auf die Ressource zugegriffen werden kann.

  • Bei Clockwork Companion-APK-Ressourcen ist die URL eine lesbare URL, die auf PAB gehostet wird. Diese ist authentifiziert und kann mit den entsprechenden OAuth2-Anmeldedaten aufgerufen werden.
  • Bei anderen Ressourcen ist die URL eine lange, nicht geschützte URL aus der internen Android Build API, die nach fünf Minuten abläuft.

URL abrufen

Um Cross-Site-Request-Forgery zu vermeiden, muss für die buildsvc-RPC ein XSRF-Token mit den anderen Parametern gesendet werden. Dieses Token macht den Prozess sicherer, erschwert aber auch den programmatischen Zugriff, da das Token (das nur im JavaScript-Code der PAB-Seite verfügbar ist) jetzt auch für den Zugriff erforderlich ist.

Um dieses Problem zu vermeiden, wurde in Android 9 das URL-Benennungsschema für alle Dateien (nicht nur APKs) neu gestaltet, sodass für den Zugriff auf Artefaktlisten und Artefakt-URLs vorhersehbare URL-Namen verwendet werden. Die PAB verwendet jetzt ein praktisches URL-Format, mit dem Partner Ressourcen herunterladen können. HC-Scripts können diese APKs ganz einfach herunterladen, da das URL-Format bekannt ist. HC kann die XSRF-/Cookie-Probleme umgehen, da es die buildsvc RPC nicht benötigt.

Lokales Dateisystem

Wenn ein Verzeichnis mit einer Liste (oder ZIP-Datei) von Artefakten angegeben ist, legt der Buildanbieter die relevanten Bilder anhand des Inhalts des Verzeichnisses fest. Mit dem Tool gsutil können Sie Dateien aus Google Cloud Storage in ein lokales Verzeichnis kopieren.

Flash-Builds

Nachdem die neuesten Geräteimages auf den Host heruntergeladen wurden, müssen diese Images auf die Geräte geflasht werden. Dazu werden die Standardbefehle adb und fastboot sowie Python-Unterprozesse verwendet, die auf den von den Build-Anbietern gespeicherten temporären Dateipfaden basieren.

Unterstützte Aktionen:

  • Nur GSI flashen
  • Flashen einzelner Images über das Hauptsystem (z.B. fastboot flash boot boot.img)
  • Alle Images werden über das Hauptsystem geflasht. Beispiel:
    • fastboot flashall (mit dem integrierten Dienstprogramm flashall)
    • fastboot flash (einen nach dem anderen)

Tests ausführen

Unter Android 9 unterstützt die VTS-Infrastruktur für automatisierte Tests nur den TradeFed-Test-Harness. Sie kann jedoch in Zukunft um die Unterstützung anderer Harnesses erweitert werden.

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

  • Wenn Sie TradeFed lokal verwenden, verwenden Sie den Befehl test im Hostcontroller. Dieser nimmt den Namen eines VTS-Testplans (z. B. vts-selftest) an und führt den Test aus.
  • Wenn Sie einen TradeFed-Cluster verwenden, der optional mit MTT verbunden ist, verwenden Sie den Befehl lease in der Hostcontroller-Konsole, um nach nicht abgeschlossenen Tests zu suchen.

Wenn Sie TradeFedCluster verwenden, wird TradeFed lokal als Remote-Manager ausgeführt. Andernfalls werden die Tests über Python-Unterprozesse aufgerufen.

Ergebnisse melden

Testergebnisse werden von VtsMultiDeviceTest automatisch an einige VTS-Dashboard-Projekte gesendet.