Komplexe Testkonfiguration

Für einige Testmodule sind möglicherweise benutzerdefinierte Einrichtungs- und Abbauvorgänge erforderlich, die nicht im Testlauf 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 haben Komponententeams in der Regel einen Host-seitigen Test geschrieben, um solche Aufgaben auszuführen. Dazu ist ein Verständnis des Trade Federation-Frameworks erforderlich, was die Komplexität eines Testmoduls in der Regel erhöht.

Wir haben das Konzept der Testmodulkonfiguration aus dem CTS übernommen, um solche Aufgaben zu unterstützen. Die oben aufgeführten allgemeinen Aufgaben können mit nur wenigen Konfigurationszeilen erreicht werden. Für maximale Flexibilität können Sie sogar einen eigenen Target-Preparer implementieren, wie er von ITargetPreparer oder ITargetCleaner definiert wird, und ihn für die Verwendung in Ihrer eigenen Testmodulkonfiguration konfigurieren.

Eine Testmodulkonfiguration für ein Testmodul ist eine erforderliche XML-Datei, die dem Quellordner des Moduls auf oberster Ebene hinzugefügt wird und den Namen „AndroidTest.xml“ hat. Das XML-Format entspricht dem einer Konfigurationsdatei, die von der Trade Federation-Testautomatisierungsplattform verwendet wird. Derzeit werden die Haupt-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 Zielvorbereiter (siehe ITargetPreparer), der eine Einrichtungsmethode bietet, die vor der Ausführung des Testmoduls zum Testen aufgerufen wird. Wenn die im „target_preparer“-Tag referenzierte Klasse auch ITargetCleaner implementiert, wird ihre Teardown-Methode nach Abschluss des Testmoduls aufgerufen.

Wenn Sie die integrierte Konfiguration des gemeinsamen Moduls verwenden möchten, 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>

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

    <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 Testharness so konfiguriert, dass:

  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 Beispiel wird die Barrierefreiheit vor bzw. nach der Ausführung des Testmoduls aktiviert bzw. deaktiviert. Nachdem ein einfaches Beispiel gezeigt wurde, müssen wir uns genauer ansehen, wie das „option“-Tag verwendet wird. Wie oben gezeigt, kann das Tag zwei Attribute haben: „name“ und „value“. Das Attribut „name“ muss sich auf eine der vom Zubereiter angebotenen Optionen beziehen.

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

  • Klassenname: PushFilePreparer

    • Kurzname: push-file
    • function: pushes arbitrary files under test case folder into destination on device
    • Hinweise:
      • Dieser Preparer kann Dateien von Ordner zu Ordner oder von Datei zu Datei übertragen. Das bedeutet, dass Sie keine Datei in einen Ordner auf dem Gerät übertragen können, sondern auch den Zieldateinamen in diesem Ordner angeben müssen.
    • options:
      • push-file:Eine Push-Spezifikation, die die lokale Datei für den Pfad angibt, in den sie auf dem Gerät übertragen werden soll. Kann wiederholt werden. Wenn mehrere Dateien so konfiguriert sind, dass sie an denselben Remote-Pfad übertragen werden, wird die letzte übertragen.
      • push:(deprecated) Eine Push-Spezifikation im Format „/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 Ausgabeverzeichnis 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 typisches Anwendungsbeispiel ist die Verwendung von „chmod“ für Berechtigungen.

  • Klassenname: InstallApkSetup

    • Kurzname:install-apk
    • Funktion:Überträgt beliebige APK-Dateien auf das Zielgerät.
    • options:
      • test-file-name:Der Name des APK, das auf dem Gerät installiert werden soll.
      • install-arg:Zusätzliche Argumente, die an den Befehl „pm install“ übergeben werden sollen, einschließlich des führenden Bindestrichs, 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.
    • options:
      • run-command:Der auszuführende „adb shell“-Befehl. Kann wiederholt werden
      • teardown-command:Der ADB-Shell-Befehl, der während der Bereinigungsphase ausgeführt werden soll. 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, bei dem ein natives Testpaket auf einem bestimmten Gerät ausgeführt wird.
    • options:
      • native-test-device-path:Der Pfad auf dem Gerät, in dem sich native Tests befinden.

  • Klassenname: InstrumentationTest

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

  • Klassenname: AndroidJUnitTest

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