Komplexe Testkonfiguration

Für einige Testmodule sind möglicherweise benutzerdefinierte Einrichtungs- und Deaktivierungsschritte erforderlich, die nicht im Testfall selbst ausgeführt werden können. Beispiele:

  • andere APKs (zusätzlich zum Test-APK) installieren
  • einige Dateien auf das Gerät übertragen
  • Befehle ausführen (z. B. adb shell pm …)

In der Vergangenheit greifen Komponententeams in der Regel darauf zurück, einen Host-Side-Test zu schreiben, um solche Aufgaben auszuführen. Dies erfordert ein Verständnis der Nutzung der Handelsföderation und erhöht in der Regel die Komplexität eines Testmoduls.

Aus CTS haben wir das Konzept der Testmodulkonfiguration übernommen, um solche Aufgaben zu unterstützen. Die oben aufgeführten gängigen Aufgaben können mit nur wenigen Konfigurationszeilen erledigt werden. Für maximale Flexibilität können Sie sogar einen eigenen Zielvorbereitungs-Objekt-Typ implementieren, wie von ITargetPreparer oder ITargetCleaner definiert, und ihn für die Verwendung in Ihrer eigenen Testmodulkonfiguration konfigurieren.

Eine Testmodulkonfiguration für ein Testmodul ist eine erforderliche XML-Datei mit dem Namen "AndroidTest.xml", die dem obersten Modul-Quellordner hinzugefügt wird. Die XML-Datei entspricht dem Format einer Konfigurationsdatei, die vom Trade Federation-Testautomatisierungs-Harness verwendet wird. Derzeit sind die Haupt-Tags, die über die Konfigurationen des Testmoduls verarbeitet werden, die Tags „target_preparer“ und „test“.

Zielvorbereitung

Ein „target_preparer“-Tag definiert, wie der Name schon sagt, einen Zielvorbereiter (siehe ITargetPreparer), der eine Einrichtungsmethode bietet, die aufgerufen wird, bevor das Testmodul zum Testen ausgeführt wird. Wenn die im „target_preparer“-Tag referenzierte Klasse auch ITargetCleaner implementiert, wird ihre Deaktivierungsmethode nach Abschluss des Testmoduls aufgerufen.

Wenn Sie die integrierte gemeinsame Modulkonfiguration verwenden möchten, fügen Sie im übergeordneten Ordner Ihres Testmoduls eine neue Datei „AndroidTest.xml“ hinzu und füllen Sie sie mit dem folgenden Inhalt aus:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

Beispielsweise können wir die folgenden Options-Tags hinzufügen (im Kommentar „insert“ oben):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

Mit den Optionen wird die Testumgebung für Folgendes konfiguriert:

  1. Bevor das Testmodul aufgerufen wird, auf dem Gerät den Shell-Befehl „settings put secure accessibility_enabled 1“ ausführen
  2. Führen Sie nach Abschluss des Testmoduls den Shell-Befehl „settings put secure accessibility_enabled 0“ aus.

In diesem Beispiel wird die Barrierefreiheit vor bzw. nach der Ausführung des Testmoduls aktiviert bzw. deaktiviert. Nachdem wir ein einfaches Beispiel gezeigt haben, müssen wir uns nun genauer mit der Verwendung des „option“-Tags befassen. Wie oben gezeigt, kann das Tag zwei Attribute haben: „name“ und „value“. Das Attribut „name“ muss sich auf eine der vom Ersteller angebotenen Optionen beziehen.

Der genaue Zweck des Wertfelds hängt davon ab, wie der Bereitsteller die Option definiert hat. Das Feld kann ein String, eine Zahl, ein boolescher Wert oder sogar ein Dateipfad sein. Hier eine Zusammenfassung der drei gängigen Zielvorbereitungstools:

  • class name: PushFilePreparer

    • Kurzname: push-file
    • Funktion: verschiebt beliebige Dateien im Ordner des Testlaufs in das Ziel auf dem Gerät
    • notes:
      • Dieser Converter kann von Ordner zu Ordner oder von Datei zu Datei übertragen. Das bedeutet, dass Sie eine Datei nicht in einen Ordner auf dem Gerät übertragen können: Sie müssen auch den Zieldateinamen unter diesem Ordner angeben.
    • options:
      • push-file:Eine Push-Spezifikation, die die lokale Datei für den Pfad angibt, unter dem sie auf das Gerät gepusht werden soll. Kann wiederholt werden. Wenn mehrere Dateien so konfiguriert sind, dass sie an denselben Remotepfad gepusht werden, wird die neueste Datei gepusht.
      • push:(veraltet) Eine Push-Spezifikation, formatiert als /path/to/srcfile.txt->/path/to/destfile.txt oder /path/to/srcfile.txt->/path/to/destdir/. Kann wiederholt werden. Dieser Pfad kann relativ zum Verzeichnis des Testmoduls oder zum Verzeichnis „out“ selbst sein.
      • post-push:Ein Befehl, der auf dem Gerät (mit adb shell <your command>) ausgeführt wird, nachdem alle Push-Vorgänge versucht wurden. Ein typischer Anwendungsfall ist die Verwendung von chmod für Berechtigungen

  • Klassenname: InstallApkSetup

    • Kurzname:install-apk
    • function:sendet beliebige APK-Dateien an das Ziel auf dem Gerät
    • Optionen:
      • test-file-name: der Name der APK-Datei, die auf dem Gerät installiert werden soll.
      • install-arg:Zusätzliche Argumente, die an den Befehl „pm install“ übergeben werden, einschließlich Bindestrich am Anfang, z.B. „-d“. Kann wiederholt werden

  • Klassenname: RunCommandTargetPreparer

    • Kurzname:run-command
    • function:Führt beliebige Shell-Befehle vor oder nach der Ausführung des Testmoduls aus.
    • Optionen:
      • run-command:Zu ausführender adb-Shell-Befehl. Kann wiederholt werden
      • teardown-command:adb-Shell-Befehl, der während der Deaktivierungsphase ausgeführt werden soll. Kann wiederholt werden

Testklasse

Eine Testklasse ist die Handelsföderationsklasse, die zum Ausführen des Tests verwendet wird.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Hier sind drei gängige Testklassen:

  • class name: GTest

    • Kurzname:gtest
    • function:Ein Test, bei dem ein natives Testpaket auf einem bestimmten Gerät ausgeführt wird.
    • options:
      • native-test-device-path:Der Pfad auf dem Gerät, unter dem sich native Tests befinden.

  • class name: InstrumentationTest

    • Kurzname:instrumentation
    • Funktion:Ein Test, der ein Instrumentierungstestpaket auf einem bestimmten Gerät ausführt
    • Optionen:
      • package:Der Manifest-Paketname der auszuführenden Android-Testanwendung.
      • class:Der Name der Testklasse, die ausgeführt werden soll.
      • method:Der Name der Testmethode, die ausgeführt werden soll.

  • Klassenname: AndroidJUnitTest

    • function:Ein Test, bei dem ein Instrumentierungstestpaket mit dem android.support.test.runner.AndroidJUnitRunner auf einem bestimmten Gerät ausgeführt wird. Dies ist die Hauptmethode zum Ausführen eines Instrumentierungstests.