Komplexe Testkonfiguration

Einige Testmodule erfordern möglicherweise benutzerdefinierte Einrichtungs- und Abbauschritte, die nicht innerhalb des Testfalls selbst durchgeführt werden können. Typische Beispiele können sein:

  • Andere APKs installieren (zusätzlich zur Test-APK)
  • Push einige Dateien auf das Gerät
  • Befehle ausführen (z. B. adb shell pm ...)

In der Vergangenheit griffen Komponententeams normalerweise darauf zurück, einen hostseitigen Test zu schreiben, um solche Aufgaben auszuführen, was ein Verständnis der Trade Federation-Harness erfordert und normalerweise die Komplexität eines Testmoduls erhöht .

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 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, die dem Modulquellordner der obersten Ebene mit dem Namen „AndroidTest.xml“ hinzugefügt wird. Das XML folgt dem Format einer Konfigurationsdatei, die von Trade Federation Test Automation Harness verwendet wird. Derzeit sind die wichtigsten Tags, die über die Testmodulkonfigurationen verarbeitet werden, die Tags „target_preparer“ und „test“.

Zielvorbereiter

Ein „target_preparer“-Tag definiert, wie der Name schon sagt, einen Target-Preparer (siehe ITargetPreparer ), der eine Setup-Methode anbietet, die aufgerufen wird, bevor das Testmodul zum Testen ausgeführt wird; und wenn die Klasse, auf die im „target_preparer“-Tag verwiesen wird, auch ITargetCleaner implementiert, wird ihre Teardown-Methode aufgerufen, nachdem das Testmodul beendet wurde.

Um die integrierte allgemeine Modulkonfiguration zu verwenden, fügen Sie eine neue Datei „AndroidTest.xml“ im Ordner der obersten Ebene für Ihr Testmodul 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 Kommentar „Einfügen“ 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>

Die Optionen konfigurieren den Testrahmen wie folgt:

  1. Führen Sie vor dem Aufrufen des Testmoduls den Shell-Befehl „settings put secureaccessibility_enabled 1“ auf dem Gerät aus
  2. Führen Sie nach Abschluss des Testmoduls den Shell-Befehl „settings put secureaccessibility_enabled 0“ aus.

In diesem speziellen Beispiel wird die Zugänglichkeit vor bzw. nach der Ausführung des Testmoduls aktiviert/deaktiviert. Mit einem einfachen Beispiel, das demonstriert wird, ist es notwendig, mehr Details darüber zu behandeln, wie das „option“-Tag verwendet wird. 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 Wertefelds hängt davon ab, wie der Ersteller die Option definiert hat: Es kann eine Zeichenfolge, eine Zahl, ein boolescher Wert oder sogar ein Dateipfad sein. 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 Ersteller kann von Ordner zu Ordner oder von Datei zu Datei schieben; 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 in dem Pfad angibt, in den sie auf das Gerät übertragen werden soll. Darf wiederholt werden. Wenn mehrere Dateien so konfiguriert sind, dass sie an denselben Remote-Pfad gepusht werden, wird die neueste gepusht.
      • push: (veraltet) Eine Push-Spezifikation, formatiert als ' /path/to/srcfile.txt->/path/to/destfile.txt ' oder ' /path/to/srcfile.txt->/path/to/destdir/ '. Darf wiederholt werden. Dieser Pfad kann relativ zum Testmodulverzeichnis oder zum Ausgangsverzeichnis selbst sein.
      • post-push: Ein Befehl, der auf dem Gerät ausgeführt werden soll (mit ` adb shell <your command> `), nachdem alle Pushs 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:
      • test-file-name: der Name der apk, die auf dem Gerät installiert werden soll.
      • install-arg: Zusätzliche Argumente, die an das pm install-Kommando übergeben werden, einschließlich führendem Bindestrich, z. B. „-d“. Darf wiederholt werden

  • Klassenname: RunCommandTargetPreparer

    • Kurzname: Run-Befehl
    • Funktion: Führt beliebige Shell-Befehle vor oder nach der Ausführung des Testmoduls aus
    • Optionen:
      • run-command: ADB-Shell-Befehl zum Ausführen. Darf wiederholt werden
      • Teardown-Befehl: ADB-Shell-Befehl, der während der Teardown-Phase ausgeführt wird. Darf 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, in dem sich native Tests befinden.

  • Klassenname: InstrumentationTest

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

  • Klassenname: AndroidJUnitTest

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