Testen der Gerätebereitstellung

Für Geräte mit Android 6 oder Android 7 können Sie die Gerätebereitstellung mit dem Android Enterprise (AE) Test Harness testen, einer Testsuite zur Überprüfung der Unternehmenskompatibilität von Android-Geräten. Das Harness umfasst Support-Apps, Testfälle, Konfigurationsdateien und einen Test-Runner ( afw-test-tradefed ), der auf cts-tradefed . Stellen Sie vor dem Einrichten des AE Test Harness sicher, dass Sie die Bereitstellung für die Geräteverwaltung abgeschlossen haben.

Für Geräte mit Android 8 oder höher ist die Verwendung des AE Test Harness veraltet .

Aufbau einer Entwicklungsumgebung

Die Entwicklungsumgebung für den AE Test Harness ähnelt dem Android-Betriebssystem. Befolgen Sie die Schritte unter Voraussetzungen , um einen Entwicklungscomputer einzurichten.

Quellcode herunterladen

Laden Sie den AE Test Harness-Quellcode herunter, indem Sie die Schritte unter Herunterladen der Quelle befolgen . Der Quellcode von AE Test Harness befindet sich im Projekt ./test/AfwTestHarness . Der Zweigname bestimmt die herunterzuladende Version von AE Test Harness (jede Android-Plattform hat eine separate Version von AE Test Harness). Beispielsweise lautet der Zweigname für Android 7.0 Nougat afw-test-harness-nougat-dev . Verwenden Sie die folgenden Befehle, um das Repository zu initialisieren und den Quellcode für diesen Zweig herunterzuladen:

mkdir WORKING_DIRECTORY
cd WORKING_DIRECTORY
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
repo init -u https://android.googlesource.com/platform/manifest -b afw-test-harness-nougat-dev
repo sync -j24

Um den Quellcode für eine andere Version auszuchecken, geben Sie den Zweig mit dem entsprechenden Tag an. Zu den verfügbaren Zweigen gehören:

Zweigname Unterstützte Android-Plattform
afw-test-harness-nougat-dev Android 7.0
afw-test-harness-2.1 Android 7.0
afw-test-harness-marshmallow-dev Android 6.0
afw-test-harness-1.5 Android 6.0

Andere Abhängigkeitsprojekte, die zum Erstellen des Kabelbaums erforderlich sind, werden ebenfalls mit dem Quellcode heruntergeladen.

Anzeige in Android Studio

So zeigen Sie den Quellcode in Android Studio an und bearbeiten ihn:

  1. Führen Sie die folgenden Befehle
    make idegen
    development/tools/idegen/idegen.sh
    
  2. Öffnen Sie in Android Studio android.ipr .

Der Quellcode von AE Test Harness befindet sich in test/AfwTestHarness .

Konfigurieren des AE-Test-Harness

Sie können den Kabelbaum anpassen, indem Sie test/AfwTestHarness/afw-test.props . Führen Sie die folgenden Schritte aus, um den Kabelbaum erfolgreich auszuführen:

  1. Konfigurieren Sie das Wi-Fi-Netzwerk in afw-test.props mit den folgenden Eigenschaften:
    wifi_ssid
    wifi_password (optional)
    wifi_security_type (optional, available options are: NONE, WEP or WPA)
    
  2. Rufen Sie mindestens ein Konto von einer Domäne ab, die an Test DPC als Device Policy Controller gebunden ist. Geben Sie die Details in afw-test.props mit den folgenden Eigenschaften an:
    work_account_username
    work_account_password
    

    Der AE-Testharness verwendet Test-DPC, um Bereitstellungsabläufe zu testen, sodass Konten an Test-DPC gebunden werden müssen , um den Testharness auszuführen.

Aufbau des AE Test Harness

Initialisieren Sie die Build-Konfiguration mit:

source build/envsetup.sh
lunch

Wählen Sie einen Gerätetyp aus und drücken Sie die Eingabetaste .

Bauen Sie den Kabelbaum mit:

make afw-test-harness -j32

Dadurch wird ein Verzeichnis ( out/host/linux-x86/afw-th/android-cts ) mit allen erforderlichen Binärdateien, Konfigurationsdateien und Tools zum Ausführen der Testumgebung erstellt. Dieses Verzeichnis wird außerdem zur Verteilung in eine Datei ( out/host/linux-x86/afw-th/android-afw-test-harness.zip ) gezippt.

Ausführen des AE-Testgeschirrs

Verwenden Sie die folgenden Schritte, um den AE Test Harness auszuführen:

  1. Starten Sie in Ihrer Build-Umgebung den Test Runner mit:
    afw-test-tradefed
    
    Dies startet die cts-tf Konsole, lädt Testpläne, Testfälle und afw-test.props von out/host/linux-x86/afw-th/android-cts .
  2. Starten Sie den Test Runner aus dem entpackten Ordner android-afw-test-harness.zip mit:
    cts-tf> ./android‐cts/tools/afw-test‐tradefed
    
    Dadurch werden Testpläne, Testfälle und afw-test.props aus dem Verzeichnis android-cts geladen. Stellen Sie sicher ./android‐cts/repository/testcases/afw-test.props über das Arbeitskonto und die Wi-Fi-Konfiguration verfügt.
  3. Führen Sie einen Testplan aus. Jeder Testplan ist eine XML-Datei, die eine Reihe von Testpaketen aus dem AfwTestHarness/tests enthält. Zu den gängigen Plänen gehören:
    • afw-userdebug-build . Enthält alle Testpakete, die einen Userdebug-Build erfordern.
    • afw-user-build . Wird auf einem Benutzer-Build ausgeführt, erfordert jedoch, dass das Testgerät ordnungsgemäß eingerichtet wird, einschließlich Abschluss der Ersteinrichtung und Aktivierung des USB-Debugging.

    Um den afw-userdebug-build , verwenden Sie:
    cts-tf> run cts --plan afw-userdebug-build
    
    Um alle Testpläne anzuzeigen, verwenden Sie den Befehl list plans . Plandefinitionen finden Sie unter out/host/linux-x86/afw-th/android-cts/repository/plans .
  4. Führen Sie ein Testpaket aus. Um ein einzelnes Testpaket auszuführen, verwenden
    cts-tf> run cts --package com.android.afwtest.NfcProvisioning
    
    . Um alle Pakete anzuzeigen, verwenden Sie den Befehl list packages . Verwenden Sie für weitere Optionen den Befehl run cts --help .

Debuggen des AE Test Harness

Führen Sie alle Befehle in der afw-test-tradefed-Konsole ( cts-tf ) aus, die Sie durch Ausführen von afw-test-tradefed .

  • Zeigen Sie weitere Informationen mit den Flags -l INFO oder -l DEBUG an. Beispiel:
    cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG
    
  • Führen Sie die Testumgebung auf einem bestimmten Gerät mit dem Flag -s aus. Beispiel:
    cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG -s device_sn
    
  • Führen Sie den Testharness auf allen verbundenen Geräten mit dem --all-devices . Beispiel:
    cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG --all-devices
    
  • Zeigen Sie aktuelle ausgeführte Ausführungen mit list invocations oder li an.
  • Zeigen Sie eine Zusammenfassung vergangener Testausführungen mithilfe von list results oder lr an.
  • Zeigen Sie andere list mithilfe von help list .
  • Überwachen Sie Logcat in Echtzeit mit Filter mit afwtest , öffnen Sie dann ein anderes Terminal und starten Sie Logcat mit: adb logcat | grep afwtest . Nach Abschluss eines Tests:
    • Protokolle in out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time . Das vollständige Geräte-Logcat und das Host-Log ( afw-test-tradefed Logs) werden in separaten ZIP-Dateien gespeichert.
    • Finden Sie relevante Informationen, indem Sie im Geräte-Logcat nach afwtest suchen . Beispiel: zless out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time /device_logcat_ random-number .zip | grep afwtest
    • Um das vollständige afw-test-tradefed-Protokoll anzuzeigen, verwenden Sie: zless out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time /host_log_ random-number .zip
  • Ein Testpaket automatisiert einen Enterprise-Provisioning-Flow, indem es UI-Seiten durchläuft und für jede Seite ein Navigationsprotokoll in der Logcat-Datei des Geräts aufzeichnet. Beispiel: afwtest.AutomationDriver: Navigating:com.android.afwtest.uiautomator.pages.gms.AddAccountPage
    UI-Seiten für das com.android.afwtest.NfcProvisioning beinhalten:
    • com.android.afwtest.uiautomator.pages.managedprovisioning.NfcProvisioningPage
    • com.android.afwtest.uiautomator.pages.PageSkipper
    • com.android.afwtest.uiautomator.pages.LandingPage
  • Wenn ein Test während des Bereitstellungsprozesses fehlschlägt, enthält logcat einen Fehler ähnlich dem folgenden:
    TestRunner: java.lang.RuntimeException: Failed to load page: com.android.afwtest.uiautomator.pages.packageinstaller.DeviceAccessPage
    
    Dies wird normalerweise durch Fehler auf einer vorherigen UI-Seite oder der Seite verursacht, die nicht geladen werden konnte. Versuchen Sie also, andere Fehlermeldungen in logcat vor diesem Fehler zu finden , und versuchen Sie dann, es nach dem Bereitstellungsablauf manuell zu reproduzieren.
  • Wenn ein Testpaket fehlschlägt:
    • Ein Screenshot wird unter out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time mit der folgenden Syntax gespeichert: screenshot-test_ test_class_full_name _ test_case_name - random_number .png . Diese Informationen werden auch im Hostprotokoll protokolliert.
    • Ein Fehlerbericht wird unter out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time gespeichert als: bug- bug- test_class_full_name _ test_case_name - random_number .zip .
  • Nachdem alle Testpakete ausgeführt wurden, wird ein Screenshot erstellt und unter out/host/linux-x86/afw-th/android-cts/repository/logs/ start-time gespeichert als: screenshot- screenshot- random_number .png . Diese Informationen werden auch im Hostprotokoll protokolliert.

FAQ

Kann ich afw-userdebug-build auf einem Gerät ausführen, das mit User Build geflasht wurde?

Nein. Testpakete im afw-userdebug-build Plan setzen das Testgerät auf die Werkseinstellungen zurück, bevor der eigentliche Testablauf ausgeführt wird, und erfordern, dass das adb -Debugging automatisch aktiviert wird. Bei einem Benutzer-Build kann das adb Debugging nur aktiviert werden, indem die Einstellung in den Entwickleroptionen manuell geändert wird.

Kann ich afw-user-build auf einem Gerät ausführen, das mit userdebug build geflasht wurde?

Ja, aber wir empfehlen, dass Sie diesen Testplan auf einem Benutzerbuild ausführen.

Manchmal schlägt mein Test fehl, weil das Laden der Benutzeroberfläche zu lange dauert. Wie kann ich das beheben?

Konfigurieren Sie die Einstellung timeout_size in ./android-cts/repository/testcases/afw-test.props . Gültige Einstellungen sind: S, M, L, XL, XXL.

Das com.android.afwtest.NfcProvisioning (oder SuwDoProvisioning ) schlägt auf meinem Gerät fehl, da die installierte Ersteinrichtung nach Abschluss der Bereitstellung eine angepasste Benutzeroberfläche (z. B. Nutzungsbedingungen) anzeigt. Wie kann ich diese angepasste Benutzeroberfläche überspringen?

Nach dem Bereitstellungsprozess sollte nur eine minimale Benutzeroberfläche vorhanden sein. Die Testumgebung überspringt automatisch eine solche Benutzeroberfläche, wenn die Benutzeroberfläche über eine Schaltfläche mit aussagekräftigem Text oder einer Inhaltsbeschreibung verfügt, die eines der folgenden Wörter enthält: Überspringen, Beenden, Fertig, Akzeptieren, Zustimmen, Weiter, Fortfahren oder Fortfahren. Alternativ können Sie eine Schaltfläche in afw-test.props definieren, um die Testumgebung so zu konfigurieren, dass Ihre Benutzeroberfläche übersprungen wird. Beispiel:

oem_widgets=your_btn
your_btn.text=your_customized_text
your_btn.package=your_package
your_btn.action=click

Um mehrere Widgets zu definieren, trennen Sie sie durch Kommas.

Das com.android.afwtest.NfcProvisioning (oder SuwDoProvisioning ) ist fehlgeschlagen und der letzte UI-Bildschirm lautet „Verify your account“. Warum passiert das und wie kann ich das Testgerät wiederherstellen?

Dieser Fehler tritt auf, weil das vorherige Testpaket den Factory Reset Protection am Ende des Tests nicht löschen konnte. Sie müssen das Konto manuell eingeben, um das Gerät zu entsperren.

Mein Gerät braucht mehr Zeit zum Zurücksetzen auf die Werkseinstellungen. Kann ich das Timeout für das Zurücksetzen auf die Werkseinstellungen verlängern?

Ja. Konfigurieren Sie die Einstellung factory_reset_timeout_min in afw-test.props . Gültige Einstellungen sind Minuten; Sie können eine beliebige Anzahl von Minuten einstellen, die mit Ihrem Gerät funktioniert.