Komplexe Testkonfiguration

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

  • andere apks installieren (zusätzlich zur test apk)
  • einige Dateien auf das Gerät übertragen
  • Befehle ausführen (zB adb shell pm ...)

In der Vergangenheit greifen Komponententeams normalerweise darauf zurück, einen Host-seitigen Test zu schreiben, um solche Aufgaben durchzuführen, was ein Verständnis des Trade Federation-Geschirrs erfordert und in der Regel 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 Ihr eigenes Ziel Vorbereiter, wie definiert durch Umsetzung ITargetPreparer oder ITargetCleaner , und konfigurieren Sie sie in Ihrer eigenen Testmodul Konfiguration verwendet werden .

Eine Testmodulkonfiguration für ein Testmodul ist eine erforderliche XML-Datei, die dem Quellordner des Moduls 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 behandelt werden, die Tags „target_preparer“ und „test“.

Zielvorbereiter

A „target_preparer“ tag, wie der Name schon sagt, definiert eine Zielvorbereiter (siehe ITargetPreparer ) , dass bietet ein Einrichtungsverfahren, das vor dem Testmodul für die Prüfung wird ausgeführt , aufgerufen wird; und wenn die Klasse in dem „target_preparer“ Tag verwies auch implementiert ITargetCleaner , wird seine Teardown - Methode aufgerufen werden , nachdem das Testmodul beendet wird.

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 „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>

Die Optionen konfigurieren den Testkabelbaum für:

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

In diesem speziellen Beispiel wird die Zugänglichkeit vor bzw. nach der Testmodulausführung aktiviert/deaktiviert. Anhand eines einfachen Beispiels, das demonstriert wird, ist es notwendig, mehr Details zur Verwendung des „option“-Tags zu behandeln. Wie oben gezeigt, kann das Tag zwei Attribute haben: Name, Wert. Das name-Attribut gibt den Namen der Option an und ist weiter in zwei Teile unterteilt, die durch einen Doppelpunkt getrennt sind: Kurzname des Erstellers und der vom Ersteller angebotene tatsächliche Optionsname.

Der genaue Zweck des Wertfeldes hängt davon ab, wie der Vorbereiter die Option definiert hat: Es kann ein String, eine Zahl, ein Boolean oder sogar ein Dateipfad usw. sein. Im obigen Beispiel bedeutet der Name „run-command:run-command“ dass wir einen Wert für die Option „run-command“ festlegen, die von einem Zielvorbereitungsprogramm mit dem Kurznamen „run-command“ definiert wurde; und der Name „run-command:teardown-command“ bedeutet, dass wir einen Wert für die Option „teardown-command“ setzen, die auch vom gleichen Zielvorbereitungsprogramm mit dem Kurznamen „run-command“ definiert wird. Hier ist eine Zusammenfassung der drei gängigen Zielvorbereiter:

  • Klassenname: PushFilePreparer

    • Kurzname: Push-Datei
    • Funktion: drückt beliebige Dateien unter Testfall Ordner in Ziel auf Gerät
    • Hinweise:
      • dieser Präparator 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: Eine Push-spec, 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 Ausgangsverzeichnis selbst sein.
      • ** post-Push: ** Ein Befehl auf dem Gerät (mit `laufen adb shell <your command> `) , nachdem alle Schübe versucht. Ein typischer Anwendungsfall wäre die Verwendung von chmod für Berechtigungen
  • Klassenname: InstallApkSetup

    • Kurzname: install-apk
    • Funktion: drückt beliebige apk Dateien unter in Ziel auf Gerät
    • Optionen:
      • Test-Datei-Name: der Name des apk auf Gerät installiert werden.
      • install-arg: Zusätzliche Argumente werden an die Uhr übergeben Befehl installieren, darunter führende Bindestrich, zB „-d“ wiederholt werden kann.
  • Klassenname: RunCommandTargetPreparer

    • Kurzname: run-Befehl
    • Funktion: Führt beliebige Shell - Befehle vor oder nach dem Prüfmodul Ausführungs
    • Optionen:
      • Run-Befehl: adb Shell - Befehl auszuführen. Kann wiederholt werden
      • Teardown-Befehl: adb Shell - Befehl während Teardown Phase auszuführen. 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 native Testpaket auf bestimmtes Gerät ausgeführt wird .
    • Optionen:
      • Native-Testgerät-Pfad: Der Pfad auf dem Gerät , auf die nativen Test befindet.
  • Klassenname: InstrumentationTest

    • Kurzname: Instrumentierung
    • Funktion: Ein Test, der auf ein bestimmtes Gerät Instrumentierung Testpaket läuft
    • Optionen:
      • Paket: Die Manifest Paketnamen der Android - Test Anwendung auszuführen.
      • Klasse: Der Name Testklasse zu laufen.
      • Methode: Die Testmethode Name auszuführen.
  • Klassenname: AndroidJUnitTest

    • Funktion: Ein Test, der auf das gegebene Vorrichtung android.support.test.runner.AndroidJUnitRunner dies mit einem Instrumententestpaket läuft , ist der wichtigste Weg einen Instrumentierungs Test auszuführen.