Komplexe Testkonfiguration

Einige Testmodule erfordern möglicherweise angepasste Einrichtungs- und Abbauschritte, die nicht im Testfall selbst ausgeführt werden können. Typische Beispiele können sein:

  • Installieren Sie andere APKs (zusätzlich zur Test-APK).
  • Schieben Sie einige Dateien auf das Gerät
  • Befehle ausführen (z. B. ADB Shell PM ...)

In der Vergangenheit griffen Komponententeams zur Durchführung solcher Aufgaben meist auf das Schreiben eines Tests auf der Hostseite zurück, was Kenntnisse über die Funktionsweise der Trade Federation erforderte und in der Regel die Komplexität eines Testmoduls erhöhte.

In Anlehnung an CTS haben wir das Konzept der Testmodulkonfiguration eingeführt, um solche Aufgaben zu unterstützen. Die oben aufgeführte allgemeine Aufgabenliste kann mit nur wenigen Konfigurationszeilen erreicht werden. Für maximale Flexibilität können Sie sogar Ihren eigenen Zielvorbereiter implementieren, wie durch 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, die dem Modulquellordner der obersten Ebene mit dem Namen „AndroidTest.xml“ hinzugefügt wird. Das XML folgt dem Format einer Konfigurationsdatei, die vom Testautomatisierungs-Harness der Trade Federation verwendet wird. Derzeit sind die wichtigsten Tags, die über die Testmodulkonfigurationen verwaltet werden, die Tags „target_preparer“ und „test“.

Zielvorbereiter

Ein „target_preparer“-Tag definiert, wie der Name schon sagt, einen Zielvorbereiter (siehe ITargetPreparer ), der eine Setup-Methode bietet, die aufgerufen wird, bevor das Testmodul zum Testen ausgeführt wird; und wenn die im Tag „target_preparer“ referenzierte Klasse auch ITargetCleaner implementiert, wird ihre Teardown-Methode aufgerufen, nachdem das Testmodul abgeschlossen ist.

Um die integrierte allgemeine Modulkonfiguration zu verwenden, fügen Sie im obersten Ordner Ihres Testmoduls eine neue Datei „AndroidTest.xml“ hinzu und füllen Sie sie mit dem folgenden Inhalt:

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

Als Beispiel können wir die folgenden Options-Tags hinzufügen (beim „Einfügen“-Kommentar 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 wie folgt konfiguriert:

  1. Bevor das Testmodul aufgerufen wird, führen Sie den Shell-Befehl „settings put secure accessibility_enabled 1“ auf dem Gerät aus
  2. Nachdem das Testmodul abgeschlossen ist, führen Sie den Shell-Befehl „settings put secure accessibility_enabled 0“ aus.

In diesem speziellen Beispiel wird die Barrierefreiheit vor bzw. nach der Ausführung des Testmoduls aktiviert/deaktiviert. Anhand eines einfachen Beispiels ist es notwendig, weitere Details zur Verwendung des „Option“-Tags zu erläutern. Wie oben gezeigt, kann das Tag zwei Attribute haben: Name, Wert. Das Namensattribut muss sich auf eine der vom Ersteller angebotenen Optionen beziehen.

Der genaue Zweck des Wertfelds hängt davon ab, wie der Ersteller die Option definiert hat: Es kann sich um eine Zeichenfolge, eine Zahl, einen booleschen Wert oder sogar einen Dateipfad handeln. Hier ist eine Zusammenfassung der drei gängigen Zielvorbereiter:

  • Klassenname: PushFilePreparer

    • Kurzname : Push-Datei
    • Funktion : Schiebt beliebige Dateien im Testfallordner in das Ziel auf dem Gerät
    • Anmerkungen :
      • Dieser Vorbereiter kann von Ordner zu Ordner oder von Datei zu Datei pushen. Das heißt, Sie können eine Datei nicht in einen Ordner auf dem Gerät verschieben: Sie müssen auch den Zieldateinamen unter diesem Ordner angeben
    • Optionen :
      • Push-Datei: Eine Push-Spezifikation, die die lokale Datei an den Pfad angibt, in den sie auf dem Gerät gepusht werden soll. Kann wiederholt werden. Wenn mehrere Dateien so konfiguriert sind, dass sie auf denselben Remote-Pfad 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 Testmodulverzeichnis oder zum Out-Verzeichnis selbst sein.
      • Post-Push: Ein Befehl, der auf dem Gerät ausgeführt wird (mit „ adb shell <your command> “), nachdem alle Push-Versuche versucht wurden. Ein typischer Anwendungsfall wäre die Verwendung von chmod für Berechtigungen
  • Klassenname: InstallApkSetup

    • Kurzname: install-apk
    • Funktion: Schiebt beliebige APK-Dateien in das Ziel auf dem Gerät
    • Optionen:
      • Testdateiname: Der Name der APK, die auf dem Gerät installiert werden soll.
      • install-arg: Zusätzliche Argumente, die an den Befehl „pm install“ übergeben werden sollen, einschließlich führender Bindestriche, z. B. „-d“. Kann wiederholt werden
  • Klassenname: RunCommandTargetPreparer

    • Kurzname: run-command
    • Funktion: Führt beliebige Shell-Befehle vor oder nach der Ausführung des Testmoduls aus
    • Optionen:
      • run-command: ADB-Shell-Befehl zum Ausführen. Kann wiederholt werden
      • Teardown-Befehl: ADB-Shell-Befehl zur Ausführung während der Teardown-Phase. Kann wiederholt werden

Testklasse

Eine Testklasse ist die Trade Federation-Klasse, 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:

  • Klassenname: GTest

    • Kurzname: gtest
    • Funktion: Ein Test, der ein natives Testpaket auf einem bestimmten Gerät ausführt.
    • Optionen:
      • native-test-device-path: Der Pfad auf dem Gerät, auf dem sich native Tests befinden.
  • Klassenname: InstrumentationTest

    • Kurzname: Instrumentierung
    • Funktion: Ein Test, der ein Instrumentierungstestpaket auf einem bestimmten Gerät ausführt
    • Optionen:
      • Paket: Der Manifest-Paketname der auszuführenden Android-Testanwendung.
      • Klasse: Der Name der auszuführenden Testklasse.
      • Methode: Der Name der auszuführenden Testmethode.
  • Klassenname: AndroidJUnitTest

    • Funktion: Ein Test, der ein Instrumentierungstestpaket auf einem bestimmten Gerät mithilfe von android.support.test.runner.AndroidJUnitRunner ausführt. Dies ist die Hauptmethode zum Ausführen eines Instrumentierungstests.